软件测试课程论文.docx

软件测试实训

NANCHANG UNIVERSITY
软件测试

题 目: 软件测试课程论文
学 院： 软件学院
专 业： 软件工程
班 级： 嵌入式133班
完成人数： 1人
成 员： 8000113040冯嘉
任课教师： 黄旭慧 职称： 副教授
完成时间： 2016 年 06 月 11 日

目录
一、黑盒测试原理及测试用例设计——等价类划分法 1
1.1测试用例的定义和特征 1
1.2设计测试用例的基本准则 1
1.3等价类划分原则 1
1.4等价类划分法设计测试用例 1
二、黑盒测试原理及测试用例设计——边界值分析法 3
2.1边界值分析法概要 3
2.2边界值分析法的思想 3
2.3测试用例：找零钱最佳组合 3
三、黑盒测试原理及测试用例设计——决策表法 5
3.1决策表法思想 5
3.2决策表的生成 5
3.3决策表的简化 5
3.4决策表法设计测试用例 5
四、黑盒测试原理及测试用例设计——因果图法设计 8
4.1因果图的定义 8
4.2因果图法设计测试用例步骤 8
五、白盒测试方法——逻辑覆盖法 10
5.1语句覆盖 10
5.2判定覆盖 10
5.3条件覆盖 10
5.4判定--条件覆盖 11
5.5条件组合覆盖 11
5.6路径覆盖 11
5.7设计测试用例 11
六、基本路径法 17
6.1基本路径法的思想 17
6.2控制流图 17
6.3环形复杂度（环路复杂性） 17
6.4独立路径 17
6.5基本路径测试步骤 17
七、LoadRunner基本使用 19
八、总结与体会 23
九、参考文献 24

一、黑盒测试原理及测试用例设计——等价类划分法
1.1测试用例的定义和特征
测试用例的定义：
（1）测试用例是为特定的目的而设计的一组测试输入、 执行条件和预期的结果。
（2）测试用例是执行的最小实体。
测试用例的特征：
（1）最有可能抓住错误的；
（2）不是重复的、多余的；
（3）一组相似测试用例中最有效的；
（4）既不是太简单，也不是太复杂。
1.2设计测试用例的基本准则
测试用例的代表性
能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
测试结果的可判定性
即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
测试结果的可再现性
即对同样的测试用例，系统的执行结果应当是相同的。
1.3等价类划分原则
等价类划分设计方法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例。 定义：将程序的输入域划分为若干部分，然后从每个部分中选取少数代表性数据当作测试例。
原因：由于实现穷举测试的不可能性，只有从大量的可能数据中选取一部分作为测试用例。
效果：经过类别划分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值。
手段：在设计测试用例时，在需求说明的基础上划分等价类，列出等价表，从而确定测试用例。
1.4等价类划分法设计测试用例
输入三个整数作为三边的边长构成三角形。当此三角形为一般三角形、等腰三角形、等边三角形时，分别作计算。用等价类划分方法为该程序进行测试用例设计。
分析程序规格说明书中给出和隐藏的对输入条件的要求，列出等价类表：
三条边：必须是大于0的整数
三边构成的关系：两边之和必须大于第三边，两边之差必须小于第三边，且必须是大于0的整数

等价类表：
输入条件
有效的等价类
编号
无效等价类
编号

边长

大于0的整数

1
小于0
7
等于0
8
除数字以外的字符
9

边长的关系
两边之和大于第三边
2
两边之和小于第三边
10
两边之差小于第三边
3
两边之差大于第三边
11
三条边相等
4

两条边相等
5
满足两个条件外，不规则长度
6

测试用例：
测试用例编号
输入数据
预期输出
边长1
边长2
边长3
结果
1
3
3
3
满足
2
5
5
4
满足
3
5
3
3
满足
4
5
5
5
满足
5
6
3
6
满足
6
4
5
3
满足
7
-1
2
3
不满足
8
1
0
1
不满足
9
2
2
b
不满足
10
4
2
8
不满足
11
8
5
2
不满足

二、黑盒测试原理及测试用例设计——边界值分析法
2.1边界值分析法概要
边界值分析法就是 对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
2.2边界值分析法的思想
故障往往出现在输入变量的边界值附近。例如，一个循环条件为“≤”时，却错写成“<”；计数器发生少计数一次。
基于可靠性理论中称为“单故障”的假设，即有两个或两个以上故障同时出现而导致软件失效的情况很少，也就是说软件失效基本上是由单故障引起的。

2.3测试用例：找零钱最佳组合
假设商店货品价格(R) 都不大于100元（且为整数），若顾客付款(P)在100元内，现有一个程序能在每位顾客付款后给出找零钱的最佳组合（找给顾客货币张数最少）。 假定此商店的货币面值只包括：50元(N50)、10元(N10)、 5元(N5)、1元(N1) 四种。
请结合等价类划分法和边界值分析法为上述程序设计 出相应的测试用例。
一、 分 析 输 入 的 情 形 。 
1.R无效： R > 100  R<=0 2.R有效： 0 < R < = 100   此种情况下再考虑P： 
2_1. P无效：P > 100 （钱给多） 2_2. P无效：P < R   （钱给少） 
2_3. P有效：R<= P <= 100   //无效输出： 多找钱 少找钱  
二、 分 析 输 出 情 形 。  
考虑输出——找零个数 
这里是有效数据，关于" 找 给 顾 客 之 最 少 货币 个（张） 数"的有效取值 50：0/1 
10：0/1/2/3/4
5 ：0/1 
1 ：0/1/2/3/4   
三、 分 析 规 格 中 每 一 决 策 点 之 情 形 
考虑输出——找零数额（RR表示找零数额）  
无效输入（不找零）：  
R > 100   
R <= 0 
0 < R < = 100   P > 100 0 < R < = 100   P < R  
输出为相应错误提示信息  
有效输入（找零）：  
0 < R < = 100  R<= P <= 100 

此时考虑的输出：（RR=P-R 假设计算正确 不考虑此种情况无效输出）  
0<=RR<4 5<=RR<10 10<=RR<50 
50<=RR<100 
RR：0、1、4、5、9、10、49、50、99 
五、 为 满 足 以 上 之 各 种 情 形 ， 测 试 用 例 设 计 如 下 ： 1. 货品价格 = 101 2. 货品价格 = 0 3.货品价格 = -1 
4. 货品价格 = 100, 付款金额 = 101 5. 货品价格 = 100, 付款金额 = 99    
6. 货品价格 = 100, 付款金额 = 100   不找零 
7. 货品价格 = 99, 付款金额 = 100    N1＝1 
8. 货品价格 = 96, 付款金额 = 100    N1＝4 9. 货品价格 = 95, 付款金额 = 100    N5＝1 10. 货品价格 = 91, 付款金额 = 100   N5＝1, N1＝4 11. 货品价格 = 90, 付款金额 = 100   N10＝1 
12. 货品价格 = 51, 付款金额 = 100   N10＝4, N5＝1，N1＝4 13. 货品价格 = 50, 付款金额 = 100   N50＝1 
14. 货品价格 = 1, 付款金额 = 100    N50＝1,N10=4,N5=1,N1=4 

三、黑盒测试原理及测试用例设计——决策表法
3.1决策表法思想
决策表的概念：决策表是分析和表达多逻辑条件下执行不同操作情况的工具。
在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。决策表很适合于处理这类问题。
3.2决策表的生成
决策表通常由以下4部分组成：
条件桩—列出问题的所有条件
条件项—针对条件桩给出的条件列出所有可能的取值
动作桩—列出问题规定的可能采取的操作
动作项—指出在条件项的各组取值情况下应采取的动作
（1） 确定规则的个数。
有n个条件的决策表有2n个规则（每个条件取真、假值）。
（2） 列出所有的条件桩和动作桩。
（3） 填入条件项。
（4） 填入动作项，得到初始决策表。
（5） 简化决策表，合并相似规则。
若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。
合并后的条件项用符号“-”表示，说明执行的动作与该条件的取值无关，称为无关条件。
3.3决策表的简化
简化是以合并相似规则为目标；
若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。
3.4决策表法设计测试用例
某厂对一部分职工重新分配工作，分配原则是：
（1）年龄不满20岁，文化程度是小学者脱产学习，文化程度是中学者当电工；
（2）年龄满20岁但不足50岁，文化程度是小学或中学者，男性当钳工，女性当车工；文化程度是大学者技术员；
（3）年龄满50及50以上，文化程度是小学或中学者当材料员，文化程度是大学者当技术员。
试分析规格说明书，建立决策表，并简化
决策表的用例测试设计条件：
A1：{A：A<20}
A2：{A：20≤A≤50}
A3：{A：50≤A}
C1：{C：C=小学}
C2：{C：C=小学||C=中学}
C3：{C：C=大学}
S1：{S：S=男}
S2：{S：S=女}
根据条件分析，则有18种规则：

化简后的规则：
选项
规则
1
2
3
4
5
6
7
条件
T1：A

T2：C

T3：S
A1
A1
A2
A2
A2
A3
A3
C1
C2
C2
C2
C3
C2
C3
S
S
S1
S2
S
S
S
动作
E1：脱产学习

E2：当电工

E3：钳工

E4：车工

E5：技术员

E6：材料员
√

√

√

√

√

√

√

四、黑盒测试原理及测试用例设计——因果图法设计
4.1因果图的定义
是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
4.2因果图法设计测试用例步骤
分析程序规格说明书描述的语义内容，找出“原因”和“结果”，将其表示成连接各个原因与各个结果的“因果图”。
由于语法或环境限制，有些原因与原因之间或与结果之间的组合情况不能出现，用记号标明约束或限制条件；
将因果图转换成决策表；
根据决策表中每一列设计测试用例
某软件规格说明书包含“订货单处理程序”的处理逻辑描述为:如果订货金额不足500 元且未过期,则向顾客发出批准单和提货单,已过期的什么通知也不发；如果订货金额超过500 但不足1000 ,则发出批准单和提货单,对已经过期的发过期通知单；如果订货金额超过1000 ,不论是否过期,都要发出批准单和提货单。
要求：画出因果图，并生成判定表和设计测试用例 ： 
实验分析如下： 
首先列出原因为：1、订货金额不足500 元；2、订货金额超过500 但不足1000； 
3、订货金额超过1000；4、过期。 
结果则是：21、发出批准单和提货单；22、无通知；23、发过期通知单。 
实验结果：原因1、2、3不能同时发生，所以对其施加异约束E，具有E约束的因果图如下：

根据因果图建立的判定表如下：

设计测试用例如下，用例ID与判定表中的对应：

五、白盒测试方法——逻辑覆盖法
5.1语句覆盖
语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。
测试用例的设计格式如下：
输入的(A, B, X)，输出的(A, B, X)
语句覆盖率
已执行的可执行语句占程序中可执行语句总数的百分比
复杂的程序不可能达到语句的完全覆盖
语句覆盖率越高越好
检查所有语句
结构简单的代码的测试效果较好
容易实现自动测试
代码覆盖率高
如果是程序块覆盖，则不涉及程序块中的源代码
优点 ：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
缺点 ：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的。如在多分支的逻辑运算中无法全面的考虑。语句覆盖是最弱的逻辑覆盖。
5.2判定覆盖
判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。
判定覆盖又称为分支覆盖。
说明：以上仅考虑了两出口的判断，我们还应把判定覆盖准则扩充到多出口判断（如Case语句）的情况。因此，判定覆盖更为广泛的含义应该是使得每一个判定获得每一种可能的结果至少一次。
优点：判定覆盖具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
缺点：往往大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。判定覆盖仍是弱的逻辑覆盖。
5.3条件覆盖
在设计程序中，一个判定语句是由多个条件组合而成的复合判定，判定(a)&&(b||c)包含了三个条件：a,b和c。为了更彻底的实现逻辑覆盖，可以采用条件覆盖。
条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
在图例中，我们事先可对所有条件的取值加以标记。
优点：增加了对条件判定情况的测试，增加了测试路径。
缺点：条件覆盖不一定包含判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
5.4判定--条件覆盖
判定/条件覆盖实际上是将判定覆盖和条件覆盖结合起来的一种方法，
就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判定的可能结果也至少出现一次。
设计测试用例覆盖4个条件的8种取值以及4个判定分支。
分析：从表面上看，判定/条件覆盖测试了各个判定中的所有条件的取值，但实际上，编译器在检查含有多个条件的逻辑表达式时，某些情况下的某些条件将会被其它条件所掩盖。因此，判定/条件覆盖也不一定能够完全检查出逻辑表达式中的错误。
优点 ：能同时满足判定、条件两种覆盖标准。
缺点 ：判定/条件覆盖准则的缺点是未考虑条件的组合情况。
5.5条件组合覆盖
条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
优点 ：条件组合覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。
缺点 ：线性地增加了测试用例的数量。
5.6路径覆盖
路径覆盖就是设计足够的测试用例，覆盖程序中所有可能的路径。
分析：
虽然前面一组测试用例满足了路径覆盖，但并没有覆盖程序中所有的条件组合，即满足路径覆盖的测试用例并不一定满足组合覆盖。
说明：
对于比较简单的小程序，实现路径覆盖是可能做到的。但如果程序中出现较多判断和较多循环，可能的路径数目将会急剧增长，要在测试中覆盖所有的路径是无法实现的。为了解决这个难题，只有把覆盖路径数量压缩到一定的限度内，如程序中的循环体只执行一次。
在实际测试中，即使对于路径数很有限的程序已经做到路径覆盖，仍然不能保证被测试程序的正确性，还需要采用其他测试方法进行补充。
5.7设计测试用例
设计测试用例,实现语句覆盖,判定覆盖,条件覆盖,判定/条件覆盖,条件组合覆盖,路径覆盖.
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
}

试做出三角形问题的语句覆盖,条件覆盖,判定覆盖,判定－条件覆盖、组合条件覆盖的测试用例.并注明满足覆盖的条件

1）判定/条件覆盖 
对于第一个判定a>0&&b>0&&c>0 ： 
条件a>0    取真值记为T1，取假值记为-T1 条件b>0    取真值记为T2，取假值记为-T2 
条件c>0    取真值记为T3，取假值记为-T3 
对于第二个判定( a+b>c)&&(a+c>b)&&(b+c>a )： 
条件a+b>c  取真值记为T4，取假值记为-T4 条件a+c>b  取真值记为T5，取假值记为-T5 条件b+c>a  取真值记为T6，取假值记为-T6 

2.
对下面的流程图用逻辑覆盖法设计测试用例（至少三种） 

1)..语句覆盖：语句覆盖可以保证程序中的每个语句都得到执行。 
测试用例输入为：{ x1=3、x2=0}  输出x3=0 ，程序执行的路径是：12345678 2.判定覆盖： 
测试用例输入为：{ x1=2、x2=1}  输出x3=0 ，程序执行的路径是：123578； 测试用例输入为：{ x1=3、x2=0}  输出x3=0 ，程序执行的路径是：12345678. 3).条件覆盖 
对于第一个判定( (x1=3)or(x2>1) )： 
条件x1=3   取真值记为T1，取假值记为-T1 
条件x2>1   取真值记为T2，取假值记为-T2 
对于第二个判定( (x1>2)and(x2=0) )： 
条件x1>2   取真值记为T3，取假值记为-T3  
条件x2=0   取真值记为T4，取假值记为-T4

基本路径测试法（画出程序的流程控制图  计算环路复杂度  画出图形矩阵） 
主要代码如下： 
1. If (inta >= intb + intc) _ 
2.         Or (intb > =inta + intc) _ 
3.               Or (intc >= intb + inta) Then 
4.     strMsg = "三角形两边之和必须大于第三边" + vbCrLf + "非三角形" 5. Else 
6.     If (inta = intb) _ 
7.              And (intb = intc) Then 
8.         strMsg = "三角形的三条边都相等" + vbCrLf + "等边三角形" 9. 
    Else 
10.         If (inta = intb) _ 11.                Or (inta = intc) _ 
12.                      Or (intc = intb) Then 
13.             strMsg = "三角形的任意两边相等" + vbCrLf + "等腰三角形" 14.         Else 
15.             strMsg = "三角形的各边均非等" + vbCrLf + "普通三角形" 16.         End If 17.     End If 18. 
End If 

1． 根据上面的代码画出程序的控制流图。

2．计算环路复杂度。 
V(G)=9 
3．求出基本路径组合。 
P1:  1-4-18 P2:  1-2-4-18 P3:  1-2-3-4-18 
P4:  1-2-3-6-7-8-17-18 
P5:  1-2-3-6-10-13-16-17-18 P6:  1-2-3-6-10-11-13-16-17-18 P7:  1-2-3-6-10-11-12-13-16-17-18 P8:  1-2-3-6-10-11-12-15-16-17-18 要点：从较短路径顺序增加 
每个分支尽可能走一次 
4．设计测试用例，按照表1的形式，设计用例。 

六、基本路径法
6.1基本路径法的思想
路径测试就是设计足够的测试用例覆盖程序中所有可能的路径.但在实际的问题中,一个不太复杂的程序,其路径都是一个庞大的数字，为解决这一难题,只得把覆盖的路径压缩到一定的范围内.基本路径测试法就是这样的一种测试方法,它是在程序控制流图的基础上,通过分析控制结构的环路复杂性,导出可执行的基本路径的集合,从而设计测试用例.设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。
6.2控制流图
程序的控制流图：描述程序控制流的一种图示方法。
6.3环形复杂度（环路复杂性）
程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
6.4独立路径
独立路径是指包括一组以前没有处理的语句或条件的一条路径。
6.5基本路径测试步骤
基本路径测试步骤
根据给出的程序流程图，完成以下要求：
（1）画出相应的控制流图。
（2）计算环形复杂度。
（3）给出相应的图矩阵。(4）找出程序的独立路径集合。

解答:
（1）控制流图如下所示：

(2)环形复杂度为2+1=3 
(3)图矩阵：图中(A<5)AND(B=5)，X=X/A，(A=2)OR(X>2)，X=X+1四个节点分别标识为1，2，3，4，则图矩阵为   0 a b 0                          0 0 c 0                          0 0 0 e                          0 0 0 0  (4)独立路径：总共4条独立路径 
   第一条：(A<5)AND(B=5)       (A=2)OR(X>2) 
   第二条：(A<5)AND(B=5)        X=X/A       (A=2)OR(X>2) 第三条：(A<5)AND(B=5)       (A=2)OR(X>2)       X=X+1 
第四条：(A<5)AND(B=5)       X=X/A       (A=2)OR(X>2)       X=X+1
七、LoadRunner基本使用
制定测试计划（包括测试实例的设计、场景的设计等）。
录制测试脚本（对用户的操作过程进行录制、回放和修改）。
创建测试场景（模拟用户的操作）。
运行测试（运行整个场景）。
监视场景（对服务器的各项性能指标进行实时监测）。
分析测试结果（帮助测试人员对测试结果进行分析）。
使用LoadRunner测试网站邮箱登录的操作过程。
选择程序组里面的LoadRunner/virtual user generator。
选择【web（http/html）】协议。不同的测试对象选择不同的协议，针对web网站，选择web协议。
切换到脚本视图，选择【view】/【script view】。其中vuser_init和vuser_end一般用于存放应用程序初始化和关闭时的脚本，这两个脚本只执行一遍。Action中存放的是实际的主体脚本，可以多次运行，测试人员也可以创建多个Action脚本。
单击工具栏上的【start recording】按钮，开始录制脚本。【URL】中填写要测试的网址()。
选择【option】按钮，配置browser，默认是IE，如系统默认的浏览器不是ie，需要配置【specify path to application】。
点击【ok】按钮，开始录制。这是会自动打开网页。需要耐心等待，lr自动会打开该网页，不能人工打开。
输入用户名和密码，点击登录按钮，直到登录后的界面完全显示后再点击录制工具栏上的停止按钮。
录制完成后，需要测试一遍该脚本。点击工具栏上的运行脚本按钮，运行完毕后会自动生成一个报告，点击页面上的recording summary链接，可以进入报告页面。
点击【TOOLS】菜单下的【create controller scenario】选项，选择【manual scenario】（人工场景），设置number of vusers（虚拟用户数）为10。
点击【edit schedule】，设置【ramp up】（开始）选项【load setting】，选择【duration】，设置【ramp down】。
单击【start scenario】开始测试。
测试完成后，单击【result】菜单，选择【analyze results】菜单，生成结果分析报告。
分析测试结果（要有文字说明和截图）。
使用QTP测试windows版的飞机订票系统（找出该程序的BUG，愈多愈好。BUG的编写格式如下（如果有多个bug参照该格式分别进行说明）：
首先需要熟悉QTP自带的"C:\Program Files\Mercury Interactive\QuickTest Professional\samples\flight\app\flight4a.exe"程序，具体可以使用该程序的help文件。登录后的界面如下所示：

单击【开始】-à【程序】--à【QuickTest professional】-à【QuickTest professional】，启动QTP。具体测试过程参见C:\Program Files\Mercury Interactive\QuickTest Professional\help \QTP4BPT.pdf文件。
单击【automation】菜单下的【record and run settings】。选择【windows application】标签，设置【record and run only on】下的【application specified below】在【application】文本框中填入"C:\Program Files\Mercury Interactive\QuickTest Professional\samples\flight\app\flight4a.exe"。这次我们使用QTP自动的航班订票系统程序来测试。
单击【tools】菜单下的【option】，单击标签【Run】，将【view results when run session ends】前面的勾去掉。
单击工具栏上的【record】按钮，QTP自动启动flight程序。
在【agent name】输入mercury，【password】输入mercury，登录。
进入后随便添加一个航班记录即可。单击【stop】按钮停止记录。
单击工具栏上的【run】按钮，进行回放。
单击【automation】菜单下的【result】菜单查看测试结果。具体如下所示：

分析测试结果（要有文字说明和截图）。
使用CppTest测试一段c代码
注意：安装c++test之前需要先安装vc++6.0。将以下代码输入到VC++6.0环境下进行编译，确保编译通过。需要编写测试用例：可以使用系统自动生成的TC，如果系统的测试用例不完善，需要自己设计TC。TC格式如下：

#include <string.h>
#include <stdio.h>
int user_input_handler(char *user_input, char * output)
{
int result = 0;
if (strcmp("load", user_input) == 0) {
strcpy(output,user_input);
} else if (strcmp("save", user_input) == 0) {
strcpy(output, user_input);
} else if (strcmp("quit", user_input) == 0) {
strcpy(output, user_input);
} else {
result = -1;
}
return result;
}
void main(void)
{
char res[] = "save";
char des[5];
printf("%d\n",user_input_handler("load",des));
}
安装c++test。
启动c++test，单击【file】菜单下的【new project】子菜单，在出现的对话框中选择【import visual c++ 6.0 project】，输入测试工程名和对应的c++工程。
单击【test】下的【read symbols】。
单击【test】下的【test using】--【active configuration】，执行单元测试。
单击标签【unit testing（native）】，查看测试用例的通过情况。
如果测试用例不全，需要添加tc，右键单击任意一个tc，选择【add】，定制arguments。
单击【test】下的【test using】--【configurations】---【built in】--【coding standards】--【crules】，执行代码规范检查。
针对以上的c代码，进行单元测试，如果c++test生成的TC不完善，请你补充完善。如果代码不规范，请加以修改。

八、总结与体会
要想成为好的测试人员，首先得了解自己要测试的软件的相关知识。要了解软件产品的架构是什么样的。要了解软件的市场需求，在接触软件之初要可以多看看用户的反馈信息，这些才是用户最关心的，也是在测试中需要注意的问题，满足客户是最大的需要。但是了解软件需求之后要学会要多读些软件系统的技术文档，软件设计文档，这些文档可以帮助了解产品如何工作。
要想在短暂的时间内，尽可能的学会一些东西，这需要跟老师、跟同学有很好的沟通，加深彼此的了解，同时我觉得这也是我将来走上社会的一把不可缺的钥匙，通过沟通了解，才能更好有针对性地学习了解各方面的知识，才能真正地学到了计算机教科书上所以或者真正用到了课本知识，巩固了旧知识，掌握了新知识，甚至在实践中推翻了本书上旧有的不合实际的知识，这才是真正体现了知识的真正价值，学以致用。
经过这次学习，遇到许多困难，也懂得了许多，在这段时间里，学习以前没有学过的知识，使我觉得特别有意义和价值。此次实训面对的数据测试及计算比较多页比较复杂，这也考验了学生的态度及耐心。
在课程中，我了解开发项目是一个有机的整体，而软件测试为最终的软件是否成功把住了最后一道关，测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
1、最基本的测试的分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试；从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。 
2、然后就是，白盒测试中的逻辑驱动测试的覆盖率测试。
 3、还有就是对于划分等价类和边界值法这一块，让我从模糊到明朗。 

九、参考文献
[1] 郑人杰,殷人昆,陶永雷《实用软件工程[M]》.北京:清华大学出版社,1999 第208~209页
[2] 郑人杰 《计算机软件测试技术[M]》.北京:清华大学出版社,1992 第121~122页
[3] 周之英,郑人杰译 《计算机软件测试技巧[M]》.北京:清华大学出版社,1992第89~103页
31
软件测试实训