谈一个老生常谈的话题，如何做好功能测试，或者说如何做好手工测试。手工测试在软件测试里一直都处于一个被低估而又不被抛弃的角色，说被低估，是因为很多人都觉得手工测试只是个体力劳动，而缺乏技术含量；说不被抛弃，确实自动化测试不能替代手工测试，而且在开发周期紧张的时候，似乎堆人就能把功能测试给做完；还有一个原因就是其实会自动化的人也没那么多，需要做自动化的测试，也找不到人来做，就手工测试先顶着吧。
手工测试其实一直存在技术含量低的误解，是因为他更深层的技术含量在与测试思维，这种偏主观的东西并不好被量化，而且舆论觉得有测试思维和没测试思维，做出来的测试质量其实差别不大，最多也就几个关键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.
