假设贵公司最重要的软件突然出现故障，会怎么样？订单可能会丢失，截止期限可能会错过，但客户肯定会抱怨。
这种噩梦般的情况是可以避免的：通过实施持续且严格的测试流程，在问题造成混乱之前将其发现并解决。不过，在贵组织中实施此类流程说起来容易做起来难。
本文将介绍您在公司内开始进行测试时需要考虑的所有事项，以及长期进行测试对您有何益处。
面向产品团队的测试最佳实践
本文第一部分介绍了如何开始在工作流中实现测试。
在团队中推行测试文化
要想在团队中成功引入测试，就需要所有人拥有共同的思维方式，并将质量视为投资而非负担。与所有其他文化转变一样，这是一个需要时间和坚持的过程。
定期召开会议讨论缺陷、缺陷的影响、缺陷的来源以及修复缺陷所需的措施，有助于塑造这种文化。这有助于让用户了解为何应从一开始就防范此类缺陷。
在团队中指定专人负责监督和推动该计划，可以大大提高成功几率。负责制定团队（甚至整个组织）准则、收集最佳实践并加以分享，并在各个级别倡导相关工作。
另一种有用的工具是轮替产品的支持角色。从客户那里获取第一手、未经滤除的洞见，了解他们在使用产品时遇到的日常问题，对产品经理、设计师和开发者来说都是宝贵的经验。
目标是让团队中的每个人都明白，质量是一项功能，与您为产品构建的任何其他功能一样重要。一旦所有人接受了这种思维方式，就会自然而然地认识到测试也是一项功能。因为测试可以确保所发布应用的质量。
分步测试流程
在产品开发中涉及的不同团队达成一致后，您可以进一步规范测试的存在和使用。
将测试纳入“完成定义”
通过将测试添加为功能要求，您可以声明在功能未经过适当的自动化测试之前，该功能不符合发布条件
定期运行测试
实现自动化测试后，它可以在开发流程的每个步骤中为您提供保障。它们无需人工干预，并且可以在开发流水线的每个关键步骤上运行。例如：
- 每次提交时。
- 针对每个拉取请求。
- 每次完整发布或环境更改后。
如果您在生产环境中依赖第三方服务，甚至可以对生产环境运行测试，以确保第三方 API 的行为符合预期。
定义和收集指标
定义一组指标对于衡量测试的有效性以及测试工作流对业务的影响至关重要。以下是您可以使用的指标的一些示例：
- 每月发布次数：每月发布次数越多，表明开发流程越敏捷。自动化测试在此发挥着关键作用，可确保放心地进行发布。
- 错误报告：错误报告数量呈下降趋势可能是个好兆头，表明您的测试（和开发流程）很有效。
- 测试覆盖率：虽然覆盖率绝不是确切的指标，但它可以很好地表明您测试关键用例的深度。
请注意，这些指标还会受到其他因素的影响，这些因素可能会导致指标出现偏差。例如，在节日季期间，您的发布次数可能会减少，而 bug 报告可能会增加。因此，请不要仅依赖于少数指标，并确保将这些指标与团队可用的其他数据进行交叉映射。
当您与团队成功实施这些步骤后，您的产品健康状况肯定会从长远来看受益。不过，您还可以采取更多措施！
面向系统管理员的测试最佳实践
产品团队无法单独完成工作。它们依赖于系统管理员维护的硬件、工具和基础架构。虽然系统管理员通常不会直接参与产品开发，但他们仍然可以对开发工作流产生积极影响。例如，积极管理公司中特定用户群组使用的浏览器版本。
本文的第二部分将介绍此功能的运作方式，并介绍 Chrome 的渠道和企业政策。
Chrome 发布渠道
默认情况下，Chrome 会自动更新，以确保每位用户都使用最新、最稳定、最安全的 Chrome 版本（包括所有最新功能），即稳定版渠道上发布的 Chrome 版本。
如果您是开发基于 Web 的产品的公司，则可能需要在稳定版渠道之前使用浏览器，以便产品团队有时间根据 Web 平台的变化调整产品。
对于此用例，Chrome 提供了四个发布渠道，分别面向不同的用户群体。
对于 Chrome，您可以使用不同的发布渠道，以便预测未来的浏览器变更，并在最新功能正式发布之前对其进行测试：
- 稳定版渠道：大多数用户都使用此渠道。稳定版渠道会在有新的 Chrome 版本发布时自动更新，这种情况每月都会发生一次。
- Beta 渠道：此版本将在 4 到 6 周内变为稳定版，让您有机会预览和测试即将发布的稳定版，并做好准备。
- 开发渠道：此渠道每周都会收到一个新版本的 Chrome，其中包含最终会进入 Beta 版阶段的所有最新修复程序。正如渠道名称所示，该渠道处于开发阶段，因此可能会意外中断，但它也包含最新的功能，有时这些功能在进入稳定版之前就已推出。因此，开发渠道非常适合用于原型设计和前沿开发。
- Canary 渠道：最具实验性的渠道，包含所有最新功能，但未经过太多测试。至少每天发布一次。
如需详细了解 Chrome 的渠道，请参阅相关的 Chrome 概念系列视频。
在示例组织中使用渠道
产品团队的结构因组织而异，因为软件开发没有放之四海而皆准的方法。例如，假设一个团队包含以下角色：产品管理、用户体验和界面、工程、运营和支持。
对于这样的组织，您可以考虑以下渠道拆分：
- 产品管理：PM 通常使用稳定版渠道，以便与大多数用户使用相同的版本。如果他们正在开发需要尚未发布的 API 的功能，有时可以使用Beta 版或开发版渠道。
- 工程和用户体验：这些团队的部分成员可以使用开发渠道，以便在最新功能（例如视图转换）尚未稳定之前就使用这些功能。
- 操作：可以采用 Beta 版，以预测接下来会影响用户的故障。
- 支持：可以使用稳定版渠道，确保他们使用与大多数客户相同的浏览器与产品互动。
使用企业政策管理渠道
除了提供指南并让用户自行决定使用哪个渠道之外，Chrome 还提供企业和管理工具，以便主动管理每个用户最终使用的渠道。这非常有用，因为它可以立即将测试范围从少数个人扩大到一组确定性的用户，这有助于尽早以可跟踪的方式发现问题。
如果您想使用这种级别的控制，我们建议您采用以下配置：
- 员工（应用用户）：为最大限度地降低服务中断风险，大多数员工应使用稳定版，该版本已由 Chrome 测试团队进行全面测试。此外，一小部分用户（5% 到 10%）可以使用Beta 版渠道。此渠道可在 4 至 6 周内预览稳定版，有助于管理员发现版本可能存在的问题，从而有更多时间来解决问题，然后再向所有用户部署该版本。
- IT 部门：IT 部门的成员（包括系统管理员本人）可以使用 Beta 版或开发者版，提前 4-6 周或 9-12 周体验即将在 Chrome 稳定版中推出的功能。
长期发布渠道
产品开发可能无法按计划快速进行，Chrome 每月一次的发布节奏可能过快。对于此用例，Chrome 提供了一个扩展稳定渠道，该渠道获得功能更新的频率较低，但仍会收到安全修复程序。此渠道每 8 周更新一次。
下图显示了不同里程碑如何通过 Chrome 的不同发布渠道进行：
- 在前四周内，稳定版和扩展稳定版提供相同的版本，之后这两个版本会分道扬镳。
- 没有扩展 Beta 版渠道；而是使用标准的四周 Beta 版周期来稳定稳定版和扩展稳定版。选择加入 8 周延长版稳定版的企业应继续像现在一样运行 Beta 版渠道，以便主动发现可能会影响其环境的问题。
总结
测试是软件开发公司确保产品质量的关键环节，也是系统管理员为组织员工提供优质软件并避免业务流程中断的重要步骤。
为了在组织内成功实现测试工作流，请务必让每个人都有一个共同的理念，即质量和测试是一项功能。
在本文中，我们介绍了将测试最佳实践集成到贵组织中的不同方法。如需深入了解现有测试工具，请参阅我们的文章Chrome 中的工具，助您轻松实现自动化测试。