什么是bug
- 当且仅当规格说明是存在的并且正确,程序与规格说明之间的不匹配才是错误
- 当没有需求规格说明书时,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时,就是软件错误
bug的级别
- 奔溃:导致整个软件不能使用的错误。比如导致操作系统崩溃、导致操作系统重启或死机(一旦出现这类问题,应当立即终止操作)
- 严重:导致整个模块不能使用或导致业务不正确的错误,或较大的需求没有满足等。比如业务流程没有达到设计要求、数据存储问题、信息丢失等等
- 一般:导致某个步骤不能正常执行或期望结果不正确,但不引起严重后果的错误,或数据刷新、操作不便等不影响用户正常功能的使用的错误。比如数据计算错误、版本问题、兼容性问题、响应时间慢等等
- 次要:界面显示或提示信息错误。比如界面不规范、界面显示错误、信息提示不清、建议性问题等等
如何描述一个bug
在提交的bug表单里应该包含以下几个部分:
- 测试版本:开发人员需要知道出现问题的版本号才能对症下药快速解决问题
- 测试环境:包括软件环境和硬件环境。如果是web,需要提供电脑系统、浏览器版本号等等;如果是app项目,需要提供手机型号、系统版本等等
- 测试步骤:描述出现问题的具体步骤
- 预期结果:以需求为标准,来描述该程序正确运行的结果
- 实际结果:测试人员实际测试的结果
- 能说明问题的其他附件:比如错误截图、错误日志等
注意:不要把多个 bug 放在一起提交
详细的bug描述更有利于故障的定位,方便快速解决问题
如何发现更多的bug
对于一个项目来说,当然是bug的遗存率越低越好
那么,作为一个测试人员,发现更多bug的注意点有以下这些:
- 软件测试同样存在二八原则,80%的故障集中于20%的模块,如果某部分问题较多,加强测试广度和深度
- 开发人员也存在二八原则,80%的故障集中于20%的开发人员,如果某些开发人员的bug较多,加强他开发模块的测试广度和深度
- 多进行逆向思维和发散性的思维
- 不要局限于用例和需求文档
- 尽早介入项目, 不要等到开发的差不多了再介入项目