测试找BUG总结
1、对业务模块的理解要全面、深刻。
即：对此次新功能或者功能改进相关的业务要理解透彻。
好处：
1）对此次需求的合理与否可做出判断。
2）对相关联的其他测试点需进行测试，以防之前的相关功能失效或开发将相关功能误改坏。
2、对整体流程要理解透彻。
好处：如测引擎算法时，相关需求的改动要看整体流是否走得通，看逻辑是否正确。
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的一些思维方面的总结，分享给大家，感谢阅读。
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
