基于SOA的系统软件所具有的服务性、粗粒度、松耦合等特点，不仅提高了企业平台架构的灵活性，也给软件测试带来新的挑战。根据基于SOA的软件测试的要求，本文研究了测试用例的生成和执行以及性能测试的方法，设计并实现了一个基于SOA的系统软件测试平台，该平台能够满足基于SOA的系统功能测试和性能测试的要求。该平台提高了测试的自动化程度，并为基于SOA的系统软件测试提供了实用的工具支持。
面向服务的体系结构（SOA）指的是围绕XML及其消息建立的框架，具有一些消息编码过程的标准，规定了协议语法和服务实例的位置。这些可以通过简单对象访问协议（SOAP）、网络服务描述语言（WSDL）、通用描述发现和集成（UDDI）的规范分别进行。SOA提供了通信的互操作性，服务的可重用性和兼容性，以及客户端和服务器之间的松散耦合。SOA的这些吸引人的特点加剧了系统分布、可观察性和可控制性问题。这也使得测试更加困难。巨大且异构的基于SOA的系统加剧了在可控性、可观察性和分布方面的挑战。测试用例的设计、生成和执行需要根据被测对象的WSDL、UDDI和BPEL文档来进行。由于缺乏关于系统的相关知识，定义这样的测试用例对测试人员来说是很困难的。性能测试也需要负载生成工具来协助测试人员在不同的服务负载下测试服务调用。传统的测试方法和工具已经不能满足基于面向服务架构的系统软件测试的要求。根据面向服务的软件架构的特点，设计并实现了一个基于SOA的软件测试平台。该平台可以为使用服务架构的系统软件功能测试提供用例生成和执行手段，为性能测试提供灵活可调的负载生成手段，满足基于SOA系统的软件测试要求。
为了实现基于SOA的系统软件测试平台的通用化，本文从软件测试的适用性和有效性角度分析了测试平台的主要功能需求。自动测试用例生成在网络服务的自动测试中起着关键作用[9]。自动测试用例生成需要通过分析WSDL来生成正常、异常和边界测试用例。本文采用组合测试思想，综合运用随机生成法、边界测试数据生成法和基于约束的测试数据生成法。测试用例以XML的形式保存，可分为界面测试和功能测试。接口测试只检测测试用例是否能成功执行，但不检查测试结果是否正确。功能测试可以设置预期的测试结果并验证结果。性能测试功能需要为测试人员提供负载测试工具，并支持负载参数的灵活设置，包括流量、最大响应时间、最小响应时间、平均响应时间、呼叫成功率等参数。测试执行需要根据服务传输协议的格式来打包和发送测试用例，并分析服务返回的消息。功能测试需要提供比较测试结果的功能，为测试人员提供预期结果的输入方式，并将预期结果与执行结果进行比较。此外，它还支持测试结果的图文显示。
基于SOA的系统软件测试平台分为三个主要模块：前端程序（SOATest）、测试执行程序（ServiceExecutor）和服务部署容器（SvcHost），如图1所示。SOA测试负责生成和执行测试案例以及性能测试功能。它为测试人员提供了一个编辑和检查测试用例及其执行的接口。测试用例被存储在数据库中。当测试项目需要被执行时，相关的测试配置将被发送到测试执行器，测试执行器可以安排执行。服务执行器执行测试用例，建立测试环境并管理服务容器组。服务执行器从测试用例设计者那里接收测试任务，根据指定的测试任务生成测试消息，如SOAP消息，并将这些消息发送至目标服务器进行测试。同时，在测试任务执行器上将维护一个服务容器列表，这将有利于服务的部署和控制服务的性能。SvcHost的功能是发布要测试的服务并监控服务的运行。黄页服务器（UDDI Server）用于发布服务信息，服务发布者可以在黄页中注册服务信息，方便检索和使用。代理转发网关（RedirectProxy）用于监控不同服务之间的消息流。基于SOA的系统软件测试平台采用标准SQL数据库，匹配MySQL和SQLite数据库。它支持导入和导出XML格式的文件。表1-3是主要的数据库表。执行 _ env _设置用于存储测试案例的运行环境信息，每条记录存储一个服务的虚拟化配置选项。功能性_test_案例存储了原子测试案例的基本信息，包括测试案例的名称，要执行的服务，以及测试运行的环境。详细情况如下：操作_sequence_test_case 记录测试案例的功能。它的主键是project_id。该表包含一系列的关键字，如测试用例id，测试用例名称，服务空间名称，服务名称，端口名称，操作名称和测试用例输入。本文将测试分为三种基本类型：接口测试、功能测试和性能测试，每种测试类型对应不同的测试案例形式。接口测试主要是测试服务间接口的正确性。功能测试主要测试最小服务单元的功能正确性（如标准Web服务的操作、DDS服务中的IDL结构、REST服务中的资源等）。性能测试通过构建测试场景来测试系统的并发性能。测试案例类型的详细描述见表4。
本文采用了联合测试的思想。根据WSDL文件中的某个操作，综合使用随机生成法、边界测试数据生成法和基于约束的测试数据生成法，并结合输入中各种因素（边界、随机性等）对应的生成方法来生成测试用例。每个测试用例包括测试用例名称、测试用例ID、对应WSDL的服务地址、对应操作的端口、输入参数、预期结果等。随机生成法根据参数的数据类型、限制和生成量在指定范围内生成测试用例，以满足生成量。该平台从WSDL文件中提取各种类型的限定信息（XSD限制），如候选字符串的枚举值、字符串模式和数字类型的上限和下限，并通过平台界面提供给测试人员。测试人员根据测试要求进行调整后，数据将被传送到测试数据生成器，测试数据生成器将根据要求生成随机数据。边界测试数据的生成方法是生成整数、浮点数、时间和日期、字符串、二进制数据、URL等的边界测试输入。平台首先根据测试者定义的数据范围过滤内置的边界值，并删除不在指定范围内的数据。然后，测试者给出的范围的两端（包括刚好在范围边界的数据和与范围边界略有不同的数据）被添加到候选边界值表中。在此基础上，该算法根据测试人员所需的测试数据量，从一组边界池中随机选择，得到一个大小符合测试人员要求的测试集。基于约束条件的测试数据生成方法主要支持测试人员创建一套关于服务的约束条件描述，以表达与业务相关的数据特征，然后根据给定的约束条件描述生成测试案例。限制条件是由线性不等式和布尔公式的组合来表达的。在约束的基础上，约束组由三个运算符 “and”, “or” 或者 “not”组成。每个原子约束都是一个线性不等式或布尔表达式。表达式由约束变量、约束常数和约束操作符组成。在获得项目的基本约束条件后，利用微软Z3 SMT约束解算器获得满足约束条件的数据组合，从而生成测试数据。具体过程如图2所示。首先，从项目的约束树中提取与服务操作相关的约束，形成一个约束集；将与WSDL中的约束信息相对应的约束添加到约束集；建立从服务操作输入数据到每个约束变量的相关信息和约束变量的求解结果，即这些参数的设定值；用Z3求解引擎求解约束条件；根据求解得到的约束变量值，推导出服务操作参数值；根据参数值，建立测试所需的完整测试数据。对于小规模的性能测试任务，可以在一台测试器主机上完成。对于大规模的性能测试任务，一个测试器主机很难产生足够的并行压力，所以提出了测试集群的概念。一个测试集群由几个测试器组成。作为主测试代理，其中一个测试代理负责与SOATest进行交互，总结测试结果和设置测试环境。其他测试器的主要工作是启动并行的测试任务，必要时挂载RedirectProxy，拦截服务间的消息流，实现服务虚拟化。如图3所示，每个测试器通常被部署在不同的物理主机上，以使用更多的物理资源来启动测试。通过配置相应的参数，测试器可以被设置为主测试器和从测试器。每个从属测试器在启动时都会自动注册到主测试器，从而组织成一个测试集群。主测试器收到性能测试任务后，根据性能测试的相关配置，向各从测试器发出并发调用请求，并规定负载发生的时间间隔。虚拟服务的主要功能是在性能测试环境中模拟第三方服务。因为被测试对象的性能可能会受到第三方服务的影响。为了建立一个可靠的性能测试环境，有必要对第三方服务进行模拟，这样测试人员可以很容易地控制第三方服务的质量指标。使用虚拟服务来构建测试环境，可以在可控的环境中实现性能测试活动。该平台提供虚拟服务，通过配置虚拟服务的状态、处理成功率、访问能力、延迟等质量性能，构建性能测试环境，从而实现服务的负载和压力测试。虚拟服务的内部处理逻辑可以根据测试项目的WSDL文件随机生成输出消息内容，也可以根据测试人员设定的约束条件生成输出消息内容。该平台支持测试人员根据测试要求设置虚拟业务的质量特征：业务状态特征可设置为正常、暂停和崩溃；处理成功率设置范围为0%~100%；接入容量设置范围为1~1000000；延迟设置范围0~1000000 ms。性能测试过程如图4所示。首先，主测试器将待测试的服务部署到服务容器中，并根据测试环境的配置要求创建一个虚拟服务。然后，主测试器根据预设的性能测试负载策略划分测试任务，并将不同的负载生成要求分配给从测试器，测试器可以是主测试器也可以是从测试器。根据负载变化策略，每个测试器在不同的时间节点调用待测服务，形成性能负载。性能测试完成后，每个测试器收集服务的各种性能指标，并将其反馈给主测试器。主测试器将向从测试器和服务容器发送控制命令，拆除已部署的待测服务和虚拟服务，并将系统恢复到其原始状态。基于SOA的系统软件测试平台通过发送SOAP包来执行测试用例。测试任务由Service Executor实现，它被动地工作，并通过Web API向外界公开套接字。接口接收JSON RPC 2.0标准的任务描述。收到任务后，Service Executor将任务放入任务队列。当一个测试任务被安排好后，它将从任务队列中删除执行。这种工作模式可以保证测试任务的性能，避免大量测试任务的拥堵。测试执行过程如图5所示。第一步：由前端发送的测试任务消息被struts 2中间件拦截，并调用DoAction的消息响应类的执行()方法来处理这些消息。第二步：DoAction层级初步解压测试任务，将解压后的任务放入任务队列，在处理完任务队列前的所有其他任务后，开始处理新提交的任务。第三步：任务队列找到与新提交的任务方向相对应的JobHandler，并调用JobHandler的运行（）方法，完成对测试任务的响应。第四步：测试任务的结果被一步步反馈，最后通过struts中间件返回到测试前端界面。
基于SOA的系统软件测试平台被应用于基于服务架构的通信管理平台的软件测试项目。这个平台被用来进行功能测试和性能测试。测试案例的执行结果如图6所示。左边是测试任务的列表，显示任务的名称、发生时间和类型。右边的上半部分是测试结果的统计，以饼状图的形式显示。右边的下半部分是测试结果的细节，显示每个测试案例的执行情况。该平台通过逐步扩大预设的执行场景，构建负载和压力过程，观察被测服务系统的性能。性能测试执行完成后，性能测试执行过程中收集的各种指标可以通过多个折线图反映出来，包括流量、平均响应时间、最大响应时间、最小响应时间和呼叫成功率，如图7和图8所示。在图7中，红线表示流量，蓝线表示平均响应时间，绿线表示最大响应时间，黄线表示最小响应时间，粉线表示成功率。对于性能测试，平台将收集数据，如每次调用的请求时间、调用的完成时间，以及调用是否成功。通过分析，可以形成各种图表来显示被测对象的性能，包括不同负载场景下的最大响应时间曲线、最小响应时间曲线、流量曲线和调用执行成功率曲线。所有的曲线都可以显示在图表上，使人们对性能测试有一个总体的认识，了解性能下降的关键节点。
根据面向服务、粗粒度、松耦合的特点，本文设计并实现了基于SOA的系统软件测试平台，为功能测试提供测试用例生成和执行手段，为性能测试提供灵活可调的负载生成手段。实例表明，该平台对于基于SOA的系统软件测试具有良好的稳定性、灵活性和通用性。
参考文献：
[1]Alanazi, Sultan T, et al. “Evaluation Approaches of Service Oriented Architecture (SOA) -A Survey. ” 2019 2nd International Conference on Computer Applications & Information Security (ICCAIS) 2019.
[2]Leitner, Philipp , et al. “The dark side of SOA testing: Towards testing contemporary SOAs based on criticality metrics. ” International Workshop on Principles of Engineering Service-Oriented Systems(PESOS) 2013.
[3]Jehan, et al. “SOA Grey Box Testing-A Constraint-Based Approach. ” IEEE Sixth International Conference on Software Testing IEEE, 2013.
[4]Jehan, Seema , I. Pill , and F. Wotawa . “SOA Testing via Random Paths in BPEL Models. ” 2014 IEEE Seventh International Conference on Software Testing, Verification and Validation Workshops (ICSTW) IEEE, 2014.
[5]Bertolino, A. , and A. Polini . “SOA Test Governance: Enabling Service Integration Testing across Organization and Technology Borders.” IEEE International Conference on Software Testing Verification and Validation Workshops, 2009.
[6]R. M. Hierons and H. Ural, “The effect of the distributed test architecture on the power of testing,” The Computer journal, vol. 51, no. 4, pp. 497- 510, 2008.
[7]Jehan, Seema , I. Pill , and F. Wotawa,“Functional SOA Testing Based on Constraints, ” IEEE 2013 8th International Workshop on Automation of Software Test (AST),2013.
[8]Buchgeher, Georg , et al. “Improving Testing in an Enterprise SOA with an Architecture-Based Approach.” Software Architecture IEEE, 2016.
[9]HE Juan-Juan,DM Liu, et al. “A monic execution sequence generation method for web service testing.”,Computer Engineering & Science, 2019,41(06).分享不易，恳请点个【👍】和【在看】
