0 引言
跨系统的业务场景是指业务需要在2个或者
2个以上系统/平台进行操作或者数据流转。联调测试是针对跨系统的业务场景（即系统间外部接口）进行业务流和数据流的测试,不含系统自身的单元测试、内部集成测试和交付测试（含功能、性能和安全测试）。联调测试可分为联调功能测试、联调非功能测试（含性能和安全测试）。测试内容主要包括：①依据系统需求规格说明书、详细设计文档及SOA相关标准,检查接口是否遵循设计要求、安全规范;②通过自动化工具及人工验证的测试方法,验证系统间接口的规范性、数据匹配性、连通性及性能效率、接口系统配置合规性、应用及数据的安全性等,并验证其抵御恶意攻击的能力,以达到减少系统试运行调试成本的目的[1]。
当前,在电力企业大型管理信息系统工程建设中,尚缺乏针对跨系统缺陷定位和调试技术的专门研究,联调测试基本上依靠的是测试人员的个人经验和能力,导致了缺陷无法定位、缺陷定位不准确、调试效率低下等问题,无法满足大规模信息系统工程建设测试的需要。因此,亟需建立一套完整的工作方法和流程,辅以相关的软件工具,以指导联调测试工作。
本文基于广东电网大型管理信息系统建设工程中联调测试的工作实践,提出了一整套的跨系统缺陷定位和调试的方法,归纳和定义了常见错误类型,规范了测试工作流程,并对具体调试工作所需工具给出了建议。
1 跨系统缺陷定位和调试的工作流程
跨系统缺陷定位的工作流程包括5个阶段,分别是入口、调试准备、调试中、缺陷验证以及调试总结,各个阶段又包含各自的子过程。
1）入口：缺陷单描述缺陷的完整信息,能帮助调试人员复现缺陷。
2）调试准备：包括技术文档收集、测试环境准备、调试工具安装部署、报文或场景数据准备等子过程,交付物可以是测试用例（包含测试数据）。
3）调试中：包含复现问题、收集过程记录（日志、报文、数据库、界面提示等）、假设原因、验证假设、波及分析等子过程,交付物是问题指向主体说明文档。
4）缺陷验证：包含缺陷验证、回归测试等子构成,交付物是缺陷分析和修复报告。
5）调试总结：缺陷分析和修复报告。
2 跨系统缺陷类型的定义
根据缺陷发生时的特征,将跨系统的缺陷划分为7个大类、20个小类。
2.1 环境配置问题
环境配置问题主要涉及到网络、中间件、数据库、服务器、客户端、操作系统,这6类设备的问题可能导致接口无法联通,或者接口性能无法满足要求。
2.2 应用配置问题
应用配置问题主要有权限账号配置、流程配置以及接口配置这3类问题。
2.3 接口连通性问题
接口连通性问题主要有两方连通性、三方连通性、多方连通性问题。
2.4 接口规范性问题
接口规范性测试主要对请求/响应报文的格式、内容是否符合SOA应用技术规范和设计要求进行验证,不符合接口规范性的问题,通常归类为接口规范性问题。具体有以下几类：服务命名问题、服务报文设计问题、服务实现问题、服务异常处理问题、大数据量处理问题以及其他相关约束问题。
2.5 接口一致性问题
接口一致性问题定位在应用系统服务的开发和实现是否严格遵守系统设计的规范和要求进行,包括应用系统的服务实现在命名、接口、功能、性能以及异常处理等方面与具体规格的设计描述保持
一致。
2.6 数据问题
各系统间数据交换时需要将基础数据做好映射,即各系统间的基础数据信息存在并保持一致。在数据交换时存在数据映射问题引起缺陷,此类问题定位数据映射问题;如在接口连通性测试时,SOA的响应报文返回的异常信息显示“接口数据映射找不到”,此时的问题主体可能为接口数据映射。
2.7 业务逻辑问题
在实施接口功能性测试时,需要制定业务测试场景并且确保业务场景符合联调实际测试需求,如果测试操作不符合操作手册和应用集成设计说明书,将会导致测试失败,接口不能成功调用或者不能查到接口响应消息,此缺陷则定义为业务逻辑问题。
3 跨系统缺陷调试的方法和工具
3.1 跨系统缺陷调试的过程
跨系统缺陷调试的过程如
图1 跨系统缺陷调试的过程Fig.1 Cross system defect debugging process
1）问题重现。当收到一个问题的报告时,应首先在测试环境进行程序的运行,观察在当前环境下是否可以重现问题,以确认这个问题是一个偶发性现象还是一个真正的缺陷。经此步骤可以排除掉网络端口不通等偶发性问题,使调试人员可以集中精力关注真正的缺陷。
2）信息收集。联调环境包括多个应用平台,牵涉到多个应用的时候,需要调试人员对系统架构了然于胸,清楚每一个应用在整个系统交换中的输入、输出、处理过程,以及每一个不同的模块具体负责的功能。根据复现步骤,通过调试工具,收集并分析缺陷信息,包括问题表象、操作步骤、实际输出的结果以及预期输出的结果。除此之外,调试人员也需要收集其他相关专业的信息,如日志/报文信息、数据库数据信息、界面显示信息等。
3）提出假设。调试和测试的区别是,调试不仅要测试以发现缺陷,而且还要找出问题原因和问题解决方案。经验丰富的调试人员可以根据已有的数据资料,大胆提出假设,如果假设有效则可以大大缩短调试所需时间。如果环境涉及多个平台或有多个应用主体,可能需要多次尝试才能形成有效的
假设。
4）验证假设。在测试工具的辅助下,对相关应用运行并察看所涉及的日志、报文、数据库数据、界面数据的变化,以验证对于问题的假设是否正确。很多情况下,这个假设和数据流相关,按照数据流方向,对每个主体做正确性判定,找到问题指向主体。
5）对缺陷解决方案做相关性分析。一般而言,开发人员在解决缺陷过程中,关注的是缺陷的一个点,而作为一个软件产品,需要注意的是整个软件的全面表现,因此需要对缺陷解决方案做相关性分析,保障回归测试的充分性。
3.2 跨系统缺陷调试的方法
3.2.1 分解法
当在应用场景中测试问题时,需采用一系列的步骤来重现这个问题,分解法就是把一个要重现的问题分解成几个最小的解决步骤,以更好定位缺陷。应用分解法可以实现以下目标：①每次只需要重新测试其中一个步骤,从而提高了测试的效率;②有效地隔离问题;③在测试过程的每一个步骤中只需要检查系统中有限的一些症状,就能发现引起问题的原因,例如三方连通性缺陷,将问题分解为提供方-SOA间连通性和SOA-消费方间连通性。
3.2.2 追踪法
在跨系统调试的过程中,追踪事件的最精确的办法是记录并查看应用运行的报文/日志,通过查看报文/日志可以知道事件发生的时间、地点、操作步骤、环境因素和系统其他假设条件,同时记录输入、输出以及处理过程。如果系统记录的报文/日志己经有了正确的输出,就不需要进行重新开发或者调试,同时这些正确的执行记录也为快速执行回归测试和问题重定义认证测试提供了有效参考。
数据追踪法有几种方式,最常见的是在应用内部嵌入相应的日志或者跟踪信息,通过相应的记录对其进行分析;还有一种是应用一些外部工具,截取传输报文,然后对相关的内容进行分析,例如SoapUI工具模拟接口报文数据,向SOA发送数据,SOA日志系统中记录该报文信息及响应信息。
3.2.3 比较法
比较法是通过对比系统正常工作时的状态和系统异常工作时的状态,从而发现其中的差异,以便快速定位缺陷。常见的差异情况有：①假定测试数据对问题影响;②假设最近的修改使系统出错,导致bug突然出现。如果是第一种情况,就需要参考正确的测试数据案例,通过比较法,找到正常数据;如果是第二种情况,则需要对版本进行比较,并进行针对性分析。
3.2.4 系统法
系统法就是从整个系统的功能方面来验证缺陷,而不是只考虑相关的子系统功能或者单系统功能,只有这样才能测试出接口的修改对整个系统的影响。系统法要求首先掌握系统的整体业务逻辑,以业务逻辑为基础可以定位到引起问题的原因;其次了解系统的所有组成部分,理解不同的子系统或者单系统的接口。
在定位缺陷上使用系统法,必须追踪每个模块的输入和输出、系统运行的过程和接口调用模块的结果。依据上述条件对系统进行过程测试,发现出现问题的部位,以便尽快以系统法解决问题。对于一个复杂的环境和系统,通常很难对系统的总体架构、各个子系统的各个业务模块和子系统之间的接口有着充分的理解,所以在进行系统测试时需要把开发系统的相关人员和测试人员集合在一起共同定位缺陷,这也是应用系统法的一个必要条件[3]。
3.3 跨系统缺陷调试的工具
1）SoapUI。SoapUI是一个开源测试工具,通过Soap/Http来检查、调用、实现Web Service接口的功能/负载/规范性调试测试[4]。
2）Eclipse。使用Eclipse模拟发送数据,通过查看busdown日志,来进行JMX接口的功能/规范性调试测试[5]。
4 联调测试案例分析
