公共应用系统一般是指某个系统或平台最基本且重要的应用系统模块，作为系统或平台中基础服务系统为其他子系统提供统一的基础参数和公共功能，对整个系统或平台具有奠基作用，在测试过程中常会涉及到多个系统模块的联调测试和演练测试。常言道“基础不牢，地动山摇”，那么我们如何合理有效地设计公共应用系统的测试环境呢？以下分五个方面进行介绍：

图1 系统或平台下公共应用系统与各子系统模块之间的功能关系

　　1、环境架构设计

　　原则上，在环境资源允许的情况下，要求统一规格的服务器和数据库，且测试环境配置尽量保证与生产环境一致。结合系统项目测试实践经验，给出系统或平台下公共应用系统环境与各子系统模块环境之间的架构设计，如下图：

图2 系统或平台下公共应用系统环境与各子系统模块环境之间的架构设计

　　开发环境：主要为公共应用系统对应的开发人员提供代码设计，以及编码完成后的单元测试、集成测试使用。

　　测试环境：主要为公共应用系统和各子系统的测试人员提供接口测试（含自动化）、界面测试（自动化、功能测试、性能测试和安全测试等）使用。同时，根据子系统需求会手动部署多个子系统的开发环境，由公共应用系统测试环境负责为各子系统接入，提供给各子系统开发人员进行代码设计、单元测试和集成测试使用。对于存在是否同期开发，是否同期测试，是否同期投产等情况，相应每个环境的具体配置情况依据现实需求及时同步部署。

　　预投产环境：用于临近投产系统的业务测试和回归测试，为拟投产项目开展各系统模块间的投产演练支持。对于投产演练计划（包括演练操作时间段、拟使用的交易清单、涉及公共应用系统协办的数据变更内容等），公共应用系统环境管理员实时数据备份，供各子系统演练使用。

　　生产环境：系统投产环境，用于系统投产后进行系统特护和生产运行指标观察。

　　2、成员沟通管理

　　公共应用系统作为系统或平台的基石，其环境版本的改动，势必牵一发而动全身，影响到各子系统的基础参数和公共功能，对各服务系统的开发和测试造成巨大影响。因此，在进行系统功能改造前，必须与各子系统业务、开发和测试等系统项目相关人员沟通确认，做到充分沟通，并达成一致。为了减少系统项目有关成员之间的沟通成本，以及测试环境人员管理成本，我们给出以下公共应用系统的沟通管理策略：

　　（1）服务方自身改造，实时告知

　　公共应用系统作为服务方，如果他的改造功能为自身功能，比如公共应用系统为自身系统管理使用的查询、下载等功能，不影响后台各系统接口间输入输出等基础参数和公共功能的，经公共应用系统对应业务和开发一致确认改造功能不影响其他子系统功能后，仅需将改动的内容备注清楚，实时告知给各子系统即可，各子系统确认是否对各自系统有影响，以及根据需要自行判定是否需要升级环境版本。

　　（2）消费方需求改造，定向通知

　　公共应用系统接收到来自消费方的改造需求，此处的消费方指系统或平台下的各子系统。首先公共系统需判断此需求的新增、修改和删除等功能是否影响第三方，这时存在两种情况：一是消费方提交的改造需求不影响第三方，仅为消费方的改造服务，那么仅需公共应用系统提供对应功能给该消费方即可，并定向通知消费方进行环境版本的升级；二是消费方提交的改造需求影响到第三方，那么就需要服务方、消费方和第三方对改造需求达成一致后，再由公共应用系统进行相应功能需求的改造，改造完成后，公共应用系统定向通知给消费方和影响到的第三方进行环境版本升级。

　　（3）服务方主动升级，全部通知

　　公共应用系统作为服务方，在进行主动升级时，影响到了所有消费方，比如公共功能和基础参数改造，那么对于服务方功能的主动升级改造，需要对所有消费方全部通知，并提示所有消费方本次改造的具体内容和可能出现的影响，通知消费方尽快进行环境版本升级。

　　3、版本部署时机

　　这里我们对版本部署时机按照服务方和消费方是否处于开发测试阶段进行划分，对三种情况进行了环境部署时机的策略分析，具体如下：

　　（1）服务方处于开发测试阶段

　　服务方处于开发测试阶段，消费方处于非开发测试阶段，由服务方测试稳定后，告知消费方此次功能改造内容，经各消费方确认无问题后，及时统一部署到各消费方的开发环境和测试环境，各消费方统一进行回归验证。

　　（2）消费方处于开发测试阶段

　　单个或多个消费方处于开发测试阶段，服务方不在开发测试阶段，那么服务方测试环境保持稳定即可，服务方无需做环境部署。

　　（3）服务方和消费方同时处于开发测试阶段

　　如果服务方和消费方均处于开发测试阶段，消费方需要根据自身需求、被影响的功能和无关功能三种情况，综合考虑是否进行服务方提供的测试环境版本升级部署。对于消费方自身需求改造，服务方在开发测试版本稳定后，经消费方同意后，进行环境部署；对于消费方功能受到服务方改造功能影响时，消费方与服务方商讨双方由谁改造，确认后进行环境版本的同步更新；对于消费方功能不受服务方功能改造影响时，服务方仅保持自身环境的更新稳定，无需给消费方实时进行环境部署支持，待到最终版本投产后，再进行统一更新。

　　4、环境部署方法

　　目前信息系统项目实施过程中，环境部署的方法主要包括自动化流水线部署和手动触发流水线部署两种，分别对应程序开发和功能测试两个阶段，简要介绍如下：

　　（1）自动化流水线部署

　　一般由开发环境配置CI/CD，持续集成流水线自动触发代码分支，实现自动化流水线部署，服务方和消费方项目组开发人员可以用流水线自动化部署程序版本。

图3 系统或平台下公共应用系统环境自动化流水线部署示例

　　（2）手动触发流水线部署

　　手动触发流水线部署指的是开发编码完成交付到测试环境的手动触发部署，主要采用“谁的环境，谁部署”原则，各消费方测试负责人负责各子系统环境部署，对应开发人员提供环境支持和相关问题解决。

图4 系统或平台下公共应用系统环境手动触发流水线部署示例

　　消费方测试负责人负责决定是否部署新版本的公共应用系统环境，但是具体部署需要公共应用系统环境对应测试负责人进行部署，公共应用系统对应开发人员负责技术支持。

　　5、环境管理及维护

　　公共应用系统测试环境和各子系统测试环境，需要指定环境管理人员，进行环境的管理和支持维护，为各环境的稳定创造条件。这里涉及到测试环境的搭建，程序部署的版本管理，以及测试环境的实时发布管理等等。环境管理是一个庞大的工程，只有合理有效地管理和安排，才能让项目实施和测试过程变得畅通无阻，让项目更加高效且保质保量的完成。

作者：李辉、裴四宝   

来源：51Testing软件测试网原创