理解测试的本质——阿里测试之道
1.3 理解测试的本质代码门禁是测试团队打破困局的第一步，但远远不是全部。在进一步阐述破局的思路前，有必要先弄清楚测试的本质。
测试的本质是反馈，就是回答一个问题：代码是不是好的。这里的“好”的定义并不是一成不变的，对于不同的需求，“好”的定义和标准都是不同的。换句话说，测试的目的是提供质量反馈，为整个软件开发过程中不同的节点提供以下3个用于决策的质量反馈。
代码门禁中的单元测试和接口测试结果，为判断是否可以接受代码提交提供决策依据。
功能回归的测试结果，为判断是否可以将当前版本的代码推进到预发布和灰度验证阶段提供决策依据。
预发布环境和灰度验证的结果，为判断是否可以将当前版本的代码进一步部署到整个线上环境提供决策依据。
只要测试是足够全面的、结果是足够可信的，且所有测试都通过了，就可以“无脑”地做出决策。这对于复杂的系统和大型的团队尤其重要，我们希望减少对人的经验、知识和判断的依赖。一个组织一定会不断地新陈代谢，而新人积累经验总是需要时间的，随着业务和系统越来越复杂，一个人能了解整个系统的各种细节和一块业务的方方面面的可能性越来越低。
测试团队是从缩短提供反馈的时间、降低提供反馈的成本和提高反馈的可信度（ConfidenceLevel）3个维度来提升测试反馈能力的，这3个维度，既是质量视角的，也是效能视角的。
有人认为质量和效能是一对矛盾体，要提升效能就要牺牲质量，要提高质量就要牺牲效能。其实，质量和效能并不是一对矛盾体，不是一个硬币的正反面，不是“鱼与熊掌不可兼得”的关系。实际上，质量和效能是“既要……也要……”的关系，是一个人的两条腿。效能提升可以让我们更快地得到反馈，以更快的节奏去迭代和试错。
效能提升对提高质量的直接作用如下。
效能提升能够让代码里的质量问题更及时地暴露出来。例如，用例执行到BugA抛错，直到BugA被修复，用例才能继续执行下去。之后，遇到了BugB，但其实BugB早已存在了，只是一直被BugA掩盖了。如果BugA能迅速被发现、被修复，那么BugB就能更早地被发现和修复。
效能提升能够让代码的质量问题更容易地暴露出来和被注意到，而不是淹没在各种噪声里。例如，接口测试或者全链路回归的确出了问题，但是由于信噪比长期很低，有效信号很容易被开发人员和测试人员忽视。
更完善的工具和基建，能够直接减少人为错误的发生。效能提升对提高质量的间接作用如下。
降低心力、脑力的负担。在项目周期长、多个项目并发的情况下，工程师每天都要在各个项目之间频繁地进行上下文切换，这对心力、脑力都是很大的（不必要的）负担。心力、脑力负担重，不免挂一漏万，增加了漏测和未能识别的潜在风险存在的可能性。
提升测试开发人员的价值。如果我们把工具和基础建设做得更好，就可以少花一些时间在搭建环境等本可以让机器来做的事情上，把花在解决比较低级的问题上的时间省下来，用在对测试和质量有更大价值的地方。反过来，质量的提高可以让我们有信心走得更快，用更少的资源、更短的时间做出决策和判断。
我们在对测试困局进行破局的过程中，以及未来的道路上，做的工作基本上都可以映射到反馈的时间、成本和可信度3个维度上。
缩短反馈弧（时间）：测试用例向“测试金字塔”的下层迁移；提高测试并发执行的能力；减少数据准备的时间，既要能够更好地复用测试数据，又要避免因测试数据复用导致的测试不稳定；打造精准测试能力，能够自动准确地剔除无关的用例；能够通过对测试用例有效性、代码覆盖率和业务覆盖率的准确度量，帮助我们更好地进行等价类分析，对测试用例集进行持续瘦身，避免用例集不断膨胀。
降低反馈成本：测试用例向“测试金字塔”的下层迁移，将更多的测试用更快、更省资源的“小型测试”（SmallTest）实现；精简测试用例、只运行相关的用例，通过缩短测试执行时间来减少对资源的占用；从“硬隔离”向“软隔离”转变，用更多的逻辑隔离替代实例隔离。
提高反馈可信度：提高测试的稳定性，降低测试结果的噪声；提高测试的代码覆盖率和业务覆盖率；提高测试的有效性；自动生成测试用例，减少人工进行测试分析和罗列测试用例产生的测试遗漏。
在这3点中，缩短反馈弧是关键。
poin:ot11 :@
新手求指导 感谢分享 感谢分享
页:
[1]
