如何找出更多软件bug的11条总结

1、对业务模块的理解要全面、深刻。

即:对此次新功能或者功能改进相关的业务要理解透彻。

好处:

1)对此次需求的合理与否可做出判断。

2)对相关联的其他测试点需进行测试,以防之前的相关功能失效或开发将相关功能误改坏。

2、对整体流程要理解透彻。

好处:能判断出主流程和分支流程,找到测试的重点和难点,以及确定测试内容的优先级。

如何找出更多软件bug的11条总结

3、提测多了以后,要善于总结哪些是开发的易错点、易遗漏的点,发现后不仅要在测试时予以测出,还要告知开发此处易错,帮助开发分析原因。

如:若是因为对此处业务理解不到位,测试可以写一些清晰易理解的说明文档给开发,以帮助开发弄懂和理解业务;若是代码方面的技术漏洞,比如:在更新的时候会报空指针,则要告知开发增加此处的判断非空,并形成代码规范。

4、若是开发新人,则测其开发的功能时,要格外重视,无论是业务方面还是代码逻辑方面,测试点都要细和全面。当测试人员手中有多个测试任务并行时,要提早进行测试此需求。

原因:此为易出错的地方,也应在测试早期就着重测试,尽早测试完成,不要因为需求简单或者自己对此需求熟悉而留到最后,因为新开发人员的修改bug速度较慢,且改完后可能引出新的bug,再次发现bug并修复是需要时间的,可能会因为此而延期;若无法延期,带着小bug匆忙上线,可能线上会出现未预期的bug的风险。

5、如果一次迭代版本中,有多个需求。要先测需求逻辑较复杂的、较难测的需求。

好处:

1)逻辑较复杂的需求,其中的错误点和隐藏错误点在大概率上是较其他需求多的。应预留出较多的时间来测此需求。在报出bug,开发修改的过程中,可穿插测完较简单的其他需求,节省整体的测试时间。

2)预留出较多的测试时间,能够对此复杂需求进行深度和广度方面的测试,能更多的发现隐藏bug。

3)bug有群集现象:发现问题越多的地方,隐含的缺陷也越多,需要重点处理。

6、先证明此功能是可用的,再证明此功能是不可用的。

即:先证明此次开发的实现结果满足产品的需求,即:按照需求文档进行功能点的测试。再破坏性的进行测试,以保证功能是健壮的。如:以小白用户的角度来测功能(易用性);以破坏软件的想法录入一些非法值、进行非常规流程的操作;以及压力测试等等。

7、功能开发完成后,开发人员需先进行自测,然后再交付给测试,有利于增加测试冒烟测试的通过率,能更早的进行测试。如果是平台方面的需求,在开发自测后,应告知产品,让其对此需求的界面UI布局和前台功能进行简单的操作使用,确认符合产品预期的原型后,再进行测试,防止开发做出的结果不是产品想要的,在测试完成后或者在上线后,产品才发现开发做的不是自己想要的,则会出现返工现象,以及可能带来客户满意度和公司金钱方面的损失等。

8、在测试前,测试人员应写好测试用例,进行测试用例评审会,此会的参与者有相关产品、开发和测试人员,最好还加上测试主管(测试主管对业务的整体流程和之前相关需求了解更全面,更易发现需求和开发中的隐藏的不符合逻辑的地方,进行及时的指正)。产品和开发在此过程中如果发现用例有不足之处,要及时对用例进行提问或补充。在此测试用例评审会中,开发也可知道测试是从哪些方面进行测试的,对其以后自测方面也有潜移默化的作用。直到产品、开发对此用例认可后,即可开始测试。

9、每次测试完成后,要对此次工作做总结。

如:

1)自我反省测试点是否全面,以及总结在测试中遇到的问题和对应的解决办法,以便在以后的测试过程中再次遇到,能够及时知晓该如何应对。

2)要对业务、代码架构和整体的测试流方面,逐步形成正确的全面的认识,站的更高,才能看得更全面,对涉及较多模块的需求才能测得更快更好,也才能发现更多的隐藏bug。

3)应将测试过程中新增的需求点,补充到wiki中,形成一个书面的完整知识体系备忘录,以便以后自己复习、查阅和供其他同事了解。

10、责任心是测试人员所必要的。要对bug负责,对软件质量负责,对最终用户负责。

11、测试自动化。自动化是对软件整体的可用性、性能等方面进行的校验。

优点:

1)对程序的回归测试更方便:能解放重复的手工测试,大大节省测试时间。

2)可以执行一些手工测试困难或不可能进行的测试。

3)能对软件质量方面增强信心。

以上是笔者在日常测试工作中,对找bug的一些思维方面的总结,分享给大家,感谢阅读。

源自公众号 360质量效能



留言