null测试用例设计
方法
快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载
测试用例设计方法主要内容主要内容
功能性测试设计
结构性测试设计
状态转换测试设计
OO单元测试设计
参考书
《软件测试（原书第二版）（Software Testing A craftsman‘s Approach Second Edition) 美 Paul C.Jorgensen 著 韩柯 杜旭涛
翻译
阿房宫赋翻译下载德汉翻译pdf阿房宫赋翻译下载阿房宫赋翻译下载翻译理论.doc
，机械工业出版社
《软件工程－实践者的研究方法》（Software Engineering A practitioner‘s Approach Fifth Edition) Roger S. Pressman,黄伯素，梅宏 翻译，机械工业出版社
《嵌入式软件测试》（Testing Embeded Software）[美] Bart Borekman,Edwin Notenboom著，张君施，张思宇，周承平译，电子工业出版社
测试用例设计方法概述测试用例设计方法概述测试用例设计方法主要分两大类：黑盒测试（功能性测试）和白盒测试（结构性测试），它们使用的测试用例在表现形式上一模一样，都是：
（输入1，输入2，…….输入n，预期输出）
这输入1，输入2，……..输入n就是程序的输入（可以理解为程序的输入参数，全局变量，触发事件），预期输出可以是程序的输出（可理解为程序的输出参数，返回值，全局变量，输出事件）如右图 程序的规格
说明
关于失联党员情况说明岗位说明总经理岗位说明书会计岗位说明书行政主管岗位说明书
（预期行为）和内部结构（决定实际行为）
黑盒测试与白盒测试的区别在于，黑盒测试方法通过程序的规格说明来识别测试用例。白盒测试根据程序的内部代码结构（分支，循环，条件）来识别测试用例 .见右图黑盒测试与白盒测试的结合黑盒测试与白盒测试的结合基于黑盒的测试（也就是基于规格说明测试）可能有些程序的内部路径（大多数是些异常处理路径）覆盖不到，往往是这里的代码会使程序表现出大家所不期望的行为（程序异常死机，或隐藏了恶意的代码，如特洛伊木马程序，还有内存泄漏，程序走飞，死循环等等）。
所以有必要在黑盒测试结束后，检查一下程序内部的测试覆盖率，对没有覆盖到的路径或代码，根据代码结构信息，再设计一些测试用例覆盖这些没有覆盖到路径或代码，看看程序是否会出现异常的行为。这是我们所倡导的基本的软件单元测试策略。 两个示例程序两个示例程序三角形问
题
快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题
NextDate问题
三角形问题陈述三角形问题陈述三角形问题接受三个整数a，b和c作为输入，用做三角形的的边。程序的输出是由这三条边确定的三角形类型：等 边三角形，等腰三角形，不等边三角形或非三角形。NextDate问题NextDate问题NextDate是一个有三个变量（月份，日期和年）的函数。函数返回输入日期后面的那个日期。变量月份，日期和年都具有整数值，且满足下列条件：
C1:1<=月份<=12
C2:1<=日期<=31
C3:1812<=年<=2012
如果任意一个条件失败，则NextDate会出示一个消息，指示相应的变量超出范围功能性测试设计功能性测试设计边界值测试
等价类测试
决策表测试边界值测试边界值测试 任何程序都可以看做是一个函数，程序的输入构成函数的定义域，程序的输出构成函数的值域，输入定义域测试是最著名的功能性测试手段，它的重点是在输入定义域
边界值分析
健壮性测试
最坏情况测试
特殊值测试
边界值分析边界值分析大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。针对各种边界情况设计测试用例，可以查出更多的错误。
边界值分析的基本思想是使用在最小值，略高于最小值，正常值，略低于最大值和最大值处取输入变量值
边界值分析基于单缺陷假设：失效极少是由两个（或多个）参数同时取某一特定值引起的,基本是由单变量取某一特定值引起的.
边界值测试用例的获得：通过所有变量取正常值，只有一个变量取边界值。
,,……共9个测试用例
变量是离散有界值都可以用边界值分析，但逻辑布尔量不适用（如电话号码）
边界值分析举例边界值分析举例在描述问题时,关于三角形的边,除了说明是整数外,没有给出其他条件.显然,低端边界都是1.我们任意取200做为高端边界,下表给出使用这些定义域产生的边界测试用例.健壮性测试健壮性测试健壮性测试是边界值分析的一种简单扩展：除了变量的五个边界值分析取值，还要通过采用一个略超过最大值（max＋）的取值，和一个略小于最小值（min－）的取值
如果程序执行显式的范围检查并适用例外处理机制解决“健壮值”问题，必须选择健壮性测试最坏情况测试最坏情况测试最坏情况测试拒绝单缺陷假设,采用多缺陷假设:某些失效(Failure)是由两个或多个参数同时取某些特定值引起的.
对每个变量首先进行包含最小值，略高于最小值，正常值，略低于最大值，最大值五元素测试
然后对这集合进行笛卡尔儿积计算，生成测试用例笛卡尔积笛卡尔积两个集合A和B的笛卡尔积，是集合
A×B＝{;xЄA^YєB}
例1：集合A={1,2,3}
集合B={w,x,y,z}
A和B的笛卡尔积是集合
A×B＝{<1,w>,<1,x>,<1,y>,<1,z>,<2,w>,<2,x>,<2,y>,<2,z>,<3,w>,<3,x>,<3,y>,<3,z>}
例2：一个更直观的例子：x轴上的点与y轴上的点的笛卡尔积是整个平面上所有点的集合。最坏情况测试举例最坏情况测试举例我们仍然以三角形程序举例来说明最坏情况测试特殊值测试特殊值测试当测试人员适用其领域知识，适用类似程序的经验以及关于“软点”信息开发测试用例时，就会出现特殊值测试，就是不使用测试方针，只使用“最佳工程判断”
特殊值测试是高度主观性的，但是所产生的测试用例集合，常常比我们已经研究过的其他方法生成的测试集合，更能有效地发现缺陷
边界值测试总结边界值测试总结除了特殊值测试，基于函数（程序）输入定义域的测试方法是所有测试方法中最基本的，这些测试方法都有一种假设：即输入变量是真正独立的，如果不能保证这种假设，就不能产生令人非常满意的测试用例（如NextDate中生成1912年2月31日）
这些方法还有两方面的区别：正常值和健壮值，单缺陷和多缺陷假设
等价类测试等价类测试使用等价类作为功能性测试的基础有两个动机：
我们希望进行完备的测试
同时又希望避免冗余
等价类测试重复边界值测试的两个决定因素：健壮性和单/多缺陷假设
等价类的重要问题是它们构成集合的划分，其中划分是指互不相交的一组子集，子集的元素都有一些共同的特点
等价类测试的思想就是通过每个等价类中的一个元素代表整个等价类元素集合，来标识测试用例。
等价类测试的关键就是选择类的等价关系。示例函数示例函数我们讨论一个具有两个变量x1,x2的函数F
其中：
a<=x1<=d, 区间为[a，b），[b,c），[c,d]
e<=x2<=g ,区间为[e,f），[f,g]
X1和x2的无效值是：x1d,和X2g
弱一般等价类测试弱一般等价类测试弱一般等价类测试：
测试用例中每个参数等价类（区间）的都被遍历到
注意单缺陷假设的作用，弱一般等价类测试的测试用例的个数等于max(参数1等价类个数，参数2等价类个数……参数n的等价类个数）强一般等价类强一般等价类强一般等价类测试基于多缺陷假设，因此测试用例的个数等于各个参数等价类个数的乘积。
弱健壮等价类测试弱健壮等价类测试这种测试的名称显然与直觉矛盾，而且自相矛盾，怎么既弱而且又健壮？
健壮是考虑了无效值
弱是有单缺陷假设
对于有效输入，使用等价类的一个值
对于无效输入，测试用例将拥有一个无效值
强健壮等价类测试强健壮等价类测试这种测试名称既不与直觉矛盾，也不自相矛盾，只是觉得有些冗余
健壮是指要考虑无效指
强是指多缺陷假设
我们从所有等价类的笛卡尔积中获得测试用例三角形问题的等价类测试用例三角形问题的等价类测试用例在描述问题时，我们曾经提到过有四种可能出现的输出：非三角形，不等边三角形，等腰三角形和等边三角形。可以使用这些输出标识如下所示的输出（值域）有效等价类（无效等价类没有列出）：
R1={:有三条边a,b和c的等边三角形}
R2 ={:有三条边a,b和c的等腰三角形}
R3 ={:有三条边a,b和c的不等边三角形}
R4={:三条边a,b和c不构成三角形}
一般等价类，弱健壮，强健壮等价类举例一般等价类，弱健壮，强健壮等价类举例NextDate问题的等价类测试NextDate问题的等价类测试NextDate是一个三变量函数，即月份，日期和年，这些变量的有效值区间定义如下：
M1={月份：1≤月份≤12}
D1={日期： 1≤日期≤31}
Y1={年：1812 ≤年≤2012}
无效等价类
M2={月份：月份〈1}
M3={月份：月份〉12}
D2={日期：日期〈1}
D3={日期：日期〉31}
Y2={年：年〈1812}
Y3={年：年〉2012}NextDate问题的等价类测试用例NextDate问题的等价类测试用例NextDate问题的等价类测试(第二次)NextDate问题的等价类测试(第二次)以上只是在有效/无效的层次上处理等价类，通过对平年和闰年的分析，日期是月末最后一天的分析，可以对有效值进行进一步区分等价类：
M1={月份：每月有30天}
M2={月份：每月有31天}
M3={月份：此月是2月}
D1={日期：1≤日期≤28}
D2={日期：日期=29}
D3={日期：日期=30}
D4={日期：日期=31}
Y1={年：年=2000}
Y2={年：年是闰年}
Y3={年：年是平年}NextDate问题的等价类测试用例NextDate问题的等价类测试用例和以前一样，机械地从对应的等价类中间选择输入，机械选择输入值不考虑领域知识，会出现不可能的输入日期，“自动”的测试用例生成永远都会有这种问题，因为领域知识不是通过等价类选择获得的。等价类测试的总结等价类测试的总结等价类测试的弱形式不如强形式的测试全面
如果输入数据以离散值区间和集合定义，则等价类测试是合适的。当然也适用于如果边界值越界系统就会出现故障的系统
通过结合边界值测试，等价类测试可得到加强
在发现“合适”的等价关系之前，可能需要进行多次尝试。如果程序函数很复杂，则等价类是被暗示的，如NextDate函数基于决策表的测试基于决策表的测试在所有功能性测试方法中，基于决策表的测试方法是最严格的，因为决策表具有逻辑严格性
20世纪60年代初以来,决策表一直被用来表示和分析复杂逻辑关系.决策表很适合描述不同条件集合下采取行动的若干组合的情况.使用决策表来设计测试用例使用决策表来设计测试用例为了使用决策表标识测试用例,我们把条件解释为输入,把行动解释为输出.(第一种方法)
有时候条件最终引用输入的等价类,行动引用被测软件的主要功能处理部分.这时每条规则就被解释成测试用例的输入.(第二种方法)
由于决策表可以机械地强制为完备的,因此可以生成用测试用例的完整集合决策表的构成决策表的构成决策表有四部分：条件桩，条件条目，行动桩和行动条目
所有条件都是二叉条件的决策表叫做有限决策表
如果条件可以有多个值，则对应的决策表叫做扩展条目表三角形问题决策表
---第一种方法三角形问题决策表
---第一种方法三角形问题决策表中，给出了不关心条目－和不可能规则使用的例子，不关心条目实际表明条件是不相关的，它代表了多条规则（如果是有限条目决策表，则规则中每出现一个不关心条目，该规则数乘一次2）不可能规则不关心条目条件桩代表测试用例的输入行动桩代表测试用例的输出每条规则标识了一个测试用例NextDate的决策表测试用例NextDate的决策表测试用例前面在讲ＮextDate的等价类测试中，发现从等价类中随意地选取输入值会产生很奇怪的测试用例，如1812年6月31日的下一天。问题的根源在于假设变量都是很独立的。如果变量确实是独立的，则是用等价类的笛卡尔积是有意义的。
如果变量之间在输入定义域中存在逻辑依赖关系，则这些依赖关系在笛卡尔积中就会丢失（说抑制可能更确切）。决策表格通过使用“不可能行动”概念来表示条件的不可能组合，使我们能够强调这种依赖关系。
选择NextDate函数，是因为它可以说明输入定义域中的依赖性问题，这使得这个例子成为基于决策表测试的一个完美的例子。NextDate的第一次尝试NextDate的第一次尝试先考虑前面为NextDate函数划分的等价类集合。
M1={月份：每月有30天}
M2={月份：每月有31天}
M3={月份：此月是2月}
D1={日期：1≤日期≤28}
D2={日期：日期=29}
D3={日期：日期=30}
D4={日期：日期=31}
Y1={年：年是闰年}
Y2={年：年不是闰年}
如果我们希望突出不可能的组合，则可以建立具有以下条件和行动的优先条目决策表
有256规则的第一次尝试有256规则的第一次尝试这个决策表会有256条规则，其中有很多是不可能的NextDate的第二次尝试NextDate的第二次尝试为了说明另一种决策表表示方法，这一次采用扩展条目决策表开发，并更仔细地研究行动桩。在构建扩展条目决策表时，必须保证等价类构成输入定义域的真划分（划分是一组不相交的子集，子集的并是全集).如果规则条目之间存在“重叠”，则会存在冗余情况，使得多个规则都能够满足。
为了产生给定日期的NextDate,能够使用的操作只有五种：日期和月份的增1和复位，年的增1，我们不允许复位年来回退时间。
利用前面的年月日的等价类划分，我们可以得到36规则的决策表与等价类测试时含36个测试用例的笛卡尔积对应。但我们利用不关心条目得到下表17条规则的决策表。（仍然有逻辑不可能的规则）第二次尝试的等价类划分第二次尝试的等价类划分M1={月份：每月有30天}
M2={月份：每月有31天}
M3={月份：此月是2月}
D1={日期：1≤日期≤28}
D2={日期：日期=29}
D3={日期：日期=30}
D4={日期：日期=31}
Y1={年：年=2000}
Y2={年：年是闰年}
Y3={年：年时平年}
17条规则的扩展决策表17条规则的扩展决策表如果填满这个决策表的行动条目，就会发现12月份由一些麻烦的问题。如果是12月31日,该怎么办?每列规则识别一个测试用例规则代表测试用例的输入行动代表程序的主要处理测试用例的输出怎么办?根据规格说明和测试用例的输入计算出来第三次尝试的等价类划分第三次尝试的等价类划分通过引入月份等价类的第三个集合，可以澄清年末问题
M1={月份：每月有30天}
M2={月份：每月有31天，12月除外}
M3={月份：此月是12月}
M4=={月份：此月是2月}
D1={日期：1≤日期≤27}
D2={日期：日期=28}
D3={日期：日期=29}
D4={日期：日期=30}
D5={日期：日期=31}
Y1={年：年是闰年}
Y2={年：年不是闰年}
这些等价类的笛卡尔积包含40个元素。由于组合规则中包含不关心条目，最后我们得到一个22规则的决策表
22条规则的决策表22条规则的决策表上图所示决策表应该是NextDate函数源代码的基础，这个例子从另一方面说明测试如何能够很好地改进程序设计。所有决策表分析都应该在NextDate函数的详细设计期间完成12月31日8月31日这四条可以合并NextDate的精简决策表NextDate的精简决策表决策表测试的指导方针决策表测试的指导方针决策表技术适用于具有以下特征的应用程序：
If then else逻辑很突出
涉及输入变量子集的计算
输入和输出存在复杂因果关系
很高的圈（McCabe）复杂度(后面解释)
决策表不能很好地伸缩（有n个条件的有限决策表有2N个规则
与其他技术一样，多次尝试的迭代会有所帮助。结构性测试设计结构性测试设计结构性测试（又称为白盒测试）用例设计方常见的主要有以下几种[1]：
条件测试
基本路径测试
循环测试
状态机测试设计
以实现测试用例对程序的逻辑覆盖，和路径覆盖：
[1] 参见《软件工程－实践者的研究方法》第17章，323页－335页测试覆盖种类测试覆盖种类
语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；
判定覆盖（也称为分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；
条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；
判定-条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次
条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值组合至少执行一次；
路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。 下面以例子进行分析讲解 下面以例子进行分析讲解 void DoWork(int x,int y,int z)
{
int k=0,j=0;
if((x>3)&&(z<10))
{
k=x*y-1; //语句块1
j=sqrt(k);
}
if((x= =4)||(y>5))
{
j=x*y+10; //语句块2
}
j=j%3; //语句块3
}null画出前面函数的流程图如右：判断条件语句覆盖：语句覆盖： 为了说明简略，分别对各个判断的取真、取假分支编号为b、c、d、e。
为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了。
测试用例输入为：{ x=4、y=5、z=5}
程序执行的路径是：abd
该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑是否有问题，例如在第一个判断中把&&错误的写成了||，则上面的测试用例仍可以覆盖所有的执行语句。可以说语句覆盖率是最弱的逻辑覆盖准则。 分支覆盖分支覆盖 对于上面的程序，如果设计两个测试用例则可以满足判定覆盖的要求。
测试用例的输入为：
{ x=4、y=5、z=5} 程序执行路径是:abd
{ x=2、y=5、z=5} 程序执行路径是:ace
上面的两个测试用例虽然能够满足分支覆盖的要求，但是也不能对判断条件进行检查，例如把第二个条件y>5错误的写成y<5,、上面的测试用例同样满足了分支覆盖。 条件覆盖条件覆盖 条件覆盖就是设计若干个测试用例，运行被测试对象，使得程序中每个判断的每个条件的可能取值至少执行一次。
对例子中的所有条件取值加以标记。例如：
对于第一个判断：
条件x>3 取真值为T1，取假值为-T1
条件z<10 取真值为T2，取假值为-T2
对于第二个判断：
条件x=4 取真值为T3，取假值为-T3
条件y>5 取真值为T4，取假值为-T4则可以设计测试用例如下 则可以设计测试用例如下 上面的测试用例不但覆盖了所有分支的真假两个分支，而且覆盖了判断中的所有条件的可能值。 null 但是如果设计了下面的测试用例，则虽然满足了条件覆盖，但只覆盖了第一个条件的取假分支和第二个条件的取真分支，不满足分支覆盖的要求。 分支条件覆盖：分支条件覆盖： 分支条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的所有可能的条件分支取值组合至少执行一次。
根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支。 null 分支条件覆盖从表面来看，它测试了所有条件的取值，但是实际上某些条件掩盖了另一些条件。例如对于条件表达式(x>3)&&(z<10)来说，必须两个条件都满足才能确定表达式为真。如果（x>3）为假则一般的编译器不在判断是否z<10了。对于第二个表达式（x= =4）||（y>5）来说，若x==4测试结果为真，就认为表达式的结果为真，这时不再检查（y>5）条件了。因此，采用分支条件覆盖，逻辑表达式中的错误不一定能够查出来了。 条件组合覆盖：条件组合覆盖： 条件组合覆盖就是设计足够的测试用例，运行被测试对象，使得每一个判断的所有可能的条件取值组合至少执行一次。
现在对例子中的各个判断的条件取值组合加以标记如下：
x>3,z<10 记做T1 T2， 第一个判断的取真分支
x>3,z>=10 记做T1 -T2， 第一个判断的取假分支
x<=3,z<0 记做-T1 T2， 第一个判断的取假分支
x<=3,z>=10 记做-T1 -T2，第一个判断的取假分支
x=4,y>5 记做T3 T4， 第二个判断的取真分支
x=4,y<=5 记做T3 -T4， 第二个判断的取真分支
x!=4,y>5 记做-T3 T4， 第二个判断的取真分支
x!=4,y<=5 记做-T3 -T4，第二个判断的取假分支null根据定义取4个测试用例，就可以覆盖上面8种条件取值的组合。
测试用例如下表： 上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径abe。
路径测试覆盖
路径测试覆盖
路径测试覆盖就是设计足够多的测试用例，覆盖被测试对象中的所有可能路径。
在上面的测试用例中再添加一个测试用例则可对程序进行了全部的路径覆盖。
基本路径测试
基本路径测试
上面的例子是一个很简单的程序函数，只有四条路径。但在实践中，一个不太复杂的程序，其路径都是一个庞大的数字，要在测试中覆盖所有的路径是不现实的。为了解决这一难题，只得把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行一次。
下面介绍的基本路径测试就是这样一种测试方法，它在程序控制图的基础上，通过分析控制构造的圈复杂度，导出基本独立路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每一个基本独立路径至少执行一次。 在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
包括以下4个步骤和一个工具方法： 在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
包括以下4个步骤和一个工具方法：画出程序的控制流图：描述程序控制流的一种图示方法。
计算程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径最大条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
导出基本独立路径：根据圈复杂度和程序结构设计用例数据输入和预期结果。
准备测试用例：确保基本路径集中的每一条路径的执行。
先讲一下控制流图的符号
在介绍基本路径方法之前，必须先介绍一种简单的控制流表示方法，即流图。流图使用下面的符号描述逻辑控制流，每一种结构化构成元素有一个相应的流图符号。先讲一下控制流图的符号
在介绍基本路径方法之前，必须先介绍一种简单的控制流表示方法，即流图。流图使用下面的符号描述逻辑控制流，每一种结构化构成元素有一个相应的流图符号。例子例子如下面的C函数：
int Sort(int iRecordNum,int iType)
1 {
2 int x=0;
3 int y=0;
4 while (iRecordNum-- > 0)
5 {
6 if(0= =iType){
7 x=y+2; break
} else
8 if(1= =iType)
9 x=y+10;
else
12 x=y+20;
13 }
14 Reutrn x;}
第一步：画出控制流图
第一步：画出控制流图
流图中的每一个圆称为流图的结点，代表一条或多条语句。流图中的箭头称为边或连接，代表控制流。
为了说明流图的用法，我们采用过程设计表示法，此处，流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中，每一个圆，称为流图的结点，代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个结点，即使该结点并不代表任何语句(例如：参见if-else-then结构的符号)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。
任何过程设计都要被翻译成控制流图。 画出其程序流程图和对应的控制流图如下：画出其程序流程图和对应的控制流图如下：图2(a)流程图图2(b) 流图
第二步：计算圈复杂度
第二步：计算圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。
有以下三种方法计算圈复杂度：
流图中区域的数量对应于环型的复杂性；
给定流图G的圈复杂度－V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量；
给定流图G的圈复杂度－V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。 null对应上面图中的圈复杂度，计算如下：
流图中有四个区域；
V(G)=10条边-8结点+2=4;
V(G)=3个判定结点+1=4。第三步：导出基本独立路径 第三步：导出基本独立路径 根据上面的计算方法，可得出四个独立的路径：
路径1：4-14
路径2：4-6-7-14
路径3：4-6-8-10-13-4-14
路径4：4-6-8-11-13-4-14
根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径。第四步：准备测试用例第四步：准备测试用例 为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是：
路径1：4-14
输入数据：iRecordNum＝0，或者取iRecordNum<0的某一个值
预期结果：x＝0
路径2：4-6-7-14
输入数据：iRecordNum＝1,iType＝0
预期结果：x＝2
路径3：4-6-8-10-13-4-14
输入数据：iRecordNum＝1,iType＝1
预期结果：x＝10
路径4：4-6-8-11-13-4-14
输入数据：iRecordNum＝1,iType＝2
预期结果：x＝20这里的预期输出有问题,应该是从程序的规格说明导出,不应该从程序的结构中导出循环测试 循环测试 循环测试是一种白盒测试技术，注重于循环构造的有效性。
有四种循环：简单循环，串接循环，嵌套循环和不规则循环。null简单循环：
下列测试集用于简单循环，其中n是允许通过循环的最大次数。
整个跳过循环；
只有一次通过循环；
两次通过循环；
m次通过循环，其中m
通知
关于发布提成方案的通知关于xx通知关于成立公司筹建组的通知关于红头文件的使用公开通知关于计发全勤奖的通知
另一个对象改变事件：基于属性改变得事件时间事件：计时器到期或者到达某个绝对时间四类事件两种不同的响应方式系统通过进行转换来对事件作出响应当系统不是处于正确的状态，或者进行转换的条件不满足时，事件被忽略。状态机的基本概念--转换状态机的基本概念--转换转换到自身防护将同一状态上同一事件触发的多个转换隔开状态机的基本概念--动作和活动状态机的基本概念--动作和活动动作：在状态机的某个特殊点，执行不可中断地行为，该行为被认为不需要花费什么时间(take a non-significant amount of time )。一个动作也可以是作为一个整体不能被中断的一串动作。活动：活动需要花费一些时间，因而可以被中断。因此只能在状态中定义活动。“开始到带”是一个动作；“到带”是一个活动。状态机的基本概念--动作和活动状态机的基本概念--动作和活动许多协议和应用模块需要建立TCP链接，维护PEER状态机。PEER状态机一般以noinfo状态作为初始状态，tcp链接链接后到达TCP-CONNECTED状态。那么“建立TCP链接”是一个“动作”，还是一个“活动”呢？如果工作于“阻塞”模式，TCP建立完成前模块不响应其他事件，则“建立TCP链接”是一个动作；否则“建立TCP链接”就应该是一个活动，二者状态机不同状态机的基本概念---嵌套状态状态机的基本概念---嵌套状态汽车收音机的状态图，其中超状态开启由两个正交区域组成事件触发动作的执行顺序事件触发动作的执行顺序B状态和D状态是A状态的子状态；C状态是B状态的子状态。t1事件：w、(x,y)、zt2事件：p、n、mt3事件：p、n、g、st4事件：q、s动作是按照一定的顺序来执行的。首先执行的是接受状态的出口标记中定义的动作，接下来是指向转换的动作，最后是结果状态的入口标记中定义的动作。状态转换测试目的状态转换测试目的许多嵌入式系统或GUI程序全部或部分表现出基于状态的行为。当设计这些系统时，可以使用基于状态的建模。从基于状态的模型中可以导出测试用例。
基于状态的测试设计技术目标是验证事件、动作、行为与状态转换之间的关系。通过使用这种技术，人们就可以判断系统基于状态的行为是否满足系统的规范集合。状态机设计、编码中可能出现缺陷原因分类状态机设计、编码中可能出现缺陷原因分类基于状态的行为出现错误可能有三种原因。
第一：状态图无法表示系统功能规范的正确转换。基于状态的测试设计技术不能够揭示这些故障类型，因为状态图本身被用作测试的基础。
第二：状态图的语法不正确或不一致。可以通过静态分析和评审来发现这些故障（例如通过使用审查清单或工具），如果解决了发现的故障，那么就可以使用基于状态的测试设计技术，使这个状态图成为动态测试的基础。
第三：从状态图到代码的转换。现在已经出现了自动转换的工具，如果这个转换过程是自动实现的，生成的代码将是状态图的准确的表示，那么就没有必要再采用基于状态的测试设计技术。基于状态的测试设计技术适用于手工编码实现状态机的场合。状态图和软件中可能发生的故障：状态状态图和软件中可能发生的故障：状态1.1 没有进入转换的状态。（规范和/或实现故障）
1.2 遗漏初始状态。必须定义状态图中的所有路径。当转换到一个没有给出最终子状态的超状态时，超状态必须包含一个初始状态。如果没有给出初始状态，那么就无法预测转换是在何处终止。（规范和/或实现故障）
1.3 额外状态。系统生成比状态图中多的状态。（实现故障）
1.4 遗漏状态。系统中没有出现状态图中给出的状态。（实现故障）
1.5 破坏性状态。转换到无效态而导致系统崩溃。（实现故障）状态图和软件中可能发生的故障：防护状态图和软件中可能发生的故障：防护2.1 防护必须指向转换而不是状态。（规范故障）
2.2 完成事件转换上的防护，如果防护被评估为false，那么系统会陷入死锁。（规范和/或实现故障）
2.3 初始转换上的防护。初始转换上不能有防护。（规范和/或实现故障）
2.4 重叠防护。在这种情况下，无法确定系统将转换到哪种状态。（规范和/或实现故障）
2.5 防护为false但仍然有转换发生，系统将达到一个预期之外的最终状态。（实现故障）
2.6 错误的防护实现。有些条件下，这将导致预期之外的系统行为。（实现故障）状态图和软件中可能发生的故障：转换状态图和软件中可能发生的故障：转换3.1 转换必须有一个接收状态与一个最终状态。（规范和/或实现故障）
3.2 相互矛盾的转换。一个事件触发系统从一个子状态改变为另一个子状态，而同时又触发超状态之外的一个转换，这实际上将导致不再能够转换到某个子状态（规范和/或实现故障）
3.3 遗漏或错误转换。最终的状态既不正确，也没有被破坏（规范和/或实现故障）
3.4 遗漏或错误动作。执行转换时执行了错误的动作。（规范和/或实现故障）状态图和软件中可能发生的故障：事件状态图和软件中可能发生的故障：事件4.1 遗漏事件。事件被忽略。（规范和/或实现故障）
4.2 隐含路径。系统对一个定义的事件作出响应，但状态图中没有定义这个响应（也被称为“潜路径”）（实现故障）
4.3 对一个没有定义的事件作出响应（也被称为“后门”）。（实现故障）状态机错误类型的检查单状态机错误类型的检查单状态转换测试技术状态转换测试技术状态转换测试技术(STT)由以下步骤组成编写状态-事件表编写转换树编写合法路径测试用例的测试脚本编写非法事件测试用例的测试脚本编写防护测试脚本录音机的状态图录音机的状态图录音机的状态-事件表录音机的状态-事件表编写录音机的状态转换树编写录音机的状态转换树第一层：初始状态第二层：初始状态经过一次转换可以到达的状态第n层：从第n-1层经过一次转换可以到达的状态叶子：如果某一层的节点（状态）在以前的某层出现过，则这个节点不必再分解下去，成为叶子编写合法路径测试用例编写合法路径测试用例借助于转换树与状态-事件表，可以创建一个只覆盖合法测试路径的测试用例集。转换树上的每一个路径都是一个测试用例，这个测试用例覆盖整个路径，直到叶子，并从叶子返回初始状态（如果可能的话），以便下一个测试用例的执行。也就是说，要想测试用例能够连续执行，每一个状态都必须有一个回到初始状态的路径。编写合法路径测试用例(续)编写合法路径测试用例(续)编写合法路径测试用例(续)编写合法路径测试用例(续)到达叶子回到初始状态注意：这个测试
用例的三个输入
在不同时间点
按顺序输入，
输出也是。编写非法事件测试用例编写非法事件测试用例可以从状态-事件表中得到非法的状态-事件组合。非法的状态-事件组合是指当在特定状态时，系统没有指定要对该事件做出响应。因而，所有非法事件测试用例的预期结果，应当是系统对此不作出响应。注意：不应当将非法事件测试用例与系统中明确指出不对某个事件作出实质响应，而只是输出一个错误消息的测试用例相混淆。编写非法事件测试脚本(续)编写非法事件测试脚本(续)编写防护测试脚本编写防护测试脚本如果防护由一个带有边界值得条件组成，那么需要对该防护进行边界值分析。对每一个防护，要从边界值左边和右边两个方向来应用边界条件和测试用例。
如果防护由一个复杂的条件组成，那么就要使用决策表（见功能性测试设计部分）的方法来覆盖测试。针对防护条件而设计的补充测试用例如下图所示 编写防护测试脚本(续)编写防护测试脚本(续)Petri网定义Petri网定义Petri网是一种双向有向图(P,T,In,Out),其中,P和T是不相交的节点集合
P我们通常称为地点（places)集合
T我们通常称为转移（Transition)集合
In和Out是边的集合.
P={ p1,p2,p3,p4,p5}
T={t1,t2,t3}
In={,,,,
Out={,,}Petri网例子Petri网例子有标记的Petri网有标记的Petri网定义
有标记的Petri网是一种5元组（P，T，In，Out，M)，其中（P，T，In，Out）是个Petri网，M是地点到正整数的映射集合
M中的元素是个n元组，其中n是集合P中的地点个数。对于右图所示的Petri网，集合M包含形式为,其中ni是与相应地点P有关的整数，整数的值表明在这个地点中的令牌（token）的个数
右图所示的有标记的Petri网的标记元组M是<1,1,0,2,0>Petri网的转移Petri网的转移定义2
转移可以在Petri网中发生，如果在其所有输入地点中至少有一个记号
定义3
当触发Petri网一个转移时，要从其每个输入地点删除一个令牌（Token),并在每个转移进的地点增加一个令牌（Token)
右上图显示了t2转移发生后，Petri网中令牌的变化
转移前转移后事件驱动的Petri网事件驱动的Petri网定义
EDPN是一种多向图（P，D，S，In，Out），包括三个节点集合P，D和S，以及两个映射集合In和Out。其中：
P是事件地点的集合
D是数据地点的集合
S是转移的集合
In是（PUD）×S的有序对偶集合
Out是S×（P∪D）的有序对偶集合
定义
EDPN（P，D，S，In，Out）的一个标记M，是p元组的一个序列,其中p=k+n，k和n是集合P和D中的元素个数，p元组中的个体项mi 表示事件或数据地点中的记号个数
每个标记M对应Petri网络的一个执行EDPN的例子EDPN的例子事件
地点数据
地点将状态机转换成EPDN将状态机转换成EPDN将状态机中的状态当做“数据地点”
将状态机中的转换当做“转移”
将状态机中的转换上的输入事件作为“输入事件地点”，用正三角形表示，将转换上的动作作为“输出事件地点”，用倒三角形表示。
Petri网中边的方向规定如下：
边从表示“接受状态”的“数据地点”和“输入事件”的“事件地点”出发，结束于“转移”。
边从表示“转移”出发，结束于表示“结果状态”的数据地点和“输出事件”的事件地点EDPN的执行过程EDPN的执行过程例子：土星牌挡风玻璃雨刷例子：土星牌挡风玻璃雨刷 某些土星牌汽车的挡风玻璃雨刷是由带刻度的控制杆控制的。这种控制杆有四个位置：停止，间歇，低速和高速；刻度盘位置有三个位置，分别是数字1，2和3。刻度盘指示三种间歇速度，刻度盘的位置只有当控制杆在间歇位置上时才有意义。
下图的决策表给出了挡风雨刷对应控制杆和刻度盘的工作速度土星牌挡风玻璃雨刷的输入和输出事件土星牌挡风玻璃雨刷的输入和输出事件土星牌挡风玻璃雨刷的状态和转移土星牌挡风玻璃雨刷的状态和转移控制杆的状态机和EDPN控制杆的状态机和EDPN刻度盘的状态机和EDPN刻度盘的状态机和EDPN档风玻璃雨刷系统的EDPN档风玻璃雨刷系统的EDPN档风玻璃雨刷系统的EDPN的样本1场景档风玻璃雨刷系统的EDPN的样本1场景样本2场景中的并行行为样本2场景中的并行行为如何使用EPDN来进行测试设计如何使用EPDN来进行测试设计EPDN是一张有向图,就如同状态机和程序流图一样，所以EPDN对测试设计的意义就在于对图的覆盖上（节点或边）。
可以将EPDN转换成状态机,采用状态转换测试设计的方法,遍历所有可能的状态转换
可以采用类似基路径测试的方法，遍历Petri网中所有的节点面向对象的单元测试设计面向对象的单元测试设计 对OO软件的类测试相当于传统软件的单元测试。和传统软件的单元测试不同，他往往关注模块的算法细节和模块接口间流动的数据，OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的。OO软件测试的特点：
因为属性和操作是被封装的，对类之外操作的测试通常是徒劳的。封装使对对象的状态快照难于获得。
继承也给测试带来了难度，即使是彻底复用的，对每个新的使用语境也需要重新测试。
多重继承更增加了需要测试的语境的数量，使测试进一步复杂化。如果从超类导出的测试用例被用于相同的问题域，有可能对超类导出的测试用例集可以用于子类的测试，然而，如果子类被用于完全不同的语境，则超类的测试用例将没有多大用途，必须设计新的测试用例集。面向对象的单元测试设计面向对象的单元测试设计 类测试一般有两种主要的方式：
功能性测试和结构性测试，即对应于传统结构化软件的黑盒测试和白盒测试。
功能性测试以类的规格说明为基础，它主要检查类是否符合其规格说明的要求。例如，对于Stack类，即检查它的操作是否满足LIFO规则；结构性测试则从程序出发，它需要考虑其中的代码是否正确，同样是Stack类，就要检查其中代码是否动作正确且至少执行过一次。
面向对象的单元白盒测试策略面向对象的单元白盒测试策略 结构性测试对类中的方法进行测试，它把类作为一个单元来进行测试。测试分为两层：
第一层考虑类中各独立方法的代码，即方法的单独测试
第二层考虑方法之间的相互作用，即方法之间的综合测试。 。
每个方法的测试要求能针对其所有的输入情况，但这样还不够，只有对这些方法之间的接口也做同样测试，才能认为测试是完整的。对于一个类的测试要保证类在其状态的代表集上能够正确工作，构造函数的参数选择以及消息序列的选择都要满足这一准则。因此，在这两个不同的测试层次上应分别做到：
面向对象的单元白盒测试策略面向对象的单元白盒测试策略方法的单独测试：结构性测试的第一层是考虑各独立的方法，这可以与过程的测试采用同样的方法，两者之间最大的差别在于方法改变了它所在实例的状态，这就要取得隐藏的状态信息来估算测试的结果，传给其它对象的消息被忽略，而以桩来代替，并根据所传的消息返回相应的值，测试数据要求能完全覆盖类中代码，可以用传统的测试技术来获取。
方法的综合测试：第二层要考虑一个方法调用本对象类中的其它方法和从一个类向其它类发送信息的情况。单独测试一个方法时，只考虑其本身执行的情况。而没有考虑动作的顺序问题，测试用例中加入了激发这些调用的信息，以检查它们是否正确运行了。对于同一类中方法之间的调用，一般只需要极少甚至不用附加数据，因为方法都是对类进行存取，故这一类测试的准则是要求遍历类的所有主要状态。
类方法的综合测试用例设计-随机测试 类方法的综合测试用例设计-随机测试 为了提供随机测试方法的简略性举例，考虑一个银行应用，其中account类有下列操作：open，setup，deposit，withdraw balance，summarize，creditLimit和close[1] P460-461，这些操作的每一个均可应用于account，但是，问题的性质隐含了一些限制（例如，帐号必须在其他操作可应用前被打开，在所有操作完成后被关闭）。即使有了这些限制，还是存在操作的很多排列。一个account实例的最小的行为生命历史包括下面操作：
open•Setup•deposit•withdraw•close
这表示了account的最小测试序列，然而，大量的其他行为可能在下面序列中发生：
open•setup•deposit•[deposit|withdraw|balance|summarize|creditiLimit]n•withdraw•close
一系列不同的操作序列可以随机产生，例如：
测试用例r1：open•setup•deposit•deposit•balance•summarize•withdraw•close
测试用例r2：open•setup•deposit•withdraw•deposit•balance•creditLimit•withdraw•close
这些和其他的随机顺序测试被进行以测试不同的类实例生命历史。
随机测试的可能排列的数量可能增长非常大。可以使用类划分测试来改善测试效果。类方法的综合测试用例设计-划分测试类方法的综合测试用例设计-划分测试测试划分（paritition testing）可以减少测试类所需的测试用例的数量，采用的是基本于传统软件的等价划分[1]P318类似的方式：输入和输出被分类，并且测试用例被设计以处理每个类别。类的等价划分测试有如下几种：
基于状态的划分基于类的操作改变类状态的能力来对类操作分类，再次考虑account类，状态操作包括deposit和withdraw，而非状态操作包括balance、summarize和creditLimit。测试被以这样一种分别独立测试改变状态的操作和那些不改变状态的操作的方式来设计，因此，
测试用例p1：open•setup•deposit•deposit•withdraw•withdraw•close
测试用例p2：open•setup•deposit•summarize•creditLimit•withdraw•close
测试用例p1改变状态，而测试用例p2测试不改变状态的操作（除了那些在最小测试序列中的操作）。
基于属性的划分基于它们使用的属性来对类操作分类，对accout类，属性balance和creditLimit可被用于定义划分，操作被分为三个类别：（1）使用creditLimit的操作，（2）修改creditLimit的操作，（3）不使用和修改creditLimitde操作。然后对每个划分设计测试序列。
基于类别的划分基于各自完成的类属函数来对类操作分类，例如，在accout类中的操作可被分类为初始化操作（open、setup）、计算操作（deposit、withdraw）、查询操作（balance、summarize、creditLimit）和终止操作（close）。类方法综合测试用例设计-类状态测试类方法综合测试用例设计-类状态测试状态－转换图（STD）是作为表示类的动态行为的模型[1]P408。类的STD可被用于帮助导出测试类（和那些与其协作的类）的动态行为的测试序列。右图给出了前面讨论的account类的STD。
根据该图，初始变迁经过了empty acct和setup acct状态，类的实例的大多数行为发生在working acct状态，最终的withdrawal和close使得account类分别向nonworking acct和dead acct状态发生变迁。
设计的测试用例集应该使类的所有可能状态达到完全的覆盖[1]P462，即应用于测试的操作序列应该导致accout类的变迁穿越所有允许的状态
测试用例s1：open•setupAccnt•deposit(initial)•withdraw(final)•close应该注意，该序列等同于8.1.1小节讨论的最小测试序列，加入其他测试序列得到最小序列中：
测试用例s2：open•setupAccnt•deposit(initial)•deposot•balance•credit•withdraw(final)•close
测试用例s3：open•setupAccnt•deposit(initial)• deposit •withdraw• accntInfo• withdraw(final) •clos
浙公网安备 33021202002483