软件测试用例设计方法

软件测试用例设计方法（精选7篇）

软件测试用例设计方法 篇1

一、等价类划分

1）确定等价类

有效等价类代表对程序的有效输入；无效等价类代表的是其他不正确的任何输入。如果需要，我们还可以将一个等价类划分为更小的一些等价类。

比如，规格说明规定了“请输入书籍的数量（1~99）以及书籍的类型（硬皮、软皮或活页）”。它们对应的等价类分别如下：

书籍数量

书籍类型

2）生成测试用例

1.为每个等价类设置编号。

2.编写测试用例，尽可能多的覆盖尚未被覆盖的有效等价类。直到所有的有效等价类都被测试用例覆盖。测试用例及其覆盖的有效等价类如下：

3.编写测试用例，覆盖一个且仅一个尚未被覆盖的无效等价类。直到所有的无效等价类都被测试用例所覆盖。测试用例及其覆盖的无效等价类如下：

用单个的测试用例覆盖无效等价类，是因为有些输入的错误检查可能会屏蔽或取代其他输入的错误检查。比如②⑦，也许程序提示“非法的书籍数量”后，就不会执行对书籍类型的检查了。

二、边界值分析

经验证明，考虑了边界条件的测试用例比其他没有考虑边界条件的测试用例，具有更高的测试回报率。所谓边界条件，是指输入和输出等价类中恰好处在边界、或超过边界、或在边界以下的状态。

上例中的书籍数量范围是1~99，那么应该针对0，1和99，100的情况分别设计测试用例。

从定义可以看出，等价划分只关注输入空间（输入等价类）的不同，边界值分析还需要从输出空间（输出等价类）设计测试用例。

举例来说：

某个程序按月计算个人所得税的速算扣除数，且最小金额是0，最大金额是13,505。使用边界值分析法，应该设计测试用例测试速算扣除数结果为0和13505的情况。此外，还应观察是否可能设计出导致速算扣除数为负数，或者超过13505的测试用例。

边界值分析法和等价划分重要的区别是，等价划分是从等价类中挑选任意一个元素作为测试数据；边界值分析法考察正处于等价划分边界或在边界附近的状态。

三、因果图

边界值分析和等价划分的缺点是，未对输入条件的组合情况、输入条件之间的相互制约关系进行分析。

1）因果图的基本关系

恒等（Identify）:若a为1，则b为1；否则b为0。

非（NOT）:若a为1，则b为0；否则b为1。

或（OR）:若a或b或c为1，则d为1；否则d为0。

与（AND）:若a和b和c都为1，则d为1；否则d为0。

2）因果图的约束条件

1、对于输入条件的约束有E、I、O、R四种：

异（E）:E必须总为真，而a、b最多只有一个为1。

或（I）:I为真时，a、b和c中至少有一个必须为1。

唯一（O）:a、b中，有且仅有一个必须为1。

要求（R）:如果a为1，b也必须为1。

2、对于输出结果的约束只有M一种：

屏蔽（M）:如果结果a为0，则b强制为0。

一、假设有一规格说明：

“第一列中的字符必须是‘A’或‘B’，第二列中的字符必须是一个数字。在这种情况下，对文件进行更新。如果第一个字符不正确，产生提示信息X12。如果第二个字符不是数字，产生提示信息X13。”

（1）将规格说明分解为可执行的片段，确定“因”和“果”，为每个“因”和“果”都赋予唯一的编号。“因”是条件，是指一个明确的输入条件等价类。“果”是动作，是指一个输出或系统转换（输入对程序或系统状态的延续影响）。

（2）分析规格说明的语义，转换为因果图。原因①和原因②不可能同时成立，为因果图添加对应的约束条件，得到右图。

因果图和添加了约束条件后的因果图

（3）将因果图转换为判定表，每一列代表一个测试用例。

判定表

（4）将判定表中的列转换为测试用例。

二、将因果图转换为判定表的思路（以上述的例子来说明）

1.选择一个“果”作为当前状态。例：71。

2.对因果图回溯，找出导致该“果”为1的所有因的组合（需要考虑到约束条件）。例：001，000。

3.在判定表中为每个“因”的组合生成一列。例：（列3）和（列4）。

4.对于每种“因”的组合，判断所有其他“果”的状态，并放置在对应的每一列中。例：已得在001，000两种组合下结点71的结果为1。判断在“因”为001的组合下，得到70和72的结果为0。判断在“因”为000的组合下，得到70的结果为0，72的结果为1。将“果”的状态填入其对应的列。

对因果图进行回溯时，需要做到以下考虑：

1.当回溯经过一个结果为1的OR结点时，不要将OR结点的1个以上的输入同时设为1。

2.当回溯经过一个结果为0的AND结点时，应列举出导致该结果为0的所有输入情况的组合。然而，当该AND结点的一个输入条件为0时，其他输入有一个或更多的1，则不必考虑其他输入为1的所有情况。

3.当回溯经过一个结果为0的AND结点时，所有输入皆为0的这一种情况应当列举出来。

找出因果图中，所有导致输出状态为0的输入条件

(1)根据上述第c)条思路，我们只需列出使得结点⑤和结点⑥皆为0的情况。结点①②③④的取值状态为：

0，0，0，0（5=0，6=0）

(2)根据第b)条思路，对于结点⑤为1而结点⑥为0的情况，应该列出导致⑥为0的所有输入情况组合。同时，只需列出一种使得⑤为1的情况即可，不需要列出⑤为1时的所有输入情况组合。又根据第a)条思路，当结点⑤为1时，我们不应将结点①和②同时设为1。于是，得到结点①②③④的取值状态：

1，0，0，0（5=1，6=0）

1，0，0，1（5=1，6=0）

1，0，1，0（5=1，6=0）

同样的，对于⑤为0而⑥为1的情况，也只需要列出⑥为1的一种情况即可（尽管在本例中也只有这一种）。

0，0，1，1（5=0，6=1）

因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的好处，就是可以指出规格说明的不完整性和二义性。但通常它不能生成全部应该被确定的有效测试用例。

注意：因果图方法没有充分考虑边界条件。建议，最好是单独考虑边界值分析。这不意味着我们要为此增加相应多的测试用例，而是在由因果图生成测试用例时，可以将边界条件分析一并考虑进去。最好的结果是既满足了两方面的目标，又不需要增加新的测试用例。

四、错误推测

错误猜测是一项依赖于直觉的非正规的过程，其基本思想是人们利用直觉和经验猜测可能犯得错误或错误易发情况的清单，然后编写测试用例来暴露这些错误。

软件测试用例设计方法 篇2

关键词：黑盒测试,等价类划分法,边界值分析法,决策表法,测试用例

随着人们对软件需求日益增长, 对软件的质量要求也越来越高。但是, 由人开发的软件, 缺陷是在所难免的, 这便是需要对开发的软件进行测试的原因。软件测试可以极大缩短软件开发周期, 它是软件质量保证的一个重要环节, 它可以验证软件是否实现了期望的功能。在软件测试方法中黑盒测试方法是其中一种测试方法。它避开软件内部程序, 相当于是直接从盒子表面对盒子特征进行测试, 直接测试的是程序本身所具备的功能。

在有限时间与资源的条件下, 想要进行完全测试, 找出所有软件缺陷和错误是不可能的。也就是说想要进行穷尽测试是不可能的, 那么在这种条件下应如何运用有限测试资源, 如何利用最少时间使测试做到充分、高效?解决这个问题就非常重要。想要在最短时间内达到最佳测试效果, 这就需要根据软件需求对软件设计相关的测试用例。

1 黑盒测试

黑盒测试 (又称功能测试、基于规格说明的测试或数据驱动测试) , 它对软件所实现的功能进行测试, 验证软件开发的功能是否满足开发文档的功能要求及性能要求。它主要的缺陷包括:

(1) 功能实现错误或有遗漏;

(2) 接口输入、输出结果错误;

(3) 界面报错;

(4) 性能无法满足需求;

(5) 数据结构或外部结构访问错误;

(6) 初始化或终止条件错误。

2 测试用例设计

2.1 等价类划分

等价类划分是黑盒测试方法中的一种典型测试方法。它是将输入的数据 (有效的数据、无效的数据) 划分成多个区间 (等价类) , 然后在每个区间选取具有代表性的值, 设计成测试用例 (由有效等价类和无效等价类的代表组成) 。利用有效等价类可验证软件是否实现了规格说明书中规定的功能和性能。利用无效等价类可验证软件是否包含了不符合规格说明书中规定的功能和性能。

等价类的划分方法包括:按区间划分、按数值划分、按数值集合划分、按限制条件或规划划分等。

(1) 按区间划分, 可确定一个有效等价类和两个无效等价类。如:在取值范围为[5, 10]整数中, 它的有效等价类为5≤X≤10, 无效等价类为X<5, X>10。

(2) 按数值划分, 即一组数据 (包含N个数据值) , 可确定N个有效等价类 (每个数值为一个有效等价类) 和一个无效等价类 (不在这N个数据值的数据) 。如:变量X的取值范围为{1, 3, 5, 7, 9, 16}, 那么它的有效等价类有6个, 分别为X=1, X=3, X=5, X=7, X=9, X=16, 无效等价类为X≠1, 3, 5, 7, 9, 16。

(3) 按数值集合划分, 在规定了数值的集合中, 可确定一个有效等价类和一个无效等价类。如:变量X的取值为5位长度的字符串, 那么它的有效等价类为X的字符串长度5位, 无效等价类为X的字符串长度不等于5位。

(4) 按限制条件或规划划分, 划分等价类中各个元素的处理方式。它可以确定一个符合限定条件或规则的有效等价类和若干个不符合条件的无效等价类。如:要求密码首字母必须为英文字母, 有效等价类为密码的首字母为英文字母, 无效等价类为密码的首字母为非英文字母的字符。

2.2 边界值分析法

边界值分析法也是黑盒测试方法之一。其是对输入或输出的边界进行测试的一种方法。这种测试方法是对等价类分析方法的补充, 其用例来自等价类的边界。通过经验证明, 大量错误通常发生在边界上, 通常对其进行测试可取得良好测试效果。因此, 通常针对各种边界情况设计测试用例, 这种对输入、输出边界附近情况设计测试用例应给予足够重视。边界类分析法的取值取的是它的正常值、它的边界 (即正好等于左右边界的值) 及它的次边界 (即刚刚大于左边界或刚刚小于右边界的值) 作为测试数据, 即取min、min+、nom、max-、max。如:变量5≤X≤10, 且X为正整数, 那么测试用例中变量X的取值为左边界最小值5、略大于左边界最小值6、值域内任意值 (7、8中的任一取值) 、略小于右边界最大值9、右边界最大值10。

2.3 决策表法

决策表法 (也被称为判定表法) , 它是黑盒测试方法中最为严格也是最具有逻辑性的测试方法。它可以分析和表达多逻辑条件下系统执行不同的操作情况。因为在实际开发应用中, 输入的条件往往是由多个因素构成的, 而非由单一因素构成。因此, 采用决策表法可以对多个输入条件的情况进行组合设计。如:判断x、y、z三个正整数能否构成三角形, 可根据相应问题生成决策表, 再将决策表转换为测试用例, 相关的决策表如表1所示:

2.4 状态转换测试

状态转换测试是黑盒测试技术中的一种, 它针对特定需求设计测试用例。因为测试对象的输出与行为方式不仅仅受到当前输入数据的影响, 同时也受到对象执行前的情况或之前输入数据的影响。因此, 通过状态转换测试对系统的每个状态以及与状态有关的函数进行测试, 通过不同的状态验证程序的逻辑流程。如打开Word进行编辑浏览状态图如图1所示:

设计用例如表2所示:

2.5 基于经验的测试

经验对于各行各业的工作者来说都是非常重要的。对于软件测试而言, 经验同样也拥有非常重要的地位。在软件测试中有时会遇到基础文档不全或不完善的情况, 这时便需要依赖测试人员的技术、知识与经验预测可能发生故障的地方, 也可作为其他测试方法的补充方法对软件进行测试。它采用逆向思维方式, 可以有针对性地设计系统的测试用例, 使测试变得更充分、高效。如:对日历进行测试时, 利用经验法会着重对日历软件易发生错误的几个方面进行测试。包括:

(1) 是否能正确分清闰年闰月;

(2) 大小月日期是否正确;

(3) 日期与星期是否能对上等。

3 结语

软件出错是无法杜绝的, 为了让用户在正式使用之前可以尽可能多发现和修改潜在错误, 应加强对软件进行测试。黑盒测试从输入和输出数据的对应关系对软件进行测试, 不涉及内部结构。在实践中证明了通过黑盒等测试方法对软件进行优化, 可以使得软件更加系统化、灵活化, 使软件质量、可靠性得到明显提升。因此, 本文对黑盒测试中的等价类划分、边界值分析法、决策表法、状态转换测试、基于经验的测试这几种测试方法进行探析。

参考文献

[1]陈威.软件测试的概述及方法[J]数字化用户, 2013 (30) .

[2]武剑洁, 陈传波, 肖来元.软件测试技术基础[M].武汉:华中科技大学出版社, 2008.

[3]殷人昆, 郑人杰, 马素霞, 等.实用软件工程 (第三版) [M].北京:清华大学出版社, 2010.

[4]陈卫卫.软件测试[M].西安:西安电子科技大学出版社, 2011.

[5]中华人民共和国国家质量监督检验检疫总局, 中国国家标准化管理委员会.GB/T 25000.51-2010/ISO/IEC25051:2006软件工程软件产品质量要求与评价 (SQua RE) 商业现货 (COTS) 软件产品的质量要求和测试细则[S]北京:中国标准出版社, 2011.

[6]国际软件测试认证委员会.ISTQB测试人员认证初级 (基础级) 大纲[M].北京:人民邮电出版社, 2011.

[7]蔡建平.软件测试大学实验指导教程[M].北京:清华大学出版社, 2009.

回归测试中机器挑选用例方法研究 篇3

【关键词】机器学习；回归测试；测试用例

1.引言

机器学习（Machine Learning， ML）是一门交叉型学科，它涉及到了多个领域，包括：概率与统计学、高等数学、逼近和凸分析等。机器学习人类的学习过程和学习行为，并且加以计算机的模拟或实现。在机器学习过程中，机器本身了获取新的知识或技能。

在机器学习和人工智能的壮大发展的时代背景，对传统的测试工作提出了一些新的挑战。研究通过机器学习的方法，提升传统的测试工作的效率，进一步的提高整个软件开发活动的劳动生产率。

2.软件测试工程的研究综述

软件测试是用于分析是否程序出现错误的过程，测试使用人工操作或者软件自动运行的方式。每个不同的软件有对自身错误的定义方式：通常是软件需求规格中定义了预期结果。

软件测试分类

1、从是否要变异/执行被测试软件分类，分为静态测试和动态测试。如基于代码审查的单元测试，以及相关代码审查工具，都属于静态测试的范畴。

2、从是否要针对软件结构、算法进行覆盖分类，分为白盒测试和黑盒测试。

3、从测试活动在软件开发过程中所处的不同阶段分类，分为单元测试、集成测试、系统测试、验收测试。

我们这里讨论的“回归测试”是属于系统测试的最后一个阶段。

在修改了旧代码后，需要对这部分子都进行测试，以确保这个代码修订没产生新的错误。在大多数情况下，回归测试占测试周期和测试自由的50%。因此，如果能够制定更有效的回归测试用例，将极大的提升整个测试的效率。

回归测试的流程如下：

（1）找出程序中因为新增需求或者故障解决，而被修改的代码

（2）从总的用例库中，去除掉不再合适的测试用例：这部分用例可能是修改没涉及的功能，也可能是一些系统性稳定性的低优先级的测试用例

（3）针对修改的影响部分，增加一部分相关模块的测试用例

（4）搜索出最基本的测试用例，纳入到测试计划：这部分测试用例保证软件不出现意外的基本功能错误

（5）用上述2～4的测试用例集合，形成回归测试的测试范围

3.现有回归测试用例选择方法

对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。

针对修改部分的测试是我们希望改进的内容

当前是优秀的高级工程师逐一的查看开发提交的各个修改点，根据自己对相关部分的理解，以及对开发修改点的学习。整理出需要回归的测试点：这种方法的主要问题是：

需要优秀的工程师参与，这位工程师必须同时具备：既了解测试组的全部测试用例库，也需要能够理解开发提供的修订说明。

每一轮测试完成后，就需要人工干预，从而产生下一轮的测试用例

替代人工的方法是，为每一轮测试，执行类型level 0/1/2这样的测试用例等级。这样同样会带来冗余的测试用例执行，拉长了测试进度。

4.机器选择测试用例的方法

用机器来模拟和替代人工的挑选测试用例：是在回归测试中引入智能化方法的先决条件。整体按照如下的流程：

首先进行的是为每一条测试用例，生成不同的特征向量。在这个步骤中，将原始的测试用例转变成为“记录每个词出现的频率”的数学符号。最后生成如下表格：

其中行代表不同的测试用例，列代表不同的词语描述，数字代表不同的词语在不同测试用例中出现的词频。

然后，根据TFIDF算法将测试用例生成的文本特征向量，转换成为最终的文本特征向量。

这样，表一通过TFIDF算法最终转化的向量表示如下：

完成了特征词语的选择后，就要给选出的特征词语赋以权重。比如“测试”一词，在每个测试用例中都有出现，那么这个词虽然词频很高：但是“权重为零”——也就是说这个词对于描述不同测试用例的不同特征，无任何帮助。对于本研究方案而言，我们使用TF*IDF算法，计算出精确的统计量，以描述特征词语对于中文内容的重要性。

最后，将代码变更说明收集起来，计算特征向量。同时将测试用例库中的内容也做成特征向量。逐个的拿代码变更的特征向量，与用例库中的特征向量进行对比：选出与代码变更特征向量相识程度最高的。这个特征向量所代表的测试用例，既为下一轮回归测试的输入。在这个模块中，我们选择KNN算法，KNN算法也叫K最近邻算法。抽取测试用例库中的每个文本，逐一的与被测试的向量进行比较，每个比较完成后相似度被计算出来。下一步：找出K个最相似的测试用例。并在此基础上给每个被选出的测试用例打分，取分值大者作为比较结果。具体计算公式为：

其中：d为待测文本（开发提交的代码变更说明）向量，q为训练集中文本（原始的测试用例描述）向量。

这里给出一个具体实践：

开发提交了一个代码变更说明如下

最后机器推荐的相关性最紧密的四个用例，如下表：

可以看出，这四个被挑出来的点，都是对ACL重定向的测试：并且测试覆盖了物理端口、AP端口、SVI端口三种不同的端口类型。

进一步的，对这部分的测试进行基于代码覆盖率的验证，可以证明机器挑选出的四个测试用例，确实的有测试覆盖到开发修订的代码。

5.结束语

让机器来自主选择回归测试用例，然后将这个方法融入到自动化测试框架中。让自动化测试框架具有一定智能，能够“自主的产生回归测试用例的变化集合”。譬如整个ACL模块测试用例个数达到300，如果全部回归费时费力，而人工参与分析则会打断持续的自动化测试过程。新方法使用四个测试用例，就可以对开发修订提交的代码进行覆盖；这样一方面我们减少了回归测试的测试用例个数，另外一方面开发修订的代码，也被完整的测试了。

参考文献

[1]米歇尔（Mitchell，T.M.）.机器学习.机械工业出版社，2008-03-01

[2]盧苇，彭雅.几种常用文本分类算法性能比较与分析.湖南大学学报（自然科学版）， 2007.

[3]JOACHIMST.A probabilistic analysis of the rocchio algorithm with TFIDF for text categorization Nashville：1997：143-151.

测试用例设计步骤 篇4

设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：

1、测试需求分析

从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析

软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

从业务流程上，应得到以下信息：

A、主流程是什么

B、条件备选流程是什么

C、数据流向是什么

D、关键的判断条件是什么

3、测试用例设计

完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：

功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。

适合的技术：由业务需求和设计说明导出的功能测试、等价类划分

边界测试：对某个功能的边界情况进行测试。

适合的技术：边界值划分

异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是

可能发生的，类似这样的情况需要书写相关的异常测试。

适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值

分析、内部边界值测试。

性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部

性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包

括响应时间，吞吐量等。

适合的技术：业务需求和设计说明导出的测试

压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不

同的平台，不同的工具，相同工具的不同版本下功能的兼容性。

4、测试用例评审

测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。

测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。

5、测试用例更新完善

自动售货机测试用例 篇5

1.售货机有零钱找 2.投入1元硬币 3.投入5角硬币

4.押下橙汁按钮 5.押下啤酒按钮

结果：

21.售货机〖零钱找完〗灯亮

22.退还1元硬币

23.退还5角硬币

24.送出橙汁饮料 25.送出啤酒饮料 2.画出因果图

如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：

11.投入1元硬币且押下饮料按钮 12.押下〖橙汁〗或〖啤酒〗的按钮 13.应当找5角零钱并且售货机有零钱找 14.钱已付清

3.转换成判定表：

4.设计测试用例

1)在售货机有零钱找的情况下，投入1元硬币，押下橙汁按钮，找回5角硬币并送出橙汁饮料。

2)在售货机有零钱找的情况下，投入1元硬币，押下啤酒按钮，找回5角硬币并送出啤酒饮料。

3)在售货机有零钱找的情况下，投入1元硬币，系统不做任何处理。

4)在售货机有零钱找的情况下，投入5角硬币，押下橙汁按钮，送出橙汁饮料。5)在售货机有零钱找的情况下，投入5角硬币，押下啤酒按钮，送出啤酒饮料。6)在售货机有零钱找的情况下，投入5角硬币，系统不做任何处理。7)在售货机有零钱找的情况下，押下橙汁按钮，系统不做任何处理。8)在售货机有零钱找的情况下，押下啤酒按钮，系统不做任何处理。

9)在售货机没有零钱找的情况下，投入1元硬币，押下橙汁按钮，售货机“零钱找完”灯亮，并退还1元硬币。

10)在售货机没有零钱找的情况下，投入1元硬币，押下啤酒按钮，售货机“零钱找完”灯亮，并退还1元硬币。

11)在售货机没有零钱找的情况下，投入1元硬币，售货机“零钱找完”灯亮。

12)在售货机没有零钱找的情况下，投入5角硬币，押下橙汁按钮，售货机“零钱找完”灯亮，并送出橙汁饮料。

13)在售货机没有零钱找的情况下，投入5角硬币，押下啤酒按钮，售货机“零钱找完”灯亮，并送出啤酒饮料。

软件测试用例设计方法 篇6

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

1．测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

2．制定测试策略

制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略可以分为：

基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。

基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。

为了更好地制定好测试策略，要做到：

全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；

基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；

根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；

需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。

3．确定测试范围

测试主要依据 “产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

优先级最高的需求功能

新增加的功能和编码改动较大的已有功能

容易出现问题的部分功能

过去测试不够充分的地方

经常被用户使用的功能和配置（占20%）

4．所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。

在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

5．编制测试计划的技巧

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；

测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；

测试项目的输入、输出和质量标准，应与各方达成一致；

建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，加以控制。

6．测试项目计划的评审

测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

二、测试用例在测试活动中的作用：

1.强化测试用例在测试活动中的作用

测试用例在实际中没有起多大作用 , 在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中等等。

为何如此？ 根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，其实，从三个方面具体来说：

1）测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！

2）制定了完备有效的测试用例，为什么不按测试用例执行测试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。

3）测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些 测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。

2.改进测试用例执行过程

那么究竟如何做，才能尽量避免上述问题呢？

我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将问题扼杀在萌芽阶段。

1）软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？

项目的测试负责人和测试工程师在 需求阶段 的任务有：

a.参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。

b.全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

2）软件分析设计阶段：

l 测试人员除制定测试计划书等基本工作外，还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。（之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因）。

l 测试人员更要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据；它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。

l 当然该文档不是非要不可，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！

3）软件开发阶段： 编写测试用例。应该遵守的原则是：

n 首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点；如此可实现趋向最大需求覆盖率。

n 其次，从数量来讲，一个多于半年开发周期（指从编码开始直到提交客户的时间段）的软件系统，它的用例数量不要低于 4000 个，甚至更多！（IBM 等大公司测试过程的人士会认为 4000 还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出 5000 个用例，那它的测试覆盖率还怕不高么）！

n 再次，如此众多测试用例的管理问题。是的，最好是需要测试用例管理工具软件。以 word 或 excel 来编写测试用例也可以。）测试用例 格式上一般内容以外的几个要点：

l 制定适合本公司的测试用例模版；

l 是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工 / 自动两种）；

l 是测试用例要有 状态跟踪，可根据用例执行状态索引用例（测试通过、测试失败、测试中断等）；

l 是执行失败的用例要 链接到相应的缺陷报告，如有根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小；

l [FS:PAGE] 是测试用例的修改，以及每个测试周期的运行都有 日志记录，以便后期追踪

和新员工参考；）软件测试阶段，测试负责人划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等），再划分不同的子测试周期（如前两个星期做 冒烟测试，测试方式是手工 / 自动，测试版本是 **，测试环境是 **，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（通常原则是每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执行测试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：

A）有健全且严格的体制保证测试执行者严格按照测试用例执行测试。这并不妨碍测试者创造力的发挥，因为前期用例的设计和编写就是项目全体测试人员智慧的结晶！我们一直苦苦追寻众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段；如此实施，即便没有解决根本问题，也会大大提高测试执行效率。

B）如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。

C）测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。

D）测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态 不断验证软件功 能点。

E）通过缺陷管理工具来 管理软件缺陷 ；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。

F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。这里要提的其他几个基本原则是：

l 是选择恰当的测试工具品牌，并要求提供培训；

l 是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；l 是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态；

l 是选择最简单、最重用的测试用例使用自动测试方法；

l 是使用工具厂商提供的测试框架编写脚本，千万别采用单纯录制回放的方式，要开发出健壮且重用性强的测试脚本 ；

l 是有专人更新脚本，也有专人跟踪自动测试结果；

l 一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；

l 是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本。）由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。）软件验收阶段 ：除了提交软件测试评估报告（各种类型测试结果的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期维护，维护阶段需要重新测试某功能点，然而用例如果不准确，碰巧又是一个

新员工来做，那就死翘翘了！）其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。

3.总结

软件测试用例设计方法 篇7

随着计算机技术的不断发展, 软件产业也在不断的向前发展, 而人们对于软件的质量要求也越来越高。目前, 技术人员已经采用了很多方法保证开发过程中的软件质量, 但是都存在局限性并且也没有达到广泛使用的程度。软件测试是保证软件质量, 提高软件可靠性的重要手段, 一方面, 对于质量差的软件, 开发商的维护费用和用户的使用成本都会增加, 并且可能还会产生一些其它的责任风险, 另一方面, 软件测试是费时费力的一个过程, 会花费大约占总价值50%以上的代价。因此, 软件测试技术是以后长时间内保持良好的软件质量的重要保证。

2 软件测试方法

利用软件测试技术可以及时发现程序中出现的错误, 它不仅可以检查所开发的软件是否合格还能发现开发软件中的错误, 是现在十分重要的一种软件检测方法。采用软件测试可以发现软件开发过程中存在的问题和错误, 并且还会制定出一套内容全面的诊断报告书, 为程序员提供一些修改意见, 提高软件开发质量降低软件开发成本。现在, 软件测试方法主要包括两种:白盒测试和黑盒测试, 这两种方法的主要思想都是利用测试用例作为执行程序, 对软件进行全面客观的检测, 确保软件的各项功能都能正常运行。

白盒测试方法能得到程序的所有路径和其逻辑信息, 主要是通过程序内部的逻辑结构和各种其它信息进行软件测试的设计, 也被成为结构测试法。白盒测试方法主要在具有独立路径的模块中使用, 它不仅能对每个逻辑模块进行检查并且判断其真假, 还能对程序中的每一个循环变量的初值、中间值以及终值进行检查, 而且对于程序内部结构和数据的检测白盒测试方法同样有效。白盒测试方法针对程序中出现的书写错误、逻辑错误、印刷错误、路径错误以及条件错误等进行测试。

和白盒测试相比较, 黑盒测试方法主要考虑程序说明书、程序规模以及程序需要, 而不用考虑程序内部的逻辑结构和特性, 当检测到程序实现的功能和程序说明书中所说的功能不符合的情况时, 就说明程序设计出现错误, 一般也被成为功能测试法。目前, 黑盒测试方法主要在强调软件功能要求的计算机程序中使用, 对于那些过分强调程序内部结构和内部细节实现的计算机程序来说不太适合。另一方面, 对于那些出现终止错误、初始化不正确、数据错误、接口错误以及性能错误等问题, 使用黑盒测试方法能取得比较好的结果。

3 测试用例构造方法

测试用例的设计对于软件测试质量的高低有直接的影响, 它是软件测试过程中的指导性规范。测试用例正在大型软件开发过程中具有十分重要的作用, 在软件测试过程中, 测试用例就像是设计书对软件编程的作用一样起着规范性作用, 对于测试功能在测试用例指导书中都有详细的叙述, 特别是对于测试要点、测试数据规范、测试报告监测、测试总结以及测试条件等都有详细具体的规定。测试的输入数据应该包括全部的测试功能, 测试的输入数据和预期结果是测试用例的主要核心内容。

3.1 测试用例的主要内容

一个完整的测试用例构造主要包括测试目标、测试数据、需要测试的功能、测试环境、测试步骤以及系统的预期行为这6个方面。设计测试用例的主要目的是具体化系统需求, 对于每个功能可以通过测试的方法进行描述, 在构造测试用例的时候我们要考虑到所有的测试用例, 保证对软件系统测试的覆盖程度, 如果出现覆盖不完整的情况则会导致很多无法发现的错误, 而且如果出现较多的交集的话则又会造成时间以及人员的浪费, 加重测试的成本, 所以说, 测试用例设计的主要目标就是利用最少的测试用例来覆盖最全面的系统功能。

设计单个的测试用例的时候, 我们可以从基于以下几个原则的方面来考虑。首先, 要遵循测试需求详细设计的原则, 要考虑测试用例的设计是否符合系统的功能要求;其次, 要遵循基于测试方法的原则, 主要有边界值分析法、基于决策表的测试方法以及等价类方法这三个;再次, 要遵循兼顾充分性测试和效率的原则;最后, 要遵循可再现的测试执行原则。

3.2 测试用例的作用

测试用例在软件测试最终具有十分重要的作用, 主要表现在以下三个方面。首先, 在指导测试实施方面, 在实施软件测试时, 测试用例是其测试的标准, 测试人员应该严格按照测试用例的说明来逐步实施;其次, 在测试评估结果的度量基准方面, 软件测试工作完成后要对结果进行分析, 而且要写测试报告, 利用测试用例检验软件测试的完成、质量以及覆盖情况等是比较准确有效的;最后, 在分析缺陷标准方面, 通过对缺陷的收集和分析, 确定是漏测还是缺陷重现, 漏测表明测试用例不完善, 应该及时修补相应的测试用例, 提高软件质量。

4 总结

软件测试是软件开发过程中的一个十分重要的步骤, 它是确保软件质量的主要方式, 作为指导测试工作的测试用例是最终的测试结果产生的依据, 同时也是保障软件测试质量的根本手段, 经过软件测试技术可以发现程序中存在的缺陷和错误, 为技术人员提供修改标准, 提高了软件的可靠性。

参考文献

[1]魏忠海.计算机软件测试技术[M].上海:复旦大学出版社, 1996.

[2]陈意刚.浅谈软件测试技术[J].电脑知识与技术, 2008. (35) :2150~2152.

[3]李健.关于软件测试的阶段分析[J].计算机科学, 2012, 6.

[4]Myers GJ, 王峰, 陈杰.软件测试的艺术 (原书第二版) 中文版.2006.