软件测试的生命周期

软件测试贯穿于软件的整个生命周期

BUG

bug的概念

是指计算机程序中存在的一个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，不符合软件需求了

准确的来说：

1. 当且仅当规格说明(需求文档)是存在的并且正确，程序与规格说明之间的不匹配才是错误
2. 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误

描述bug的要素

为什么描述bug还有要素要求？
在心理学上说，人们在编写文档的时候，经常会出现自己想表达的和写出来的内容往往南辕北辙

描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果、bug级别

bug级别

通过定义bug的级别，能够明确看出问题的严重程度。工作中开发人员通常需要按照bug的级别来分配优先级来处理bug，除此之外，通过bug级别也能够体现出开发人员的开发质量

bug级别一般分为：崩溃、严重、一般、次要

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

bug的生命周期

测试人员在执行测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug生命起源），创建好的bug需要被开发人员修复，以及测试人员的持续跟踪和测试

• New:测试人员创建了一个bug
• Open：确认是Bug，并且认为需要进行修复，指派给相应的开发人员。如果是无效的bug的话状态流转为Rejected
• Fixed:开发人员进行修复后状态转变成修改状态，有待测试人员的回归测试验证。
• Rejected：如果认为不是Bug，则拒绝修改
• Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改
• Closed：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug
• Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改

与开发产生争执怎么办（高频考题）

1. 先检查自身，是不是测试的时候出现了误操作,是否bug描述不清楚
2. 站在用户角度考虑并抛出问题,应该让开发人员了解到Bug对用户可能造成的困扰，促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
3. BUG定级要有理有据。BUG定级时，不仅要参考BUG定级描述文档，还要考虑BUG是否会影响到流程
4. 提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
5. bug评审
   如果确实是bug，友好沟通不能解决问题，那么就召开bug评审
   bug评审主要解决两个问题：
   1）决定如何处理bug
   2）分析缺陷产生的原因，找出预防的对策
   bug评审至少需要项目组各个方面的代表参加：
   1）测试代表
   2）开发代表
   3）产品代表