用例设计

用例设计（共9篇）

用例设计 篇1

1 软件测试的概念

使用人工和自动化手段来测试或运行某个系统的过程,其目的在于检验它是否真的满足规定的需求或者是明确预期结果与实际结果之间的差异。

2 测试用例的定义

测试用例是为特定的目的而设计的一组测试输入、执行条件和逾期结果。测试用例是执行的最小实体。

3 测试用例的特征

(1)最有可能发生的错误;

(2)不是重复的、多余的;

(3)一组相似测试用例最有效的;

(4)不要太复杂;

(5)可复用。

4 测试用例设计的原则

(1)全面性原则。覆盖所需要测试的功能点,要想达到覆盖面比较全,首先要对测试产品全面了解,并且明确测试范围,即明确不需要测试的内容和需要测试的内容。

(2)单个测试用例覆盖最小化的原则。假如要测试一个功能Y,它有三个子功能Y1、Y2和Y3,可以用下面两种方法来设计测试用例。

方法1:用一个测试用例覆盖三个子功能-Test_Y1_Y2_Y3。

方法2:用三个单独的用例分别来覆盖三个子功能-Test_Y1,Test_Y2,Test_Y3。

方法1适用规模较小的工程,但有规模和质量要求的项目,方法2则是更合适的选择,因为它具下面几个优点:测试用例的覆盖边界定义更明确;测试结果对产品问题的明确指向性更强;测试用例间的耦合度最低,彼此之间的干扰也就越低。

以上3个优点带来的直接好处是测试用例的调试、分析和维护成本是最低的。每个测试用例应尽可能简单,只验证所需要验证的内容,否则只会增加测试执行阶段的风险,还会带来彼此之间的干扰。此外,覆盖功能点简单明确的测试用例,便于组合生成新的测试,如在Visual Studio中引入了Ordered Test的概念。

(3)测试用例替代产品文档的功能原则。在开发软件产品的初级阶段通常是用Word文档的形式来记录产品的需求描述、功能描述和功能的具体细节等信息,来描述未来要实现产品的功能,便于团队进行交流,并且在团队内部达成对产品功能和细节的共识。假设在这时达成的共识并描述的功能是B,随着产品开发进程的深入,团队成员对产品的功能有更新的认识,产品功能也会变得更具体细化,在一个迭代或者Sprint结束时最终实现的功能很可能是B+。如此反复,在不断接纳用户的反馈,多个迭代过后,原本被描述为B的功能很可能最终变为了C。这时再去看曾经的Word文档和One Note页面,它们仍然记录的是B。之所以会这样,是因为很少有人会去以及能够去不断更新那些文档,以准确反映出产品功能当前准确的状态。

产品代码和测试用例能够准确描述产品的功能细节。产品代码实现了产品功能,且准确描述了产品的功能,但是,由于各种编程技术,如面向对象、抽象技术、设计模式、资源文件等,使得产品代码本身很难读懂,所以,往往是在知道产品功能的前提下去读代码,而不是反过来看代码来了解功能。目前来看测试用例能如实反映产品功能,测试执行也如实反映了产品功能,否则测试用例就会执行失败。所以,对测试用例的理解应再上升到另一个高度,测试用例能够体现产品描述文档的功能。所以,要求编写的测试用例足够详细、测试用例的组织要有条理,这些单靠Word、Excel或者One Note这样通用的工具是无法实现的,需要使用专业的测试用例管理工具来辅助,例如,Mercury Interactive公司生产的企业级测试管理工具Test Director。

对于自动化测试用例而言,代码在编写上应有别于产品代码编写风格,可读性和描述性应是重点考虑内容。在测试代码中,可以引入面向对象、设计模式等优秀的设计思想,但是一定要适度使用,通常面向过程的编码方式更利于组织、阅读和描述。

5 测试用例的设计方法

5.1 等价类划分法

等价类划分法是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的常用的黑盒测试用例设计方法。

在进行测试用例设计时,要同时考虑有效等价类和无效等价类,这样能使软件接受合理的数据,验证合理的功能,也要经受住不合理的意外考验,增强程序的容错能力,确保软件的测试具有更高的可靠性。

有效等价类:是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类:与有效等价类的定义相反,无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

5.2 边界值分析方法

边界值分析方法是对等价类划分方法的补充,也是黑盒测试方法之一,是对等价类分析方法的一种补充。

在测试工作中得出的经验证明,大量错误发生在输入或输出的边界值上,所以,设计各种边界值的测试用例,可以发现更多BUG。

使用边界值分析方法设计测试用例,首先应确定边界情况,通常输入或者输出等价类的边界,着重测试的边界情况,应选取正好等于或者略大于或者略小于便界的值作为测试数据,而不是选择等价类中的典型值或者任意值作为输入数据。

基于边界值分析方法选择测试用例的原则如下:

(1)如果输入条件规定了值的范围,则应取刚达到这个范围边界的值,或者刚刚超过这个范围边界的值作为测试输入数据;

(2)如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据;

(3)根据规格说明的每个输出条件,使用前面的原则;

(4)根据规格说明的每个输出条件,应用前面的原则;

(5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例;

(6)如果程序中使用了一个内部数据结构,则应选择这个内部数据结构的边界上的值作为测试用例;

(7)分析规格说明找出其他可能的边界条件。

5.3 案例

以计算三角形面积的程序为例,运用基本的测试用例设计方法灵活设计测试用例。

某程序需要实现如下功能:输入3个整数D、E、F,输出D、E、F为三边的三角形面积(1<=D、E、F<100),结果保留2位小数。

分析:可以运用等价类和边界值的方法,编写测试用例,具体分析见图1:

根据上面的分析,设计出计算三角形面积测试用例,见表1:

6 结语

影响软件测试的因素很多,如软件的复杂度、团队成员的素质、测试方法、测试技术等。因为某些客观因素存在,有些因素是波动的、不稳定的,会影响测试者的情绪,这种情况下测试用例在软件测试中发挥重要的指导作用。只有理解测试用例的设计原则、设计方法,和具体业务相结合,设计出合理的、高覆盖率、高容错率的测试用例,测试用例才能更好地规范测试执行人员对软件产品进行测试,使软件产品质量得到保障,人们才能使用到高质量的软件产品。

摘要：随着科技的发展,电脑、手机等电子产品的普及,软件的应用越来越普遍,软件测试的重要性得到越来越多的关注。软件产品的测试质量如何保障,重点还是在软件的测试用例设计上,软件测试用例设计的合理性、覆盖率和容错能力,决定了软件产品本身的质量。基于此,介绍了软件测试的基本概念、软件测试用例设计的原则和软件测试用例设计几个基本方法。

关键词：软件测试,测试用例设计,等价类划分法

参考文献

[1]郑人杰.计算机软件测试技术[M].北京:清华大学出版社,1992.

[2]赵斌.软件测试技术经典教程(第二版)[M].北京:科学出版社,2011.

用例设计 篇2

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

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

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

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

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

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

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

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

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

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

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

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

5、测试用例的框架

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

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

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

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

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

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

7、测试用例的一些思路

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

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

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

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

（4）容量测试

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

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

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

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

（9）可靠性，容错性

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

（11）安全性

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

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

Web安全测试用例设计研究 篇3

随着电子商务和互联网的广泛应用,Web应用软件被越来越广泛的使用。除了传统的应用如电子邮件、新闻网站等,目前Web应用软件也被越来越多的关键性任务使用,例如互联网证券、互联网银行、网络购物等涉及金钱交易的应用,以及政府部门的电子政务等业务通过互联网来开展等。上述关键性的应用对软件安全的要求越来越高,假如由于软件的不安全造成系统被破坏或信息被泄露,将会给国家、集体甚至个人带来巨大的损失。所以,确保Web应用软件的安全是非常重要的,设计全面、有效的安全测试用例则是重中之重。

2 常见Web安全问题

研究Web应用软件的安全性测试技术,首先应对已知的应用软件安全问题进行研究,了解各种漏洞产生的原因、触发的条件、造成的后果,抽象出各类漏洞的特征,进行科学的分类,才能有效指导安全性测试工作,保障其科学性、高效性和针对性。OWASP(The Open Web Application Security Project)是一个致力于web应用安全的国际组织,OWASP分析实际应用中经常出现的安全漏洞,并对各类漏洞进行总结描述,发布每年度的最危险的十大漏洞,能够很好地反映Web安全所面临的威胁和这些威胁的发展趋势,被众多权威性机构(如美国国防部、国际信用卡数据安全技术标准、美国联邦贸易委员会等)列为应用程序安全规范。根据OWASP提出的Web应用安全漏洞数据分布来看,Web应用程序面临的安全形势依然严峻,常见的安全问题包括:

1)注入式攻击。例如SQL、OS以及LDAP注入,发生在不受信任的数据作为一条指令或是查询要求的一部分被发往解释程序之时。攻击者所植入的恶意数据可以骗过解释程序,导致该指令或查询要求在无意中被执行。

2)跨站点脚本(简称XSS)。每当一个应用程序携带了不受信任的数据并将其发送至页面浏览器而又未经过相关验证及转换解析时,XSS类漏洞就会蠢蠢欲动。XSS允许攻击者在受害者的浏览器中执行脚本,这会导致用户的会话遭受劫持、网站受到破坏或者是将用户的访问目标重新定向至某些恶意网站。

3)无效的认证及会话管理功能。应用程序的相关认证及会话管理功能在执行过程中常常发生各种问题,导致攻击者有可能获取到密码、密钥、会话授权或是通过利用其他执行性漏洞来盗取用户身份。

4)对不安全对象的直接引用。当开发者公开引用某种对内部执行对象,例如索引系统、一个文档或是数据库关键信息时,就有可能发生这种不利情况。由于缺乏访问控制检查等安全保护措施,攻击者能够利用引用信息对未获授权的数据进行访问。

5)伪造的跨站点请求(简称CSRF)。CSRF类攻击的特点是,强迫受害者的某个已进行登录操作的浏览器向安全保护薄弱的页面应用程序发送一条伪造的HTTP请求,包括受害者会话缓存内容及其他任何自动产生的包含认证信息的内容。这就导致了攻击者可以通过强制受害者浏览器向具有漏洞的应用程序传递请求的方式,使相关的应用程序认定该请求是受害者本人所发出的合理请求。

3 Web安全测试内容

攻击者攻击网络的手段多种多样,目的在于寻找并利用网络中存在的漏洞。要想实现周密的安全防范,就需要分析攻击者入侵网络的方式。攻击者对网络攻击的方式包括本地攻击、远程攻击和伪远程攻击。他们的目的主要包括:非法访问目标系统,以获取不应有的访问权限;篡改相关数据,修改重要资料;获取所需资料;使用有关资源,发布虚假信息、占用存储空间甚至发动分布式攻击等。

攻击者进行Web应用攻击行为的过程包括:首先,发现Web系统或应用程序中已存在的漏洞;然后,根据具体漏洞的类别采取对应的、有效的攻击手段;最后,人工分析攻击结果,获取想要的信息或权限。按照目前常见的攻击手段,应该有针对性的进行测试,主要的测试内容如下:

1)漏洞扫描。安全漏洞扫描一般需要借助特定的漏洞扫描器完成,漏洞扫描器其实就是一种能自动检测本地主机或远程端安全性弱点的程序。系统管理员通过漏洞扫描器能及时发现维护的信息系统中存在的安全漏洞,这样在保卫信息系统网络安全过程中可以有的放矢,及时对漏洞进行修补。按照常规标准划分,漏洞扫描一般分为两类,分别为网络漏洞扫描器(Net Scanner)和主机漏洞扫描器(Host Scanner)。网络漏洞扫描器是指通过网络,远程检测目标主机或网络系统的安全漏洞的程序,典型的程序包括ISS Internet Scanner、Satan等。主机漏洞扫描器是指在本地主机或网络系统上运行检测安全漏洞的程序,如著名的COPS、Tiger等软件。

2)功能验证。功能验证属于软件测试当中的黑盒测试方法,对涉及软件的安全功能,如权限管理功能、用户管理功能、认证功能、加密功能等进行测试,验证上述功能是否安全有效。进行黑盒测试的目的是为了模拟一个用户可能采取的恶意行为,观察Web应用系统及其配套的安全措施能否真正地起到防护过滤恶意行为的作用。

3)网络侦听。实际上,网络侦听是指在数据交互或数据通信过程中对数据进行截取并分析的过程。目前,比较通用的网络侦听技术就是捕获网络数据包,我们通常称为Capture,黑客可以通过该项技术盗取公司或个人有价值的数据,同理,测试人员一样可以利用该项技术测试Web应用软件或系统的安全性。

4)模拟攻击测试。模拟攻击测试对于安全测试来说是一种特殊的黑盒测试案例,我们通过模拟攻击的方式来验证信息系统或软件的安全防护能力,在数据处理与数据通信环境中常见的攻击包括冒充、重演、消息篡改、服务拒绝、内部攻击、外部攻击、陷阱门、特洛伊木马等。

4 测试用例设计原则

一个完整的Web安全测试用例体系设计可以从身份验证、加密、输入验证、敏感数据、配置管理、授权、异常管理、会话管理、参数操作、审核和日志记录、部署与基础结构等几个方面入手。下面将详细描述测试用例设计时需要注意的要点。

1)数据加密设计原则。执行数据传输操作需要对某些数据进行信息加密和过滤,比如用户登录密码信息、用户信用卡信息等。此时,其他操作也需要相应进行,如解密发送到客户浏览器或用户电子邮箱、将信息存储到数据库等。目前的加密算法种类越来越多,设计越来越复杂,但数据加密的过程一般是可逆的,意思就是能对数据进行加密,也能对数据进行解密。一般可在后台数据库查看登录的账户和密码是否进行了加密。

2)目录设计原则。Web的目录安全是一个不容忽视的因素,如果Web服务器或Web应用程序的设计不合理,攻击者就可以通过简单的URL推测和替换,完全获取整个Web目录的权限,这样就对Web站点造成很大的安全性隐患。我们可以采取一定的预防措施,如在访问每个目录时设置index.htm,或者访问Web服务器的目录时对权限进行严格的设定,从而使发生安全问题的可能性尽可能地降低到最小程度。

3)登录设计原则。一般的Web应用站点都会采用登录或注册后使用的方式,所以必须对用户名和密码进行匹配校验,以防止用户非法登录。进行登录测试时,需要考虑的方面包括输入的密码是否区分大小写、是否有长度条件限制,最多可以尝试登录多少次,哪些文件或者页面需要登录后才能访问或下载等。

4)服务器脚本语言设计原则。脚本语言存在一定的安全隐患,每种脚本语言的细节略有不同,有些脚本语言允许访问根目录,其他脚本语言只允许访问邮件服务器,但是有经验的黑客可以通过脚本漏洞获取服务器的用户名和口令。设计测试用例时需确认站点使用了哪种脚本语言,并研究该语言的漏洞,还需要考虑是否存在没有经过授权就在服务器端编辑或放置脚本的情况。

5)SSL设计原则。现在越来越多的Web站点使用SSL安全协议进行数据传送。SSL是Secure Sockets Layer(安全套接字协议层)的缩写,是Netscape首先发布的网络数据安全传输协议。SSL的原理是通过私有密钥/公开密钥的加密技术(RSA),在TCP层和HTTP层之间对用户与服务器之间的通信进行加密,确保信息传递的安全性。SSL是在私人密钥和公共密钥的基础上进行工作,任何用户都可以获取公共密钥来加密数据,但解密数据需要使用相应的私人密钥。打开一个SSL站点后,有时候能看到浏览器弹出警告信息,地址栏的http变成https,对SSL进行测试的时候需要确认上述特征,以及站点是否具备时间链接限制等相关的安全保护措施。

5 结束语

Web应用是一种典型的应用程序,Web应用本身越来越复杂,同时它所使用的开发语言和开发模型在不断发展,所有这些因素给测试带来了很大的难度。目前的安全测试主要依赖测试工程师的直觉和经验,Web安全测试被认为是一个耗时、代价昂贵的过程,因此,迫切需要设计一套系统的Web安全测试用例对Web应用进行全面的测试。本文正是基于以上目的,对Web安全漏洞进行分类,研究了Web安全测试内容,阐述了安全测试用例设计原则。

参考文献

[1]方建超,徐全军.网络安全漏洞检测技术分析[J].计算机安全,2005(10):32-33.

[2]施寅生,邓世伟,谷天阳.服务安全性测试技术研究[J].计算机工程与科学,2007,29(10):11-13.

[3]刘焕洲,缪淮扣.Web应用程序建模和测试用例生成方法[J].计算机工程,2008,34(6):60-62.

[4]The Open Web Application Security Project[EB/OL].http://www.owasp.org/index.php/Main_Page.

软件测试经典用例设计面试笔试题 篇4

1.测试项目：电梯

需求测试:查看电梯使用说明书、安全说明书等

界面测试:查看电梯外观

功能测试：测试电梯能否实现正常的上升和下降功能.电梯的按钮是否都可以用;

电梯门的打开，关闭是否正常;报警装置是否可用，报警电话是否可用;

通风状况如何.突然停电时的情况;是否有手机信号;

比如说上升途中的响应，电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来;

电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停;

可靠性：门关上的一刹那出现障碍物，同时按关门和开门按钮，点击当前楼层号码，多次点击同一楼层的号码等等;同时按上键和下键会怎样;

易用性：电梯的按钮的设计符合一般人使用的习惯吗.

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

压力测试：看电梯的最大限度的承受重量.在负载过重时报警装置是否有提醒.在一定时间内不断的.让电梯上升，下降.最大负载下平稳运行的最长时间，

2.测试项目：杯子

需求测试: 查看杯子使用说明书

界面测试: 查看杯子外观

功能度：用水杯装水看漏不漏;水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水(案例一)放24 小时检查泄漏时间和情况;盛上汽油(案例二)放24 小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

毕业设计选题系统的用例分析 篇5

关键词：毕业设计选题,UML,用例图,用例描述

现在已经进入互联网时代, 教学管理软件配合计算机硬件的强大处理能力, 提高了很多高等学校教学和管理工作的效率。但是一些学校的毕业设计选题仍采用手工管理的方式, 效率低而且易出错, 这就有了开发毕业设计选题系统的需要。

而开发一个软件系统, 首先要做的是需求分析。在众多需求分析方法中, 用例分析以其简单、直观、清晰、适用范围广、易于交流的特点, 受到了广泛的认可。本文就将使用用例分析法, 对毕业设计选题系统进行功能分析。

毕业设计选题系统有三种角色的使用者, 分别为:学生、教师和管理员。首先从学生的角度, 分析系统需要提供哪些功能。如下图:

用例图能够直观地描述出系统的外部功能, 但是不能详细地描述功能的内部流程。这就需要用例描述的配合。这里将不列出所有用例的描述, 只列出其中的两个核心的。首先是“查看题目信息”用例。

接着是“选题”用例。

接下来再从教师和管理员的角度分析用例, 结果如下图:

因篇幅所限, 在此不列出这两幅图对应的用例描述, 有兴趣者可以自己分析和补充。欢迎给予批评和指导!

参考文献

远程心电监护系统的测试用例设计 篇6

关键词：远程心电监护系统,黑盒测试技术,心电图,测试用例的复用性

1 远程心电监护系统概述

远程心电监护系统分为家庭端、医疗中心端及两者间的通信连接构成。家庭端部分包括用户端心电图监测设备、连接因特网的工作站、远程心电监护客户端软件。医疗中心端部分包括位于不同地理位置的医疗中心终端、远程心电监护医疗中心端软件。两者间的通信连接包括从心电图监测设备采样连接、以及工作站选择不同接入网连接Internet网络。系统能够在平台内实现心电信号的实时图像传输。

2 远程心电监护系统测试用例设计

测试用例设计要体现软件工程的思想和原则，针对远程心电监护系统的特定功能或组合功能设计测试方案并编写成文档。测试的目的就是暴露应用软件中隐藏的缺陷，所以在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据。结合监护系统复杂的运行环境，在所有可能的输入条件和输出条件中确定测试数据，来检查应用软件是否都能产生正确的输出。

常见的黑盒测试技术有等价类划分法、边界值分析法、错误推测法、功能分解法、状态图转换法等。使用这些方法来设计远程心电监护系统测试用例不仅实用快捷，而且避免了盲目性，突出了重点，提高了效率，缩短了测试周期。

2.1 等价类划分法及其应用

等价类划分法是在分析需求规格说明的基础上把远程心电监护系统某功能的输入域合理划分成若干部分，各部分形成的子集合就是等价类，测试某等价类中的代表值就等于对该等价类的其他值的测试。

等价类划分有：有效等价类和无效等价类。

有效等价类是指对于需求规格说明而言是正确、合理的输入构成的集合，可验证远程心电监护系统是否正确实现该功能。

无效等价类是指那些不合理、无意义的输入构成的集合，可测试远程心电监护系统是否能经受意外考验，是否稳定可靠。

例如：远程心电监护系统测试中有测试需求“在软件中七通道ECG波形是否正确显示”对此项测试需求，在设计测试用例时主要使用等价类划分法，其划分步骤如下：

第一步：划分等价类，并且为每个等价类编号。

第二步：为有效等价类设计测试用例，使一个测试用例尽可能覆盖多个有效等价类。对表中编号为(1)(2)(3)的3个有效等价类用3个测试用例覆盖。

第三步：为无效等价类设计一个测试用例。

因此，利用等价类划分，可设计出如表2至表3所示的至少4个用例。采用等价类划分法可以在远程心电监护系统功能测试中大大减少工作量、提高测试效率。

2.2 边界值分析法及其应用

测试用例的选择既要有一般情况，也应有极限情况以及最大和最小的边界值情况。边界值分析法是一种补充等价类划分的测试技术，方法是通过选择等价类的边缘值作为测试用例，让每个等价类的边界都得到测试。远程心电监护系统在面临某些边界输入情况时，会出现一些意想不到的问题。例如：远程心电监护系统测试中有测试需求“病人心电数据显示是否正确”采用边界值分析法可设计出如表4所示的至少4个用例。

2.3 错误推测法及其应用

凭经验或直觉推测可能的错误，列出程序中可能有的错误和容易发生错误的特殊情况，是针对性很强的测试用例设计方法。例如：远程心电监护系统测试中有测试需求“系统是否正常工作在windows环境下，影响其余应用程序工作进程”，利用错误推测法可设计出如表5所示3个测试用例。

2.4 几种方法组合及其应用

等价类划分方法和边界值分析方法，着重考虑输入条件，但未考虑输入条件之间的联系,相互组合等。因果图法描述了对于多种条件的组合，比如针对测试需求“在软件中七通道ECG波形是否正确显示”，同时还需要考虑到是否需要“冻结某通道显示”。对远程心电监护系统的测试用例设计时，需要把这些黑盒测试方法结合应用。灵活使用等价类法、错误推测法、边界值法等相互补充来设计用例，才能有效提高测试效率和测试覆盖率，提高软件的质量。

3 软件测试用例的复用

以最少的人力和资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，是软件公司探索和追求的目标。在远程心电监护系统测试用例的设计中，充分考虑了对于今后同类被测系统的测试用例复用性上。在用例的写作过程，把测试用例有效的组织起来，使得每一个测试用例都能独立运行，比如针对输入、输出接口类的测试用例放在一起等方式。使得今后使用最少的测试用例，实现最大的测试覆盖，可复用度好。在测试用例的设计、选择的基础上，构造出基于复用的测试用例，同时采用测试用例库管理的方法来实现测试用例的复用，可以提高软件测试的工作效率。

4 结束语

在测试用例设计过程，首先要使用测试用例设计的各种方法结合应用，有效提高测试覆盖率;同时要构造出基于复用的测试用例，不断的应用新软件系统开发去构建测试用例库，这样就能在新项目中做到用最少的人力和资源、最少的测试用例，覆盖到所有的测试覆盖。

参考文献

[1]郑人杰.计算机软件测试技术.北京:清华大学出版社,1992.

[2]徐芳.软件测试技术.北京:机械工业出版社,2006.

[3]尚冬娟,郝克刚,葛玮,等.软件测试中的测试用例及复用研究.西安:计算机技术与发展,2006(16):69-72.

[4]匡青,朱宜炳.高职院校软件测试课程教学改革探索.武汉:现代商贸工业,2010(3):237-238.

软件系统测试类型及测试用例设计 篇7

随着航空型号功能的日趋复杂, 软件在型号中的应用越来越多, 其规模和复杂度也日趋上升。由软件所导致的问题的比例也在上升, 软件已经成为影响航空型号产品质量和可靠性的关键因素之一。软件测试作为软件研制的重要环节, 其是否充分、有效, 将直接影响到软件产品的质量[1]。

软件测试类型按照开发阶段分为单元测试、部件测试、配置项测试和系统测试[2]。对于航空型号软件而言, 系统测试是最重要的测试, 它能够发现软件中潜藏的时序、软硬件接口等方面的问题。

1 系统测试概述

系统测试是在真实系统工作环境下或系统仿真环境下检验完整的软件配置项能否和系统正确连接, 并满足系统设计文档的要求[3]。系统测试过程描述见图1。

2 系统测试类型及测试用例设计要求

常见的系统测试类型分为功能测试、性能测试、边界测试、接口测试、余量测试、安全性测试、强度测试等[3]。不同的测试类型, 在设计测试用例时, 其测试点各有不同, 下面结合测试实践经验, 对不同的测试类型的测试点进行分析。

2.1 功能测试

功能测试是对软件需求规格说明中的功能需求逐项进行的测试, 以验证其功能是否满足要求。其测试点包括:

1) 用正常值的等价类输入数据值测试;

2) 用非正常的等价类输入数据值测试;

3) 进行每个功能的合法边界和非法边界值输入的测试;

4) 用一系列真实的数据类型和数据值运行, 测试超负荷、饱和及其他“最坏情况”的结果;

5) 对控制流程的正确性、合理性等进行验证。

功能测试是最基本的测试, 同时也是最重要的测试。在进行功能测试时, 首先要明确功能测试的正常等价类, 同时在用例设计中别遗漏了正常等价类;根据输入数据的属性展开想象, 设计非正常的功能测试用例, 并且注意预期结果;设计测试用例时, 一方面分析输入数据, 另一方面分析操作流程。

2.2 性能测试

性能测试是对软件需求规格说明中的性能需求逐项进行测试, 以验证其性能是否满足需求。其测试点包括:

1) 数据采集功能的测试;

2) 测试在获得定量结果时程序计算的精确性 (处理精度) ;

3) 测试其时间特性和实际完成功能的时间 (响应时间) ;

4) 测试为完成功能所处理的数据量;

5) 测试程序运行所占用的空间;

6) 测试负荷潜力;

7) 测试软件的性能和硬件性能的集成;

8) 测试系统对并发事物和并发用户访问的处理能力。

性能测试经常与余量测试、强度测试、容量测试一起进行, 基本的性能度量应当首先以没有争议的方式在主要的功能上被执行;其次在系统处于竞争模式下进行, 即在一种苛刻的环境中衡量资源的使用常常是必要的。

2.3 边界测试

边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试测试点包括:

1) 软件的输入域或输出域的边界或端点的测试;

2) 状态转换的边界或端点的测试;

3) 功能界限的边界或端点的测试;

4) 性能界限的边界或端点的测试;

5) 容量界限的边界或端点的测试。

边界测试是最为普遍的测试类型之一, 几乎所有的软件都有边界测试。看到有范围和数值要求时, 应立刻联想到数值边界;同时注意不同分辨率 (数据精度) 的边界, 如整数和浮点数的范围、角度的范围、时间的范围等。

2.4 接口测试

接口测试是对软件需求规格中的接口需求逐项进行的测试。接口测试的测试点包括:

1) 测试所有外部接口, 检查接口信息的格式及内容;

2) 对每一个外部输入/输出接口必须做正常和异常情况的测试;

3) 测试硬件提供的接口是否便于使用;

4) 测试系统的特性 (如数据特性、错误特性、速度特性) 对软件功能、性能特性的影响;

5) 对所有的内部接口的功能、性能进行测试。

接口测试往往与软件的功能测试结合在一起, 但是接口测试的关注点是接口。接口测试同样需要考虑正常与异常数据的情况, 并且明确所测对象有哪些接口, 然后根据接口的格式特点设计用例。

2.5 余量测试

余量测试是对软件是否达到需求规格说明中要求的余量的测试。按照国军标要求, 一般至少留有20%的余量。余量测试的测试点为:

1) 全部存储量的余量;

2) 输入/输出及通道的吞吐能力余量;

3) 功能处理时间的余量。

余量测试需要分析能够进行余量测试的测试项。余量测试一般为隐含需求, 一般要求留有20%的余量;只要所测对象含有数据要求均可考察其余量, 目前比较重视主要是硬件配置方面的余量;余量测试需在任务较繁重的前提下进行, 并对余量提取是否合适进行确认。

2.6 安全性测试

安全性测试是检验软件中已存在的安全性、安全保密性措施是否有效的测试。其测试点包括:

1) 对安全性关键的软件部件, 必须单独测试安全性需求;

2) 在测试中全面检验防止危险状态措施的有效性和每个危险状态下的反应;

3) 对设计中用于提高安全性的结构、算法、容错、冗余及中断处理等方案, 必须进行针对性测试;

4) 对软件处于标准配置下其处理和保护能力的测试。

5) 应进行对异常条件下系统/软件的处理和保护能力的测试;

6) 对输入故障模式的测试;

7) 必须包含边界、界外及边界结合部的测试;

8) 对安全性关键的操作错误的测试;

9) 对具有防止非法进入软件并保护软件的数据完整性能力的测试;

10) 对重要数据的抗非法访问能力的测试。

2.7 强度测试

强度测试是强制软件运行在不正常到发生故障的情况下 (设计的极限状态到超出极限) , 检测软件可以运行到何种程度的测试。其测试点包括:

1) 最大处理的信息量;

2) 数据能力的饱和实验指标;

3) 最大存储范围 (如常驻内存、缓冲等) ;

4) 在人为错误 (如寄存器数据跳变、错误的接口) 状态下进行软件反应的测试;

5) 需进行持续一段规定的时间, 而且连续不能中断的测试。

3 软件系统测试设计

3.1 系统测试用例设计策略

具体的软件测试项目中, 设计测试用例有多种方法, 对于简单的功能, 选取一种适合的方法即可满足要求, 而对复杂的功能, 运用某一种方法设计出的用例显然不能全面的覆盖各个测试点, 应该联合使用各种的方法, 形成一种综合策略。具体地说, 可以归纳为下述策略:

1) 将测试需求分解为测试项, 选用的测试类型的集合要覆盖规定的测试类型, 对现有条件无法测试的测试项 (不可测项) 要给出不可测的原因, 并给出降低风险的方法;

2) 在编写某一测试类型测试用例时, 要尽可能多地覆盖相应的测试要求;

3) 对重要功能使用频度高的功能, 可适当增加测试用例数量 (包括对各种可能出现的异常情况的考虑) ;

4) 对静态分析中复杂度高的模块所对应的功能适当增加测试用例数量;

5) 在一个功能中发现缺陷后, 要生成用例测试其余功能是否存在同样缺陷;

6) 依靠专业积累, 彻底全面地思考测试场景, 发现并有效的找出隐错;

7) 测试类型并非正交的, 多个测试类型之间存在交叉, 设计测试用例时应把握二个原则:即不能重复、不能遗漏。

3.2 测试实践

在某软件系统测试过程中, 依据软件设计文档进行了测试需求分析和策划, 制定了测试计划, 明确了测试项, 并编制了测试说明, 对软件进行了全面的测试, 共设计了31个测试项目、648个测试用例, 覆盖了功能、性能、边界、接口、余量、强度和安全性所有的测试类型 (见表1) , 达到了国军标对软件测试类型的覆盖要求, 也对软件设计文档的各项设计要求及相关指标进行了测试验证。

表1测试项目及测试用例覆盖情况统计表

在设计测试用例过程中, 有些用例可以按照第2章节描述的方法进行独立设计, 但大部分测试用例的设计需要采用组合策略, 既满足覆盖性要求, 同时也提高测试的效率。表2列举了在测试过程中, 针对不同的测试类型分解的部分测试项的实例。从表2可以看出, 既有通过组合设计的测试项目, 也有进行独立设计的测试项目。

3.3 测试结果评价

在某软件的测试中, 根据以上测试类型综合设计测试项, 使设计出的测试用例更合理, 更全面。通过执行这些用例, 对软件功能进行了全面的测试, 发现了软件在设计方面存在的问题。软件测试工作通过了上级部门组织的评审, 对软件是否实现了预期的功能和是否可以进行系统联试起到了良好的评价作用。

4 结论

本文介绍了常见的系统测试类型及其用例设计方法, 这些方法都是在日常测试任务中实用的设计方法。在实际的测试过程中, 通过各种测试类型的交叉和组合应用来设计用例, 可以有效地对软件进行测试, 提高了测试效率, 降低了测试成本。该系统测试用例设计方法已用于多个型号软件的测试过程, 经证明是一个通用性强、切实有效的设计方法。

参考文献

[1]弹载软件系统测试方法研究.科学技术与工程[J].2008, 8 (13) :3559-3562.

[2]石柱.软件工程标准手册[M].北京:中国标准出版社, 2004.

浅析黑盒测试用例设计的因果图法 篇8

1 因果图法的内涵

因果图法是利用图解法, 根据输入条件的组合、约束关系和输出条件的因果关系, 分析输入条件的各种组合情况, 设计测试用例的方法[1]。

2 主要的因果关系

因果图中主要有两种结点:原因结点与结果结点, 这两种结点分别有两种状态:0状态、1状态。若原因为假, 则为0状态, 否则为1状态;若结果发生, 则为1状态, 否则为0状态。通常情况下, 原因结点用符号Ci (i≥1) 表示, 结果结点用符号Ei (i≥1) 表示。

在因果图中, 原因与结果的主要关系有:与 (∧) 、或 (∨) 、非 (~) 、恒等。

(1) 与关系表示当且仅当所有原因都为真, 结果才为真;只要有一个原因为假, 结果就为假, 其含义用伪代码可以表示为:if (C1&&C2) then E1。

(2) 或关系表示只要有一个原因为真, 结果就为真;当且仅当所有的原因为假, 结果才为假。其含义用伪代码可以表示为:if (C1||C2) then E1。

(3) 非关系表示原因与结果间的否定, 若原因为真, 结果就为假;若原因为假, 结果就为真。其含义用伪代码可以表示为:if (!C1) then E1。

(4) 恒等关系表示原因与结果间的一对一关系。若原因为真, 则结果就为真;若原因为假, 则结果就为假。其含义用伪代码可以表示为:if (C1) then E1。

在以上伪代码中, C1、C2分别表示原因, E1表示结果。

因果图中与、或、非、恒等关系的表示如下图1所示。

3 原因之间的约束

原因之间的约束是指输入条件之间存在的依赖关系 (如某些输入条件本身不可能同时出现, 或者必须同时出现等) 。例如某企业的库存控制管理系统, 其功能是跟踪企业产品的库存变化情况。对于每种产品库存的3种状态:库存正常、库存不足、库存为空, 在任何情况下这3种状态最多只能有一个为真。

在因果图中原因之间的约束主要有排异约束、包容约束、唯一约束、要求约束。

(1) 排异约束又称排他性约束, 表示在任何情况下, 各个原因之间只能有一个为真 (不能同时为真) , 但可以同时为假, 在因果图中用符号E表示, 如下图2。

(2) 包容约束又称包含性约束, 存在包容约束的各个原因中总有一个为真 (可以同时为真) , 但不可以同时为假, 在因果图中用符号I表示, 如下图3。

(3) 唯一约束表示各个原因中有且仅有一个为真, 在因果图中用符号O表示, 如下图4。

(4) 要求约束又称必要性约束, 若原因C1、C2之间存在要求约束, 表示若C1为真, 则C2也必须为真, 在因果图中用符号R表示, 如下图5。

4 因果图法应用分析

应用因果图法设计测试用例时, 首先需要分析软件需求规格说明书, 找出原因 (输入条件) 、结果 (输出条件) , 然后确定原因与结果之间的关系、原因之间的约束关系, 最后根据绘制的因果图, 将其转换为判定表, 指导设计测试用例[1]。

虽然因果图法可以设计多个输入条件的组合用例, 减少因果关系的复杂程度, 帮助我们以较快地的速度生成判定表设计测试用例。但是有的输入条件与输出结果的因果关系非常隐蔽, 很难从软件需求规格说明书中顺利获取, 有时即使找到了这些因果关系, 也会因为因果关系复杂, 规模太大, 导致因果图非常庞大, 测试用例数目及其庞大, 这就很容易导致产生冗余的测试用例, 所以因果图法一般应用于有明显的因果关系的测试[2]。

参考文献

[1]库波.软件测试技术[M].中国水利水电出版社, 2010.

[2]Rom Patton著, 张小松, 王钰, 曹跃等译.软件测试 (第2版) .机械工业出版社, 2006.

用例设计 篇9

1 正交试验法

1.1 正交试验法简介

正交试验设计起源于科学试验,应用正交表从大量的试验条件中挑选出适量的有代表性的条件来合理安排试验。运用这种方法安排的试验具有“均匀分散、整齐可比”的特点。“均匀分散”性使试验点均匀的分布在试验范围内,让每个试验点有充分的代表性;“整齐可比”性使试验结果的分析十分方便。

1.2 正交试验与全面试验、单因素轮换试验的比较

1.2.1 全面试验

全面试验就是把所有的因素和水平逐一搭配起来进行试验。例如,对于3个因素、3个水平的试验,需要做33=27次试验。若将这27个试验点标绘在以A、B、C为三个坐标轴的直角坐标系内(见图1),其对应的是立方体的27个点。

全面试验的优点是试验的全面性,缺点是要求的试验次数太多,对于m个因素、n个水平,总的试验次数是nm,这在大多数情况下无法实现。

1.2.2 单因素轮换试验

单因素轮换试验是一种把多因素的试验问题转化为单因素的试验问题的处理方法。在这种试验中,每次只变化一个因素,其他因素固定。这种方法的优点是试验次数比较少。例如,对于三个因素A、B、C三个水平的试验,其中的一种试验方案如表1所示。

同样,将这九个点标绘在以A、B、C为坐标轴的直角坐标系对应的位置上(见图2)。从图2可以看出,这些点的分布并不均匀,说明试验的代表性不是很好,因此这些试验的方法是不全面的,它不能客观地反映27个试验的情况。

1.2.3 正交试验

正交试验汲取了上面两种方法的优点,同时克服了它们的缺点。同样的情况,用正交法L9(34)安排的九次试验,反映在以A、B、C为三个坐标轴的直角坐标系中,就是立方体的九个点,如图3所示。这九个点在立方体内均匀分布,因此能够基本反映27个试验的情况。

2 正交法设计软件测试用例的基本步骤

主要包括五个步骤:

(1)确定因素。这里的因素是指软件的输入和硬件的运行环境。若因素太多且测试资源有限,可根据专业知识和工作经验,去掉那些对试验结果影响不大的因素。

(2)确定因素的取值范围。因素的取值范围是指软件的输入范围以及可用的硬件资源。

(3)确定每个因素的水平。根据因素的取值范围,采用等价类划分、边界值分析以及其他软件测试技术,在每个因素的取值范围内挑选出“有效等价类、无效等价类、边界值、临界值”等有代表性的测试点。

(4)选择正交表。根据确定的因素和水平,选择一张合适的正交表。合适的正交表要满足以下两个条件:1正交表的行数与所确定的水平数完全一致;2正交表中的列数要大于或等于所确定的因素数。

(5)设计测试用例表。将所确定的因素与正交表中的“列号”相对应,所确定的水平与正交表中的行数相对应,填写正交表。

3 应用实例

下面以某模拟器的参数设置界面(如图4)为例说明测试用例的正交设计方法。

(1)确定因素。在软件界面上有五个输入参数,分别是工作电流、编码方式、波门、NETD值和俯仰。通过对该应用的分析,确定这五个输入项为因素。

(2)确定因素的取值范围。工作电流、编码方式、波门、NETD值这四个参数的取值范围已经确定。俯仰可以输入1~10之间的整数。

(3)确定每个因素的水平。工作电流、编码方式、波门、NETD值这四个参数分别对应三个水平。由于俯仰可以输入10个值,因此存在无效等价类:小于1的数、大于10的数。对俯仰先设计2个无效等价类测试用例,取0、11,预期结果是:提示输入参数超范围。在有效等价类中取1、5、10三个值。

(4)选择正交表。依据上面的分析,这个测试有5个因素,每个因素有3个水平。选用正交表L16(45)设计测试用例。

(5)设计测试用例表。由于每个因素只有3个水平,因此将所有水平4用1代替,然后合并相同的项,最后得到表2所示的正交表。

如果采用全面试验法设计测试用例,则测试用例的个数为:3×3×3×3×3=243。使用正交试验法得到的测试用例个数为15个,测试用例的数目大大减少,有效提高了软件测试效率,而且软件测试的覆盖率也得到保证。

4 结论

使用正交试验法设计测试用例,是从工程的角度去理解软件测试,有组织、有计划、有步骤地开展软件测试,在测试效率得到很大提高的同时,又避免了测试用例设计的随意性。如何实现用正交测试法来自动生成测试数据,是下一步的研究课题。

参考文献

[1]徐仲安,王天宝,李常英.正交试验设计法简介[J].科技情报开发与经济,2002,12(5):148-150.

[2]吴翊.应用树立统计[M].长沙:国防科技大学出版社,1995.

[3]增德.正交表的构造及正交性的证明[J].江西教育学院学报,2003,24(6):6.

[4]赵斌,辛文逵.目前软件测试发展中的误区[J].信息与电子工程,2003,1(4):323-325.

[5]于秀山.正交实验设计方法在测试用例设计中的应用[J].计算机工程与应用,2004,20(1):62-63.

[6]Glenford J Myers.The Art of Software Testing[M].北京:北京机械工业出版社,2006.

[7]Paul C,Jorgensen.Software Testing[M].北京:北京机械工业出版社,2003.

[8]Soumen Maity,Amiya Nayak.Improved test generation al gorithms for pair-wise testing[C]//Proceeding of the 16thIEEE International Symposium on Software Reliability En gineering,2005.

[9]QIAN Feng-an,JIANG Jian-hui.An improved test casegeneration method of pair-wise testing[C]//The 16th IEEEAsian Test Symposium,2007.