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