谈一个老生常谈的话题,如何做好功能测试,或者说如何做好手工测试。手工测试在软件测试里一直都处于一个被低估而又不被抛弃的角色,说被低估,是因为很多人都觉得手工测试只是个体力劳动,而缺乏技术含量;说不被抛弃,确实自动化测试不能替代手工测试,而且在开发周期紧张的时候,似乎堆人就能把功能测试给做完;还有一个原因就是其实会自动化的人也没那么多,需要做自动化的测试,也找不到人来做,就手工测试先顶着吧。
手工测试其实一直存在技术含量低的误解,是因为他更深层的技术含量在与测试思维,这种偏主观的东西并不好被量化,而且舆论觉得有测试思维和没测试思维,做出来的测试质量其实差别不大,最多也就几个关键bug的差别而已。
其实搞不好那几个关键的严重bug可能就决定了这个产品上线以后,用户的口碑走向,是否需要花更多的人力去弥补这个bug造成的损失。
如何做好手工测试呢?梳理一下功能测试三剑客吧,不是我的原创,但是希望能让更多人了解。
首先是功能测试框架。功能测试框架,即梳理出测试类型,产品的功能点的测试,按功能测试框架来把要测试的东西分类。我们现在做成了一个“套餐”的概念,例如,这个产品有5个功能点,其中功能点1,需要用到的套餐是:功能测试+兼容性测试+稳定性测试;功能点2,需要用套餐:接口测试+性能测试;功能点3,套餐:功能测试+UI检查;功能点4,套餐:功能测试+竞品测试+安全测试;功能点5,套餐:功能测试+易用性测试+UI检查。可以看出把功能点按测试类型划分以后,能够拓宽测试范围,而不止是局限在功能测试一个点上,这样无疑扩大了覆盖率。
其次是bug预防体系。这个东西可以说是很多人想做,但是推不动的一个东西。20%的bug总是在各个产品里以类似的形态重复出现,甚至在同一个产品的不同阶段也会重复出现。为了消灭这20%的bug,我们就需要做bug预防。怎么做bug预防呢?第一步,需要汇总整理bug,把bug都汇总一起,根据各种维度打上标签,并且记录好bug产生的原因;第二步,对相同维度的bug产生的原因进行根因分析,把相同根因的bug进行提炼,总结出哪些bug能够做bug预防;第三步,就是完善各种规范,开发规范,UI规范,测试规范,用规范来强制规定什么情况该如何处理,这就不是测试能推得动的了,而是整个技术部门从上到下,达成一致并且遵照执行。
最后是探索式测试。为了进一步扩大手工测试的覆盖率,软件测试里引入了探索式测试这样的概念。探索式测试需要基于丰富的项目经验来进行各种对产品功能的探索,需要测试在脑子里模拟各种非正常的操作场景来实施测试,当然也会运用到各种探索式测试的测试方法。
做到功能测试三剑客,基本上手工测试这一块就没什么好担心了,已经可以做得非常好了,并且能够解放一部分测试伙伴的精力,让他们花更多的时间在测试开发上进行深入学习。
END.
网友评论