软件测试用例的编写

软件测试用例的编写（精选6篇）

软件测试用例的编写 篇1

摘要：软件测试是保证软件产品质量的重要手段。本文通过探讨系统用例与测试用例之间的关系, 提出了针对系统用例编写测试用例的一般途径, 以及如何在业务层次上实现测试用例的复用。

关键词：系统用例,测试用例,复用,软件质量

1、引言

长期以来，软件质量问题一直困扰着大多数国内的软件企业。大多数企业，重开发、轻测试，认为软件测试是可有可无的事情。软件测试要么流于形式，由开发人员自己对自己的代码进行检查，要么根本没有，拿用户做实验，软件直接交给用户来测，待用户发现问题后再做补救。软件的质量根本无法保证。近年来，随着客户对软件质量的要求越来越高，软件行业也逐渐意识到，软件测试才是确保软件质量的最有效的手段。因此，近年来形成了比较完善的软件测试理论体系。但是，如何编写高效的测试用例。即，如何利用尽可能少的用例做到尽可能大的覆盖率，仍是每一个测试人员需要面对的问题。[1]

2、软件测试的一般方法

软件测试按照阶段划分一般分为：单元测试、集成测试、系统测试、验收测试。[1]单元测试针对每个模块进行的测试，通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。单元测试的目的是看已完成的编码是否符合详细设计说明书上的要求。集成测试在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。集成测试着眼于各模块之间的接口是否正确。由于软件集成的过程是一个持续的过程，会形成多个临时版本。因此，在集成测试的过程中，需要不断地对系统进行冒烟测试，即对程序的主要功能进行测试。确认测试验证软件的功能和性能及其它特性是否与系统的概要设计说明书一致。系统测试和验收测试的目的在于检验系统的提供的功能是否与用户的要求一致，系统测试是在实际运行环境或相对真实的模拟环境下进行一系列的测试。

软件测试按照测试技术划分，一般分为：白盒测试和黑盒测试。白盒测试检查程序的代码设计。该方法将语句与判断作为研究对象，检查所有的结构和路径是否都是正确的。白盒测试以覆盖率作为衡量标准，覆盖率越高，其测试越充分。白盒测试一般分为语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖以及路径覆盖等[1]。然而100%的代码测试几乎是不可能的，白盒测试的成本非常高，除非在航空或军用领域，一般的应用系统只需针对最重要的核心代码进行白盒测试。

黑盒测试是从用户的角度对系统进行测试查找系统存在的缺陷。黑盒测试与需求紧密相关，系统业务需求分析的正确程度直接影响黑盒测试的质量。在进行嵌入式软件黑盒测试时，要把用户需求作为重要依据。黑盒测试针对的是系统的外在功能，因此对软件系统的分支覆盖率比白盒测试要低，在系统修改后，一般要进行回归测试。[5]

3、系统用例和测试用例的关系

作为分析建模活动的一部分，系统用例用来捕获信息的生产者、使用者和系统本身之间发生的交互。即，从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。[2]下面通过一个实例来说明用例的组成与结构。

用例1：登录

[执行者]：员工

[基本路径]：

1）、员工插入安全锁触发系统登录过程。

2）、系统打开安全锁

3）、系统从安全锁中获取证书信息。

4）、系统验证证书的合法性。

5）、系统获取证书中的用户名。

6）、系统将用户的考勤信息存储至数据库。

7）、系统将用户的在线状态记录至数据库。

8）、系统从数据库中获得在线用户列表、通知列表、带接收文件列表、日程安排、收文回执列表等。

[扩展路径]：

2a、无法打开安全锁

2a1、提示用户安全锁错误。

2a2、用例结束

2b、PIN码不正确

2b1、输入未超过3次，要求用户重新输入PIN码

2b2、返回步骤2

2b1a、用户输入PIN码达到3次

2b1a1、用例结束

3a、无法获得安全锁中的证书

3a1、提示用户锁内证书无法获得

3a2、用例结束

4a、证书验证不合法

4a1、提示用户锁内证书不合法

4a2、用例结束

6a、无法存储至数据库

6a1、将登录信息存储至本地

6a2、重复尝试存储登录信息。

7a、无法存储至数据库

8 a 1、重复尝试存储在线信息。

这是一个利用硬件设备通过数字证书进行系统登录的用例。基本路径描述了自顶向下的易于理解的典型场景。在其中用户目标得以实现，风险承担者的利益也得到了保障。[4]扩展路径则表述了系统出现问题情况下的场景。扩展路径可以在执行后重新加入到基本路径中，也可以不再重新加入基本路径而终止用例。

我们在得到了系统用例之后，则可以通过该用例来设计测试用例。在设计过程中，不仅要考虑基本路径所产生的成功场景，也必须要考虑当扩展路径执行时的失败场景。

通过表1六个用例执行了系统用例中步骤1-4中的场景。用例1为正面测试用例，它沿着系统用例的基本路径执行，未发生任何偏差。用例2-6为负面测试用例，它们在系统出现偏差时沿着扩展路径执行。负面测试是相对于基本路径而言的，对于扩展路径来说用例2-6是正面测试。

通过系统用例生成测试用例非常方便，二者之间的转换是非常自然的过程。与其他方法不同，这个方法对系统用例的依赖程度高。因此，测试用例的成功与否，取决与系统需求分析的正确程度。只有真正捕获了用户的需求，并且编写出正确的系统用例，才能得到高效的测试用例。

4、用例复用

测试用例复用是指重复使用“为了复用目的而设计的测试用例”的过程。[3]相应地，可复用测试用例是指为了复用目的而设计的测试用例。与软件复用的概念相对应，软件的复用是为了支持软件在应用维的演化，使用“为复用而开发的软件 (构件) ”来更快、更好地开发新的应用系统。好的测试用例用来确保软件的质量，而有效复用现有的测试用例更能提升软件测试的效率。[2]测试用例的复用技术目前已成为一个新的研究热点，由于本人的水平有限，在这里只能根据自己的经验提出一点自己的体会。

传统上，我们都是针对特定的系统设计软件系统设计测试用例，过于局限于某一种产品，依赖性非常强，不利于测试用例的复用。

需求分析的结果取决于用户需求，系统分析结果是针对问题域的某些问题的抽象程度较高的结果，很少受到设计技术及实现条件的影响，因此复用的机会更多。一般可以从现有系统的分析结果中提取可复用构件。[2]因而通过系统用例生成测试用例的方法则可以凭借软件工程中的软件构件技术实现需求、系统和软件的需求规约的复用；继而确保由这些复用构件生成的测试用例达到复用的目的。

5、结束语

通过系统用例我们可以很方便的得到测试用例，进行系统测试。测试用例能够达到的效果取决于系统需求分析的准确程度。因此，要求我们在系统开发的过程中要高度重视系统的需求分析，准确把握用户的需求。测试用例可以与系统用例同步开发，将测试介入到软件开发过程的时间大大提前，从而确保软件开发的每一阶段，都能通过测试保证开发的质量。

需要注意的是, 本介绍的方法属于黑盒测试的范畴。覆盖率能够达到30-40%。因此, 对于系统的核心模块, 如有必要还必须借助白盒测试的方法进行全面的测试。

参考文献

[1]柳纯录.软件评测师教程.清华大学出版社.2005

[2]邵维忠.面向对象的系统分析.清华大学出版社.2005

[3]Roger Pressman.软件工程-实践者的研究方法.机械工业出版社.2007

[4]Alistair Cockburn.Writings Effective Use Case.机械工业出版社.2002

[5]王立福, 麻志毅, 张世琨, 编著.软件工程 (第二版) .北京大学出版社.2002

软件测试用例的编写 篇2

在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者（客户）的需求。理解原始需求后，编写的测试用例才更有目的性。

2、熟悉软件的功能需求（测试点）

这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把 “粗略”的需求，细化成一个个小需求点。熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。

总之，测试用例一定要全部覆盖所有的需求点，这是最基本的一点。

3、熟悉软件的实现原理（测试点）

在理解原始需求和软件的功能需求后，根据需求编写的测试用例，基本上都能覆盖得比较全面了。

在此基础上，熟悉软件的实现原理，理解软件的内部处理。

（1）熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到，而这些没有覆盖到的代码很可能就是一个风险点。

（2）熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大，“互相影响”就会越多，若设计用例单单从模块本身考虑的话，很可能就会对其他模块造成风险。

4、用户场景和网上问题（测试点）

从用户的使用场景考虑，这在一些网络设备比较重要，比如软件后期在一些真实的使用环境中使用。

还要就是从一些网上问题总结出来的，那些地方容易出错，在设计案例的时候需要考虑进去。

5、测试用例的框架

一个测试用例的框架体现了一个测试人员在设计测试用例的整体思路。框架也是从大到小划分下来，可以是：

UI界面，功能，容错，兼容，性能等几大类，每个大类在根据软件的逻辑等进行划分成小类，最后细分到测试点。

6、测试步骤（测试技巧方法）

前面4点都是从测试点的角度考虑，测试用例在完成测试点外，接下来就是测试步骤和测试结果啦。

测试用例可以写的很详细，也可以写的比较简单。这要看公司的要求，有些公司要求测试步骤很细很细，包括测试结果和测试步骤一一对应。

要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。如果测试步骤写的很详细的话，会很耗时间，而且过于详细的会限制执行人员的思维。个人认为测试用例的重点在于测试点上。

7、测试用例的一些思路

在设计测试用例中，通常较多使用的是边界值，等价类，通过和不通过测试。下面从单个模块或者单个功能点考虑：（结合一些网上文章的观点）

（1）UI界面：易用性，提示信息，整体布局，按钮图标，色彩，中英文标点错别字。

（2）数据的多样性：有效数据，合法的无效数据（边界值），非法的异常数据，产生错误输出的合法数据组合等各种数据的组合。

（3）操作多样性：添加删除编辑查询，多用户的操作。

（4）容量测试

（5）用户权限：使用权限，各种操作的权限。

（6）升级安装卸载：平滑升级

（7）日志相关（包括调试日志）

（8）软件功能的逻辑划分：功能上划分未能覆盖的代码逻辑，可以添加白盒灰盒用例。

（9）可靠性，容错性

（10）兼容性：浏览器，系统，支撑软件。

（11）安全性

（12）性能（这里的性能是指，单个模块或者子系统的性能）

总之测试用例首先要能覆盖所有功能需求点，然后搞懂软件处理逻辑，可以找开发一起看测试用例，把没有覆盖到的代码流程相应的用例补充，至此，用例基本不会出现基本功能的问题。

基于UML软件测试用例的探讨 篇3

关键词：测试,用例,UML图,框架

(一) 引言

随着社会信息化发展, 软件在经济和社会生活各方面的应用越来越深入。而软件质量问题导致巨大经济损失的事实, 已引起人们的重视。

2008年5月24日, 软件测试厂商核心安全技术公司CST透露, 运行在苹果电脑Mac OS X操作系统上的i Cal日历应用程序存在三个致命的安全漏洞, 给Mac用户造成了严重的后果。对此, 公司高级测试工程师托马斯表示, 该程序出现安全漏洞的主要原因是测试不足导致的。

如何保障软件的质量?人们需要进行一个测试验证工作。因此, 软件测试是软件产品交付前必须进行的关键步骤之一。

软件测试在软件质量安全控制上的地位不可替代。像美国这样软件产业发达的国家, 软件企业将40%的工作量花在软件测试上, 测试费用占项目总费用的30%~50%, 甚至翻倍。在企业中测试人员和开发人员配比大多为1∶1, 甚至2∶1。因为通过必要测试, 软件缺陷数可至少降低75%, 而软件的投资回报率能达到350%。

(二) 测试法原则

1. 结构化测试 (也叫白盒测试)

白盒测试是知道软件内部工作过程, 检验程序中的每条通路是否都能按预定要求正确工作, 而不考虑它的功能是怎样的。白盒测试的主要方法有基本路径分析、语句覆盖、分支覆盖、条件覆盖等, 是深入到代码一级的测试, 这样可较早发现问题, 效果很好。由于测试对象进入代码内部, 需要测试人员根据自己对代码的理解和接触进行测试, 所以这一阶段测试以软件开发人员为主。

2. 功能性测试 (也叫黑盒测试)

黑盒测试是一种从用户观点出发的测试。该测试不需要知道程序如何工作, 只关心程序是否能适当地接收输入数据而产生正确的输出信息, 并且保持外部信息的完整性。即只检查程序功能是否按照需求规格说明书的规定来正常使用。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等, 主要用于软件确认测试, “黑盒”法着眼于程序外部结构, 一般由独立测试小组执行测试。

白盒测试较难掌握, 一旦掌握, 则一通百通;黑盒测试入门简单, 但做好较难。

(三) 基于UML测试法

现在, 软件开发技术和模型的表现手法虽然层出不穷, 面向对象的方法占据着主导地位。这决定着软件开发过程模型化技术的发展, 面向对象的建模技术 (OMT) 方法成为主导的方法。UML (统一建模语言) 面向对象技术领域内占主导地位的标准建模语言。所谓统一, 是指它与具体的过程无关, 与具体的实现无关, 可应用于任何软件开发的过程、任何语言平台和工具平台。它支持面向对象的设计与开发中出现的高级概念, 它强调软件在开发过程中对架构、框架、模式和组件的重用。UML能够进行可视化建模, 主要以图形的方式对系统进行分析、设计。以UML模型图作为测试基础, 主要有状态图, 序列图, 协作图, 活动图, 用例图, 类图。对于黑盒测试来说, UML的建模方式能提供较好的解决方案。

测试用例是测试工作的指导, 是软件测试的必须遵守的准则。测试用例的设计在测试设计中占据非常重要的地位。把UML图更加有效地运用到测试用例的设计中, 成为研究的热点。下面是基于UML用例生成的若干介绍。

1. 用例图

用例图描述的是客户对该系统的需求, 强调这个系统做什么而不是怎么工作。主要有4个部分:

(1) 参与者:向系统输入和要求系统输出信息

(2) 系统:用于执行某种功能, 从参与者角度看系统是个黑盒子

(3) 用例:一种操作, 完成系统所要完成的某个部分的操作。通过不同用例实现不同的功能进行组合, 形成参与者对系统总体需求

(4) 关系:用例与参与者间的关系

图1为图书系统用例图 (部分) , 图中可体现以下功能:

(1) 系统分析随着需求的不断提出以及用例的不断产生, 会发掘更多新的需求。通过开发者与客户的不断交流, 决定需求的取舍。

(2) 生成的用例图, 可指导应用到实际测试用例的设计。

2. 活动图

活动图是UML中描述系统动态行为的工具之一, 借用流程图、状态转换图和Petri网的思想, 表示活动可能发生的顺序。

图2、3为图书系统中借书用例的活动图例子。一个活动图确定好所要描述的用例后, 创建主路径。在主路径的基础上, 完成从路径的创建。主路径描述了用例图的主要工作流, 没有任何转移条件或错误处理。从路径进一步添加活动图的内容, 包括判断、转移条件和错误处理等, 在主路径基础上完善活动图。

完善后的活动图有结点、转移边、环路、判断、数据流, 存在对应的五大覆盖准则, 使得用例间迁移过程得以正确有效的覆盖。利用相应遍历法遍历活动图, 可提取系统执行路径, 从而生成用例。

3. 序列图

序列图, 又称顺序图。顺序图描述用例图的场景, 场景是相互交互的对象间传递的一个消息序列, 每个消息序列代表该用例的一个可能的事件流。一个顺序图可表示组件间的一个协作。举例:图4为图书管理员登录图书系统顺序图。

测试用例生成和执行, 就是从顺序图上找到其表示的预期行为, 然后据此获取让系统再现该行为所必需的输入条件, 用这些测试用例执行系统时会得到实际的行为, 通过验证动态模型表示的系统预期行为与软件在运行时的行为是否一致, 来确定组件交互中是否存在与规约不一致的错误。

4. 类图

类图, 在面向对象开发中, 类是一组具有相同属性和操作的对象集合, 它为所有属于该类的对象提供统一的描述。显示出什么可以产生影响但不会表现什么时候产生影响。

类的测试用例设计方法主要有:随机测试、划分测试、基于故障的测试等。

针对面向对象程序语言java, 一种设计基于UML类图模型的静态分析法如下:选择要分析的源文件.java, 对源程序进行充分的语法分析, 提取程序中类信息 (属性和操作) , 利用了数据库技术和UML图形模型, 保证分析的准确有效和标准化。该分析方法主要用于源程序的分析, 查找错误或者收集一些度量数据, 并不需要对代码进行编译和仿真运行。

5. 状态图

基于UML状态图生成测试用例的方法, 主要有状态/事件对导出、图遍历法导出、UML语义文档导出法。举例:图6为图书Book对象状态图。

状态图测试用例由消息序列和测试数据组成, 每个测试用例都要求完成一次由初态到特定状态 (一般为终态) 的转换。测试序列的生成问题可以看成一个有向图的遍历问题。测试序列的生成除了需要考虑测试覆盖需求以外, 还要求生成的测试序列尽可能的短, 这样节约测试资源, 又能保证充分发现软件行为存在的缺陷。UML状态图的测试覆盖准则, 包括状态覆盖、迁移覆盖、迁移对覆盖、全路径覆盖。

6. 协作图

UML 1.x中的协作图在UML 2.0中已重命名为通信图。协作图与顺序图合称为交互图。协作图强调的是组件的结构组织和它们之间消息的发送和接受, 表示的是组件之间的关系, 而不突出消息的时间顺序, 它描绘了在特定上下文中一组相关组件之间的协作, 以及这些组件为产生所要求的操作或结果而进行协作时交换的一组消息。

通过通信图构建树, 然后遍历树, 选择树的分叉点 (即条件) , 利用分叉点和数学求值法生成测试用例, 这样可同时满足消息路径和边界两种覆盖。利用树, 可以更简易的选择测试路径, 且测试用例不增加的情况下满足高覆盖率要求。举例:图7为借书用例基本工作流通信图。

(四) 结束语

测试根据每个不同的软件进行, 测试用例也会随之有不同的需求和形式。即便在同一个系统进行测试, 在不同的开发阶段所需的测试用例也是针对不同的模块有不同的需求。对于不必关心开发程序结构的黑盒测试来说, 需求是用例设计的主要标准。虽然测试技术和方法有很多种, 但统一的行业标准仍没有形成, 很多测试方法难在实践工程中应用, 很多测试工具与实际工作结合效果不好的原因, 就在于工程系统和测试系统都有各自特点, 通用性不够。UML的统一建模方式, 也是根据需求, 以UML模型图为基础, 创建工程系统需求的通用框架, 用例复用性大, 也与黑盒测试有相通之处。但在具体的测试活动中根据工程本身的特点, 灵活的选择测试方法和测试工具, 实践与理论相结合才能取得时间、资源等的合理投入和最大产品效益的获得。

参考文献

[1]Antonia Bertolino, Software Testing Research Achievements, Challenges, Dreams, Future of Software Engineering (FOSE'07) , 2007.

[2]章涛, 顾庆, 陈道蓄.基于UML状态图的测试技术研究[J].计算机科学, 2007.

[3]谢棠棠.UML软件测试[J].信息科学, 2007 (5) .

[4]叶俊民.软件工程[M].清华大学, 2006.

测试用例的复用技术的研究 篇4

随着信息技术应用在人们的日常生活工作中起到越来越大的作用, 软件业也迅猛地发展起来, 软件的功能由简单变得强大, 软件的复杂程度也越来越高。软件作为一种广泛使用的产品, 其质量的重视程度在被不断提升, 特别像一些高风险的行业, 例如证券行业, 软件质量的好坏直接关系到客户的交易是否安全, 顺畅。软件测试作为软件生命周期的一个重要阶段, 是在软件开发, 维护阶段对软件产品进行质量控制, 检验软件系统是否满足需求的重要手段之一, 是整个软件质量保证的关键一环。

在软件的测试过程中, 选择合适的测试用例很重要, 这将决定最后测试是否能顺利地按时按质完成。在软件测试中, 测试用例设计是软件测试步骤中最重要的环节之一, 测试用例的设计人员的水平不一, 低水平的测试用例设计人员的测试效率低, 会降低测试效率, 这样也会影响软件交付的时间。测试人员经验不足同时也会导致测试用例设计质量的低下, 设计出的测试用例不能发现足够多的软件问题, 对保证软件项目质量不利。软件测试中, 一些测试内容会经常反复进行, 相同或者相似测试用例的重复设计的劳动经常发生, 浪费人力物力和时间, 这样会提高软件开发和维护的成本。软件测试用例的复用技术在软件复用技术较好的应用和发展的影响下, 也得到了发展, 这对解决测试中的冗余现象, 提高软件测试效率提出了很好的方法。软件测试复用技术广泛地应用在软件开发和维护的各个阶段, 本文研究了测试用例复用技术, 并对测试用例复用在证券软件测试中如何实现做了研究。

2、软件测试用例

测试用例 (Test Case) 是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果, 以便测试某个程序路径或核实是否满足某个特定需求。

3、测试用例在软件测试中的作用

测试用例是软件测试全部过程的核心, 是测试执行环节的基本依据, 在软件测试过程中起着很大的作用。没有测试也可以进行软件测试, 但测试是无序的, 只是按照自己的测试思路进行测试, 难免有所遗漏。有了测试用例, 就有了测试的依据, 可以按照测试用例有序的执行测试步骤, 不易遗漏测试点, 能过较好保证最后的测试质量。每个测试人员的测试环境, 技术背景, 测试思路等都不一定相同, 不同的测试者的测试方法都不一样, 一个较大的软件在测试过程中, 许多测试人员一起测试, 不能保证测试各个测试点的测试质量。通过测试用例的设计, 可以把测试目的, 内容等编成文档, 保存在用例库中, 便于其他测试人员借鉴, 共同提高测试技能。测试中可以引入审核部门, 对测试用例进行评估, 通过一些量化的数据, 如测试覆盖率、测试合格率、重要测试合格率等, 衡量测试用例的优劣, 总结测试用例设计中产生的问题, 评估各个测试用例设计人员的工作绩效, 将评估结果反馈给测试人员, 测试人员可以改良测试用例, 并把结果存入测试用例库中, 在下次同一模块或相似模块的测试中就能提高效率和准确性。测试用例存入测试用例库中, 也可以专门由人进行维护, 不断更新和完善测试用例。一个好的测试用例库必然会让共享的测试人员获益, 从而提高工作效率, 更好保证产品质量。

4、测试用例设计方法

软件测试方法众多, 主要有黑盒测试方法, 也称功能测试;白盒测试方法, 也称结构测试或逻辑驱动测试。

5、软件测试复用

5.1 软件复用的概念

软件复用 (SoftWare Reuse) 是将已有软件的各种有关知识用于建立新的软件, 以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。

5.2 软件测试的复用

软件测试复用可以理解为在两次或多次不同的软件测试过程中重复使用相同或相近的测试资源来组织测试, 它的目的是充分继承以前软件测试中的经验, 将已经使用过的测试用例标准化后存档, 在未来的某个时间进行检索后的借鉴或者复用, 减少设计测试用例的时间, 增强测试的效率和可靠性, 而不是每次用例设计都从头开始, 增加更多的冗余时间。测试用例复用是把一个软件的测试用例在新的软件测试中使用, 或者在软件作出修改时在新的一轮测试中使用, 作为软件测试的核心内容, 它的复用也就成为整个软件测试复用工作的关键环节。

6、软件测试用例的复用

6.1 测试用例的复用

所谓测试用例复用就是指测试工程师在执行一项新的测试工作时, 通过直接调用或修改现有的、适合此项测试的测试用例, 并将它们运用其中的过程。也就是说测试用例要实现复用必须具备三个条件, 必须有可复用的测试用例, 要复用的用例必须有用, 测试工程师知道如何使用, 而这三个条件恰恰通过测试用例的创建、维护、执行管理就可以实现。

6.2 测试用例复用数据库的维护

要对测试用例进行复用, 首先要有能够复用的测试用例, 然后将测试用例进行归类存档, 以一定的形式保存在测试用例库中, 接下来就要对测试用例进行维护, 在维护中不断添加新的测试用例, 更新旧的可完善的测试用例, 删除有问题的测试用例。测试用例的设计由于每个设计人员的水平, 设计的用例的复杂度, 不太可能每个设计的测试用例都能完美无缺的满足测试需求, 总是会有些测试用例编写的并不符合要求, 测试执行过程里肯定会发现有些测试路径或数据在用例里没有覆盖一些应用场景, 那么在测试用例维护时, 该将其补充到用例库里, 以方便他人和后续版本的测试。现在比较流行迭代的软件开发方式, 这是为了符合客户对软件功能不断变更的需求, 相应的, 在当前迭代版本的测试要使用前一个版本的测试用例时, 由于需求的改变, 测试用例也要随之变更。测试用例的维护分不同的情况, 可以用不同的方法分别进行处理。其一, 软件需求并没有发生变更, 只是原先设计的测试用例不是很完善, 没有完全满足测试需求, 在测试过程中, 不断地细化, 深入分析需求文档时, 有了更完整, 清楚的认识, 这时, 就需要完善测试用例, 让测试用例的测试效果更能贴近客户的需求, 然后修改需要更新的测试用例;其二, 测试需求没有发生变更, 但是软件的功能增强了, 原测试用例只对未增强的功能模块有效, 我们就需要设计新的版本的测试用例, 符合增强后的功能的测试需求, 也就是增加一个测试用例, 而原来的测试用例对增强前的功能依然有效;其三, 需求变更, 增加了新的功能, 这就需要添加新的测试用例;其四, 需求变更, 原功能被取消了, 相应的测试用例失去了作用, 但测试可能在将来被其他人在相似的测试中借鉴或修改复用, 这时只要将与该功能对应的测试用例在标志位上置为无效标记。测试用例维护流程的模式如图1。

6.3 测试用例的复用思路

要实现测试用例的复用, 首先要测试用例规范化。统一的用例建模, 统一的标识规范, 例如都由测试用例ID、测试概要、和用例描述3个部分组成, 将设计好的测试用例放入测试用例库, 并按照用例各自的属性特点进行多级合理的分类、组织、存储, 这样, 在测试用例复用时, 就能够快速的检索到所需要借鉴或复用的测试用例。然后, 对测试用例库中的测试用例进行维护, 及时更新测试用例库, 不断地进行完善, 通过提供有助于复用的多种查询方式, 确保测试用例的复用程度。最后, 对数据库中的测试用例具体实现复用, 通过测试需求分析, 检索测试用例库, 查找可以借鉴和复用的测试用例。同时对测试用例库做必要的更新。测试用例的复用能在保证软件测试质量的前提下提高测试效率。复用的简单流程的模式如图2。

6.4 证券行业软件测试用例复用的实现过程

金融行业中的证券行业软件复用常常发生在测试用例复用发生在系统维护阶段应急演练测试, 系统新功能上线后的系统测试, 系统部分参数变更时的测试, 同一测试软件在系统不同的测试阶段的测试。

(1) 系统维护阶段应急演练测试。在系统维阶段, 为了维护系统的在客户使用时地稳定性, 会为平时运行的系统安排应急措施, 这样, 当主系统发生故障时, 能够启用系统的备份方案, 维系系统的功能仍然有效。这种测试在对系统稳定, 风险较大的行业, 像金融业等, 经常会定期进行, 其目的是让系统维护熟悉系统的应急措施, 确保系统在出现问题时, 能在最短的时间内恢复系统的正常功能, 减少或消除客户和公司的损失。系统功能的复杂性越高, 系统地风险越大, 这种测试也会变得更频繁, 制定详细地可复用的测试用例, 放在测试库里。同时制定测试计划, 当某功能测试需要实施时, 从测试用例库中调用相应的测试用例进行复用。这样可以节省时间, 同时也能当不同的维护人员做同一测试时, 能运用以前测试人员的方法, 快速实施测试。这种测试用例的复用其实也是一种有效地故障处理方法。

(2) 系统升级后的系统测试。同一个系统在运维时期, 功能往往不会一尘不变的。这种系统的变更往往是被动发生的。业务需求的变更是系统功能变更的主因。例如金融公司, 不断会有创新业务产生, 需要随着业务的需求变化, 不断地增加新功能, 这些新功能的增加, 需要测试系统的新功能, 而新功能和以前地功能往往具有相似性, 我们可以查找测试用例库, 具有类似功能的模块的测试用例, 做一些相应的适当改动, 满足新的功能的测试需求。然后将新的测试用例放入测试用例库, 作为以后的定期功能测试时复用, 或者其它新的相似功能模块上线时测试用例复用和测试用例设计参考使用。

(3) 系统部分参数变更时的测试。系统的整体功能并没有改变, 只是由于业务需求的原因, 改变了一些系统参数, 这种情况在金融业时有发生, 例如国家的金融宏观调控, 一些政策发生改变, 某些收费比率会发生变更。政策的变化导致了系统参数的变更, 使用该系统进行资金往来或者交易的客户往往因为政策改变交易策略, 会引起交易市场的震荡, 这种情况在证券市场时有发生, 这就需要通过测试来检验系统的稳定性, 了解市场波动给系统带来的影响, 从而才取相应的应对措施。由于这些参数的改变, 对系统地功能并没有大的影响, 可以查找测试用例库, 复用以前的测试用例进行测试, 测试系统的稳定性, 为系统是否需要改进, 或系统的硬件是否需要升级, 做评估。

(4) 同一测试软件在系统不同的测试阶段的测试。证券软件从软件开发的过程按阶段划分有单元测试、集成测试、确认测试和系统测试及验收测试。在不同的开发过程中的测试所对应的对象会有许多功能模块在先前的测试阶段已经测试过, 例如集成测试中的测试对象在单元测试中已经测试过, 我们可以查找测试用例库, 把前一个阶段使用过的测试用例拿出来继续使用, 对软件进行测试。如果测试需要改进, 可以稍作修改后, 将新产生的测试用例做好分类标识后放入测试用例库, 供以后软件测试的复用。

7、结语

本文通过介绍软件测试过程中测试用例的设计的作用、测试用例的设计方法、软件测试用例库的维护, 软件测试复用的具体思路、方法, 在证券软件中测试复用的具体实现过程, 说明了软件测试复用的可行性, 在复用技术的研究提高下, 能在保测试证质量的前提下, 提高测试的效率, 更好完成测试任务。

参考文献

[1]杨根兴, 蔡立志, 陈昊鹏, 蒋建伟.软件质量保证、测试与评价北京:清华大学出版社, 2008.6.

[2]卜国峰, 孙志刚, 丁小良.软件测试用例的复用研究[J].四川兵工学报, 第3O卷第5期, 2009.5:34—35.

[3]尹平.可复用测试用例研究[J].计算机应用, 2010, 5.

[4].胡正芳.测试用例复用技术研究.2009.

优化测试用例的黑盒测试方法研究 篇5

关键词：黑盒测试,测试用例,分类树方法

0 引言

黑盒测试方法是一种从软件系统的功能说明书出发去寻找软件错误的测试方法, 测试软件系统功能。与白盒测试方法不同, 黑盒测试方法不关注软件的逻辑结构, 将待测试的软件看作一个黑盒子, 只关注软件功能的实现。常见的黑盒测试方法有:随机测试、等价类划分、边界值分析和因果图等。

1 常用黑盒测试方法

1.1 随机测试

该测试方法仅仅依靠测试者的直觉和个人经验去设计测试用例, 对软件进行随机测试, 因此较难发现错误, 效率较低, 大型软件一般很少使用。

1.2 等价类划分

该方法是从软件输入数据的限定条件出发, 或者从软件的输出数据倒推输入数据的特性, 从而划分为不同的类别, 每一个类别称为等价类, 每个等价类中可选取一组数据作为该等价类的代表, 对系统进行测试。如系统要求输入的数据为0~5之间的整数, 就可划分出3个等价类:小于0的整数;0~5的整数;大于5的整数。

1.3 边界值分析

此方法通常结合等价类划分方法一起使用。系统在边界处产生错误的概率较大, 因此有必要对边界处加强测试。选取的测试数据可以略大于、略小于或等于边界值。对上述等价类的例子而言, 可设定-1、0、1、4、5、6进行测试。

1.4 因果图

与等价类划分和边界值分析方法相比, 因果图方法既考虑了输入条件的组合关系, 又考虑了输出条件对输入条件的依赖关系, 效率较高。它将自然语言描述的规格说明转换为类似数字逻辑电路的因果图。步骤如下: (1) 将功能说明书分解成片段。将输入条件分成若干组, 分别对每个组使用因果图, 减少输入条件组合的数目; (2) 识别原因和结果, 并加以编号。原因是指输入条件或输入条件的等价类, 结果是指输出条件或系统变换。每个原因和结果都对应于因果图中的一个结点, 当原因或结果成立 (或出现) 时, 相应结点的值为1, 否则为0; (3) 根据功能说明中规定的原因与结果之间的关系画出因果图; (4) 根据功能说明在因果图中加上约束条件; (5) 根据因果图画出判定表; (6) 为判定表的每一列设计一个测试用例。

2 优化测试用例数量的黑盒测试方法

前述黑盒测试方法测试用例数量有时过多, 有必要采用化方法选取有代表性的测试用例来提高发现错误的概率。

2.1 分类树方法

该方法与等价类划分类似, 不同之处在于分类树方法是用树状图来表示各类别。操作步骤如下:

(1) 从软件系统的功能说明书中识别出不同的类别。以求两数中较大数的程序为例:假设程序要求的输入文件是File, File接收两个数据a和b。计算a-b的结果, 由得到的结果判断两数的大小。因此, 输入文件File有3个类别:不存在、存在但为空文件、存在但非空。a-b的值也可分为3类:大于0、小于0、等于0。

(2) 根据得到的类别构造分类树。

(3) 根据分类树的结点设计测试用例表。

(4) 从用例表中挑选可行的测试用例。

本文以企业员工考勤系统为例探讨分类树设计测试用例的方法。此考勤系统的功能说明书如下:

(1) 统计企业每月考勤结果。员工平时上下班刷卡的时间记录在考勤系统中。根据考勤记录统计员工的出勤情况。每个员工都有一个ID, 可唯一识别员工的个人信息, 如员工的姓名、岗位、工资等信息。

(2) 在考勤系统界面上输入员工ID, 系统information文件中存放员工个人信息, 根据该文件可识别员工的权限, 如果ID号码不合法, 或是离职员工, 系统将提示“无法统计出勤情况”。在职员工分为两类:一类是普通员工, 需进行功能说明书第3步的操作;另一类是特权员工, 如总经理等级别的员工, 常因出差、招标等原因外出, 因此考勤可以适当放宽, 执行功能说明书第4步操作。

(3) 上班时间为早上9:00到下午5:00, 刷卡时间允许前后波动15分钟。普通员工一个月内最多可迟到3次。超过3次, 每超过1次扣除员工月工资总额的1/30。假设刷卡时间为time, 月工资为salary, 迟到次数为count。迟到次数小于3次, 系统提示“无迟到记录”;迟到次数等于3次, 系统提示“本月迟到达到3次”;迟到次数大于3次, 系统计算本月应扣除工资:salary/30× (count-3) , 并将结果显示出来。

(4) 特权员工刷卡时间不作为考勤的唯一标准。统计此类员工考勤信息时, 系统弹出“特权员工不按照普通员工的考勤考核办法”。

根据考勤系统的功能说明书, 可以分析得出系统的不同类别, 如下表1所示。

由表1可知, 每个分类分别有3、2、2、3个类别, 将这些类别分别组合, 可知该系统的用例总数为3×2×2×3=36个。但其中有些用例是不合法的, 比如:“information文件的状态”如果是空, 则不可能与“员工ID状态”这个分类进行组合。此类不合法的测试用例无需进行测试。因此实际测试用例少于36个。构造系统分类树, 如图1所示。

该分类树中图形含义如下: (1) 圆点表示开始, 代表根结点, 表示系统的输入域。位于顶点下方的“information文件的状态”为顶层分类; (2) 矩形框表示按照功能说明进行的分类 (即表格1中第一列的项目) ; (3) 分类树的终端即叶子结点用列 (竖线) 来表示; (4) 分类树中的每一行代表一个测试用例。

分类树下方用横线隔开, 每一行可以设计一个测试用例。可设计如下7个测试用例: (1) 输入information文件状态为“不存在”, 预期输出:考勤系统弹出错误提示; (2) 输入information文件状态为“存在但为空”, 预期输出:考勤系统弹出错误提示; (3) 输入information文件状态为“存在但不空”, 员工ID状态为“无此ID”, 预期输出:考勤系统弹出“无法统计出勤情况”的提示; (4) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“特权员工”, 预期输出:考勤系统弹出“特权员工不按普通员工的考勤办法考核”; (5) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count小于3, 预期输出:考勤系统弹出“无迟到记录”; (6) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count等于3, 预期输出:考勤系统弹出“本月迟到达到3次”; (7) 输入:information文件状态为“存在但不空”, 员工ID状态为“有此ID”, ID的权限为“普通员工”, 迟到次数count大于3, 预期输出:考勤系统显示员工本月应扣工资金额。由图1可知, 由分类树设计的7个测试用例, 相比原先由组合关系得到的36个测试用例, 数量明显减少, 根据系统的输入数据域, 可全面测试系统功能。

2.2 正交试验设计

正交试验设计 (Orthogonal experimental design) 是研究多因素多水平的一种设计方法, 它根据正交表从全面试验中挑选出部分有代表性的点进行试验。正交表是均衡分散的, 在减少测试用例的同时, 也能对软件进行全面的测试。在正交测试中, 次数 (Runs) 表示测试用例的个数;因素数 (Factors) 表示影响某结果的变量个数;水平数 (Levels) 表示每个因素取值的个数;正交表的表现形式记为:Lruns (1evelsfactors) 。其操作步骤如下: (1) 找出与软件系统输出结果相关的因素与水平; (2) 根据不同的因素和水平, 选择适当的正交表。如果影响软件的水平数相同, 因素数刚好符合正交表, 则直接选用该正交表。如果水平数相同, 但在正交表中找不到相应的因素数, 则取因素数最接近但略大实际值的表; (3) 将正交表转化为含有因素的测试用例方案。

3 结语

分类树方法与等价类划分相似, 但主要采用树形图来设计测试用例, 可以减少用例数量。此方法对测试者软件项目经验要求不高, 而且可以不依赖自动化工具即可进行测试。正交试验设计法也可以优化用例的数量。该方法由正交表来设计测试用例, 减少试验次数。但利用正交试验设计法有时因素数和水平数与正交表不会恰好相符, 有一定的误差。本文两种方法各有优点。

参考文献

[1]段力军.软件产品黑盒测试的测试用例设计[J].测试技术学报, 2007, 21 (2) :160-162.

[2]CHEN TY, PAK LOK POON.Experience with teaching blackbox testing in a computer science/software engineering curriculum[J].Education, IEEE Transactions on Issue Date:Feb.2004, 47 (1) :42-50.

[3]郭学品, 钟声, 黄成.软件测试用例设计分析[J].海南广播电视大学学报, 2010 (4) :16-19.

软件测试用例的编写 篇6

国家广播电影电视总局于2012年10月发布了NGB终端中间件技术规范,标准号为GY/T 267—2012[1]。 目前遵循该规范的NGB终端机顶盒已进入研发和生产阶段,接下来产品的测试和认证工作就显得尤为迫切和重要,因此判定产品是否符合中间件技术要求将是亟待解决的问题。

GY/T 267—2012[1]标准对NGB终端中间件的软件架构、协议栈、内容格式、应用信令、应用传输、应用支撑、安全机制、应用编程接口等各个方面的技术要求进行了规定。其中应有编程接口是该标准的核心内容, 检验终端产品是否符合中间件标准要求基本可通过对应有编程接口的全方位测试来加以验证。本文将简述中间件API接口要求,描述API接口的测试方法和测试方案,以典型测试单元为例,介绍测试用例的设计和实现方法。

1中间件API

NGB终端中间件软件架构示意见图1。

图1中的应用编程接口,即中间件提供给应用的接口。NGB终端中间件所能支撑的应用,按应用开发技术类型可分为NGB-J和NGB-H应用:

1)NGB-J应用是指采用Java编程语言开发应用的统称;

2)NGB-H应用是指 采用HTML,JavaScript, CSS等Web技术开发应用的统称[1]。

GY/T 267—2012标准[1]针对NGB-J应用和NGB-H应用分别定义了Java API和JS(JavaScript)API两套接口。

1.1 Java API

NGB终端中间件应为NGB-J应用开发提供三类Java接口,即Java基础接口、DAVIC扩展接口和NGB扩展接口[1]。

Java基础接口由SUN公司制定,是开发NGB-J应用的必要支撑。NGB终端中间件应支持CDC1.1.2 (JSR 218)/FP 1.1.2(JSR 219)/PBP1.1.2(JSR 217)和MIDP2.0(JSR 118)Java基础接口[1]。

NGB扩展接口由中间件标准定义,针对NGB应用需求扩展制定。NGB终端中间件应实现的扩展Java接口功能单元包括:单向广播网络接入单元、广播协议处理单元、媒体处理单元、应用引擎单元——频道搜索、 应用引擎单元——业务选择等[1]。

DAVIC扩展接口由数字音频视频委员会针对数字电视应用而制定。NGB终端中间件应支持的DAVIC 1.4.1p9定义的部分接口,主要包括MPEG/DVB传输流、 表格数据装载等处理的相关类和方法[3]。

1.2 JS API

NGB终端中间件应为NGB-H应用提供两类JS对象,即基础JS对象和NGB扩展JS对象[1]。

基础JS对象由W3C组织定义,是开发NGB-H应用的基础。NGB-H应用应支持的基础JS对象遵循W3CJS 1.5规范[1]。

NGB扩展JS对象由中间件标准定义,针对NGB应用需求扩展制定[1]。NGB-H应用应支持的扩展JS对象功能单元与Java接口基本相同。

2测试方案设计

2.1设计原则

NGB中间件API数量庞大,涉及业务逻辑繁多复杂,如果想完全模拟这些业务逻辑,需要设计一套基于白盒测试的模拟测试环境,通过调用API对业务逻辑的触发来验证API功能的完整性和稳定性。

白盒测试又称结构测试或逻辑驱动测试,主要是对程序模块进行如下检查:

1)对逻辑模块的所有独立的执行路径至少测试一遍;

2)对所有的逻辑判定,取“真”与取 “假”的两种情况都至少测试一遍;

3)在循环边界和运行界限内执行循环体;

4)测试内部数据结构的有效性[4]。

应用白盒测试的思想,通过测试用例设计和脚本的编写,即可实现对NGB中间件API接口的可用性和完整性进行更准确的测试。由于NGB-H和NGB-J应用编程接口的基础接口主要采用现有成熟技术,出现问题的可能性较小,所以测试用例主要针对中间件标准定义的扩展接口来进行设计。测试用例的设计原则为:

1)对API的调用,覆盖率达到100%;

2)对同一API接口测试涵盖正例和反例;

3)对API的调用,符合业务逻辑执行规律;

4)模拟NGB业务典型应用场景。

2.2设计方案

本测试实施过程将采用单元测试,以及自动化和手动相结合的方式。针对这种方式,测试用例的设计方案为:

1)采用模块化设计,模块划分以标准定义的功能单元为依据,包括单向广播网络接入单元、广播协议处理单元、双向宽带网络接入单元等;

2)设计两类测试用例,分别为自动化方式和手动方式,两种方式相互补充,使测试过程更趋向高效和完整。

2.2.1自动化方式

自动化方式测试用例主要按照以下要求进行设计:

1)测试程序运行后,将自动执行测试步骤和测试项;

2)API的输入参数为预先设定的固定值,参数一般取有效和无效两种情况;

3)测试结果的判定一般依据函数的返回值或者有无异常情况;

4)每个测试项执行完成后将自动显示测试结果 “PASS”或“FAIL”。

这类测试用例的优点是测试过程效率高,操作简单,测试结果准确且直观;不足之处是对测试条件有一定要求,不够灵活(如前端发送信号的调谐参数要与测试程序里的有效参数一致等),并且对一些须人工审核测试结果的API不能准确测试(如媒体播放API等)。

2.2.2手动方式

手动方式测试用例主要按照以下要求进行设计:

1)具有可视化的交互界面;

2)测试程序运行后,由人为触发测试项,须手动执行测试步骤;

3)API的输入参数须手动输入或选择;

4)正例测试和反例测试须由测试人员操作;

5)测试结果的判定须由测试人员依据输出结果、 返回数据或显示效果等来验证;

6)每个测试项的测试结果须测试人员记录 “PASS”或“FAIL”。

这类测试用例的优点是测试条件灵活(如前端发送信号的参数可随意修改等),可测试多种情况和场景,且便于测试一些须人为观察测试结果的API(如媒体播放API等);不足之处测试过程较长,操作稍显复杂,测试结果因由人工审核,所以对测试人员的专业要求较高(如须熟悉DVB/MPEG相关技术规范等)。

3测试用例实现

本章将以NGB中间件Java API接口的频道搜索模块和媒体处理单元为例,分别描述自动化方式和手动方式这两类测试用例的实现方法。

3.1频道搜索

频道搜索测试单元主要测试中间件标准Java应用引擎中的org.ngb.toolkit.channelscan包,该包的概要见表1。

频道搜索单元测试用例采用自动化方式,该单元设计为一个Xlet(一种J2ME应用模型)模型,其中每个子测试用例为1个函数测试1~2个API[5]。Xlet在启动运行后,自动执行每个子测试用例,测试过程如发现问题则输出错误位置和原因,并在执行结束前输出测试结果“PASS”或者“FAIL”。

频道搜索单元测试用例设计流程图见如图2所示, 其中图左侧为该测试单元的整体软件设计流程,右侧为子测试用例ChannelScanTC8(测试启动频道自动搜索功能)的软件设计流程。该测试单元所测接口和测试目的见表2。

3.2媒体处理

媒体处理单元主要测试中间件标准Java媒体处理单元中的org.ngb.media包,该包的概要见表3。

媒体处理单元测试用例采用手动方式,该单元设计为1个Xlet模型,其中每个子测试用例为一个测试项测试1~3个API[5]。Xlet在启动运行后,每个测试项将人为地按下界面中的按钮来触发执行,API调用后的返回数据、接收事件、异常情况或错误信息将输出打印在界面中,并且音视频的播放效果也将直接呈现,测试人员以此判断并记录测试结果“PASS”或者“FAIL”。该测试单元所测接口和测试目的见表4。

媒体处理单元测试用例设计流程图如图3所示,图中左侧为该测试单元的整体软件设计流程,右侧为子测试用例MediaTC3(测试启动媒体播放器功能)的软件设计流程。

4小结