测试----关于Bug
软件测试的生命周期
需求分析—测试计划—测试设计、测试开发—测试执行—测试评估
软件测试和软件开发生命周期
需求阶段—计划阶段—设计阶段—编码阶段—测试阶段—运行维护
如何描述一个Bug
一个合格的bug描述应该包括以下几个部分：
1.发现问题的版本
开发人员需要知道出现错误的版本，才能获取对应版本的代码来重现故障2.问题出现的环境
详细的环境描述有利于故障的定位。如果是web项目，需要描述浏览器的版本、客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等3.错误重现的步骤
描述问题重现的最短步骤4.预期行为的描述
要让开发人员知道怎样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的5.错误行为的描述
描述错误的现象6.其他
7.不要把多个Bug放在一起
在无法确认是同一段代码出现故障时，不要讲bug放在一起提交
如何定义Bug的级别
1.Blocker(崩溃)
如：代码错误、死循环、数据库发生死锁、重要的功能不能使用等2.Critical(严重)
如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误3.Major(一般)
功能没有完全实现但是不影响使用，如：操作时间长、查询时间长4.Minor(次要)
如：错别字、界面格式不规范、页面显示重叠等
Bug的生命周期
每个公司，每个工具对Bug生命周期的定义是不一样的，下面举一个常见的例子
测试人员应该跟踪一个Bug的整个生命周期，从New到Closed的所有状态
如图是Bug状态转换图
各种状态分别代表什么含义？
New：新发现的Bug，未经评审决定是否指派给开发人员进行修改
Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员
Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
Rejected：如果认为不是Bug，则拒绝修改
Delay：如果认为暂时不需要更改或暂时不能更改，则延后修改
Closed：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug
- Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改
测试的执行和Bug管理
- 1.打开待测试的系统
- 2.打开测试管理工具用例模块，开始执行用例
- 3.发现Bug！进行复现，并确认Bug的复现步骤
- 4.记录Bug
- 5.沟通Bug
- 6.验证以前提交的Bug
- 7.确认本次测试完成
- 8.编写测试报告
如何发现更多的Bug？？
1.软件测试存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度
2.开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的Bug较多，加强他开发模块的测试广度和深度
3.多进行逆向的和发散性的思维
4.不要局限于用例和需求文档
- 5.今早介入项目，不要等到开发的差不多了再介入项目