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