测试方法论－质量的基石



测试行业最难的命题不是测试技术，而是测试质量。
大家对这个场景都很熟悉：出现生产问题，解决问题，生产事故复盘、责任分配到人。
如果你所处的团队经常遇到这种情况，不是运气不好，也不必烧香拜佛，而是质量体系出了问题。
影响质量的因素是多方面的，尤其重要的是－测试方法论。

第一步，测试活动分解质量阶段

不同公司可能存在差异，以笔者公司为例：

• 需求和技术方案评审；
• 测试设计；
• 线下测试；
• 线上测试；
• 线上监控。

第二步，每个阶段的工作，都要为质量服务

需求和技术方案评审

• 外部评审：测试不是被动的接受，应该和产品、开发一起脑暴，发现设计缺陷、技术风险和隐患、关联方影响等（不具备该能力的可通过内部评审进行实训锻炼）；
• 内部评审：团队内部对技术方案进行评审、实训，找出关注点、风险点（团队能力普遍较高的可以裁减）。

目的：此阶段是质量的基石，通过测试左移，尽早发现需求设计缺陷、技术方案风险、接口设计缺陷、性能设计缺陷、关联方依赖影响，了解测试关注点，关注可测试性等问题。

测试设计

• 用例设计：除了对业务的理解，还需要扎实的基本功（边界值、等价类划分、正交等）；
• 场景设计：正常场景、异常场景、补偿场景，场景流的每个关键节点都要列出检查项，如何模拟特殊场景，是一种挑战；
• 数据准备：前后端之间、组件之间、己方和第三方之间的联调，测试应该提前准备好相关方案，如Mock接口、Mock数据。

目的：此阶段是质量的骨架，通过测试设计，覆盖更多的测试点、模拟更多的场景、做好更充分的测试准备，为质量保驾护航，为测试赢得更多宝贵的时间。

线下测试

• 接口测试：需要遵循严格的接口测试规范执行，例如：必填项、取值范围、默认值、分页、单接口耗时、冗余、联动、数据落地正确性、安全性等；
• 单点覆盖：严格按测试用例执行，例如：功能和需求是否一致、db数据正确性、健壮性、安全性、友好性、内存泄露等；
• 横向覆盖：对于一个场景，从开始到结束涉及到的关键节点，都要进行检查点覆盖，包括功能实现、数据读取、数据计算、数据写入的正确性；
• 纵向覆盖：正常场景、异常场景、补偿场景都要覆盖；
• 探索性测试：以上之外，可以凭个人经验进行探索测试；
• 回归测试：拉取回归测试集，并确保主流程的横向覆盖、纵向覆盖、自动化回归等；
• 性能测试：前端性能测试（什么情况用异步请求、什么情况只能用同步请求、渲染、压缩、什么是正确姿势），后端性能测试（如何对结果分析定位问题）。

目的：此阶段是质量的成型，通过测试设计的充分准备、线下测试的严格、立体的执行，发现和解决绝大部分问题。

线上测试

• 新功能测试：拉取线上快速验证测试集，并确保主流程的横向覆盖、纵向覆盖；
• 回归测试：拉取线上回归测试集，并确保主流程的横向覆盖、纵向覆盖；
• 性能测试：全链路压测（数据隔离）。

目的：此阶段是版本质量终态，线上测试主要是为了确保代码部署、生产配置、生产环境对质量的影响。

线上监控
目的：此阶段是质量补偿，快速响应和解决，降低生产事故造成的损失。

总结，质量取决于团队的能力

首先，要找到合适的方法论，其次，同样的方法论，执行效果还是取决于人的能力。所以，千万不要忽视对人的培养。

PS：有句话叫空谈误国实干兴邦。测试思想在逐渐的改进，很多技术本身就是就是测试思想的最佳体现。比如流行的非常有价值的移动端和服务端hook技术。测试思想是研发和测试都在使用。如果一个人没技术有思想他现在互联网公司基本找不到测试工作了。一个人有技术没思想就如实习生一样还是可以培养的，这就是为什么越来越多的公司宁愿要实习生培养。我几个朋友在这方面做过尝试，懂技术的实习生稍加引导在半年后多会胜过那些满腹测试思想却缺乏技术的老员工，而且表现多超预期。所以技术功底很重要。