作为开发人员，我们应谨记这些话： "质量不是来自检查，而是来自生产过程的改进"。

- 爱德华兹-戴明

公理：“测试就是代码。”

太多的组织将任何未编码的东西视为一次性的。显然，测试是不可或缺的，但我们一次又一次地发现，有些团队将测试自动化和相关材料视为二等公民。测试是用户行为的文档，与产品组织产生的需求密不可分，并在虚拟层面与用于创建功能的代码相连。如果它能提供价值，就应该对其进行版本控制、维护、关注和尊重，就好像它是产品本身的核心功能一样。这应包括测试用例规范、设计和技术文档以及错误报告。

还有 "时间会扼杀信心"

你会认为，在一项功能上花费的时间越多，你就有越多的时间去完善、磨练、测试和探索它。与直觉相反，这适合 "旧世界 "的开发风格，有一个测试环境、一个演示环境，以及许多关于用户如何与之交互的宏大假设。

这些法则试图将 SDLC 拉入云计算的世界：微小、渐进的变化，先在有限的受众中推出，然后再推向整个世界。"从键盘到生产只需 10 分钟"--这将带来更快的反馈、更少的逃避和更高的信心。以下是编码新世界的 10 条法则。

一、十大法则

1.每个人都要测试-每个人

无论采用何种流程，无论生产何种产品，无论从事何种行业，团队中的每个成员都要对产品质量负责。产品、工程、测试，甚至周边职能部门：客户支持、销售、市场营销、业务开发、早期测试客户、高管--每个人都要测试。

2.衡量风险，而非覆假队

假设团队能够就 "完美 "的工作定义达成一致，那么仅仅追求完美就会分散对最重要事情的注意力：关键缺陷泄漏到生产中给业务带来的风险。

在你开始担心所有功能的全面覆盖之前，请先关注对你的业务最关键的六个用户流。

3.测试“钱”想要什么

每个企业、每个部门和每个团队都会部署一套对收入影响较大的核心功能。或者，每个团队都必须维护一套影响较小但仍然必要的功能。将测试重点放在影响收入的部分，然后再考虑其他因素。对于电子商务，优先考虑结账流程，而不是用户配置文件。对于财务，优先考虑安全和资金处理工作流程，而不是信息页面。

4.广度比深度更重要

用一种浅显的方式测试产品的所有领域比用一种深入的方式测试产品的某些领域更重要。业务逻辑的深度、多变量组合旨在找到最模糊的边缘情况:这有可能在其他高优先级领域中遗漏更明显的缺陷。

一旦实现了广度，你要对某一特定功能进行多深度的测试呢？见定律 2。

5.唯一完美的信号就是用户的信

在用户与软件进行交互之前，你所做的一切都是理论性的。

测试是模型。它们是用户行为的近似值，基于从过去的用户行为中获得的信息。我们从测试中获得的信号可能会因环境、测试本身的逻辑缺陷、无意识的偏见，甚至以前模型中的错误数据而受到影响！

要想知道用户使用软件时会发生什么，唯一的办法就是观察用户使用软件时会发生什么。生产分析中的用户旅程应与测试覆盖率相关联，以评估测试策略的有效性。

此外，还要考虑到用户体验包括一些甚至不会被视为错误的元素，这些元素可能不会反映在分析中。当构建变成绿色时，你的工作并不一定就完成了。

6.代码在可测试（并经过测试）之前是不完整的

可测试性是指对代码的各个部分进行检测。如果不允许对这些信号进行轮询和解释，就很难判断行为的正确性。这将导致过多的额外工作，增加发布周期的时间，并将注意力从客户体验上转移开。时间会扼杀信心。

7.每个测试都应导致明确的行动

如果你不知道测试失败时该做什么（无论是从测试角度还是从产品角度），那么测试就没有价值。

这通常是由于测试步骤过多，或者是由于产品没有提供足够的失败信息（包括没有足够的可测试性。 参见定律 2）。

8.始终测试信号最强的地

软件测试有 "层"（从高到低）：生产、UAT、功能、集成和单元。

高层测试对于强制不同团队开发的不同组件之间的交互至关重要，但边缘案例的细枝末节很可能可以下移到低层。这些低层测试的依赖性较少，避免了昂贵的管道配置/协调，运行速度也比高层测试更快。

举例来说，用户界面测试只能用于确定用户界面是否能够渲染应用程序接口的输出。如果重复通过相同的用户界面测试业务逻辑，则应将大部分测试 "下移 "到应用程序接口层。

9.不要链接测试

所有测试都应该在不考虑任何其他测试状态的情况下执行。应该对测试数据进行管理，这样每个测试都存在于自己独立的场景中，并且不能被另一个测试更改。

测试应该是原子的和自治的。

10.选择最紧密的反馈循环

所有的测试都是反馈循环。他们从一个特定的角度运行产品，并向特定的人或团队提供反馈。最紧密的反馈回路是尽可能地切断对特定操作的测试。测试比必要的更宽的循环会引入一些变量，这些变量可能会混淆你从测试中获得的信号。

二、结论

人们喜欢争论。你不需要走很远就能找到它。这十条法则并不完整，当然，还有许多注意事项和限定条件，可读性和字数都不允许。我很想听听各位的反馈意见；你们的测试十大法则是什么？我漏掉了什么？

这些项目是作为法则提出的，但我认识到背景很重要，而且你不可能总是完美无缺。有时，这些法则只是愿望而非实际。有时你会发现自己每次都会违反一两条（或十条）--重要的是要不断改进，而不是追求完美。