测试-BUG篇
软件测试的生命周期
软件测试贯穿于软件的整个生命周期
BUG
bug的概念
是指计算机程序中存在的一个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，不符合软件需求了
准确的来说：
- 当且仅当规格说明(需求文档)是存在的并且正确，程序与规格说明之间的不匹配才是错误
- 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
描述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，开发人员重新修改
与开发产生争执怎么办（高频考题）
- 先检查自身，是不是测试的时候出现了误操作,是否bug描述不清楚
- 站在用户角度考虑并抛出问题,应该让开发人员了解到Bug对用户可能造成的困扰，促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
- BUG定级要有理有据。BUG定级时，不仅要参考BUG定级描述文档，还要考虑BUG是否会影响到流程
- 提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
- bug评审
如果确实是bug，友好沟通不能解决问题，那么就召开bug评审
bug评审主要解决两个问题：
1）决定如何处理bug
2）分析缺陷产生的原因，找出预防的对策
bug评审至少需要项目组各个方面的代表参加：
1）测试代表
2）开发代表
3）产品代表
原文地址：https://blog.csdn.net/2302_77179144/article/details/142714122
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！