一十一
发表于 2018-03-14 16:40:22
摘要：
TestOps模型旨在将整个团队的注意力集中在质量上，因此TestOps确实需要无缝且可靠。 一个简单的例子是任何测试框架必须足够可靠，以至于很少有停机或连接问题。 无论何时，如果评估失败，或者延迟发布版本的反馈，都会对系统的有用性产生不好的印象。 这使TestOps团队的心态变得至关重要。
TestOps工具
对于TestOps团队来说，最重要的活动就是准确提供产品团队测试和接收反馈所需的工具。 对于敏捷产品团队和微服务的出现，出现了对新型测试基础架构的需求，而不是传统模型，其中测试环境取决于整个应用程序堆栈的可用性。
最重要的是，新组建的TestOps团队需要规划一个工作流程。
对于DevOps，构建系统是所有团队创建发布工件并执行较低级别测试的核心应用程序。 在功能测试工作流程方面，考虑到这些测试的长期运行并且通常很脆弱，从而阻碍了在失败测试中完成构建是一个问题，考虑到这一点，功能测试作为构建系统的后期过程被启动，并且因此 要求TestOps构建一个基础架构，不仅要从DevOps系统中提示它，而且要尽可能与其集成，以便为团队提供透明的工作流程。
图2 - 新测试和部署工作流程，同步DevOps和TestOps工具
要充分认识到这一无缝工作流程的价值，团队必须指定他们想要测试的内容以及何时进行测试 一个规范必须存在，TestOps可以以编程方式理解消除由人为干涉来配置测试所引起的延迟，其中包含如下详细信息：
-
定义运行测试的时间 - 每次提交，或者每当指定的标识符（在这种情况下，Github标签/版本存在）及其子集
-
给定的版本/模块/功能的测试边界
-
测试计划中都包含哪些技术
-
需要什么测试运行器命令
-
这些测试将使用哪种服务模板 - 基本上需要执行这些测试的资源和环境，例如服务器，Docker镜像等等
然后TestOps可以将这些要求转化为在构建完成后立即开始测试，测试可以在没有人为干预的情况下开始，此时QA的任务是审查测试结果。
大多数团队的功能都不足以孤立地工作，很多都依赖于外部服务。能够确保对测试和任何消费者的变更的信心是一个挑战，特别是当这些消费者通常不在同一位置或代码库时。 TestOps应该提供一种机制来配置其他模块测试可以在后期构建中使用，以确保一致性，并在没有人工干预的情况下彻底根除下游消费者的任何中断变化。 该配置最好放置在与其他测试配置相同的位置，即前面部分中提到的测试规范。 这个规范是消除风险的另一个项目，因为产品团队在大多数情况下应该最清楚他们所做的更改与哪些应用程序/平台交互的部分。
TestOps文化
在DevOps和TestOps之间基础设施的两个方面，剩下的部分是文化上的变化，以确保所有产品团队都能看到这个系统的好处，他们都投资于追求质量。最终的理想之处是能够在没有质量保证干预的情况下发布软件，因为整个团队都在测试覆盖率和质量方面投入了大量资金，DevOps / TestOps工具允许对发布状态作出快速准确的反馈。
评估
-
由于测试和发布工具的变化，我们已经摆脱了不规则的发布时间表，我们平均每周发布两次。 我们现在每周都会连续四次发布产品。
-
将构建自动部署到测试环境会减少从构建完成到测试的平均时间，从构建完成和测试开始到平均延迟为零，平均延迟1天，测试从构建完成后立即开始。 这使得测试版本平均提前1天准备发布。
-
测试和发布管理工具的这些优势和其他效率提升，我们减少了交付到生产的平均时间，从平均一周到一个工作日
-
Docker容器立即可用于运行测试，测试问题可以实现即时反馈
-
自开始这项工作以来，我们成本降低了20％
找到TestOps适合测试场景，而不会妨碍开发工作流程。 通过TestOps保障交付质量，确保团队有权随意发布，同时保持我们产品的质量水平 客户期望。
 |
TestOps中文社区公众号 |
| 微信 : wonter | |
| QQ群 : 632418478 |
