目录

• 一、软件测试的生命周期（软件测试的流程是什么
• • 1.1软件测试&软件开发生命周期
• 二、如何描述一个BUG/li>
• 三、如何定义bug的级别
• 四、bug的生命周期
• 五、问题：发现一个BUG，开发人员修改了，通知测试人员验证，但是测试人员又复现了这个BUG，是什么原因引起的/li>
• 六、测试人员因为一个BUG和开发人员产生冲突，怎么办/li>

一、软件测试的生命周期（软件测试的流程是什么

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

需求分析：分析需求；验证需求的正确性、合理性；细化需求，根据需求取提炼测试点。
测试计划：确定测试范围、目的、目标；测试人员；测试工具；时间；测试环境。
测试设计/开发：开发测试用例。
测试执行：开发人员已经提交代码，执行测试，提交BUG。
测试 告：本次迭代的代词情况进行分析和总结；写了多少测试用例，执行了多少；发现了多少BUG，修改了多少，剩余BUG的解决方案；测试的覆盖率。

1.1软件测试&软件开发生命周期

a.需求阶段—测试人员了解需求、对需求进行分解，得出测试需求。
b.计划阶段—根据需求编写测试计划/测试方案
c.设计阶段—测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架,根据需求和设计编写一部分测试用例。
d.编码阶段—测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。
e.测试阶段—测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试 告。
f.运行维护—测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人。

二、如何描述一个BUG/h1>

三、如何定义bug的级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。以下为样例：
1、Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试，回退到上一个可用的稳定的历史版本）。
2、Critical（严重）：
服务器可以用，但是不稳定，继续使用会产生严重的错误；系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）
4、Minor（次要）：
界面、性能缺陷，**建议类问题，**不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

四、bug的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的。
测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。
BUG状态转换图：

五、问题：发现一个BUG，开发人员修改了，通知测试人员验证，但是测试人员又复现了这个BUG，是什么原因引起的/h1>

1.测试环境不一样
2.开发人员理解不到位，没有修改成功
3.代码：开发人员修改后，没有提交代码到远程，测试人员用的是旧的代码（有问题的代码）进行测试。

六、测试人员因为一个BUG和开发人员产生冲突，怎么办/h1>

1、先检查自身，是否bug描述不清楚
2、站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。
3、BUG定级要有理有据。
BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别。
4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案。
5、开发人员不接受时，不要争吵，可以找产品经理讨论问题的解决方案。
此时可以发起Bug评审。Bug评审要注意的问题：缺陷的评审应该包括以下两个层面：
● 决定如何处理Bug：这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开
发代表、产品代表。
● 分析缺陷产生的原因，找出预防的对策。