bug的一辈子：如何体现测试专业度？

bug像是一个被过度宠爱的小孩子，获得了特别多的关注。它们在开发者的IDE里悄然无声的诞生，但在现身之刻却引来一片喧闹“——bug的一辈子

 

对于测试人员来讲，bug的生命周期通常分为：发现bug—>提交bug—>验证bug，那在这三个阶段中如何体现测试的专业度呢？

 

第一阶段：发现bug

场景：

“测试不就是发现bug吗，有什么技术含量？”

 

思考:

当发现一个bug，除了尽快报告问题之外，咱们还能作哪些事情？

 

回答：

测试人员发现bug，花些时间细细品味

1. 这个bug复现的必要条件是什么？

2. 除了发现bug的这条路径，是否还有更多的路径也会致使相同的问题？

3. bug是否存在可能影响其它数据或者其它应用的反作用？

4. 其它功能模块是否也存在相似问题？

5. bug的复现路径是否在用户可达之路上？

6. 复现bug的路径是否在测试用例中？有没有可借鉴性？

 

经过以上分析，咱们可能得到如下额外收获：

1. 经过bug的定位，确认必现路径、可能的缘由，帮助开发快速定位、解决问题

 

2. 经过bug的路径、影响范围等分析，发掘更多的隐藏bug，《探索式测试》-恶邻测试法：重灾区每每会有更多的bug

 

3. 经过分析操做路径，补充测试用例，扩展测试用例范围、思路

 

第二阶段：提交bug

场景:

一个阳光明媚的下午，小白正在测试一个用例的时候，忽然app异常退出了，再重复进行以上步骤，问题没有复现。他意识到这是个bug，因而他赶忙提交给开发。没过一会，开发大神怒气冲冲的过来讲“你这bug也没必现步骤，也没日志，这怎么修改！”。小白内心一阵嘀咕“原本就是一个bug，你应该想办法解决呀，我怎么知道”

 

思考：如何才能提交一个有效的bug？

回答：

1. 确保bug有效。

1）不要由于环境问题或者是操做错误引发“bug”

2）不要提交一些重复的bug

 

2. 写好bug描述。

1）bug描述精确、没有歧义，详细简洁的测试步骤。

2）保证各个字段内容与实际现象一致。好比：版本、复现率等

3）对于复现率低的问题，尽量提供一些可参考信息：截图、视频、日志、可能的步骤、可能缘由等（若是你能经过各类手段定位到问题的缘由，开发大神也会对你另眼相看的）

4）对于特殊的测试场景，附带相关的数据，好比1024kb的图片等

 

第三阶段：验证bug

场景：

当我仍是一个测试新手的时候，对于bug验证，每每是按照步骤验证复现，若是没有问题就关闭了（不知道如今还有多少人跟我当初同样~）

 

思考：如何作好bug的回归验证？

回答：

1. 确认好bug的复现前说起操做步骤。

2. 确认bug产生的缘由及修复方法。

1） 明确bug产生的缘由，举一反三，分析其余模块可能存在的问题

2 ) 经过bug产生的缘由，积累测试经验，扩展测试思路

3） 经过bug的修改方法，分析修改是否能修复问题？是否回引起其余问题？

4） 积累bug经验，在后续相关问题发现时，快速定位问题，提供解决思路

 

3. 确认bug的回归范围及用例。

在了解清楚bug产生的缘由及修复方法基础上，再根据业务关联、功能模块关联确认回归范围，确保bug修复全面且没有引发新的bug

 

最后

一个小小的bug，多多思考也是能发掘隐藏在背后的问题、测试工具、测试知识，从而提升本身的测试能力、专业度。