测试感悟，测试方法小总结

      今年听到最多的词就是高效，快，敏捷。怎么能更高效的测试，更快的让产品上线，同时又能保证高质量。我把我测试中发现比较好的方法，整理下来，一个是给自己做个备忘，也希望能帮助到其他人。 

1.测试需求早介入。这也是公司测试组一直在鼓励推行的要求，测试向前走。

        在前期需求投入更多的时间，尽早参与产品需求的讨论，会对整个产品方向上有更好的了解。对需求细化梳理，至少在编写TC时，需要对整个需求的细节点能明确，可减少后期沟通变更的成本。

       用测试设计驱动开发过程，在前期细化需求，产出测试用例时，需要和开发一起评审。 让开发在写代码参考测试用例，对测试用例中的校验点留心，可减少低级bug出现概率。

 2.测试用例巧分类：对用例分不同的优先级，设计主流程路径用例，高风险用例。

      我们知道bug发现越早，测试成本越小，但是往往测试时有很多的bug，如果你只是一个一个顺序测下去，很有可能bug不会在早期被发现。推荐对所有用例进行一个优先级，高优先级和主流程用例提前执行，高风险用例提前执行。一方面可以保证主流程没问题，一方面降低风险。何为高风险用例，这需要测试人员根据自己的经验和测试敏感性，提取认为最容易有问题的用例进行测试，提早发现问题。 

3.提前准备测试数据，测试数据要准备充分。

       多样的测试数据才是真正发现bug的根源，在前期测试准备时就需要在测试数据上下功夫。在数据的选择上要多思考，想想哪种情况更能引发bug，哪些是最常用的数据，数据的覆盖是否全面，否则后面要花更多的时间为自己的偷懒买单。

 4.提测的质量要保证，测试版本要控制。

        事先和开发约定好提测的标准，要求开发在提测前做自测。

        正式提测时先做冒烟测试，不通过时退回给开发，可减少低级bug的情况。对开发提测版本高要求，需要开发对其修改的点进行一定的单元测试，可以及早捕获低级的bug，更好的保证我们有时间发现更高级的bug，减少bug风险。

       测试的过程中需要分阶段，提bug也可以更灵活：

        1）对于刚开始提测时，一般问题会比较多，可以考虑集中记录bug，多个类似问题提一个bug，或在开发很快修改的情况下不提bug。这块测试同学可以处理的更灵活一些，一方面减少提bug带来的时间投入，提高效率，同时和开发的关系也会更融洽。

           2）对于严重类型的bug，或者比较经典的问题，需要记录bug。一方面可以做个借鉴，另一方面也可分享给其它人，减少类似问题出现的机率。

5.加强和开发的沟通，不要放过任何疑问。

         凡事多问几个为什么，多动手定位思考一下。和开发一起讨论定位bug，能让测试同学对程序代码有更深的了解，同时一起讨论时，更容易分析出类似可能出现的问题，发现一些潜在的风险。

         总之，测试的最终目的是保证产品质量，并不是体现在提了多少bug。要有和整个开发，pd一个团队共同努力把产品质量做好的想法。