2020-12-29

1.B/S架构和C/S架构区别

所谓的软件架构我们可以理解为是用来指导我们软件开发的一种思维，目前来说最常见的两种架构模式就是b/s c/s
b—browser 浏览器
C----clent 客户端
S----server 服务端
两种架构的比较
1，标准：相对于cs架构来说bs架构的两端都是在使用现成的成熟产品。所以bs会显示的标准一些。
2，效率：相对bs架构来说cs中的客户端可以分担一些数据的处理，因此执行效率会高一些
3，安全：bs架构当中得到数据传输都是以HTTP协议进行的输出，而HTTP协议又是明文输出。可以被抓包，所以相对于cs架构来说bs就显得不那么安全（相对的）
4，升级：bs架构只需要在服务器端将数据进地更新，前台只需要刷新页面就可以完成升级，而cs架构当中必须要将两端都进行更新
5，开发成本：相对于bs架构来说cs当中的客户端需要自己开发，所以相对于来说成本会高一些
B/S 只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢C/S响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统,需要针对性的开发,并且维护成本高

2.HTTP协议

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。
http状态代码的第一个数字代表当前响应的类型：
1xx消息——请求已被服务器接收，继续处理
2xx成功——请求已成功被服务器接收、理解、并接受
3xx重定向——需要后续操作才能完成这一请求
4xx请求错误——请求含有词法错误或者无法被执行
5xx服务器错误——服务器在处理某个正确请求时发生错误

3.POST与GET区别

1.GET使用URL或Cookie传参。而POST将数据放在BODY中。
2.GET的URL会有长度上的限制，2kb，则POST的数据则可以非常大。
3.POST比GET安全，因为数据在地址栏上不可见。
4.一般get请求用来获取数据，post请求用来发送数据。

4.Cookie和Session的区别与联系

cookie不是很安全相对于session 安全性考虑使用session
考虑性能方面减轻服务器压力使用cookie

cookie与session的联系：
当服务器端生成一个session时就会向客户端发送一个cookie保存在客户端
这个cookie保存的是session的sessionId
这样才能保证客户端发起请求后，
客户端已经登录的用户能够与服务器端成千上万的session中准确匹配到已经保存了该用户信息的session，
同时也能够确保不同页面之间传值时的正确匹配。

5.测试的目的

简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正

6.软件测试原则

1.测试表明项目目前存在的缺陷
2.不可能进行详尽的测试
3.早期测试
4.缺陷聚类
5.杀虫剂悖论
6.基本测试上依赖于上下文
7.无错误谬论

7.软件测试分为哪几个阶段？

单元测试、集成测试、系统测试、验收测试。

8.单元测试与集成测试的侧重点

单元测试
是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。
集成测试
也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。
系统测试
是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。

9.系统测试范围

功能测试、ui测试、性能测试、容错测试、可用性测试、异常问题测试、稳定性测试、系统稳定性测试、兼容性测试、接口测试、安全性测试、登录权限测试

10.a测试与ß测试的区别

а测试 软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。

ß测试 软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。

11.验收测试怎么做？

1.界面测试；指软件产品所有的页面浏览时功能按钮或者界面是否能正常显示。
2.功能测试；产品的功能是否都能正常实现。
3.性能测试；发现性能瓶颈的过程，包括对CPU、内存、网络环境、版本等多项测试内容。
4.安全测试；产品的信息保密，密码保护等功能的测试。

12.白盒、黑盒和灰盒测试区别

白箱测试或白盒测试： 是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。

黑箱测试或黑盒测试： 是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。

灰箱测试或灰盒测试: 灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。

13.冒烟测试的目的

为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。

14.回归测试怎么做

1.在测试策略制定阶段，制定回归测试策略
2.确定需要回归测试的版本
3.回归测试版本发布,按照回归测试策略执行回归测试
4.回归测试通过，关闭缺陷跟踪单（问题单）
5.回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

15.全部回归与部分回归的区别

16.需求分析的目的

第一、把用户需求转化为功能需求：1）对测试范围进度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确。
第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。

17.测试计划的目的

1.尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。
2.所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。
3.测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。

18.什么时候开始写测试计划

测试计划时在需求整理完成，和开发计划一起制定的一份计划书，它属于项目计划中其中的一个计划

19.由谁来编写测试计划

项目经理（从项目角度考虑）
测试经理（从测试组角度考虑）
测试人员（编写具体测试计划）

20.测试计划的内容

1.测试目标：对测试目标进行简要的描述。
2.测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
3.测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
4.重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
5.质量目标：制定测试软件的产品质量目标和软件测试目标。
6.资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
7.人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
8.测试策略：制定测试整体策略、所使用的测试技术和方法。
9.发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
10.测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。
11.测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。
12.风险分析：需要考虑测试计划中可能的风险和解决方法。

21.结束条件(项目上线的条件)

1、软件经过充分的测试
开发人员测试—〉交叉测试—〉测试人员测试—〉用户的业务专家测试—〉一定数量的用户业务专家集中测试—〉上线前试运行----〉上线。
压力测试是必须的
2、用户培训
管理员，一定厂或地区必须有一个人经过了培训。
3、基础数据导入完成
用户、组织机构、业务数据等基础必须数据导入完成。
4、授权必须完成
5、新老系统的切换必须提前演练过，各种老数据的导入工作完成。
6、应急方案必须有。

22.常见的测试风险

1.需求风险
2.测试用例风险
3.缺陷风险
4.代码质量风险
5.测试环境风险
6.测试技术风险
7.回归测试风险
8.沟通协调风险
9.研发流程风险
10.其他不可预计风险

23.测试用例的要素

1.用例编号
2.测试模块
3.用例的标题
4.测试级别
5.测试目的和条件
6.测试输入
7.操作步骤
8.预期结果

24.测试用例级别的划分

测试用例优先级的目的：测试用例优先级可以用来方便地基于测试策略来筛选用例。比如某块功能改动小，就只用测高或中高优先级的用例。 比如冒烟测试的时候我们只需要筛选优先级最高的用例执行即可。

根据我们测试用例优先级目的：那么优先级越高的测试用例覆盖的测试点应该是用户最关心的， 比如一个注册功能， 能够注册成功这个用例的优先级就是最高的（但是不是所有的注册成功的case都是优先级最高，只需要挑选一个即可）， 其他各种异常校验都是次要优先级的， 还有一些场景覆盖的测试点很难出现，或者叫就算有问题影响也不大， 可以放到低优先级

25.怎样保证覆盖用户需求？

1.确认需求2.梳理需求，确认测试范围、3.制定测试计划、4.根据测试计划编写测试用例、5.执行测试步骤

26.写好测试用例的关键 /写好用例要关注的维度

测试前：
1.对测试目的有一个清晰的认知、2.熟悉产品的功能测试点、3.熟悉模块原理，避免“互相影响”问题的产生、4.关注用户场景问题和上网问题、
5.不可马虎的关键测试用例设计、
编写测试用例时：
1.构建测试用例框架、2.测试步骤的设计（一是如果步骤过于粗糙很容易出现漏测问题；二是写的过于细致，可能耗时耗力，并且会限制执行人员的思维。）
测试用例设计方法及思考
1.切记产品测试的主要目标、2.注意用词精准问题

27.测试用例的状态

排队（In Queue）、进行中（IP）、阻塞（Block）、跳过（Skip）、通过（Pass）、失败（Fail）、警告（Warn）、关闭（Close）

28.常见的测试用例设计方法

等价类划分、边界值分析、错误推断法、判定法表、正交实验法

29.判定表用在哪些时候/哪些功能

30.什么时候用到场景法

场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。

使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。

基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。

场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。

Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。

31.测试环境怎么搭建的

搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。

32.偶然性问题的处理

1.一定要提交bug、
(1)． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
(2)． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
(3)． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。
(4)． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
(5)． 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。
2.尽量重现bug

33.当我们认为某个地方是bug，但开发认为不是bug，怎么处理

1.告知开发bug的判断依据，同时明确开发说不是bug的理由。
2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。
3.校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量

34.产品在上线后用户发现bug，这时测试人员应做哪些工作

1.测试人员复现问题后，提交问题单进行跟踪；
2.评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3.问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4.总结经验，分析问题发生的原因，避免下次出现同样问题。

35.二八定理

缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。

36.如何跟踪缺陷

当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。

37.缺陷的状态

1.始化：缺陷的初始状态；
2.待分配：缺陷等待分配给相关开发人员处理；
3.待修正：缺陷等待开发人员修正；
4.验证：开发人员已完成修正，等待测试人员验证；
5.待评审：开发人员拒绝修改缺陷，需要评审委员会评审；
6.关闭：缺陷已被处理完成。

38.缺陷的等级

轻微缺陷、一般缺陷、严重缺陷、致命缺陷

39.缺陷单应该包含这些要素

缺陷标题、缺陷类型、重现步骤、预期结果、实际结果、缺陷优先级、附件备注

40.测试报告的主要内容

测试报告包括哪些内容: 测试模块（每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下）

BUG的统计，根据时间轴来统计BUG的数量，例如：XXXX年X月X日，发现BUG多少，关闭BUG多少，剩余BUG多少，高级的BUG有多少，中级的BUG有多少，低级和建议的BUG有多少，一直罗列到项目完结

项目总结，汇报一下测试的大致结果。

遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明

最后评判该软件是否符合上线标准，日期，签字，加盖章等

41.如何定位bug：

1.发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题
2.检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常
3.确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析，比如firebug插件等
4.如果产品或业务有相关的日志记录，可通过分析日志来确认bug
5.当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了（注意沟通技巧）
6.如果各方面都分析完还不能确认bug的原因，可以找开发一起定位（注意保留bug现场或者可以复现bug场景）
7.确认bug后，提单给开发进行bug跟踪。
问题单上要描述清楚以下信息：
　 具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象（最好截图）、日志记录、预期结果、bug确认相关人员等
8、跟踪bug，等开发人员修复bug后进行回归测试。（关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）

42.开发没时间修复，如何推进bug的修复：

1.针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2.线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3.修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4.第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方的工作人员，反馈问题，尽量推动应用解决问题
小结
总之，bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。

43.软件测试流程

了解用户需求–》参考需求规格说明书–》测试计划（人力物力时间进度的安排）–》编写测试用例–》评审用例–》搭建环境–》测试包安排预测（冒烟测试）-正式测试-bug-测试结束出报告–》版本上线–》面向用户

44.项目介绍

45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计

• 性能测试
  能否正常书写 是否有笔油泄露 笔帽是否能正常按下弹起来

• 功能测试
  一支笔可以用多少时间、写出的字是否褪色

• 易用性测试
  笔的长短粗细是否顺手 一根笔芯用尽是否方便更换

• 界面测试
  外形是否美观 时尚有趣

• 安全性测试
  笔油是否含有有害物质 笔尖是否容易伤到人 笔油或者墨水保质期多长 过期是否产生有害物质、

• 兼容性测试
  在不同的温度、气压、和重力下能否正常使用 在不同的纸质和力度下书写结果如何

• 三角形测试用例设计：
  1、当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
  2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
  3、若是等边三角形，则打印：“等边三角形”。
  4、画出程序流程图并设计一个测试用例。

• 因果图、等价类划分（推荐测试方法）

46.在项目中发现哪些经典bug？什么原因导致的？

1.编码的问题
(1).接口限流防刷的时候，通过计数器限流，如果超过某个阈值，向前端返回一个codeMsg对象用于显示的时候，显示的是String是乱码的问题，之前由于一直返回都是json 格式，都是封装好在data里。
(2).这次返回是直接通过输出流直接写到response直接返回字节数组的，而不是spring controller 返回数据（springboot 默认utf-8），出现乱码问题，用utf-8编码，解决。
2.比较难解决的bug无非就两种，一种就是程序的逻辑出现问题，导致得不到正确的结果，第二种就是一些中间件，开发环境的问题。
（1）如果是逻辑出现了问题，你项目比较大的话，那只能是通过单步调试，或者用System.out.println()打印出来想要得到的数据看看是哪步出了问题。
（2）如果是开发环境或者是中间件的问题，那只能是通过网上查阅资料来解决问题。如果你英语阅读能力还可以的话，我推荐使用Stack Overflow来查阅资料。

47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

48.在需求文档不太详细的情况下，如何开展测试？

1、主动了解做这个功能的背景，意图，要去解决一个什么样的问题， 这个可以找产品或者开发要，或者谁要求做这个功能的人要，知道这些后，测试的时候才心中有数，知道功能实现对不对
2、尽量让熟悉这块的业务的人去测试，这样功能的一些业务问题就可以测试出来
3、 因为没有需求说明书，测试这边只有在功能做好了，转测试了，才知道功能是什么样子，所以这个时候写测试用例来不及，就采取这样思路操作 ，测试的时候边测试边记录测试的点，然后组内把这些测试点评审下，看看是否还有遗漏的地方，

49.如何尽快找到软件中的bug?

优先解决可重现的bug、对于某些没有头绪的bug，可以找有经验的同事商讨、bug放大、二分定位法、模拟现场、等

50.什么是bug？

bug是计算机领域专业术语，bug原意是“臭虫”，现在用来指代计算机上存在的漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害。

51.ATM机吞卡的吞卡现象是不是BUG?

不是，是特意设置的安全措施，防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款，所以特意设置了倒计时，限时内没有取走银行卡就会吞卡

52.如何减少非问题单的提交？

1.缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。
2.一个完整的缺陷报告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。
3 缺陷的重现步奏必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。
4.指派给人一定要明确，如知道缺陷是所属具体的某一个开发人员时，应该直接指派给对应的负责人，这样就能减少中间分配环节的时间。
5.测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
6.附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在，所以必要的时候提供附件或者截图信息也非常的重要。
7.描述缺陷内容的语气，在进行缺陷单书写时，尽量使用专业术语（体现测试的专业性），其次注意书写缺陷报告单时不要带有个人客观的语气内容，以免影响开发和测试人员之间的关系。

53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

1.检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2.检查软件/硬件的配置是否符合软件的推荐标准
3.确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4.如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5.在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，

54.你们发现bug会怎么处理。

提交bug、指派bug、确认bug、解决bug、重测bug、关闭bug、bug存档