测试环境管理概述

在进行测试环境管理的介绍前，先确定两个概念：测试环境和测试环境管理。

1.什么是测试环境？

“测试环境（Testing environment）是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。稳定和可控测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现”

2.什么是测试环境管理？

“通过一系列方法来规划、管理测试环境，减少因环境自身问题对测试活动带来的影响，以提升测试工作效率和质量。”

测试环境管理价值

测试环境是众多测试活动的土壤，无论后续如何完备和有效的 CI/CD 原子能力都需要扎根到这片土地上，只有完备的测试环境才能更好的发挥各项测试活动，减少因环境自身问题带来的误报，也会使得自动化度量更加准确，因此测试环境的有效管理对于后续的测试活动意义重大。举两个实际例子更能说明测试环境管理的价值：

例 1：在当前日益严峻的环境下，线上环境与线下环境在存储、网络、流量等方面的隔离，在很大程度上能够减少因安全合规问题所带来的风险，而在线上线下环境完全隔离后如何有效的开展开发测试活动？这里测试环境管理就是一个极为重要的解决方案。

例 2：当业务需求快速迭代，尤其是微服务的架构体系下，一个微服务可能同时涉及多个需求，而如果只有一套测试环境的话，会造成代码在测试环境的相互覆盖影响测试活动，这里也需要对测试环境的有效管理。

因此测试环境管理无论对外保证安全合规以降低风险，还是对内保证并行需求迭代以提升交付效率，都有着重要的价值。

测试环境管理实现

在介绍测试环境管理实现落地步骤前，先介绍在实际产品研发生命周期中不同阶段推荐使用的环境。

1. 环境使用推荐总览

在整个产品研发生命周期中，存在各个阶段，主要分为开发阶段、测试阶段、验收阶段、上线阶段，在各阶段中有不同的环境使用推荐。

环境：环境可分为线上环境和线下环境

• 线下环境：除基准环境外，都可用于需求联调测试

• 线上环境：不允许用于联调测试，预览环境也仅是用于预览真实数据

不同阶段环境使用建议：

• 开发阶段：基于开发机、功能环境进行编码、自测、联调

• 测试阶段：基于功能环境进行自动化测试、手工测试

• 验收阶段：是发版审查正式上线前，为了保证用户使用体验而进行的集体确认设计 &开发质量的过程，基于预览环境进行小流量的预览体验，而非测试阶段

• 上线阶段：线上环境部署、更新基准环境

2. 测试环境特性和定位

测试环境管理的第一步就是要确定不同种类测试环境的适用场景及明确定位，虽然都称作测试环境，但测试环境间也有很大差异，胡乱使用会影响测试环境稳定性与测试数据准确性，从而对研发测试活动效率带来严重影响。一般来说测试环境可分为三大类：本地开发机环境、基准环境和功能环境，本文将着重介绍后两种环境。

1. 基准环境：基准环境中部署的代码分支为上线分支，同时基准环境中无论是代码还是配置都需要与线上保持同步更新，它的主要作用是用于其他服务来进行联调测试，而非自身服务进行需求测试，也可以理解为基准环境是一个'底座环境'，为别的服务联调提供帮助。因为它的特殊'使命'，所以要保证基准环境高稳定性，具体实践措施后续表述。

2. 功能环境：功能环境中部署的代码分支为开发分支，主要用于开发工程师自测联调、测试工程师测试。如果一个服务有多个并行需求，则我们可以针对不同需求创建多套不同的功能环境。同一个微服务可以进行多套功能环境部署，不同的功能环境可以通过环境标志进行区分。对于一个微服务而言一般包括一套稳定的基准环境（基准环境长期稳定存在）和多套功能环境（短期存在并且定期销毁)。

3. 测试环境使用规范

在确定好测试环境特性及其定位后，为了更准确的使用不同种类测试环境，我们需要根据测试环境的不同特性去确立相应的测试环境流程规范。

1. 基准环境：基准环境是对外提供联调服务的环境，要保证与线上环境代码的一致性及高稳定性，因此基准环境必须部署发布分支代码而非开发分支代码(和线上保持一致)，并加入到上线流水线中(以保证及时同步)；

2. 功能环境：

• 研发同学自测或联调测试，必须创建功能环境，基于此环境联调通过，方可提测；

• 提测后产品经理和测试工程师需直接使用功能环境进行验收测试，不能使用基准环境进行测试；

4. 业务团队宣讲和培训

在确定测试环境使用规范后，需要找到试点业务进行宣讲培训，试点业务选取的标准可参考以下三点：

4. 新业务：可以选择新业务，原因是新起业务没有过多的历史包袱和技术债，相对于已经特别成型的业务在修改代码配置和使用习惯上会相对容易些；

5. 迭代较频繁业务：测试环境使用规范是否符合业务实际情况，需要反复尝试摸索，而核心业务的频繁迭代上线也增加了这种验证的频率，使得问题能更快的暴露和被解决(当然也要更为谨慎)；

6. 熟业务：笔者认为这是比前两点更重要的点，在测试环境使用规范实施落地中一定会遇到许多问题，不断调整小步快跑是一个不错的选择，同时我们也要认识到很多问题并不是单个角色就能搞定，因此选择一个你比较熟悉的业务(或者是跟业务的开发工程师和测试工程师都比较熟)，在推进中配合度更高也会使得效果的达成更有把握。

5. 测试环境创建和更新

在业务团队进行测试环境管理时，我们需提供一些方案降低测试环境创建和更新的成本，主要分为以下几种：

4. 流水线模式：这种模式是人工操作成本很小的方式，通过配置流程，在开发工程师 push 代码到开发分支后，即可自动进行功能环境的创建，同时随着不断的 push，功能环境也会随之进行更新，保证了功能环境的代码更新及时性；在测试完成后代码合入到发布分支，则自动触发上线流水线，以执行上线流水线中基准环境的更新，这样能保证合入到基准环境的代码都是在功能环境进行过充分测试的，以此来保证基准环境的稳定性，同时也能保证基准环境与线上环境的代码一致性；

5. 平台创建模式：流水线模式需要事先配置，并且一般流水线上都会配置多个原子能力，整体部署时长较长，而一些简单的自测也可以选择平台创建模式，开发工程师在平台输入服务名称、代码分支、环境标识，一键创建功能环境，即可在功能环境进行自测和联调。合入到发布分支后，也可在平台进行基准环境的更新部署；

6. 本地创建模式：开发工程师通过本地开发机或者是 IDE 上安装对应插件，可以将本地代码编译部署到功能环境中；

6. 测试环境访问

在测试环境部署更新完成后，进入到测试环境访问阶段，而对功能环境的访问不同端方式也各不相同。

• 服务端：可采用直接访问后端接口的方式，因为测试环境与线上环境域名不同，通过域名替换、更改环境标识的方式来进行功能环境访问；

• 客户端：通过端上的配置，输入对应的环境标识，将客户端请求发送到功能环境；

• Web 端：可在浏览器进行环境标识的配置变更，发送对应请求到功能环境；

7. 测试环境销毁

随着需求迭代的不断增加，功能环境数量也随之不断累积，有很多功能环境随着需求的结束而不再使用，新的功能环境又在不断的被创建出来，这就造成了极大的资源浪费，为了解决这个问题我们需要对测试环境进行销毁，环境的销毁主要有以下几个方式：

1. 流水线回收：在测试流水线进行配置，当功能环境被创建后会进入[人工卡点]阶段，测试工程师/开发工程师在此功能环境进行对应测试活动，测试任务完成后，由测试工程师或开发工程师点击[人工卡点]通过，此时流水线继续执行以回收功能环境；

2. 长期未使用销毁：在功能环境被创建后，对功能环境进行计时，若超过设定天数(比如 15 天)，功能环境一直没有被再次更新，则给环境创建者发送通知以确认是否进行功能环境使用延期，若不延期或过时未处理，则在第二天进行环境的回收销毁；

3. 定时销毁：可在流水线配置，设定超过设定天数后，将流水线及流水线所创建的环境同时进行销毁，这样可以避免大量功能环境被销毁但失去作用流水线被保留，从而避免流水线空间越发臃肿的情况；

4. 存量销毁：按照业务维度进行归类统计，对于过去 3 个月内未有新请求访问功能环境，统一销毁；

测试环境管理误区

1. 测试环境管理重要但不紧急？

测试环境管理过程中，每个阶段的推进都会遇到问题，甚至在早期试点落地可能也会影响研发效率，这时有些人会想测试环境确实是重要，但跟业务的需求迭代相比这件事的落地是不是没那么紧急？其实测试环境管理并非是重要不紧急的事情，也跟业务所处的阶段及外界环境有紧密关系，在业务的早期发展过程中，层出不穷的新功能可能是大部分人所关心的，而随着业务不断扩大、影响范围越来越广，业务在求发展快的时候更要求稳，保证安全合规，而测试环境管理就是避免安全合规问题的重要解决方案，因此它是一个重要且紧急的事项。

2. 测试环境管理应该谁来负责？

测试环境管理所涉及的服务、组件、中台、架构等各方面极为繁杂，并没有任何一个角色能够完全推进负责，就像在使用测试环境的过程一样，每个人不仅仅是测试环境的使用者，更是测试环境的建设者，每个人都需要有意识的把负责的服务测试环境稳定性提升上来，这样整体业务的测试环境稳定性才能有保障，大家要为自己的测试环境负责，这里包括测试环境稳定性、数据丰富度、测试环境功能补齐等各方面。