跨系统缺陷定位和调试方法研究

Research on Location and Debugging Method of Cross System Defects

张金波, 梁哲恒

广东电网有限责任公司 信息中心,广东 广州 510080

ZHANG Jin-bo, LIANG Zhe-heng

Information Center, Guangdong Power Grid Co., Ltd., Guangzhou 510080, China

文章编号: 2095-641X(2017)09-0-06 中图分类号: TP319

摘要

在电力企业大型管理信息系统建设过程中,如何做好联调测试是一个关键性的难题。而在联调测试工作中,重中之重则是跨系统缺陷的定位和调试。当前,在电力信息系统工程建设中针对跨系统缺陷定位和调试缺乏有效的方法,基本上是依靠测试人员的个人经验和水平,不利于大规模工程项目的实施。为了提高联调测试的效率和准确性,文章基于实践总结提出了一套跨系统缺陷定位和调试的方法,对跨系统缺陷的错误类型进行了归纳和定义,对测试工作所使用的方法和软件工具给出了建议,如分解法、系统法等。实践证明,这些方法的应用提高了联调测试工作效率。

关键词 : 跨系统; 缺陷; 定位和调试; 信息集成; 面向服务的架构;

DOI:10.16543/j.2095-641x.electric.power.ict.2017.09.019

ABSTRACT

In the process of large-scale management information system construction of electric power enterprises, how to do joint debugging is a key problem. In the joint test work, the top priority is cross-system defects in the positioning and debugging. At present,due to lack of effective methodology in the construction of power information system engineering for cross-system defect location and debugging, basically rely on the personal experience and level of testers, is not conducive to the implementation of large-scale projects. In order to improve the efficiency and accuracy of the joint test, this paper proposes a set of cross-system defect location and debugging method based on the practice summary, summarizes and defines the error types of cross-system defects, and the methods and software used for testing tools have given suggestions, such as decomposition method, system method, etc. Practice shows that these methods improve the efficiency of the joint test work.

KEY WORDS : cross system; defect; positioning and debugging; information integration; service oriented architecture; web services;

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所示。

图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 联调测试案例分析

图2为某公司账卡物一致性业务流程,以此流程为例来描述联调功能测试的实施方法。

图2 账卡物一致性业务流程 Fig.2 Account card in kind consistency business process

4.1 测试准备

1)查阅系统需求规格说明书、详细设计文档、接口文档等文件。

2)组织联调测试所涉及的各方人员进行讨论,包括业务专家、各系统开发商、联调测试组等。

3)梳理信息集成业务场景。

4)绘制业务场景流程图。

5)明确信息集成业务流程关键点。

6)根据系统操作手册及业务场景,编制业务场景测试用例。

7)细化系统及平台的交互图。

4.2 编写测试用例

1)业务部门将测试过程按场景划分,每个场景包含了独立系统中若干个操作步骤,场景之间的依赖关系参见《集成设计说明书》流程图。

2)结合《集成设计说明书》中的系统交互时序图、测试功能点和《协同场景操作手册》中每个场景的操作指南,并结合业务数据,编写功能测试用例。

4.3 测试执行

1)两方连通性测试(含正向连通性测试和反向连通性测试)。

2)SOA规范性测试。

3)设计一致性测试。

在上述测试执行过程中综合运用了分解法、追踪法、对比法以及系统法,最终完成了测试。

4.4 测试流程

1)测试用例:正向连通性测试。

2)测试说明:使用SoapUI工具向接口发送请求,检查测试结果与预期结果是否一致。

3)预制条件:SoapUI工具正确安装,网络连通,能成功访问信息集成平台。

4)菜单路径:SoapUI:File → New Soap Project。

5)信息集成平台:服务资产→查询→配置[6-15]

4.5 测试步骤

1)步骤1:登录信息集成平台(http://10.10.6.9: 3000),点击“服务资产”的按钮,在查询窗口输入所要测试的接口英文名称,点击“查询”按钮,之后点击接口后面的“配置”按钮,复制里面的服务地址(WSDL地址)。

2)步骤2:进入SoapUI首界面,点击左上角的“File”菜单,选择“New Soap Project”,在弹出的界面中为新建的工程填写名称(最好填写接口中文名),再把从信息集成平台获取的WSDL地址复制进去或直接导入WSDL文件,其余的默认,点击“OK”按钮(见图3)。

图3 测试步骤2 Fig.3 Second test step

3)步骤3:完成测试步骤2之后在Project下面多了一个工程(见图4),双击Request 1,右边会出现请求编辑器,左边是请求区域,右边是响应区域,然后把SOA生成的空报文替换为有参数的接口报文,至此SoapUI的设置结束,需要运行直接点击左上角的绿色小三角即可,向接口发送请求,右边会显示回复的结果报文,依据实际情况具体分析结果是不是自己想要的。

图4 测试步骤3 Fig.4 Third test step

5 结语

在对基于SOA的大型集成信息系统进行深入分析的基础上,本文提出了跨系统缺陷定位和调试的一般过程,建立了跨系统缺陷调试的通用理论方法,最后建议了实际调试所需用到的软件工具,可以提升大规模信息系统集成联调测试工作的效率,并提高测试人员的水平。跨系统联调测试技术发展是一个逐步完善的过程,相关技术和功能需要在工程实际中进一步验证和完善。

(编辑:张钦芝)

参考文献

[1] 计算机软件测试规范:GB/T 15532—2008[S]. 2008.

[2] 计算机软件测试文档编制规范:GB/T 9386—2008[S]. 2008.

[3] 软件工程软件测量过程:GB/T 20917—2007[S]. 2007.

[4] 罗作民, 朱燕, 程明. Web服务测试工具SOAPUI及其分析[J]. 计算机应用与软件, 2010, 27(5): 155-157.

LUO Zuo-min, ZHU Yan, CHENG Ming.Web service testing tool SOAPUI and its analysis[J]. Computer Application and Software, 2010, 27(5): 155-157.

[5] 刘鹏飞. Web服务测试工具的设计与实现[D]. 呼和浩特: 内蒙古大学, 2016.

[6] 刘航. 基于服务网络的Web Service开发工具的设计与实现[D]. 天津: 天津大学, 2009.

[7] 郑蓉蓉. 基于WSDL/SOAP接口的测试系统研究与实现[D]. 北京: 北京邮电大学, 2009.

[8] 许蕾, 李言辉, 陈林, . 一种面向用户需求的Web服务测试方法[J]. 计算机学报, 2014, 37(3): 512-521.

XU Lei, LI Yan-hui, CHEN Lin, et al.A web service testing method for user needs[J]. Chinese Journal of Computers, 2014, 37(3): 512-521.

[9] 杨利利, 李必信. Web服务测试问题综述[J]. 计算机科学, 2008, 35(9): 258-265.

YANG Li-li, LI Bi-xin.Testing web service: a review[J]. Computer Science, 2008, 35(9): 258-265.

[10] 白凯, 崔冬华. 基于JUnit自动化单元测试的研究[J]. 计算机与数字工程, 2010, 38(2): 52-55.

BAI Kai, CUI Dong-hua.Research of automatic unit based on JUnit[J]. Computer & Digital Engineering, 2010, 38(2): 52-55.

[11] 郭双宙, 梁金兰. 自动测试系统软件框架的设计与实现[J]. 计算机测量与控制, 2009, 17(1): 224-227.

GUO Shuang-zhou, LIANG Jin-lan.Design and implementation of automated testing framework[J]. Computer Measurement & Control, 2009, 17(1): 224-227.

[12] 耿艳萍. SOA架构在电力信息系统中的应用研究[J]. 电力学报, 2013, 28(4): 332-335.

GENG Yan-ping.Research on application of SOA in electric power information system[J]. Journal of Electric Power, 2013, 28(4): 332-335.

[13] 杨启亮, 崇大平, 刑建春, . WebService Behavior技术及其应用研究[J]. 计算机应用与软件, 2008, 25(2): 146-149, 177.

YANG Qi-liang, CHONG Da-ping, XING Jian-chun, et al.Study of webservice behavior and its application[J]. Computer Applications and Software, 2008, 25(2): 146-149, 177.

[14] 软件工程—软件产品质量要求与评价(SQuaRE)商业现货(COTS)软件产品的质量要求和测试细则: GB/T 25000. 51—2010 GB/T 25000. 51—2010[S]. 2010.

[15] 袁士君, 艾中良, 李喻. 基于用户需求特征的Web服务动态组合方法研究[J]. 软件, 2015, 36(3): 69-74.

YUAN Shi-jun, AI Zhong-liang, LI Yu.Research of web services combination recommendation based on user demand characteristics[J]. Computer Engineering & Software, 2015, 36(3): 69-74.

  • 张金波(1979-),男,湖北襄阳人,工程师,从事电力信息系统运维及测试工作;

  • 梁哲恒(1986-),男,广东广州人,工程师,从事电力信息系统运维及测试工作。

  • 目录

    图1