软件测试的生命周期
生命周期:
需求分析->测试计划->测试设计->测试开发->测试执行->测试评估
在这里与软件开发的周期进行类比学习,其实就是V模型.
描述bug
合格的bug包含:
1.发现问题的版本.
2.问题出现的环境(查看项目的支持版本,测试的环境不同可能结果也会不同).
3.错误重现的步骤(类比测试用例的步骤).
4.预期行为的描述(需要开发人员的指导).
5.错误行为的描述.
6.其它:例如:功能故障,界面故障,兼容性故障等.
注意:不要把多个bug放在一起(若写一起,可能就无法定义bug出现的位置).
bug级别
在不同的公司对bug的定义级别不同.
1.Blocker(崩溃):
造成系统崩溃,死机,死循环,导致数据库丢失,与数据库连接错误等.
2.Critical(严重):
系统主要功能部分丧失,数据库保存调用错误,用户数据丢失.
3.Major(一般):
功能没有完全实现但是不影响使用.例如:操作时间长,查询时间长,删除没有确认框等.
4.Minor(次要):
建议性的问题,不影响操作功能的指向,可以优化性能的方案等.
bug生命周期
不同的公司对bug的生命周期定义不同.
下图是一个简单的bug的流程
New:发现的新的bug;
Open:确认是bug,并且认为需要修改,指派给相应的开发人员.
Fixed:开发人员进行修改后标识为修改状态,等待测试人员的回归测试验证.
Rejected:如果开发人员不认为是bug,拒绝修改.
Delay:延后修改.
Closed:修改状态的bug经过测试人员的回归验证通过,就关闭bug.
Reopen:如果经验证后bug仍然存在,则需要重新打开bug,开发人员重新修改.
无效的bug:
Open->Closed,Open->Rejected->Closed
菜鸟之测试流程:
1.阅读所有项目有关的文档.
2.尽可能参加各种项目会议.
3.熟悉项目所有的测试管理工具,配置管理工具.
4.阅读旧的bug库,了解系统功能.
5.了解公司的规范要求.
7.寻找了解业务的测试人员请求指导(主动找).
发现更多的bug
1.二八原则:80%的故障可能集中于20%的模块(着重测试这块代码).当然也有可能是80%的故障集中于20%的开发人员(着重对这些测试人员的代码尽心测试).
2.多进行逆向思维和发散性思维.
3.不要局限于用例和需求文档.
4.尽早的了解项目,介入项目.