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