作为开发人员，我们信奉一种理念：“质量不是源于检查，而是源于生产过程的改进。”——爱德华·戴明。这一理念的核心在于一个观点：“测试即代码”。
许多组织将未编码的东西视为一次性任务，显然，测试是不可或缺的。我们常常发现团队将测试自动化和相关资料视为次要任务。实际上，测试是对用户行为的记录，与产品组织产生的需求紧密相连，并在虚拟层面上与创建功能的代码紧密相连。若测试提供了价值，那么它应该被版本化、维护、精心照料和尊重，如同产品本身的核心功能一般。这涵盖了测试用例规范、设计和技术文档以及错误报告。
在开发领域，有一条原则令人深省：“时间扼杀信心。”我们可能会认为，在一个功能上花费的时间越多，就越需要时间来完善、测试和探索它。在云计算和编码新世界里，这一观念并不完全适用。相反，我们生活在一个快速反馈、减少逃避和增强信心的时代。以下是编程新世界的十大法则。
人人皆测试。无论流程如何、产品如何、行业如何——每个人都是测试的一部分。产品、工程、测试，乃至客户支持、销售、营销、业务开发、早期访问测试版客户、高管——每个人都在参与测试。
我们应该度量风险而非覆盖率。即使团队能达成关于“完美工作”的共识，过度追求完美可能导致我们忽视了真正的风险——即生产中对业务的关键缺陷。我们应该关注对业务最关键的六个用户流，而不是所有功能的全面覆盖。
测试应聚焦于“金钱”所在之处。每个业务、部门和团队都有一组对收入影响更大的核心功能。测试工作的重点应放在这些关键部件上。例如，在电子商务中，结账流程的重要性就优先于用户配置文件。
第四，广度比深度更重要。测试产品的所有区域比深入测试某些特定区域更为重要。在寻找最模糊的边缘案例的我们不应忽视更明显的缺陷。一旦达到了足够的广度，我们可以再关注某个特定功能的深度。但记住，优先考量依然依据法则二而定。
第五条法则提到，唯一的完美信号来自用户本身。在用户与软件互动之前，我们的一切工作都是理论性的。测试只是模型，是基于过去用户行为信息的近似值。生产分析的用户旅程应与测试覆盖率紧密关联，以评估测试策略的有效性。而且在实际的用户体验中还可能存在未被视为bug的元素，这些元素可能不会在分析中反映出来。即使构建过程显示为正常也不意味着工作已经结束。
接下来是法则六：代码在可测试（并经过测试）之前是不完整的。这意味着我们必须允许对代码的各个部分进行检测并解释这些信号否则很难判断正确的行为这可能导致额外的比例增加发布周期的时间和焦点从客户体验上转移开避免这种情况的最好方法就是尽早开始测试并持续进行下去避免时间的压力扼杀我们的信心。
第七法则强调每项测试都应导致明确的行动。如果不知道当测试失败时该怎么办无论是从测试的角度还是从产品的角度测试都没有提供价值这通常是由于过多的测试步骤或产品没有提供足够的失败信息造成的解决方案是提高测试的效率和准确性同时加强产品的反馈机制。
第八法则提醒我们始终要测试高层级软件测试有不同的层次从高到低包括生产、UAT、功能集成和单元高层级测试对于确保不同团队开发的组件之间的交互至关重要但同时也不能忽视细节层面的测试以确保更全面的覆盖。例如UI测试应该只关注用户界面是否能正确呈现API的输出而不是重复测试业务逻辑如果这样那么这些测试应该更多地关注API层面而不是UI层面。
然后是法则九：从不链接测试所有的测试都应该在独立的环境中执行不受其他测试状态的影响。这意味着我们需要管理好测试数据确保每个测试都在独立的场景中执行不被其他测试干扰这样测试的原子性和自主性才能得到保证。
在探索未知的测试领域，一个至关重要的概念便是构建反馈回路。这并非简单的循环，而是一个经过深思熟虑、精准切割的闭环系统。真正的测试精髓在于，通过最小化回路以集中测试特定操作，确保每一个细节都能得到细致入微的考察。想象一下，如果测试一个比实际所需更宽泛的循环，那么在这个过程中可能会引入许多额外的变量。这些变量如同迷雾中的纷扰因素，可能会干扰我们对测试结果的真实解读。
当我们谈及测试的十大法则时，这些法则更像是一盏指引我们前行的明灯。它们为我们提供了宝贵的经验和方向，帮助我们避免在探索未知的测试领域迷失方向。这些法则并不是铁板钉钉的教条，它们并不是封闭完美的规则体系。实际上，它们更像是一个不断演化的知识体系，随着我们对测试领域的理解而不断完善。在某些特定的情境中，或许我们会遇到需要突破这些法则的情况。不必过于教条地遵循它们，而是应该灵活地运用它们，寻求持续改进和进步。毕竟，真正的目标并不是追求一次完美的测试，而是通过不断的尝试和改进，逐渐接近完美。这样的旅程充满了挑战和机遇，让我们勇敢前行，不断探索测试的无限可能。 |
