可复用测试用例库（通用3篇）
可复用测试用例库 篇1
0 引 言
随着软件产业化发展,软件的功能越来越强大,软件的复杂度也越来越高,更好地保障软件质量成为亟待解决的难题。在整个软件开发过程中,软件测试占有举足轻重的地位,是保证软件质量的重要手段。测试用例复用技术的发展,大大提高了软件测试的效率,更好地保证软件质量。形式化方法描述是提高测试用例复用的一个有效途径。
软件测试可分为基于代码的测试和基于规格说明的测试[12]。基于代码的测试对编程语言、开发和运行环境具有很强的依赖性。为了增强测试用例库中用例的可复用程度,本文将定位于基于形式规格说明的测试用例库建设。从规格说明产生的测试用例和环境具有相对独立性,从而使得这些用例非常适合于可复用测试用例库的建设。
1 形式规格说明语言
为了将规格说明准确地表达出来,通常采用一种新的软件开发范型,即通过形式化、规范化的数学理论,用描述“做什么”来取代“怎么做”,这就是形式规格说明。它采用形式规格说明语言书写,具有简洁、明确、无歧义的优点,易于用计算机自动地对其进行正确性证明,能够在软件开发的早期检查软件规格说明的一致性和完整性。常用的形式规格说明语言有Z、VDM、Larch和OBJ等。
Z是目前使用最广泛的一种形式化规格说明语言,它以一阶谓词逻辑和集合论作为形式语义基础,利用集合、序列、包和函数等数学概念对目标软件系统的结构和行为特征进行抽象描述,具有简明、精确的特点[8]。其主要的结构是模式,每个模式由变量说明和谓词两部分组成。模式又可分为状态模式和操作模式。状态模式是对系统的状态空间及其约束特性的描述,是系统最基本的模式,它定义了一个系统的本质特征。操作模式定义了系统在状态空间上的操作,描述了该操作所要满足的条件以及操作前后系统状态的变化关系。
以一个登录系统为例说明:
类型定义,User表示所有用户的集合,类型Word表示所用用户密码的集合。模式上方为声明部分,下方为谓词部分。状态模式LogSys定义了系统的特征,password用User到Word的部分函数表示;reg、active分别表示注册用户和激活用户,都是类型User的幂集。模式LogIn为操作模式,描述注册用户激活账号操作。u?、p?为输入变量,谓词部分的前两个式子是表示输入变量的前置条件,即进行一个操作时输入变量要满足的条件,表示该用户已注册但未激活并且输入的密码p与用户u相对应;后面的式子反映了输入后系统的变化及约束关系。关于Z语言的细节可参阅参考文献[8]。
2 软件测试中的测试用例
2.1 测试用例在软件测试中的作用
测试用例是对软件运行过程中所有可能存在的目标、运动、行为、环境和结果的描述,是对客观世界的一种抽象。测试用例体现了一定的测试方案、方法、技术和策略。
影响软件测试的因素有很多,例如软件本身的复杂程度、开发人员的素质、测试方法和技术的运用等。测试用例是测试工作的指导,可以把人为因素减少到最少,而且会随着测试的进行日趋完善,是软件测试质量稳定的根本保障。所以说,软件测试的核心任务是编写和执行测试用例,以验证软件的质量。测试用例是软件测试工作的指导,是软件测试必须遵守的准则,更是软件测试质量稳定的根本保障。因此如何设计出好的测试用例达到最佳测试效果是进行软件测试的关键和核心[13]。
2.2 测试用例的复用
测试用例的复用就是把一个软件的测试用例在一个新的软件测试中使用或是在软件新版本的测试中使用[7]。其中包括测试用例的设计思想、具体内容、操作步骤以及测试过程中产生的信息的复用。
测试用例的复用可分为在同一软件的不同测试阶段、不同时间测试下的复用和相似软件之间的复用。同一软件的不同测试阶段中的测试用例复用是指在项目开发过程中,低层测试对象的测试用例可能部分地用到高层对象的测试中,例如单元测试的测试用例可以用到集成测试中。对一软件多个版本的测试中,如果软件在上一次测试未通过,那么产生的大量测试用例被保存下来,在新的一次测试中,可以查询找到相关的测试用例,直接导出运行来进行测试。本文提出的测试用例库,基于形式化描述,测试用例描述精确、规范、属性全面,可以根据软件所属行业、测试类型或测试输入等在库中查询相似软件的测试用例。项目间的测试用例的复用主要是设计思想、测试方法、执行步骤以及测试用例的选择和测试数据等的复用。
2.3 可复用测试用例的设计和描述
通常把软件测试分为黑盒测试和白盒测试。黑盒测试一般为功能测试,它是在已知软件所应具有的功能,通过测试来检验每个功能是否能正常使用。黑盒测试不考虑程序内部结构和内部特性,通常采用等价类划分、因果图、边界值分析等方法来生成测试用例;白盒测试是基于代码的测试,它是根据程序的内部逻辑结构生成测试用例。白盒测试生成测试用例时要依据一定的覆盖准则,包括:语句覆盖、判定覆盖、条件覆盖、条件组合覆盖和路径覆盖等。
软件测试用例复用的基本前提:一是必须有可以复用的测试用例,二是所复用的测试用例必须是有用的,三是复用者必须知道如何去使用被复用的测试用例。因此,正确刻画、描述和管理可复用的测试用例是实现测试用例复用的关键技术[6]。复用测试用例首先要对测试用例进行分类描述,这种描述是否权威、完整、可理解与规范化,则决定了该测试用例能否或多大程度上可以被测试人员所理解并接受。所以,规范化的测试用例描述在软件测试与测试用例复用中具有重要的作用。
测试用例是定义测试实现及其环境、测试输入、测试条件及为一个特定目标所开发的预期结果的集合。全面地描述测试用例并详细分类,加强测试用例的独立性。测试用例的分类涉及被测软件类型、测试的类型、软件所应用的领域等多个方面,通过合理、科学的测试用例描述和分类,降低测试用例之间的联系,提高测试用例的可复用性。可复用测试用例的形式化描述在下文中给出了定义。
3 测试用例与系统操作的形式化描述
3.1 形式化描述
规格说明首先给出类型定义:[Person,TestCase,ID,Intro,SoftwareType,TestType,ApplyArea,Senario,Input,Output,Result,CurrentStock,HistoryStock]。Person是所有人的集合,包括用户和管理员;TestCase是所有用例的集合;后面的类型定义用于描述测试用例的属性。SoftwareType表示测试软件类型,包括应用软件、系统软件、支持软件等;TestType表示测试类型,包括功能测试、性能测试、安全测试、负载测试、UI测试、数据库测试、易用性测试等。
状态模式CaseInfo定义了测试用例的信息。为了更好地实现测试用例的复用,测试用例的属性定义要全面,粒度要小,便于用户根据自己的需求在用例库系统中查找,属性值包括了ID号、用例简介、测试软件类型、测试类型、测试软件应用领域、测试场景、输入输出和预期结果。CaseStock是测试用例库和复用信息的数据库状态模式,其中变量reusetime来标示每个用例的复用次数,便于用户查找行业中使用最频繁的测试用例,提高测试用例的复用效率;变量stock、available、history分别表示当前用例库、可用用例和历史用例库;reuse是用例的复用记录,它以从测试用例到用户的部分函数形式表现出来;last_reuse记录最后复用某用例的用户。谓词部分对用户操作进行了限制,只有当前用例库中的可用用例才可进行复用。
InitCaseStock为初始状态模式。系统初始时,测试用例库中无用例,无用户,也无复用记录,但至少存在一个管理员。初始状态模式中只规定管理员集合不为空,其余全为空。
下面的模式为操作模式。模式Reuse定义了系统中测试用例复用操作。该操作会对测试用例库系统产生影响,要求测试用例是可用的,即该测试用例属于当前用例库。复用操作更改当前测试用例信息和最后复用用例的用户信息,及时更新,并将属性reusetime加1。模式AddCase定义了添加测试用例操作,输入测试用例的简介、软件类型、测试类型、输入、输出等信息。通过函数case_info,判断输入的测试用例信息是否与库中存在的测试用例信息相同,不存在则操作合法,否则为重复,不可以再添加。测试用例库中新添加了测试用例,可用测试用例和当前用例库要将新添加的测试用例包含进去。模式ApplyArea_search和 Input_search分别定义了根据被测软件的应用领域和测试用例的输入进行搜索的操作,用户和管理员都可对测试用例搜索,根据输入的属性变量值输出测试用例信息。
3.2 初始化定理的证明
对于任何系统的状态模式S,都有一个初始状态InitS。一个没有初始状态的系统一般来说是没有什么用处的。所以写下一个规格说明后,就必须证明系统的初始状态是存在的。
可复用测试用例库的形式规格说明CaseStock的初始化定理可描述为:∃CaseStock′,InitCaseDtock。先进行预处理,依据规则(∃J|P.Q)⇔(∃J.P∩Q),展开定理为:
这样该初始化定理中含有12个子目标:
子目标G1、G2、G3和G4很容易用定律L12(0∈ZΠ S)得到证明;G5显然是正确的;子目标G6、G7、G8可用定律L14(Ø∈S→T)得到证明;根据定律将dom 0重写为0,然后由定律L4,子目标G9和G10都得到证明;G11和G12根据数学定律显然也是正确的。综上,整个初始化定理得到证明,说明该系统初始状态的存在性。
4 系统实现及更新维护机制
要使测试用例库能保持永久的活力,测试用例库中的用例必须是一个动态进化、持续更新的系统,可复用的测试用例库的基本架构如图1所示。
可复用测试用例库系统为用户提供全面的软件测试服务,用户可以在此平台新建测试项目、编写测试需求、测试计划、测试用例和缺陷报告;提供统一的测试文档模板,可以在最大程度上避免测试的随意性,规范中小企业的测试流程,提高测试设计的质量。形式规格说明中的ApplyArea_search模式定义了根据测试用例中测试软件应用领域的查询操作,得到相应的测试用例进行复用操作或添加到收藏。一个测试用例经复用操作后,变量reusetime加1,系统统计每个用例的复用次数,并用图表显示各行业各领域中复用频繁的测试用例,方便用户查询,了解行业最新测试动态和信息。
如果测试用例库无法增加新的测试用例,那么该测试用例库随着时间的推移,将失去其使用价值[11]。模式AddCase定义了添加测试用例的操作,要求新添加的用例是当前测试用例库中不存在的,避免重复用例的出现。为提高复用程度,测试用例的模式定义CaseInfo是可配置的,可以根据测试项目要求添加其他属性,比如测试环境、测试用例设计方法、项目来源等信息。
测试用例库中的用例逐渐增加,部分测试用例查看和复用次数较少,或随着技术的不断改进,部分测试用例可能不再具备实际运行的条件而成为过时的测试用例,可将其移动到历史用例库。为了提高测试用例的搜索效率,删除多个测试用例来测试同样功能的冗余的或不具有复用特性的测试用例。
5 小 结
利用形式化方法描述进行需求分析,有助于发现需求中隐含的不一致性、二义性、不完整性,并对其进行更深入和更精确的理解,从而进行规范化管理。通过对测试用例的形式化描述,增强对测试用例的管理,使测试用例结构文档实现标准化,提高测试用例的复用能力。
本文提出的基于形式化描述的可复用测试用例库系统,有助于测试用例的复用和共享,可以大大提高软件测试效率,保证软件的质量。
摘要：软件测试作为保证软件质量的重要手段,是软件开发过程中的重要环节。软件测试过程中产生的大量测试用例对保证软件的质量起到了关键作用。为了共享和复用测试用例,提出了基于形式化语言描述的可复用测试用例库的构建方法,收集大量测试用例,并进行合理的分类和管理,测试人员可以从库中选择合适的测试用例直接使用或稍作修改来使用,从而大幅度降低了测试人员的工作量,极大地提高了测试工作效率,进而更好地保证软件质量。
关键词：形式化语言,Z规格,软件测试,可复用测试用例,测试用例库
可复用测试用例研究 篇2
随着软件测试的长期实施, 一般都会积累丰富的高质量的测试用例, 如果能够在以后的软件测试工作中利用现有的资源, 那么会减少测试用例设计的时间, 提高软件测试过程中发现软件缺陷的效率, 缩短软件测试的时间及成本, 保证软件产品的质量, 给软件产品的按时发布带来极大的可能。
在实际工作过程中, 测试用例在设计过程中过分依赖于被测软件, 只能在软件升级及改进的时候可以加以利用;测试用例之间一般都会存在或多或少的联系, 如有些测试用例的运行取决于其它测试用例的运行结果;每个测试工程师在设计测试用例的时候都有自己的喜好, 对测试用例的格式和结构也没有一个统一的定义, 并且对测试用例没有统一进行管理, 描述也不太充分, 这些都为测试用例的复用带来了很大的困难。
1 研究现状
随着人们对软件产品质量的重视程度的加强, 软件测试在软件开发中的重要性也越来越突出, 在软件开发中所占的成本也逐渐提高, 对于一些安全性较高的软件, 如银行系统等, 软件测试费用会所占的比重会更高。
测试用例的设计作为软件测试过程的核心, 它的优劣直接影响了软件测试的效率, 而测试用例的设计在很大程度上取决于测试人员的经验等, 如何利用已有的资源对测试用例进行重用避免软件测试过程中的重复工作, 提高软件质量, 就显的很有必要了, 很多学者对测试用例的复用进行了研究。
文献[1]提出了通过抽取测试用例操作步骤的关键词, 将其提炼为可复用的测试项集合的方法来实现对测试用例的复用, 此方法降低了测试用例复用与被测功能的相关性, 但是只是对测试用例的输入域进行复用, 对测试用例设计的思想, 设计步骤没有办法复用。文献[2]从测试用例的分类着手, 针对其具有的共性以及面向对象语言的特点, 将面向对象系统中的测试用例依据设计方法分为状态检查测试用例和状态比较测试用例, 进而提出了一个统一的测试用例生成、执行模式, 使测试用例能够独立于被测对象, 在理论上讨论了通过使用统一的调用模式, 以达到测试用例复用的目的。文献[3]针对第三方测试机构的特点给出了一种测试用例复用过程模型, 对测试用例进行统一建模组织, 并进行有效管理的思路。文献[4]提出了一种测试复用机制, 通过对测试用例进行可复用描述, 得到可复用的测试用例, 并利用刻面树作为逻辑结构, 生成测试用例库, 通过用例库的各种功能实现用例的复用。文献[5]给出了基于形式规格说明的测试用例库, 增强测试用例库中用例的复用程度。文献[6]针对航天测控软件的特点, 介绍了面向复用的测试用例的结构、组织方式, 用例复用的流程等技术, 实现了测试用例的管理和复用。
以上文献对测试用例可复用性的研究, 都把测试用例的描述作为研究重点, 分析测试用例可复用特征, 通过不同的测试用例复用策略, 生成不同程度的可复用测试用例库, 该文在上述研究的基础上, 对可复用测试用例的概念、设计思想进行详细分析, 给出了可复用测试用例库的模型, 对提高测试用例的复用程度有很好的效果。
2 测试用例复用
2.1 测试用例复用的概念
软件复用是指利用已开发成功的值得借鉴的成果、经验来开发新的软件产品的过程, 整个软件开发中的一切优秀成果都可以进行复用, 包含软件测试过程, 软件测试复用主要是重复利用测试过程中产生的测试理论、测试思想、测试策略、测试用例及测试文档等等。其中对软件测试的核心——测试用例的复用将会提高测试的效率。
测试用例的复用就是在软件测试过程中利用已经存在的测试用例的过程, 根据测试用例被复用的程度, 可以分为直接复用和改进复用, 如果搜索出来的测试用例与需求完全一致, 则直接复用现有测试用例, 一般情况下, 直接复用测试用例的情况很少, 如果搜索出来的测试用例与需求近似, 则对现有的测试用例进行修改和继承, 得到一个新的测试用例之后再复用, 即改进复用。
2.2 测试用例复用的类型
按照测试用例的复用[5]类型, 可分为以下几种:
1) 同一软件在不同测试阶段的测试用例复用
在项目开发过程中, 底层测试对象的测试用例可能部分地复用到高层对象的测试中, 例如单元测试的测试用例可以用到集成测试中。
2) 同一软件在不同时间测试下的测试用例复用
在项目开发过程中, 随着应用的推广, 新的需求会被提出来, 那么就会出现这种产品的多个版本, 在对一个软件多个版本的测试中, 如果软件在上一次测试过程中产生的大量测试用例被保存下来, 在新的一次测试中, 可以查询找到相关的测试用例, 进行测试用例的复用, 缩短了软件产品的升级时间及提高了后续版本的质量。
3) 类似软件之间的测试用例复用
同类软件的测试用例在设计思想、测试策略、测试数据、及测试步骤等都有类似之处, 通过借鉴原有的测试用例对发现被测软件的缺陷, 测试效率的提高有很大的帮助。
2.3 可复用测试用例的设计思想
要实现软件测试过程中对测试用例的复用, 必须满足以下条件:首先应该存在用于复用的软件测试用例, 如果没有测试用例可供选择, 对测试用例的复用将无从谈起;其次可复用的测试用例是有效的, 能够为将来的软件测试提供服务, 测试用例的描述应该完整, 并与被测软件的相关性降低到最小, 这样的测试用例才能满足将来的软件测试需求;最后软件测试工程师了解可复用测试用例的使用方法, 才能更好的实施测试用例的复用。在实际操作过程中, 需要对测试用例的结构有一个良好的定义, 这样才能在测试环境发生改变的时候, 测试用例能够继续利用, 那么在设计可复用的测试用例的时候要遵循的指导原则如下:
1) 测试用例之间的相关性尽量降低到最低;
2) 测试用例对被测软件的依赖尽量减弱;
3) 测试用例的描述要规范化;
4) 测试用例尽量不包含常量, 输入值用变量代替;
5) 测试用例的内容要完整, 结构要统一;
6) 测试用例的分类要合理。
3 基于复用的测试用例库模型
实现软件测试用例复用的有效途径就是建立一个测试用例库, 并按照适合领域、类型等进行多级合理的分类、组织、存储, 以便进行查找和利用现有测试用例。
软件测试的目的是尽可能的发现软件的缺陷, 发现缺陷越高的测试用例, 越有复用的必要, 在测试用例库的设计中添加测试用例发现的缺陷描述, 这样在复用测试用例的时候, 优先选择易于发现软件错误的优质测试用例;对于优质的测试用例, 被复用的测试也会越来越多, 那么, 在以后的测试用例的选取上, 也尽量选择复用次数较高的测试用例;对于复用效果好的测试用例, 或者对于测试用例复用的时候的一些心得体会也很重要, 可以指导后面的测试用例的选取, 在测试用例的结构中添加复用人的评论也至关重要。
随着测试用例库中的用例逐渐增加, 测试用例库逐渐庞大起来, 为了提高测试用例的搜索效率, 对于部分复用次数较少的测试用例, 或随着技术的不断改进, 对于不再具备实际运行的条件而成为过时的测试用例, 可将其删除或者移动到历史用例库。
在测试用例库中对测试用例发现的缺陷进行排序, 可以对相似类的软件系统所出现的缺陷有一定的预测作用。在复用测试用例的时候, 优先选择易于发现缺陷的测试用例和数据。
4 总结
软件测试对于软件产品质量的高低起着至关重要的作用, 如何提高软件测试的效率已经越来越影响软件产品是否能够按时发布, 作为软件测试的核心——测试用例的设计将变得更为重要。为了缩短软件测试的时间, 就需要重复利用以往的先进经验成果, 即复用测试用例。测试用例的复用程度, 取决于测试用例设计的独立程度及是否规范, 并且有一个有效的对测试用例进行规范管理的测试用例库。该文对可复用测试用例的设计思想进行详细分析, 提出了可复用测试用例库的模型, 对测试用例的复用有很好的效果。
摘要：软件测试是提高软件质量的关键步骤, 测试用例的设计又是软件测试的核心, 对已有的优秀的测试用例进行复用能够缩短软件测试的时间, 该文对介绍了可复用测试用例的概念及设计思想, 提出了可复用测试用例库的模型, 提高了测试用例的复用程度。
关键词：测试用例,复用,软件测试,测试用例库
参考文献
[1]胡珊, 杨丰玉, 张晔, 等.基于测试项抽取的测试用例复用方法[J].微电子学与计算机, 2010 (1) .
[2]徐仁佐, 陈斌, 陈波, 等.构造面向对象软件可复用测试用例的模式研究[J].武汉大学学报:理学版, 2003 (5) .
[3]卜国峰, 孙志刚, 丁小良.软件测试用例的复用研究[J].四川兵工学报, 2009 (5) .
[4]肖寒, 顾春华.一种基于Z规格说明的测试用例复用机制[J].计算机应用与软件, 2009 (12) .
[5]张红燕, 杨根兴, 蔡立志.基于形式化描述可复用测试用例库的研究与实现[J].计算机应用与软件, 2010 (7) .
软件测试用例可复用性度量 篇3
关键词：软件测试用例,可复用性,度量
0 引 言
软件测试是软件工程不可或缺的一个环节,是软件产品质量的重要保证。当今软件行业快速的开发过程使得软件测试面临不少困难,如测试需求不断增加,新加入的测试人员测试技能和经验不足等。采用软件测试复用是解决测试人员经验不足、提高测试的质量、解决软件测试效率的有效途径。软件测试中的复用主要包括测试过程的复用、测试方法的复用和测试技巧的复用,测试技巧的复用主要指测试用例的复用。将大量的测试用例收集到测试用例库中供测试人员使用,以实现测试用例的复用。对测试用例的可复用性进行度量是保证测试用例库中测试用例的可复用性的关键技术之一。此外,对测试用例的可复用性进行度量还能帮助测试用例库的管理员对用例库进行有效管理和为测试人员选用可复用用例时提供参考。
基于以上目的,本文开展了对软件测试用例可复用性度量的研究。
1 软件可复用性度量相关研究
NATO制定的软件复用指导性标准将可复用性定义为软件构件可以被复用的程度或范围[1]。其中的软件构件不仅包括源代码构件、还包括测试用例、需求规约、软件构架等软件过程中可复用的部分。
国外许多质量模型都提到了软件构件的可复用性,如NATO模型[2]、REBOOT模型[3]等。Jeffery S.Poulin在对众多可复用性度量方法进行了总结后,将软件可复用性度量方法分为两类:先验方法和定性方法。先验方法是根据客观的实验数据进行度量的方法;定性方法则是根据主观认同的规范和标准进行度量的方法[4]。
ISO/IEC9126:2001是业界广泛认可的质量标准,它从外部质量、内部质量和是使用质量三个层面刻画了软件质量,在内、外部质量模型中提出了功能性、可靠性、易用性、效率、维护性、可移植性等质量特性,使用质量模型中提出了有效性、生产率、安全性、满意度等质量特性[5,6,7,8]。
2 测试用例的可复用性度量
测试用例是为一个特定目标所开发的测试实现及其环境、测试输入、测试条件及预期结果的集合,是一种特殊的软件构件。测试用例相对于其他软件构件有其自身的特点,实现对其可复用性的度量需要从设计原则、描述模式等方面考虑。
2.1 可复用测试用例设计原则
本文以上海市计算机软件评测重点实验室承担的国家“863”课题为背景和所开展的软件评测项目为对象,研究得出以下的可复用测试用例设计原则:
(1) 可复用的测试用例应易于理解。
(2) 可复用的测试用例应是独立的。
(3) 可复用的测试用例应具有较好的适用性。
(4) 可复用的测试用例应易于修改、配置。
其中,原则(1)要求测试用例的描述信息完整、规范和易于理解;原则(2)要求测试用例具有强内聚性,能不依赖其他测试用例和特定的测试环境独立运行;原则(3)要求测试用例尽可能适用于较多的领域或平台;原则(4)要求测试用例具有方便修改例化和重新配置的能力,进而能在新的运行环境中工作。
2.2 可复用性度量模型TCRM
借鉴ISO/IEC9126:2001外部质量模型和使用质量模型的基础上,本文提出测试用例可复用性度量模型TCRM(Test Case Reusability Metrics),如图1所示。TCRM模型以可复用测试用例的设计原则为依据,选取易理解性U(Understandability)、独立性I(Independence)、适用性A(Adaptability)、可配置性C(Configurability)(UIAC特性)4个对可复用性有重大影响的特性作为其子特性。此外,TCRM模型还将测试用例使用质量中的可信度作为可复用性的修正特性。因为,复用者对测试用例的信任情况在一定程度上反映了该测试用例本身的可复用能力。使用可信度对可复用性的度量值进行修正,可以使测试用例可复用性的度量值更加接近实际值。使用TCRM模型后,对测试用例可复用性的度量可以转化为对UIAC特性和可信度的度量。
以下是TCRM中UIAC特性以及可信度的具体说明:
(1) 易理解性 它指测试用例使复用者能理解该用例是否合适以及如何将该用例应用于当前测试目标和测试场景的能力。复用者要复用某个测试用例,首先需要理解该测试用例,对测试用例的理解包括对测试目的、测试场景、测试要点的理解。只有对该用例充分理解后才能判断其是否能达到复用要求。所以,测试用例的易理解性直接影响了复用者对测试用例的选择,是可复用性的重要特性。
(2) 独立性 它指测试用例在运行时不依赖于其他的测试用例和特定测试环境而能独立工作的程度。通常情况下,测试用例之间存在相互联系,一些测试用例的运行环境取决于前一个测试用例的执行状态,当前一个用例因为测试环境的变化而失效时,后一个测试用例也随之失去了复用价值。因此,要实现复用,测试用例应该具有相对独立性,即测试用例之间不应该存在线性依赖。能够不依赖特定测试环境的测试用例也更容易被复用。
(3) 适用性 它指测试用例应用的普适性,包括测试场景、被测软件类型的种类,被测软件领域的广度等。测试用例的适用程度越高越容易被复用。
(4) 可配置性 它指测试用例具有被修改例化、配置的能力。测试用例通常是针对特定的测试环境设计的,需要在一定的环境中才能被执行。复用者进行复用时,目标环境与被复用测试用例所需环境可能存在差异,这时往往需要对测试用例进行修改才能实现复用。测试用例被修改和配置的难易程度也是决定其可复用性的关键因素。
(5) 可信度 它指复用者对测试用例的信任程度。可信度是测试用例使用质量的一部分,从复用者的角度出发,用例复用次数、复用者评分、复用者评论等因素都反映了复用者对测试用例的信任程度。
3 TCRM模型的实现
本文设计了一套针对TCRM模型的度量方法,该方法第一步先对可复用的软件测试用例进行统一描述,即设计一个可复用测试用例模式,所有要进行度量的测试用例使用该模式描述。可复用测试用例模式必须能够满足实际软件测试需要,并且其中的元素或子元素能方便进行统计。第二步找出可复用测试用例模式中的元素或子元素和UIAC特性以及可信度之间的关联。第三步使用对某个特性有影响的元素进行计算,得到测试用例该特性的度量值。
3.1 可复用测试用例模式
本文设计的可复用测试用例模式包括7个元素,即用例ID,前驱用例ID,版本信息,接口信息,使用信息,测试概要和测试项,如表1所示。其中接口信息可以使测试用例满足检索要求,同时也使测试用例的描述更加全面;使用信息用来记录复用者使用该测试用例时的信息;而测试项可以为任意多项,每个测试项也可以有任意多步骤。表1列出了可复用测试用例模式包括的元素和子元素,以及它们的说明,同时也给出了各个元素所影响的特性。
3.2 度量方法
测试用例使用可复用测试用例模式进行描述后,即可开始对测试用例的可复用性进行度量。可根据表1中影响UIAC特性的元素对UIAC特性进行度量,从而得到测试用例可复用性的初始值,然后再对可信度进行度量,最后使用可信度的度量值对可复用性的初始值进行修正。
(1) UIAC特性度量
1) 易理解性度量
易理解性主要根据测试概要和测试项进行度量,详细度量如下:
易理解性:U=XUTs+YUTi(0≤U≤1,越接近1易理解性越好)。
度量方法:
UTs为测试概要的度量值,UTs=WTpUTp+WTcUTc+WTeUTe(WTp,WTc,WTe为权值,表示UTp、UTc、UTe影响UTs的程度,且满足归一化WTp+WTc+WTe=1,0≤UTs≤1),若度量的测试用例没有测试目的、测试场景、测试要点的描述则UTp、UTc、UTe对应为0,反之为1。
UTi为测试项的度量值,UTi=N/Ti,Ti为度量的测试用例包括的测试项数目,该公式中N为度量的测试用例前置条件,测试操作、测试输入和预期结果的描述全部存在的测试项数目。
X、Y为变量,分别表示UTs、UTi影响U的程度,满足X+Y=1。设置X、Y两个变量是因为随着测试项数目的增加,理解测试项所花费的成本也相应增加,即测试项对测试用例易理解性的影响将增大,用Y的增减来表示UTi对U影响程度的增减。这里取Y=WY1+WY2((Ti-1)/Ti),WY1、WY2为权值,用于控制Y的取值,进而控制UTs、UTi对U的影响程度,且满足WY1+WY2=1。从Y的计算公式中,我们可以看到当测试项增加到一定的值时Y将趋于1,X趋于0,这和实际情况不相符合,因为实际当中对测试概要的理解始终影响着对整个测试用例的理解。所以,Ti>10时,取Ti=10来对Y进行计算。
2) 独立性度量
独立性主要根据前驱用例ID和测试场景进行度量,详细度量如下:
独立性:I=WPtIPt+WTcITc(WPt、WTc为权值,表示IPt、ITc影响I的程度,且WPt+WTc=1,0≤I≤1,越接近1独立性越强)。
度量方法:
IPt为前驱用例的度量值,该度量的测试用例存在前驱用例则IPt为0,反之为1。
ITc为测试场景的度量值,度量测试用例的测试场景如果包含特定的测试环境,如特定的操作系统,则ITc为0,反之为1。
3) 适用性度量
适用性度量主要根据接口信息进行度量,详细度量如下:
适用性:A=WDtADt+WTtATt+WStASt+WSdASd(WDt、WTt、WSt、WSd为权值,表示ADt、ATt、ASt、ASd影响A的程度,WDt+WTt+WSt+WSd=1,0≤A≤1,越接近1适用性越强)
度量方法:
ADt是设计技术的度量值,其值为度量的测试用例用到的设计技术与所有列出的设计技术的比值。
ATt是测试类型的度量值,当度量的测试用例测试类型为功能测试时,ATt等于1;为其他测试类型,ATt等于0.5,无明确测试类型时,ATt为0。
ASt是被测软件类型的度量值,其值为度量的测试用例所测试的软件类型数与所有列出的被测软件类型数的比值。当被测软件类型为“通用”时,ASt值为1。
ASd是被测软件领域的度量值,其值为度量的测试用例所测试的软件应用领域数与所有列出的被测软件领域数的比值。当被测软件领域为“通用”时,ASd值为1。
4) 可配置性度量
可配置性度量主要根据测试项进行度量,详细度量如下:
可配置性:C=WPCP+WSCS(WP、WS为权值,表示CP、CS影响C的程度,WP+CS=1,0≤C≤1,越接近1可配置性越高)。
度量方法:
CP是测试项中前置条件的度量值,CP=1-N/Ti,Ti为度量的测试用例包括的测试项数目,该公式中N为度量的测试用例中以其他测试项执行结果作为前置条件的测试项数目。
CS是测试项中测试步骤的度量值,CS=N/S,S为度量的测试用例包括的测试步骤数目,该公式中N为度量的测试用例中能独立于前后测试步骤的测试步骤数目,即能单独执行的测试步骤。
(2) 可复用性初始值
可复用性初始值主要由UIAC特性决定,度量如下:
可复用性:R=WUU+WII+WAA+WCC(WU、WI、 WA、WC为权值,表示U、I、A、C影响R的程度,WU+WI+WA+WC=1,0≤R≤1,越接近1可复用性越高)。
为了获得以上度量方法中权值的取值,我们从大量实际应用的测试用例中挑选出100个,100个中有被复用过多次的测试用例,有较少被复用的测试用例,也有不具备复用价值的测试用例。对这100个测试用例进行处理后交由10个具备丰富项目经验的资深测试工程师进行评分。测试工程师分别对100个测试用例的易理解性、独立性、适用性、可配置性和可复用性进行评分,评分从0分到1分,分值越高特性越强。
要获得易理解性度量方法中权值的取值,先对100个测试用例的测试概要和测试项进行随机处理,先随机的去除一些测试用例的测试目的、测试场景、测试要点的描述,再随机去除一些测试用例某个测试项的测试输入或测试数据,但测试用例的其他元素全部予以保留。将进行处理后的测试用例交由10位测试工程师,让他们针对易理解性进行评分,再统计每个测试用例的易理解性平均得分。对100个测试用例的易理解性得分进行统计计算后可以得到WTp、WTc、WTe、WY1、WY2的值。
采取上述方法同样可得到其他特性度量方法中的权值,最终得到度量公式为:
U=XUTs+YUTi
其中: Y=0.37+0.63((Ti-1)/Ti)
X=1-Y,UTs=0.35UTp+0.42UTc+0.23UTe
I=0.75IPt+0.25ITc
A=0.18ADt+0.45ATt+0.25ASt+0.12ASd
C=0.65CP+0.35CS
R=0.32U+0.23I+0.28A+0.17C
(3) 可复用性修正
可信度度量主要根据使用信息进行度量,详细度量如下:
可信度:Cr=WRcCrRc+WRmCrRm(WRc、WRm为权值,表示CrRc、CrRm影响Cr的程度,WRc+WRm=1,-1≤Cr≤1,Cr的绝对值越大则修正幅度越大)。
度量方法:
CrRc为测试用例复用次数的度量值,CrRc=(Rc-QRcDc)/max(Rc,QRcDc),-1≤CrRc≤1,Rc为度量的测试用例的复用次数,Dc为度量的测试用例加入到测试用例库的天数。QRc为系数,取值范围为正实数,它用来表示Rc和Dc的关系,其值将根据测试用例库的实际情况设置。
CrRm为测试用例复用者评分的度量值,其值为所有复用者评分的平均值Rm与R的差值,复用者评分的范围为0分至1分,则0≤Rm≤1,-1≤CrRm≤1。
修正后的可复用性度量如下:
当Dc≤30,R=0.32U+0.23I+0.28A+0.17C
当Dc>30
R=0.32U+0.23I+0.28A+0.17C+WCrCr(WCr为权值,表示Cr影响R的程度,0≤WCr≤1)
上述公式的计算结果R>1时,取R=1,R<0时,取R=0。
3.3 应用实例
本节以实际项目中常见的系统登录为例,来说明如何根据上节提出的度量方法对测试用例的可复用性进行度量。
表2为验证系统登录的测试用例实例,以下是对该测试用例可复用性度量值的具体计算方法。
计算易理解性U:
UTs=0.35×1+0.42×1+0.23×1,UTi=2/2=1
Y=0.37+0.63((2-1)/2)=0.685
U=(1-0.685)×1+0.685×1=1
计算独立性I:
IPt=1,ITc=1
I=0.75×1+0.25×1=1
计算适用性A:
ADt=1/18(18种设计技术) ATt=1 ASt=1 ASd=1
A=0.18×1/18+0.45×1+0.25×1+0.12×1=0.83
计算可配置性C:
CP=1-0/2=1 CS=2/2=1
C=0.65×1+0.35×1=1
则可复用性的初始值为:
R=0.32×1+0.23×1+0.28×0.83+0.17×1=0.9524
为了说明可信度的计算方法和可复用性的修正过程,这里暂取Rc、Dc为100、40,Rm取0.9,WRc、WRm取0.75、0.25,QRc取5,WCr取0.15。
则可计算可信度Cr:
CrRc=(100-5×40)/(5×40)=-0.5
CrRm=0.9-0.9524=-0.0524
Cr=0.75(-0.5)+0.25(-0.0524)=-0.3881
最后,对可复用性的初始值进行修正:
R=0.9524+0.15(-0.3881)=0.89415
3.4 度量方法验证
使用TCRM模型对前文提到的100个测试用例进行度量,其度量结果与这些测试用例的被复用次数Rc进行对比。
根据Rc的取值划分10个区间,用区间中间点的值作为该区间的区间值,区间值越高表示该区间内测试用例被复用次数越多,即该区间内测试用例的可复用性越高。若一个测试用例的Rc介于一个区间,则该测试用例属于该区间,以此统计每个区间的测试用例数量。然后使用TCRM模型对区间内测试用例的可复用性进行度量,得到区间内每个测试用例的可复用性度量值,计算它们的平均值A(R)。最后对比每个区间的区间值与A(R),具体对比情况可见图2。
从图2可以看到,A(R)与每个区间的区间值基本成正比,即A(R)的大小变化与测试用例被复用的次数的变化基本是一致的。该结果表明使用TCRM模型对测试用例的可复用性进行度量所得到的度量值,基本能代表测试用例实际所具有的复用能力。
4 TCRM模型应用
TCRM模型将应用于国家“863”项目——基于可复用测试用例库的测试管理平台(以下简称测试管理平台),该项目使用TCRM模型来对测试用例库中的测试用例进行度量。
测试管理平台以可复用测试用例库RTCL(Reusable Test Case Library)为核心,为软件企业提供完成整个软件测试流程的所有功能,其组织和使用方式可见图3。测试管理平台中的测试用例将使用可复用测试用例模式进行描述,从而更好地实现测试用例的搜索、复用和度量。使用测试管理平台,当用户需要设计新的测试用例时,只需输入搜索条件即可在RTCL中搜索所需的测试用例,用户对搜索到的测试用例可直接复用,亦可修改后复用。用户新建的测试用例经过验证后将收集到RTCL中,这一机制不仅使RTCL中的测试用例不断增加,也实现了不同用户之间测试用例的共享。测试管理平台通过用例度量系统对RTCL中的测试用例进行度量和管理。用例度量系统使用TCRM模型对RTCL中测试用例的可复用性进行度量,度量后将删除不具有复用特性和冗余的测试用例,使其进入历史用例库,这不但能保证RTCL中测试用例的高可复用性,还能提高RTCL的用例检索效率。测试管理平台也支持管理员手动修改和更新RTCL和历史用例库中的测试用例。
在测试管理平台的使用过程中,管理员可根据实际使用情况设置和调整可信度度量的权值WRc、WRm、系数QRc以及可复用性度量的权值WCr,即调整可信度对可复用性的修正幅度。
5 结束语
本文提出了测试用例可复用性度量模型TCRM,以及针对TCRM的度量方法,实现了对测试用例可复用性的度量。在实际应用TCRM模型和度量方法时,使用者可根据当前系统的实际情况,对上述度量公式中的权值和系数进行调整。测试用例可复用性度量的实现有助于可复用测试用例库构建和控制以及最终的测试用例复用。
参考文献
[1]郭立峰,郭耀,常继传.NATO软件复用标准导论[J].计算机科学,1999,26(5).
[2]NATO.NATO Standard for Management of a Reusable Software Compo-nent Library[S].NATO Contact Number CO-5957-ADA,1991.
[3]Sindre G,Conradi R,EAKarlsson.The REBOOTApproach to SoftwareReuse[J].Journal of Systems and Software,1995.
[4]Jeffery S,Poulin.Measuring software reusability[C]//Proceedings ofthe Third International Conference on Software Reuse:Advances inSoftware Reusability.Los Alamitos.CA:IEEE Computer Society Press,1994.
[5]GB/T16260.1-2006(ISO/IEC 9126)第1部分:质量模型[S].软件工程-产品质量,2006.
[6]GB/T16260.2-2006(ISO/IEC 9126)第2部分:外部度量[S].软件工程-产品质量,2006.
[7]GB/T16260.3-2006(ISO/IEC 9126)第3部分:内部度量[S].软件工程-产品质量,2006.