如何描述一个bug

什么是bug

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

bug的级别

1. 奔溃：导致整个软件不能使用的错误。比如导致操作系统崩溃、导致操作系统重启或死机（一旦出现这类问题，应当立即终止操作）
2. 严重：导致整个模块不能使用或导致业务不正确的错误，或较大的需求没有满足等。比如业务流程没有达到设计要求、数据存储问题、信息丢失等等
3. 一般：导致某个步骤不能正常执行或期望结果不正确，但不引起严重后果的错误，或数据刷新、操作不便等不影响用户正常功能的使用的错误。比如数据计算错误、版本问题、兼容性问题、响应时间慢等等
4. 次要：界面显示或提示信息错误。比如界面不规范、界面显示错误、信息提示不清、建议性问题等等

如何描述一个bug

在提交的bug表单里应该包含以下几个部分：

1. 测试版本：开发人员需要知道出现问题的版本号才能对症下药快速解决问题
2. 测试环境：包括软件环境和硬件环境。如果是web，需要提供电脑系统、浏览器版本号等等；如果是app项目，需要提供手机型号、系统版本等等
3. 测试步骤：描述出现问题的具体步骤
4. 预期结果：以需求为标准，来描述该程序正确运行的结果
5. 实际结果：测试人员实际测试的结果
6. 能说明问题的其他附件：比如错误截图、错误日志等

注意：不要把多个 bug 放在一起提交

详细的bug描述更有利于故障的定位，方便快速解决问题

如何发现更多的bug

对于一个项目来说，当然是bug的遗存率越低越好
那么，作为一个测试人员，发现更多bug的注意点有以下这些：

1. 软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度
2. 开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度
3. 多进行逆向思维和发散性的思维
4. 不要局限于用例和需求文档
5. 尽早介入项目, 不要等到开发的差不多了再介入项目