概述
面对当前应用系统之间的关联关系复杂，尤其是渠道类应用系统，后台关联系统更为庞大，任何后台环境的可用性出现问题都会直接影响前台渠道类应用的联调与测试问题，本文提供了基于自动化测试案例的测试环境监控解决方案，实现对外提供服务类环境进行精准监控。通过对上下游环境建立链路监控配置、上下游环境和上下游交易码的一致性校验、监控环境关联关系视图、监控项调用视图、监控链路分析等技术手段建立完整的监控体系，最终生成全链路环境可用性状态报告和监控实时预警信息，对于测试环境可用性提升、开发测试效率提升具有积极意义。
下文主要从对外提供服务环境建设和监控、监控调用关系配置和分析、监控环境关联关系统一视图、基于链路的监控结果分析策略、监控状态报告和预警等方面对测试环境的监控解决方案进行重点阐述。
关键词：对外服务环境、链路监控、环境调用关系视图、链路分析、可用性度量
环境对外提供服务能力
面对测试环境越来越多，关联关系越来越越复杂的实际情况，环境的管理和使用面临以下突出的问题。
高可用：环境管理的精细化、高可用越来越重要。
版本更新问题：环境的版本更新频繁，造成关联的消费方系统无法正常使用，且无法提前感知问题。
关联关系问题：环境之间的关联关系复杂度不断提升，系统由于开发测试需要，修改和调整关联关系的情况经常存在，影响关联系统的正常使用。
问题排查：关联系统太多，交易做不通时需从前往后排查，具体是哪个系统的问题。
针对以上环境使用中存在的突出问题，在环境的统筹规划中，重点强调本系统环境的对外提供服务能力。该对外提供服务的环境可以是UAT测试环境、回归测试环境，也可以其他相对稳定环境，重点强调环境的对外提供服务能力，同时针对该对外提供服务的环境进行监控，当该对外提供服务环境不可用时，提供基于链路的监控预警信息，实时反应链路的可用性状态。
监控调用关系视图
利用业务自动化案例结合环境信息，基于分层监控的思路，建立产品功能从渠道到中间关联系统到核心系统的全链路监控。层层梳理，绑定关系。形成从前端到后台的监控项调用关联关系树，如下图所示（A、B、C、D为从渠道到后台的各个测试环境）。同时，在保证上下游监控环境一致性方面，面临2个主要问题。
B节点的存储结构如下JSON:
{ "mid": "20041821333300457", "name": "B-贷款查询", "children": [{ "mid": "20042009543604967", "name": "C-贷款查询", "children": [{ "mid": "20041411211057505", "name": "D-贷款查询", "children": [] }] }]} |
上下游环境连接一致性：由于一个系统有多套环境，需要保证上下游环境配置的监控项环境连接关系正确，避免存在无关联的监控。
上下游环境监控的交易一致：要达到监控功能的准确无误，避免上下游配置的监控项监控内容不一致造成，造成监控失效的问题。
针对以上问题，采用如下解决方案：通过监控环境地址信息与监控项执行地址信息校验，保证监控环境的正确性。通过上下游关联监控项交易码的校验，保证上下游之间监控交易接口的一致性，从而实现对外服务环境的精准监控。
监控环境关联关系统一视图
前文强调对外服务环境的监控和管理，但是如何体现同一个系统的不同环境种类，环境之间的即时连接关系是什么？本课题试图建立基于监控关联关系抽取的环境统一视图，通过提取监控配置中环境之间调用关系信息，建立环境调用关系视图，实时反映环境之间的链接关系。
监控平台通过对接环境基础信息平台，实现监控平台监控环境与环境基础信息平台的一致性。采用不同的颜色表示不同的环境类型，分类如下表所示：
例如下图中：A（UAT测试环境)——>B(回归测试环境)——>C(仿真环境）——>D系统（开发环境）调用联系（示例）。
监控方案及状态报告
测试环境是一个长链条，尤其对于渠道系统来说，链条中的任意一个中后台系统出问题都会导致前端系统的不可用，为了准确度量系统的可用性，就要区分出当前的问题是系统自身故障导致的还是由于关联系统的故障造成的当前系统不可用，因此我们对环境的状态做出如下定义：
可用：本环境业务功能监控项执行成功。
不可用：本环境业务功能监控项执行不成功，关联环境监控项执行不成功。
故障：本环境业务功能监控项执行不成功，关联环境监控项执行成功
由上可知，故障为问题节点，不可用为故障引起的环境失败。
例如有A、B、C、D4个系统，调用关系为A->B->C->D。如下图所示，根据A、B、C、D各个节点的执行状态，判断各个节点的可用性状态见结论。
根据前文所述的链路监控思路，通过链路分析，可以生成监控执行报告，如下图所示，在同一个功能的上下游监控结果中，红色为故障节点，黄色为不可用节点，绿色为环境可用，然后根据执行数据计算可用率、不可用率，故障率，根据3项数据可以知道当前环境的可用状态情况。
可用率 = 可用次数/总次数 *100%
不可用率= 不可用次数/总次数 * 100%
故障率 = 故障次数/总次数 *100%
同时，在环境执行失败的时候，会及时告警，告知环境管理员、监控配置人员、其他环境使用干系人，目前环境的状态及对应下游的运行状态，便于环境管理人员提前排查问题，减小环境问题的影响范围。
如下图示例：调用关系为A->B->C->D，根据上述定义，D环境为监控执行成功环境状态为可用；C环境执行失败，为故障节点；A,B环境节点都执行失败，为由于C节点的故障产生的不可用。因此可以定位问题出现在C ,通过邮件通知干系人，干系人可以快速定位问题出现原因，提升测试过程中问题解决效率。
结语
本文针对银行复杂系统关联关系背景下，当某节点出现问题后，需要上下游各个节点逐级分析问题，问题排查解决工作复杂，消耗时间长的问题。利用环境基础信息平台、业务自动化案例、邮件服务等，建立了对外提供服务上下游环境关键场景的精准监控，同时结合上下游链路分析系统、可用性度量算法，实时生成可用性报表，即时反应环境的可用性状态，并对环境不可用链路信息实时预警。实现了复杂银行系统下环境状态提前感知能力，对于推进环境可用性提升具体积极的意义。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
