我今天主要是从测试执行的角度来说一下我的想法。

1，整体的疏通测试

拿到一个需求以后，最好是快速的先进行主干流程、重要功能的疏通测试，看是否有阻碍性的问题，如果有阻碍性问题，把他们提交给开发后，再进行具体模块的详细测试，当开发把阻碍性问题修改好后，要去验证并再往下测一些，看是否还会再次卡住，如果又有问题，再次提交给开发后，继续详细的测试。这样的话，我们对这个项目会有一个整体的概念，总体质量怎么样，哪里可能比较薄弱，总体时间的把控会比较好。另外一点，开发在刚刚提测的时候，修改bug的时间，一般也是比较充裕的，提测几天以后，他可能就接到其他项目，一边做新需求，一边改问题了，效率会比较低。

2，在测试的时候，尽量的去定位问题原因

比如查看数据库、查看日志、抓包。一方面，比如在看日志报错信息的时候，可以初步排查下是否是自己的操作或数据的原因导致的，实际上不是bug；另一方面，看报错信息，也可以让我们了解这个问题具体是什么原因导致的，方便开发修改问题，也方便我们复现问题；通过看数据库，我们可以了解当前这个问题是落库的时候就不对，还是只是前端展示的问题，从而预判处这个问题的严重程度，并且通过观察库表的变化，也可以知道是哪一步出现了问题；抓包，对于前后端分离的项目，可以看下是后端返回的问题，还是前端展示的问题，方便提交bug给不同的开发；另一方面，测试初步定位问题也可以缩减开发修改问题的时间。

3，善用各种工具辅助测试

比如数据库、redis可视化工具、熟悉各种表关系，也方便做数据和查询数据，有的时候有些数据可以直接改库，会方便很多；利用redis可以查看虚拟的用户的验证码、清redis都可以辅助我们测试。

4，要多问为什么

比如说开发修改一个问题后，可以问问他，这个问题产生的原因，知道了原因以后，我们就可以判断下，跟它并列的原因，是否需要测一下，是否会出现问题；另外，知道了问题产生的原因后，也可以一定程度上判断出开发修改的范围，从而推断出影响的范围，得出在验证问题的时候，需要回归的范围。这样就一定程度上避免了，开发修改了问题后，我们只是验证了当前问题，引发的其他问题没有去关注的情况。

5，要了解实际使用场景

这样方便我们抓住测试重点，一方面防止我们测试的场景和实际使用场景不同，上线后出现问题，另一方面也避免浪费时间，测试了大量实际完全用不上的场景。在时间有限的情况下，首先保证核心内容没有问题，其他影响不大，可以快速上线修复的问题，就可以适当的少用一些时间。

6，团队协作的时候，注意交叉测试

可以一个人负责一个端，然后发现问题时，互相多交流，并且在二轮或回归的时候，进行适当的交叉测试。

7，前期准备越充分，后期进行会越顺利

所以我们在需求评审的时候，就要提出自己的疑问。在写用例、过用例的时候，确认好需求疑点。这样在测试执行阶段，就只有个别问题需要确认，就可以把更多就精力放在测试上面。并且我们在前期就把这些有疑问的场景提出来，也可以提醒开发，在开发的时候，他也就会把这些逻辑加进去，防止在测试阶段才提出问题，开发去做，这样提问题、验问题会浪费我们大量的时间，影响测试质量。

 

8，不同的产品阶段，对质量要求不同

前期不断试错的过程，需要小步快跑，这个阶段对质量的要求也就相应降低。当产品处于一个稳定的阶段，从研发设计开始就应该想如何更好的设计，避免为以后埋坑。

 

9，bug燃尽图呈下降趋势，且逐步趋近于0