近年来,面向服务的架构(SOA)和软件即服务(SaaS)模型等技术领域的革新极大地影响了软件系统的特征,并促使软件从业人员朝着面向服务的业务模式转变^{[ 1]}。一切即服务(XaaS)模式以灵活、面向在线用户需求的服务逐渐取代传统意义上的本地ICT系统模式,从而彻底改变了软件产品的生产和消费方式。与此同时,由于软件系统日趋复杂,可产生高附加值的应用领域越来越多,导致软件开发过程中产生更复杂、更专业的质量需求,使得质量保证日趋成为开发过程中耗资最大的环节。云端网络环境为软件服务商提供了一个拥有广阔存储空间、带宽、标准云架构和各类应用程序接口等丰富资源的在线基础设施,使开发和测试传统的和基于XaaS模式的软件更加快捷高效。软件特征与业务模式的演化意味着与之密切相关的软件测试理论、方法和工具也需要发生改变。

测试即服务(Testing as an Service, TaaS)是将测试软件作为一项服务通过Internet提供给消费者的新一代软件测试模式^{[ 2]}。 在TaaS模式下, 测试用户通过浏览器、测试框架、 云端虚拟服务器等进行日常测试业务、 测试维护和测试支持等活动。在这一环境下,传统意义上的测试数据已无法满足TaaS模式下软件质量保证的需求;在测试过程中,服务使用者(软件开发组织)对测试数据保密性的安全需求与服务提供者对测试数据开放性的功能需求存在着不可忽视的矛盾。在此背景下,本文对应用于TaaS模式下的测试数据定义泛化问题进行深入的探讨,通过对比传统测试模型和TaaS测试模型下测试人员的角色变化,两种模式中软件结构的差异性所带来的影响等角度,引出重新界定测试数据的原因。本文提出基于测试数据新特征的测试数据管理模型,为TaaS模式下的测试数据管理提供可行的参考。

TaaS是指测试服务提供商利用云计算平台和基础设施为测试用户提供的第三方软件测试服务,包括功能测试与非功能测试(压力测试、性能测试、兼容性测试等)、测试维护和测试支持等测试服务模式,TaaS架构层次模型如图1所示:

图1

	Figure Option ViewDownloadNew Window
	图1 TaaS架构层次模型

TaaS模式对传统软件测试的影响主要体现在以下几个方面:

(1)测试环境的改变。TaaS模式与传统的软件测试的最大区别在于提供资源池化,技术虚拟化,部署分布化,使用自动化的云测试平台,可以为复杂的 XaaS模式的应用软件动态匹配所需测试资源和虚拟测试环境。柔性的虚拟测试环境使TaaS服务者提供面向软件生命周期不同环节的测试服务成为可能。

(2)测试重心的转移。TaaS模式强调面向整个业务流程,并确保流程的各个部分正常交互。TaaS的服务对象主要为XaaS模式下的应用软件,后者大部分逻辑都用于处理各个服务模块之间的连接,而不是模块内部。传统软件测试流程仍然是以软件功能模块或按垂直业务单元来进行组织,测试重心的转移是TaaS对传统软件测试影响的核心所在。

(3)测试范围的扩展。XaaS类型软件的用户对软件的可靠性和可用性要求较高,使得TaaS的测试范围由验证和确认软件功能对用户需求的满足,扩展到对软件SaaS功能和非功能性的服务要求的质量保证^{[ 3]}。

(4)商业模式的演化。TaaS模式下的测试基础设施由测试服务提供者通过私有云测试平台提供支持,TaaS提供商拥有专业测试人员,包括领域专家或众包服务,用户根据测试项目规模、测试目标和测试时间等方式按需购买。这有别于传统软件测试,后者主要由软件开发者在开发过程中调用组织内部资源完成测试流程。

测试数据是在软件测试过程中,根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一组测试用数据集合,即图1的测试数据库中软件源代码、用户数据和测试文档的总和。传统软件测试的实质就是利用这些测试数据运行程序,以发现程序错误的过程^{[ 4]}。对于传统软件测试过程而言,测试数据的分类主要有以下几种形式,如表1所示:

表1

表1

表1 测试数据分类 测试数据 种类 来源阶段 来源位置 范例 功能性 测试数据 分析与设计阶段 从软件需求分析说明书、概要设计说明书等资源中获得。 产品功能范围界定、功能需求输入、加工和输出等(出自国标软件需求说明书产品功能章节);系统错误信息处理规则、补救措施等(出自国标概要设计说明书系统出错处理设计章节)。 结构性 测试数据 设计与编码阶段 从详细设计文档、代码编写规范、元数据字典等资源中获得。 程序流程逻辑、接口规范等(出自国标详细设计说明书程序设计说明章节);元数据区间(出自系统元数据字典);单元测试用例(来自通用测试用例库)。 查错性 测试数据 编码阶段 从开发过程中产生的日志和错误消息中获得。 Info、Error、Debug等系统研发常见调试信息;底层支持系统运维信息。

表1 测试数据分类

在TaaS环境下的测试数据,笔者认为除了传统意义上的测试数据外,还包括客户待测系统各类元信息文档、系统数据库、客户组织内部文档以及受保护的系统用户敏感数据等信息资源。测试数据概念的扩展是由XaaS模式下软件开发者、测试服务提供者和软件使用者角色与职责的变化以及基于SOA的Web服务软件内部结构的变化所决定的。

在新的软件模型的影响下,对软件服务提供者而言,XaaS模式下的软件生产流程可能需要来自不同组织的开发者进行服务组件协同开发,但开发者很难对需要同外部服务组件进行交互的软件模块进行界定;与之相对的,如今的软件用户已具备技术上的高素质,他们对软件的功能和质量有着明显高于以往的期望。传统的软件测试实践,在近年发展十分缓慢,软件测试人员的工作已无法满足上述需要。因此软件开发者、测试服务提供者和软件使用者之间的关系在TaaS模式下将发生不可避免的转变。

TaaS将测试看作一项可提供给软件开发者进行错误识别、验证和确认问题的服务^{[ 5]}。通过这些服务就能将原本需要软件开发者负担的工作转接到测试服务提供者处,后者拥有足够的专业能力和技术资源来处理复杂的测试业务。TaaS中软件开发者和测试者最大的不同在于前者基于技术驱动,而后者基于流程与业务驱动^{[ 6]},因此测试服务提供者成为确保软件产品高质量的同时满足软件使用者业务需求的最终裁决者,这就对测试数据的涵盖范围提出了更高的要求。TaaS将软件可用性、用户满意度、业务需求映射作为测试议程中的一部分加以验证,这使得测试服务提供者不再仅仅是代码测试员,更成为软件用户的代理来对产品需求进行整体掌控。

在TaaS模式中,不同的测试等级和不同的软件开发周期阶段需要不同的测试目标集合。图2表明软件测试者转化为测试服务提供者后,将为软件开发者和使用者同时提供服务。

图2

	Figure Option ViewDownloadNew Window
	图2 测试者转变为服务提供者

(1)服务I为开发者提供错误侦测、代码验证和确认等服务,例如提供单元测试服务用以保证系统源程序的健壮性,提供功能测试服务以保证功能模块满足业务流程的需要,或提供边界测试、压力测试和负载测试等非功能测试服务确保软件产品能在真实的网络环境中稳定运行。这些服务在一定程度上都属于传统软件测试范畴,但测试的执行者将是独立开发组织的第三方测试服务提供者。

(2)服务II包含一系列的测试服务帮助测试者模拟软件用户以确认产品是否满足他们的需要。例如验收测试服务、Alpha测试服务和Beta测试服务等。这些服务要求测试者了解用户对软件的期望,以便作为用户代理制定出完全符合用户质量要求的测试计划和策略并构建测试用例。

从图2中可知测试服务提供者已处在核心的战略位置^{[ 7]},一般的测试服务通过自动化软件测试技术实现,对特定业务领域则可能需要来自众包的第三方测试专家的参与。测试服务提供者需要兼顾开发者对软件产品的健壮性需求和用户对软件功能的高度期望,这种职责范围的扩大,使他们的测试目标更加泛化,从而对测试数据的范围和深度提出更高的要求。因此,不同于传统测试数据的系统元信息、敏感的用户信息以及其他可能受到保护的软件开发组织内部信息都将划入测试数据的来源范围。

除了角色上的变化,XaaS模式下的软件作为基于SOA的Web服务,其自身的结构也与传统的本地ICT产品有很大的不同。其中对测试有影响的方面主要体现在^{[ 8]}:

(1)基于SOA结构的服务请求需要通过UDDI、SOAP、WSDL等标准协议选择和调用所需的Web服务,而这些协议尚未成为成熟的产业标准,对协议的验证也是测试内容的一部分。

(2)服务的开发环境无法模拟软件服务实际的运行环境,在开发过程中,受计算机资源的限制,开发者无法准确覆盖所有可能出现的运行场景。拥有云端丰富软硬件资源的TaaS测试需要为目标系统提供多样化的测试环境。

(3)Web服务发布、查找和绑定都是动态完成的,其过程的不确定性将增加测试的难度。

(4)Web服务是包含大量运行时行为的分布式应用,大量用户可能同一时间访问同一服务,因此性能和可扩展性测试也是服务测试的重要方面,需要测试者对目标系统的服务内部结构有较深的了解。

(5)由于SOA架构良好的封装性,服务提供者一般以接口的形式发布服务而不会暴露服务实现的细节,调用服务只能通过查阅服务接口信息获得,因此对于不属于软件开发组织的测试人员,如果不能拥有相关服务内部实现的信息,则无法进行白盒测试。

(6)由于Web服务是被调用而非被拥有,用户无法了解服务何时会发生演变,如版本升级或细节变更,因此服务的回归测试难以控制。

在软件开发周期中,传统软件测试和TaaS环境下的测试的比较结果,如表2所示:

表2

表2

表2 传统软件测试与基于SaaS模式软件测试比较 比较项 传统软件测试 基于SaaS模式的软件测试 测试参与 软件开发组织中的开发者和测试小组。 由服务提供者作为开发者和用户代理完成全程测试。 测试分布 集中的、多阶段的测试。 分布的、远程的和多阶段的测试。 测试覆盖 拥有软件源码, 可建立丰富的结构(白盒) 和功能(黑盒)覆盖测试模型。 除软件开发者拥有传统的覆盖范围外,第三方只有黑盒覆盖范围。 测试执行 离线测试。 在线即时测试。 测试预言 软件行为是可预知的,因此测试预言的生成较为容易。 由于Web 服务动态绑定特性,很难预测其实际的运行情况,测试预言的生成需要服务开发者提供软件元信息支持。 回归测试 离线的回归测试,测试者了解软件变更情况,能及时进行回归测试。 在线的、基于运行时收集数据的测试,除服务运营商外,测试人员并不掌握服务的演化情况,回归测试需要与软件变更有关的开发文档支持。

表2 传统软件测试与基于SaaS模式软件测试比较

可以看出,即使仅从为开发者提供服务的角度来看,传统的测试数据显然无法支持完整有效的系统健壮性测试,因此额外数据的支持是相当必要的。例如,需要为服务测试者提供必要的服务内部实现源码以解决结构覆盖测试缺失的问题。

为解决TaaS环境下测试数据的保密性与开放性矛盾问题,需要在测试数据调度过程中采取必要的措施。建议如下:

(1)在测试服务提供组织内部,建设完善的测试数据管理制度,充分考虑到软件开发者对测试数据的安全性需求与测试人员(内部的自动化测试小组和外包的测试专家)对测试数据深度开放性需求。通过在不同测试环节建立差异化的数据保密措施细化测试数据管理,并在不断的测试实践中探讨和修正测试数据的管理政策。

(2)深化测试人员的测试数据保护理念,通过访谈、培训等方式培养测试第一线的工作人员形成对测试数据保护的敏感性。同时通过技术手段加强软件测试服务平台的安全性,最大程度降低测试数据被污染的可能性。

(3)同软件开发者建立长期稳定的测试数据保护交流机制,积极学习他们在软件开发过程中数据保护等方面的经验,同时建立良好的互信合作关系,使软件开发者对第三方测试组织降低戒备心,通过健全的测试数据保护体系获得其对测试服务平台的认可和支持以建立起行业信誉。

(4)从软件服务开发者角度研究解决测试数据安全问题的技术方案。例如改进XaaS软件开发流程,能在开发过程中产生实际数据的“复制品”,以满足测试数据需求。采用这种解决方案的前提是软件开发者通过对软件系统和平台进行评估,确认可以得到一定数量的产品数据拷贝。这一过程需要通过今后的软件模式实践加以验证。

XaaS模式对软件生产环节的影响日渐增大,但即使XaaS的商业模式已初获成功,对于TaaS模式国内学术界和相关行业仍然了解甚少。本文通过分析XaaS模式下不同的软件生产活动参与者的角色变化,以及基于SOA的Web服务软件结构对测试活动的影响,对测试数据定义进行新的界定,强调将属于软件开发者的部分内部数据纳入测试数据的采集范围。在创建并分析测试数据管理模型的基础上,细分了在测试流程不同阶段测试数据管理的侧重点,从管理制度、管理理念、管理机制、技术方案几方面探讨测试数据管理策略,为解决测试数据保密性与开放性之间的矛盾提出建议。