-
白盒测试基本概念（转）
2009-03-02 13:51:43
-
黑盒测试 PK 白盒测试(转)
2009-03-02 13:48:38
-
黑盒测试、白盒测试和灰盒测试的基本概念(转)
2009-03-02 13:32:37
-
白盒测试之基本路径测试法（转）
2009-03-02 13:22:56
白盒测试之基本路径测试法
白盒
测试 的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序 变异。51Testing软件测试网5O Aw)L W P o"Y4F]mJJ c)H85282 其中运用最为广泛的是基本路径测试法。
$V?jw-xw`*Jj Jb852827k~"i,[Q!U Q85282
基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而 51Testing软件测试网)r lZ!h:|;~| eG设计 测试用例的方法。j3^3k)y$p:N%b85282 设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。
g uq*Gt?$@s85282wSQr \"O A)l2[y%n85282
51Testing软件测试网3k$O `.Z:J'}4d B在程序控制流图的基础上，通过 51Testing软件测试网 Epk5g&_Yl分析 控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下4个步骤和一个工具方法：
51Testing软件测试网ORx9K(l1. 程序的 51Testing软件测试网6Q kHEd+w:mS控制 流图：描述程序控制流的一种图示方法。
"g)c0A5B&ETx)@/m852822. 程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确 定程序 中每个可执行语句至少执行一次所必须的测试用例数目的上界。},K4A"]-Z5o85282
1?4Ta&D$U852823. 导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期 结果 。t8oBZ1rxJ\du85282 4. 准备测试用例：确保基本路径集中的每一条路径的执行。
#_1y,s } W`VF85282z-z3P qf E+c85282 工具方法：51Testing软件测试网'eU"Yx`&eW!kU
.^_7u{y*R$|%b/\N6Y85282 图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。51Testing软件测试网&WbA'Ft&T-YI
O} U i,u85282 程序的控制流图：描述程序控制流的一种图示方法。
3^,v3B(jJ1Bh85282P9I+|1Z-K#M,Swom R!~85282 圆圈称为控制流图的一个结点，表示一个或多个无分支的语句或源程序语句
K|)SUi @_*|85282
iK@X HWi8528251Testing软件测试网fP[vD Np
流图只有二种图形符号：51Testing软件测试网:_$?&P^/z7\e
51Testing软件测试网%g fmXvVC.C ^w图中的每一个圆称为流图的结点，代表一条或多条语句。
y {5m"x8W X'h85282q$hv G R2\85282 流图中的箭头称为边或连接，代表控制流
[ K{s1P/J[8A85282.G!ff B#^85282 任何过程设计都要被翻译成控制流图。
*y4Fgfpj8528251Testing软件测试网s2KU6m5}~~f
|N~v| A E2t2p8528251Testing软件测试网Cd2J u fb*C-l2f(K如何 根据 程序流程图画出控制流程图?在将程序流程图简化成控制流图时，应注意：
B r7x7ya8528251Testing软件测试网wzV9f*E2j @5M+^n 在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。
6eh Z-s;EE8528251Testing软件测试网0y Hun1}q{5Kun 边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。51Testing软件测试网7N2O s1R[&Y%l{*r
4I0K/p&A!{-Ci85282 如下页图所示
+g `1u0az*E.w:p85282
'M6KCd;UObT+r%f |85282
n 如果判断中的条件表达式是由一个或多个逻辑运算符 (OR, AND, NAND, NOR) 连接的复合条件表达式，则需要改为一系列只有单条件的嵌套的判断。51Testing软件测试网s%u1aB_cBE
51Testing软件测试网 _K)f2B e,[{例如：51Testing软件测试网 y [~/q8^#Aw;\j0n
t)F-XZUO |wX Z kD"r85282 1 if a or b
g`6t\1of852823_F7tN|)w h+[}85282 2 x51Testing软件测试网/U#H2^"Ea6B+V.h
51Testing软件测试网 H { Jg l}X$W6^3 else51Testing软件测试网9a3To W%N5N
ha t T ty;[_-~85282 4 y51Testing软件测试网4Dk)g@)V2w IF$D
5yWfE&Jk C85282 对应的逻辑为：51Testing软件测试网/p6CO&Ei2B&s
51Testing软件测试网M"h&CgP E e#jZl#r(B1c `\ Z)e85282 独立路径：至少沿一条新的边移动的路径51Testing软件测试网@&c*P A9nCk x"Ns+is
eGC K*}-}I.\,oq85282
o 第一步：画出控制流图51Testing软件测试网:Q1Vdu\ C`
51Testing软件测试网!g"F8sU v流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中，每一个圆，称为流图的结点，代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个结点，即使该结点并不代表任何语句(例如：if-else-then结构)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。
\6H KI9V:d$D'a85282
51Testing软件测试网Nu {a U1K9t1W
51Testing软件测试网 D;D| z Hh? h画出其程序流程图和对应的控制流图如下51Testing软件测试网JV2m{0X;X/h U Z(W
51Testing软件测试网,hD ][/{v^3FiCb/Kt,D)n$B'GK n:v85282 o 第二步：计算圈复杂度51Testing软件测试网8{.P%{0c'd
.{2HxL4{W;J85282 圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。
];U G6TD8E Vr)r+c85282{6T,CI4K ]4z:R3x85282 有以下三种方法计算圈复杂度：
j U&n s5Az+_v8528251Testing软件测试网d L \\7Ek流图中区域的数量对应于环型的复杂性;
h%dW6g,u4d I8528251Testing软件测试网!J.t#w6UJ:xyz给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量;
O,A4u$V(J*rd85282ZW/rB,B)f lO85282 给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。
_ Yt&}P2x C85282
51Testing软件测试网5kH h#{@ l pd @2yo 第三步：导出测试用例51Testing软件测试网)NkIyuV z
QVAfwq^i \N85282 根据上面的计算方法，可得出四个独立的路径。(一条独立路径是指，和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数。)51Testing软件测试网 V ^ Q,\7i#A+_
51Testing软件测试网 z m[jy+J#oü 路径1：4-14
c,_bL |:Uy~8528251Testing软件测试网-D DkM/@ o*Z)|Rnü 路径2：4-6-7-14
hM H*p$g5w8528251Testing软件测试网,d:VTV#sü 路径3：4-6-8-10-13-4-1451Testing软件测试网.u,HhD-h|\y
%K EF.I.? E4HR2^85282 ü 路径4：4-6-8-11-13-4-14
YW8d6n6Ag4B85282XQ(e9^ Ix{s85282 根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径。51Testing软件测试网d,An M,DGC/r3p
5|&R!l]:? ok85282 o 第四步：准备测试用例
Y ABI%_8528251Testing软件测试网^I:\@:c#`为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是：51Testing软件测试网Z!e;f d RKm d
51Testing软件测试网 @_4B/IE4G9E"o举例说明：51Testing软件测试网_7v E} Q~V;M N*vi
;@9Tf*{.u]z85282
i.EQg Z b85282例：下例 程序 流程图描述了最多输入50个值(以–1作为输入结束标志)，计算其中有效的学生分数的个数、总分数和平均值。
`J(r"]8y8E(Y"y85282
9H| |-J u]85282 步骤1：导出过程的流图。
:dNk4chxqt85282
kTK3A%Jc2[8528251Testing软件测试网"{ {)h(M C @8x
步骤2:确定环形复杂性度量V(G)：51Testing软件测试网 }l |&U"Q T)k
l{p8Ki L,I85282 1)V(G)= 6 (个区域)
A8C Q ?%P n4r8528251Testing软件测试网i6BL ?1c b r v|2)V(G)=E–N+2=16–12+2=6
;ix#O-TI@2gp85282{f&i'}A85282 其中E为流图中的边数，N为结点数;
@"M;q/Vv x852821h3MILS(I4X!P85282 3)V(G)=P+1=5+1=651Testing软件测试网Vm/D8~"r/Z+rn8V/X
51Testing软件测试网f i7o6D j!Xc"F*\其中P为谓词结点的个数。在流图中，结点2、3、5、6、9是谓词结点。51Testing软件测试网q,W L T D
51Testing软件测试网 A K Y)V @N$}g步骤3：确定基本路径集合(即独立路径集合)。于是可确定6条独立的路径：
;s k-F/tFt6ai8528251Testing软件测试网r:`7j/V^T&C1IA1D路径1：1-2-9-10-1251Testing软件测试网ie*sTw#g5g oG
"y7Z a}}1m5n0s85282 路径2：1-2-9-11-12
QF0\:F[5Q2j.J5I l8528251Testing软件测试网7XJq0Hws路径3：1-2-3-9-10-12
Flg1Jl4f{#P7s85282Hz I qD#hw2y8j'?85282 路径4：1-2-3-4-5-8-2…
-?u? T0V| jr$Y85282-]5v h3z,_1k!S#g85282 路径5：1-2-3-4-5-6-8-2…51Testing软件测试网XU0c5C1|5e
'f SM|v%fx85282 路径6：1-2-3-4-5-6-7-8-2…
5K\O SIIx uF8528251Testing软件测试网]'mTt%?/\"^步骤4：为每一条独立路径各 51Testing软件测试网p;U`9v M设计 一组测试用例，以便强迫程序沿着该路径至少执行一次。l1v%^&c T8zs)^9@C$m85282 1)路径1(1-2-9-10-12)的测试用例：51Testing软件测试网 b3y#Q e"H4Z8h
51Testing软件测试网8H^&N@0OS(Escore[k]=有效分数值，当k < i ;
X {5Mf*[;j'g7f"K8528251Testing软件测试网 vs)UL.s#l#yscore[i]=–1, 2≤i≤50;51Testing软件测试网|a-HG l:lm
51Testing软件测试网t(r:uv}8|do
!hV0`S F4^85282期望结果：根据输入的有效分数算出正确的分数个数n1、总分sum和 平均分 average。;c.jay4Lc h85282 2)路径2(1-2-9-11-12)的测试用例：51Testing软件测试网B\ }0H3`$W4n
51Testing软件测试网 WKY!]bc1aoscore[ 1 ]= – 1 ;
'L7U1fX.c5o3wO*N"\s8528251Testing软件测试网(V ot}c.yb:[
r_ {k-YV0sb85282期望的 结果 ：average = – 1 ，其他量保持初值。.w_w6pW Z+V S85282 3)路径3(1-2-3-9-10-12)的测试用例：
'G8Jf @ P^85282J{4`-P;B5Nz Z)`B{85282 输入多于50个有效分数，即试图处理51个分数，要求前51个为有效分数;51Testing软件测试网%} T p9jW5Z r
0L8Jh v j6y85282 期望结果：n1=50、且算出正确的总分和平均分。
E:Z;jnY"FP5i852824`(dN0P/E _)x85282 4)路径4(1-2-3-4-5-8-2…)的测试用例：51Testing软件测试网 F.k k&Y7d0DSi#l
`"I$m+_w-{.R'_9T H.o85282 score[i]=有效分数，当i<50;
3`7}atB w852821]MEN0?u&`85282 score[k]<0， k< i ;
iy js#@852828z4wM(ho.T85282 期望结果：根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average
,`6I}/a{ V85282:p"d,t$p!j-G{85282 score[i]=有效分数， 当i<50;51Testing软件测试网"Qr2n6s z-UF i_Yg
51Testing软件测试网Z$A } |0g7c7J Z,Qscore[k]>100， k< i ;
Lfo-S#HbS85282W+] Q5z f$?85282
51Testing软件测试网 V Sd;R%?`期望结果： 51Testing软件测试网){+`~ H)| r$np根据 输入的有效分数算出正确的分数个数n1、总分sum和平均分average。6)路径6(1-2-3-4-5-6-7-8-2…)的测试用例：51Testing软件测试网x g5L'dJ \'_3~
51Testing软件测试网x(\})n-d RYscore[i]=有效分数， 当i<50;
@f}+t7V9@85282L:O6Zd F*\85282 期望结果：根据输入的有效分数算出正确的分数个数n1、总分sum和平均分average。51Testing软件测试网J$pNSKC L\
Hm I`2B85282 注意事项：
{X'Fgccv85282!j&U5N;q;a85282
必须注意，一些独立的路径，往往不是完全孤立的，有时它是 51Testing软件测试网 LpX(N!P P n程序 正常的控制流的一部分，这时，这些路径的测试可以是另一条路径测试的一部分。^&g ET7fXoV85282 方法工具：图形矩阵51Testing软件测试网%_ \`2O5M3e H8S
q-sI V6{'m'n&x85282
o 导出控制流图和决定基本测试路径的过程均需要机械化，为了 数据结构很有用。51Testing软件测试网 ntN4L#~9t$v B开发 辅助基本路径测试的软件工具，称为图形矩阵(graph matrix)的J"`)Af SIS85282
"H$I GzS8k7h85282利用图形矩阵可以实现自动地确定一个基本路径集。一个图形矩阵是一个方阵，其行/列数 控制 流图中的结点数，每行和每列依次对应到一个被标识的结点，矩阵元素对应到结点间的连接(即边)。在图中，控制流图的每一个结点都用数字加以标识，每一条边都用字母加以标识。如果 在控制流图中第i个结点到第j个结点有一个名为x的边相连接，则在对应的图形矩阵中第i行/第j列有一个非空的元素x。O"J5t2G B L+XjK85282
51Testing软件测试网Y;|(l*p:{%s对每个矩阵项加入连接权值(link weight)，图矩阵就可以用于在测试中评估程序的控制结构，连接权值为控制流提供了另外的信息。最 51Testing软件测试网O$Hy-q1@简单 情况下，连接权值是 1(存在连接)或0(不存在连接)，但是，连接权值可以赋予更有趣的属性：执行连接(边)的概率。51Testing软件测试网3Y6T&Ol9r"U8A#f
51Testing软件测试网#JG_Gn;D$e穿越连接的处理时间。
/R ZX-j!UP6Q\8528251Testing软件测试网&N)Hz.K D2Q+l
Z:gN1n[ R8528251Testing软件测试网 bA8Xrg9l#p~ c穿越连接时所需的 内存 。穿越连接时所需的资源。51Testing软件测试网MN2C*oN2r!e
FiFRT a$Y85282 根据上面的方法对例4画出图形矩阵如下：
S U*}DnU%^P#Dq,B85282
51Testing软件测试网 ~'Ju&w\!K
51Testing软件测试网!l_0e g:I xne-I
^Spc \85282连接权为“1”表示存在一个连接，在图中如果一行有两个或更多的元素“1”，则这行所代表的结点 一定 是一个判定结点，通过连接矩阵中有两个以上(包括两个)元素为“1”的个数，就可以得到确定该图圈复杂度的另一种算法。 -
常用嵌入式软件白盒测试工具介绍
2009-03-02 13:15:11
-
为何要进行白盒测试(转)
2009-03-02 12:58:37
为何要进行白盒测试
软件白盒测试是一个与黑盒测试相对的概念，是指测试者针对可见代码进行的一种测试。白盒测试通常再划分为单元测试、集成测试两大类，但依据不同的流程，对白盒测试细分的标准也不尽一致，比如在IBM
的IPD流程之下，白盒测试可能划分为如下几类： 51Testing软件测试网 k2VU:L#Js;R模块 单元测试、模块集成测试、模块系统测试、渐增Build集成测试、系统集成测试等。而在XP实践中，单元测试与集成测试之间的界限并不明显，统称为渐增迭代测试。一、从一个比喻开始51Testing软件测试网oE9X)|$hA,~*NN` t
51Testing软件测试网?ZbKYY-o^NZ
为什么要做白盒测试？这个问题比较复杂，我们先从一个比喻开始讲起。51Testing软件测试网 Rl,bd3fi7T9R.UV
51Testing软件测试网`` Y6Q#n]
假设有一台的面包机，从上面倒入面粉与水，开动机器后从下面出来的就是烤好了的面包，这个机器的功能比较单一，接口很清晰，输入是面粉与水，输出是面包。现在假定这个面包机多年未用，内部都生锈了，现在要清洗它，类似于我们 开发 的软件，软件有Bug，那得通过测试来清理。
6Q:@"B8\/u+rPJ85282
51Testing软件测试网!I%w9V'nOlpCbV-I"C Fx-\m85282 那如何更快速的清洗这台面包机呢？有两种洗法，一是拿水从上往下灌，这是系统测试的方法。另一种是拆开来洗，拆开机 器后，拿抺布沾点清洁剂，把各零件的坑坑槽槽擦洗一遍，然后组装回来，再用水从上往下冲一遍，拆开来洗是白盒方法，组装回来用水冲是黑盒方式，相当于白盒 测试之后再追加一次系统测试。51Testing软件测试网-P"\8Z.`;[\
/w Nng^AQ1{ ~6G85282 无疑，上面第二种方法是正确的，我们的前提是：清洗多年未用的面包机，铁锈够多，如果洗不干净，造出的面包都是致癌物质。当然，清洗面包机还只能算简单劳动，清理软件中的Bug要复杂得多，一个if语句有两条分支，一个while循环判断也是两条分支，还有break、continue、return等，想想看，一个1万行规模的软件能有多少个分支！一个分支就是一条坑坑槽槽，而且软件Bug还具备动态特性，不是静止的明摆在哪儿。
6y8D9W1d ]B`8528251Testing软件测试网 i{'r p.y6J` D L
所以，软件的白盒测试不可或缺，因为遗留Bug的影响很大，就像面包机没洗净留铁锈会致癌，还因为软件系统远比面包机复杂，不拆开来怎么能洗干净！51Testing软件测试网-Z;s"h1Y1zco
_ b0x!p$i85282 二、白盒测试是高效测试51Testing软件测试网Bp~)L7[I
51Testing软件测试网me;n5x!W~;n`
尽管白盒测试如此重要，为什么还有许多 51Testing软件测试网l!h$sz0w,e2|企业 不愿做白盒测试，有一个很重要的原因是：认为白盒测试太低效，不值得去做。%fx xup]-R7R85282 实际上这种观点有许多误解成分，首先，决策者评估各阶段测试的有效性，仅以发现问题的数量为依据，这好比锈蚀斑斑的面包机，第一次冲水下去，看到大量浊水流出就很有成就感，其实这只是表象，思维方式有不足：把发现问题与解决问题割裂开来了。
4N ?4oF$T C85282
(V"d,K`0k2c w,J2dG85282
我们测试的目标是按既定质量标准稳定推进产品 51Testing软件测试网#f:E8b:h H,U/rHx9O)i研发 进度，只做系统测试的结果是：第一次冲水，很有成效，第二次冲水， 还能冲出点铁锈，第三次就没什么效果了。采用该手段并不能有效的达成既定质量目标。其次，研发质量改善，不只发现问题，还要定位问题、解决问题。白盒测试 是拆开来洗，发现、定位与解决问题不仅是彻底的，也是直接的，效率非常高，所以，单以发现问题数评估一个测试过程是否有效不尽准确，我们应该综合评估一个问题从被发现，到定位、解决，以及针对它完成回归测试的总效率。51Testing软件测试网2Sh+a/\ ~b*q X:@2Y
下图来源于Capers Jones与McGraw-Hill的“Applied Software Measurement”文章，从该统计数据可看出，针对一个功能点的测试，若将问题发现、定位与解决都计算进去，单元测试效率最高，是集成测试的2倍，是系统测试的3倍。51Testing软件测试网G ^_S7k
51Testing软件测试网'g5@(_&p Z0Eb!XwcdP/^ P85282
认为白盒测试低效的另一个误解是，决策者并未认清一个bug若遗留到下一阶段须多付出多少代价。经验数据表明，编码阶段的一个问题遗留到验收测试去解决，所须费用将 增加 5倍，如下图，一个问题越遗留到后面阶段解决，付出代价就越高，而且是成倍递增关系。51Testing软件测试网^ Y)J m"M;|j2e51Testing软件测试网q lQC#f/i'U6f Sw2w
~+nz!? Y'B }:~.xv Q0f+?8528251Testing软件测试网)Y5TXM6\ vg;L4xo'c
Mt X y@:DP:K85282
Xt&E z%Dy ox85282 所以，越早测试就越能节约成本，白盒测试作为早期测试，跳过不做是得不偿失的。
P v+\ yTP"yr{4n8528251Testing软件测试网*c[V O{N
依据上述原因，我们评估白盒测试效率时，通常将发现问题总数乘上一个系数K，以此为据再与其它测试方段的发现问题效率做对比，来权衡白盒测试值不值得去做。系数K取值与产品形态相关，按照实际经验，系数K取值区间为1.5~2.5，产品越复杂，出现问题越不容易解决的，K值要往大调。
$Q!I8oRXJ$b3r5d zE85282
FL'B"~ jN(PZb p85282 三、白盒测试能彻底解决编码阶段引入的问题
0G bA X3\+M CX4O8w85282
6z2w9Rat5_7u1F5l {85282 前面我们分析了白盒测试是高效的测试，值得一做，下面我们要接着说明白盒测试必须要做，不可或缺。51Testing软件测试网-d6pV7wq
&~z#kOiP[X85282先看一个案例，在某交换机产品的系统测试中，发现ISDN话机拨打某新业务号码时，在特定线路上，若一位一位的拨至18位，不会有问题，但如果先拨完号码再成组发送，会导致系统死机。这是一个导致死机的致命问题，最后定位出问题所在：呼叫处理的某段代码判断有误，本应小于18的判断，错写成小于等于18。
$sc-}X0q!Og!i85282
Y:P e!UL85282 这个问题本该在单元测试去发现，由于单元测试没做，问题就遗留到系统测试，庆幸的是没把它遗留到网上，否则问题就大 了。我们从另一个角度去反思，这个问题是特定线路下的特定终端，按特定方式拔打特定业务才暴露，在系统测试好不容易把它揪出来，但类似的其它问题呢？如何 保证在系统测试阶段都能测得出来？51Testing软件测试网FE t^` ]-S{)Rj+G~p
51Testing软件测试网T/e"i a9_9b zJ
不同阶段的测试发现问题的特点各不相同，比如：单元测试阶段，容易发现逻辑问题、边界条件（如上例“小于18” 的错误）、变量未初始化、内存越界等问题，而集成测试容易发现接口错误、任务配合问题等，系统测试容易发现业务流程问题、界面操作问题等。如果某阶段的测 试没做，把问题遗留后面阶段，又如何能保证查错的彻底性。比如使用非法内存，出问题是否表现出来是随机的，如果操作非法内存当前被系统还认为是有效的，系统并不死机，但某些情况下，操作非法内存会死机，而另一些情况，非法内存操作将不期望变化的变量改写了，会导致其它莫名其妙的问题。类似这样的问题，在白 盒测试阶段很容易发现，也容易定位解决，但遗留系统测试阶段，就很难去发现、去定位。
v ^4Ye V8528251Testing软件测试网)x,E5q? |:Ch
在V模型中，软件开发过程与测试行为具有不同层次的对应关系，如下图：51Testing软件测试网@YF2f}k
51Testing软件测试网Q9ob[Z wNG0t6_7K p3_+w ZY8g85282 单元测试针对编码阶段引入的问题，集成测试与功能测试针对软件设计中引入的问题，验收测试针对需求与规格。单元测试不要或缺的重要原因是：编码阶段引入的问题占很高比例，不进行单元测试就难以保证系统最终的稳定性。51Testing软件测试网.{ ~-T8Ep5x2} ?
51Testing软件测试网OJ @4hQ;k:Z Z \ IX"E"A
我们再来看一个实际案例：有两个产品形态接近的项目，A项目正式实施单元测试与集成测试，另一个项目B项目没正式做白盒测试（简单的拿调试当测试）。最后项目结束时对研发全过程的全部问题进行缺陷分析，如下图：51Testing软件测试网3RSe v.JDo H*L
51Testing软件测试网p9CJn.b b$y|rF2Q"s R$z5pgX`*SE8528251Testing软件测试网6L$N M E'so ]Kk
`0D;N-z K? { _~!L*|85282 A项目的缺陷类型分析
&a'Y1b$Qj pd*X4Q5u8V85282
(CNI u.A k6[#i85282 B项目的缺陷类型分析e8I&L6L ~mN8528251Testing软件测试网1?["W6d6q gp0@;M
A项目的所有问题中，应该发现问题的阶段是白盒测试（单元测试与集成测试）的占50%，而B项目所有问题中，应在白盒测试阶段发现的仅占33%，另外，A项目发现逻辑错误占13%，而B项目只占8%。由这个统计数据表明，不做白盒测试必然导致大量问题漏测。 51Testing软件测试网/Y"a^$l)U6N
51Testing软件测试网"^c9Y,o$Bof:m
四、白盒测试要做到什么程度才算合适51Testing软件测试网'f1J1}(y#L"lM
51Testing软件测试网 i iv}B
既然白盒测试不可或缺，那么，白盒测试应做到什么程度才算合适呢？具体来说，白盒测试与黑盒测试应维持什么样的比例才算合适？51Testing软件测试网.S,Ii[A9n
51Testing软件测试网T_ dt%i7j
一般而言，白盒测试做多做少与产品形态有关，如果产品更多的具备软件平台特性，白盒测试应占总测试的80%以上，甚至接近100%，而如果产品具备复杂的业务操作，有大量GUI界面，黑盒测试的份量应该更重些。根据经验，对于大多数嵌入式产品，白盒方式展开测试（包括代码走读）应占总测试投入的一半以上，白盒测试发现的问题数也应超过总问题数的一半。51Testing软件测试网5i!sf:b @
51Testing软件测试网cvtW5[j
由于产品的形态不一样，很难定一个标准说某产品必须做百分之多少白盒测试，但依据历史经验，我们还可以进行定量分析的。比如，收集某产品的某历史版本在开发与维护中发生的所有问题，对这些问题进行正交缺陷分析（Orthogonal Defect Classification，ODC），把“问题根源对象”属于概要设计、详细设计与编码的问题整理出来，这些都是属于白盒测试应发现的问题，统计这些问题占总问题数的比例，大致就是白盒测试应投入的比例。
8M4J4z9lz4{4k]gT8528251Testing软件测试网h(s IQ,Y L p+X
通过正交缺陷分析，还能推论历史版本各阶段测试的遗留缺陷率，根据“发现问题的活动”，能统计出与“问题根源对象”不相匹配的问题数，这些各阶段不匹配问题的比例就是该阶段的漏测率。51Testing软件测试网*C)L2H[+Y.^ T,lui
MSG2d dH8E85282 参考文献：
lM5_2B'mL4MTX85282
p5uNd8m%`$K85282 1. IPL, "Why Bother to Unit Test? "51Testing软件测试网2{ U)`w4[:G8b
;m(N$^t-}5\ g0H;z85282 2. Wayne Chan, 《第4代白盒测试方法介绍》51Testing软件测试网1ic ~M"j_~
-E E(E VTa"gJg^85282 3. Yang Gu, fromIBM, "Adopting ODC to improve software quality: A case study"
j r(Z8HKY1F85282
-
关于白盒测试（转）
2009-03-02 12:49:29
-
白盒测试实例1~10（转）
2009-03-02 11:25:47
白盒测试实例之一——需求说明
三角形的问题在很多软件测试的书籍中都出现过，问题虽小，五脏俱全，是个很不错的软件测试的教学例子。本文借助这个例子结合教学经验，从更高的视角来探讨需求分析、软件设计、软件开发与软件测试之间的关系与作用。
题目：根据下面给出的三角形的需求完成程序并完成测试：
一、输入条件：
1、 条件1：a+b>c
2、 条件2：a+c>b
3、 条件3：b+c>a
4、 条件4：0<a<200
5、 条件5：0<b<200
6、 条件6：0<c<200
7、 条件7：a==b
8、 条件8：a==c
9、 条件9：b==c
10、条件10：a2+b2==c2
11、条件11：a2+ c2== b2
12、条件12：c2+b2== a2
二、输出结果：
1、不能组成三角形
2、等边三角形
3、等腰三角形
4、直角三角形
5、一般三角形
6、某些边不满足限制
白盒测试实例之二——答案
很多初学者一看到这个需求（详见白盒测试实例之一——需求说明收藏），都觉得很简单，然后立刻就开始动手写代码了，这并不是一个很好的习惯。如果你的第一直觉也是这样的，不妨耐心看到文章的最后。
大部分人的思路：
1、首先建立一个main函数， main函数第一件事是提示用户输入三角形的三边，然后获取用户的输入（假设用户的输入都是整数的情况），用C语言来写，这一步基本上不是问题（printf和scanf），但是要求用java来写的话，很多学生就马上遇到问题了，java5.0及之前的版本不容易获取用户的输入。
点评：这样的思路做出来的程序只能通过手工方式来测试所有业务逻辑，而且这个程序只能是DOS界面版本了，要是想使用图形化界面来做输入，就得全部写过代码。
2、业务处理流程的思路用流程图表示如下：
3、C语言代码：
1. #include<stdio.h>
2. void main()
3. {
4. int a, b, c;
5. printf("please enter three integer:");
6. scanf("%d%d%d", &a, &b, &c);
7. if(0<a && a<200 && 0<b && b<200 && 0<c && c<200)
8. {
9. if(a+b>c && a+c>b && c+b>a)
10. {
11. if(a==b && b==c && a==c) //这里可以省掉一个判断
12. {
13. printf("1是等边三角形");
14. }
15. else
16. {
17. if(a==b || b==c || a==c)
18. {
19. printf("2是等腰三角形");
20. }
21. else
22. {
23. if(a*a+b*b==c*c || a*a+c*c==b*b || b*b+c*c==a*a)
24. {
25. printf("3是直角三角形");
26. }
27. else
28. {
29. printf("4是一般三角形");
30. }
31. }
32. }
33. }
34. else
35. {
36. printf("5不能组成三角形");
37. }
38. }
39. else
40. {
41. printf("6某些边不满足限制");
42. }
43. }点评：这样的思路做出来的程序只能通过手工方式来测试所有业务逻辑，而且这个程序只能是DOS界面版本了，要是想使用web或图形化界面来做输入，就得全部写过代码。
相关阅读：
白盒测试实例之三——需求分析
关键字：白盒测试、需求分析
需求分析是后续工作的基石，如果分析思路有问题，后续工作可能就会走向不正确的方向，比如：代码重用性差、难于测试、难于扩展和难于维护等。反而，如果需求分析做的好，对设计、开发和测试来说，都可能是很大的帮助。
看到题目给出的条件达12个之多，粗粗一看，好像很复杂，但仔细分析之后，发现可以把它们分成4组来讨论：
1、 条件1：a+b>c； 条件2：a+c>b； 条件3：b+c>a
这三个表达式有什么特点呢？实际上它们的逻辑是一样的：两个数之和大于第三个数。那么，前面程序的写法就存在逻辑重复的地方，应该把这个逻辑提取到一个函数中。
2、 条件4：0<a<200； 条件5：0<b<200； 条件6：0<c<200
这三个表达式也是同一个逻辑：判断一个数的范围是否在（0, 200）区间内，也应该把这个逻辑提取到一个函数中，去掉重复的逻辑，提高代码的可重用性。
可重用性的好处：比如，现在用户的需求改为了三条边的取值范围要改为[100,400]，那么，按前面的思路来说，需要改3个地方，而现在只需要在一个函数里改1个地方，这就是代码重用的好处。
3、条件7：a==b； 条件8：a==c； 条件9：b==c
这三个表达式的逻辑：判断两个数是否相等。也应该把它提取到一个函数中。
我们进一步来分析一下判断是否是等边三角形或等腰三角形的条件：
（1）前面程序的判断是从最直观的方式（a==b && b==c && a==c）（实际上只需要两个表达式成立即可）三条边都相等来判定是等边三角形；（a==b || b==c || a==c）只有两条边相等来判定是等腰三角形。
（2）转变一下思路：给定三个整数，然后用一个函数来判断这三个整数有几个相等，返回相等的个数，如果返回值等于3，那么它是等边三角形，如果返回值是2，那么它是等腰三角形，否则，它是一般三角形（如果不是直角三角形的话）。
4、条件10：a2+b2==c2 条件11：a2+ c2== b2 条件12：c2+b2== a2
这三个条件的处理方式有两种：
（1）跟前面三组分析一样，把相同的逻辑提取到一个函数中，然后三次调用。
（2）根据直角三角形的特点：斜边是最长的，所以我们可以事先写一个函数来找到最长的边，然后把它赋值给c，这样处理之后，只需要一次调用判定（a2+b2==c2）的函数了。
相关阅读：
白盒测试实例之四——程序设计
关键字：白盒测试
程序设计对于软件的质量和软件实施过程的难易程度起着至关重要的作用。好的设计，即使聘用没什么经验的开发人员都很容易产生出高质量的代码出来；而差的设计，即使是经验很丰富的开发人员也很容易产生缺陷，特别是可重用性、可测试性、可维护性、可扩展性等方面的缺陷。
经过以上的分析，下面来看一下如何设计。在下图中，每个方框都使用一个函数来实现，为了跟用户界面分开，最顶上的函数不要写在main函数中。
把思路用流程图的方式表达出来，不用停留在脑袋里：
具体的函数的调用关系图：
复杂模块triangleType的流程图：
相关阅读：
白盒测试实例之五——编码
1、Triangle.h
1. /*
2. * Copyright (c) 2008, 胡添发(hutianfa@163.com)
3. *
4. * 三角形类型判断
5. *
6. */
7.
8. #include<stdio.h>
9. #include<String.h>
10.
11. /*
12. * 判断一个整数是否在(0, 200)区间内
13. * 返回值：true-否； false-是
14. */
15. bool isOutOfRange(int i);
16.
17. /*
18. * 判断三条边是否合法(即：判断三条边都在合法的范围内)
19. * 返回值：true-是； false-否
20. */
21. bool isLegal(int a, int b, int c);
22.
23. /*
24. * 判断两条边之和是否大于第三边
25. * 返回值：true-是； false-否
26. */
27. bool isSumBiger(int a, int b, int c);
28.
29. /*
30. * 判断三条边是否能够组成三角形
31. * 返回值：true-是； false-否
32. */
33. bool isTriangle(int a, int b, int c);
34.
35. /*
36. * 判断两条边是否相等
37. * 返回值：true-是； false-否
38. */
39. bool isEquals(int a, int b);
40.
41. /*
42. * 求三角形有几条边相等
43. * 返回值：相等边的数量
44. */
45. int howManyEquals(int a, int b, int c);
46.
47. /*
48. * 判断是否满足两边平方之和是否等于第三边的平方
49. *
50. */
51. bool isPowerSumEquals(int a, int b, int c);
52.
53. /*
54. * 判断第一个数是否比第二个数大
55. */
56. bool isGreaterThan(int a, int b);
57.
58. /*
59. * 判断是否是直角三角形
60. *
61. */
62. bool isRightRriangle(int a, int b, int c);
63.
64. /*
65. * 判断三角形的类型，返回值：
66. * 1、不能组成三角形
67. * 2、等边三角形
68. * 3、等腰三角形
69. * 4、直角三角形
70. * 5、一般三角形
71. * 6、某些边不满足限制
72. */
73. int triangleType(int a, int b, int c);
白盒测试实例之六——单元测试的步骤
单元测试的步骤：
1、 理解需求和设计
理解设计是很重要的，特别是要搞清楚被测试模块在整个软件中所处的位置，这对测试的内容将会有很大的影响。需要记住的一个原则就是：好的设计，各模块只负责完成自己的事情，层次与分工是很明确的。在单元测试的时候，可以不用测试不属于被测试模块所负责的功能，以减少测试用例的冗余，集成测试的时候会有机会测试到的。
举例：
1. /*
2.
3. * 判断三条边是否能够组成三角形
4.
5. * 返回值：true-是； false-否
6.
7. */
8.
9. bool isTriangle(int a, int b, int c);
测试该函数的时候，只需要测试三条边（在合法的取值范围内的整数）是否能够满足两边之和是否大于第三边的功能，而不需要测试三条边是否在合法的范围（0， 200）之间的整数，因为调用该函数之前，一定要先通过下面函数的检查，要是检查不通过，就不会执行isTriangle函数。
1. /*
2.
3. * 判断三条边是否合法(即：判断三条边都在合法的范围内)
4.
5. * 返回值：true-是； false-否
6.
7. */
8.
9. bool isLegal(int a, int b, int c);
所以，单元测试主要是关注本单元的内部逻辑，而不用关注整个业务的逻辑，因为会有别的模块去完成相关的功能。
白盒测试实例之七——单元测试的尝试
以测试isOutOfRange函数为例，首先知道该函数在整个软件架构中处于最底层（叶子），所以对它进行测试并不需要写桩模块，只需要写驱动模块。要注意的问题是：对于测试结果是否通过测试不要使用printf方式打印被测试函数的返回结果值，否则就需要人工去检查结果了。
使用边界值的方法可以得到5个测试用例，写的驱动模块代码如下：
TestTriangle.cpp：
1. /*
2. * Copyright (c) 2008, 胡添发(hutianfa@163.com)
3. *
4. * 单元测试与集成测试
5. *
6. */
7. #include "Triangle.h"
8. /*
9. * 测试isOutOfRange函数，使用边界值的方法(0,1,5,199,200)
10. *
11. */
12. void testIsOutOfRange_try()
13. {
14. if(isOutOfRange(0) == true)
15. {
16. printf("pass!\n");
17. }
18. else
19. {
20. printf("fail!\n");
21. }
22.
23. if(isOutOfRange(1) == false)
24. {
25. printf("pass!\n");
26. }
27. else
28. {
29. printf("fail!\n");
30. }
31.
32. }
33.
34.
35. void main()
36. {
37. testIsOutOfRange_try();
38. }
小知识：做单元测试的时候，一般不直接在main函数中写所有的测试代码，否则的话，main函数将会非常庞大。正确的做法：针对每个函数分别创建一个或若干个（函数比较复杂时）测试函数，测试函数的名称习惯以test开头。
写到这里发现重复的代码太多了，而且如果测试用例数量很多的话，对于测试结果的检查也将是很大的工作量。在测试有错误的时候，这样的单元测试结果也很难获得更多关于错误的信息。
解决问题的途径可以采用cppUnit单元测试框架。不过这里为了让学生能够对单元测试和单元测试框架有进一步的理解，我决定自己写一个类似cppUnit的简单的测试框架。
相关阅读：
白盒测试实例之八——构建自己的单元测试框架（上）
在上一讲“单元测试的尝试”里我们遇到了几个问题：
1、代码重复的问题太多
2、测试结果需要人工去检查
3、对测试的总体信息也无从得知
本讲将构建一个简单的单元测试框架来解决以上的问题：
1、代码重复的问题太多
这个问题很容易解决，只需要把判断预期结果和实际结果的逻辑提取到某个函数中即可。从整个代码来看，有两种类型的结果的函数：
（1）返回布尔型
（2）返回整数
因此，需要两个类型的判断预期结果和实际结果是否相符的函数：
1. /*
2. * 判断是否取值为真
3. */
4. void assertTrue(char *msg, bool actual)
5. {
6. if(actual)
7. {
8. printf(".");
9. }
10. else
11. {
12. printf("F");
13. }
14. }
15.
16. /*
17. * 判断预期结果和实际结果是否相符
18. */
19. void assertEquals(char *msg, int expect, int actual)
20. {
21. if(expect == actual)
22. {
23. printf(".");
24. }
25. else
26. {
27. printf("F");
28. }
29. }
小知识：XUnit系列的框架的习惯使用assert*的命名来定义判断函数，对于通过的测试习惯打印一个“.”号，而对于失败的测试习惯打印一个“F”。
2、测试结果需要人工去检查
对于测试结果不要使用printf方式打印被测试函数的返回结果值就可以避免这个问题。
3、对测试的总体信息也无从得知
除了问题1的解决办法里使用“.”表示测试通过和“F”表示测试失败可以提高对测试结果的信息的直观性之外，做单元测试的人还希望能够得到以下的信息：
（1）执行的测试用例总数、通过的数量和失败的数量
（2）测试执行的时间
（3）如果测试用例执行失败了，希望知道是哪个测试用例失败，从而去分析失败的原因。
白盒测试实例之九——构建自己的单元测试框架（下）
完整的源代码如下：
1、UnitTest.h
1. /*
2. * Copyright (c) 2008, 胡添发
3. *
4. * 简单的单元测试框架
5. *
6. */
7.
8. #include<stdio.h>
9. #include<string.h>
10. #include<time.h>
11. #include<stdlib.h>
12.
13. /*
14. * VC中没有sleep函数，自己写一个
15. * wait单位是毫秒
16. */
17. extern void sleep(clock_t wait);
18.
19.
20. /*
21. * 判断是否取值为真
22. */
23. void assertTrue(char *msg, bool actual);
24.
25. /*
26. * 判断预期结果和实际结果是否相符
27. */
28. void assertEquals(char *msg, int expect, int actual);
29.
30. /*
31. * 初始化测试，开始计时
32. */
33. void init();
34.
35. /*
36. * 结束测试，结束计时，打印报告
37. */
38. void end();
白盒测试实例之十——集成测试的概念
测一、桩模块和驱动模块（以C语言为例）：
很多人对桩模块和驱动模块的概念会搞不清楚，下面先介绍这两个概念：
模块结构实例图：
假设现在项目组把任务分给了7个人，每个人负责实现一个模块。你负责的是B模块，你很优秀，第一个完成了编码工作，现在需要开展单元测试工作，先分析结构图：
1、由于B模块不是最顶层模块，所以它一定不包含main函数（A模块包含main函数），也就不能独立运行。
2、B模块调用了D模块和E模块，而目前D模块和E模块都还没有开发好，那么想让B模块通过编译器的编译也是不可能的。
那么怎样才能测试B模块呢？需要做：
1、写两个模块Sd和Se分别代替D模块和E模块（函数名、返回值、传递的参数相同），这样B模块就可以通过编译了。Sd模块和Se模块就是桩模块。
2、写一个模块Da用来代替A模块，里面包含main函数，可以在main函数中调用B模块，让B模块运行起来。Da模块就是驱动模块。
知识点：
桩模块的使命除了使得程序能够编译通过之外，还需要模拟返回被代替的模块的各种可能返回值（什么时候返回什么值需要根据测试用例的情况来决定）。
驱动模块的使命就是根据测试用例的设计去调用被测试模块，并且判断被测试模块的返回值是否与测试用例的预期结果相符。
二、集成测试策略：
1、 非增式集成测试
各个单元模块经过单元测试之后，一次性组装成完整的系统。
优点：集成过程很简单。
缺点：出现集成问题时，查找问题比较麻烦，而且测试容易遗漏。
范例：
2、 增式集成测试
（1）自顶向下
A、 纵向优先
从最顶层开始测试，需要写桩模块。测试的顺序：从跟节点开始，每次顺着某枝干到该枝干的叶子节点添加一个节点到已测试好的子系统中，接着再加入另一枝干的节点，直到所有节点集成到系统中。
B、 横向优先
跟纵向优先的区别在于：每次并不是顺着枝干走到叶子，而是逐一加入它的直属子节点。
纵向优先的范例：
（2）自底向上
每次从叶子节点开始测试，测试过的节点摘掉，然后把树上的叶子节点摘下来加入到已经测试好的子系统之中。优点：不需要写桩模块，但需要写驱动模块。
范例：
相关阅读：
-
为何进行白盒测试 从“清洗面包机”讲起（转）
2009-03-02 11:17:36
-
如何编写单元测试用例（白盒测试）（转）
2009-03-02 11:14:52
如何编写单元测试用例（白盒测试）
前段时间公司进行有关测试的培训，集成测试，性能测试，压力测试说了很多。由于本人还处于Coder阶段，只是对单元测试有了些了解。写下来怕以后自己忘记了。都是些自己的看法，不一定准确，欢迎高手指教。
一、 单元测试的概念
单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。
测试的覆盖种类
1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。
2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。
3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。
4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。
5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。
6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。
二、开始测试前的准备
在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。穷举测试是不可能的。 所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。
三、开始测试
基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。
函数说明 ：当i_flag=0；返回 i_count + 100
否则当 i_flag=1；返回 i_ temp + 10
否则 返回 i_temp + 20
输入参数：int i_count ， int i_flag
输出参数： int i_temp;
代码：
1 int Test(int i_count, int i_flag)
2 {
3 int i_temp = 0;
4 while (i_count>0)
5 {
6 if (0 == i_flag)
7 {
8 i_temp = i_count + 100;
9 break;
10 }
11 else
12 {
13 if (1 == i_flag)
14 {
15 i_temp = i_temp + 10;
16 }
17 else
18 {
19 i_temp = i_temp + 20;
20 }
21 }
22 i_count--;
23 }
24 return i_temp;
25 }
1.画出程序控制流程图
图例：
事例程序流程图：
圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13,8......作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。让我们看程序中；第2行，第3行是按顺序执行下来的。直到第4行才出现了循环操作。而2，3行没有什么判断，选择等分支操作，所以我们把2，3，4全部合并成一个结点。其他的也是照这个规则合并，然后就有了上面的流程图。2.计算圈复杂度
有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。
这里有有了一个新概念——圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少执行一次的测试数量的上界。
公式圈复杂度V（G）=E-N+2，E是流图中边的数量，N是流图中结点的数量。
公式圈复杂度V（G）=P+1 ，P是流图G中判定结点的数量。
通俗的说圈负责度就是判断单元是不是复杂，是不是好测试的标准。一般来说如果圈复杂度如果大于20就表示这个单元的可测试性不好，太复杂（也许有人觉得无所谓，但是如果你们公司实行了CMMI5的话，对这个是有规定的）。
从图中我们可以看到，
V（G）=10条边-8结点+2=4
V（G）=3个判定结点+1=4
上图的圈复杂图是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。
3.导出程序基本路径。
现在我们知道了起码要写4个测试用例，但是怎么设计这4个测试用例？
导出程序基本路径，根据程序基本路径设计测试用例子。
程序基本路径：基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历，但是每条路径至少应该包含一条已定义路径不曾用到的边。（看起来不好理解，让我们看例子）。
让我们看上面的流程图：从结点4到24有几条路径呢？
1 B（4，24）
2 C，E，J（4，6，8，24）
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
还有吗？？
5 C，D，C，I，A，C，E，J（4，6，13，19，22，4，6，8，24）算吗？
不算，为什么？因为上面的4条路径已经包括了所有的边。第5条路径已经不包含没有用过的边了。所有的路径都遍历过了。
好了，现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。
1 B（4，24）
输入数据：i_count=0，或者是i_count<0的某一个值。
预期结果：i_temp=0.
2 C，E，J（4，6，8，24）
输入数据：i_count =1; i_flag=0
预期结果：i_temp=101.
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
输入数据：i_count =1; i_flag=1
预期结果：i_temp=10.
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
输入数据：i_count =1; i_flag=2
预期结果：i_temp=22.
这里的输入数据是由路径和程序推论出来的。而要注意的是预期结果是从函数说明中导出，不能根据程序结构中导出。
为什么这么说？
让我们看程序中的第3行。
int i_temp=0;假如开发人员一不小心写错了，变成了int i_temp=1;根据程序导出的预期结果就会是一个错误的值，但是单元测试不出来问题。
那单元测试就失去了意义。
有人也许会问这么简单的函数就有4个测试用例，如果还复杂一些的怎么办？上面的测试用例还可以简化吗？答案是可以。
我们来看 路径 1 B（4，24）和 4 C，D，G，I，A，B（4，6，13，19，22，4，24），路径1是路径4的真子集， 所以1是可以不必要的。上图的圈复杂度是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。所以说圈复杂度标示是最多的测试用例个数，不是一定要4个测试用例才可以。不过有一点要申明的是测试用例越简化代表你的测试越少，这样程序的安全性就越低了。
四、完成测试
接下来根据测试用例使用工具测试NUNIT，VS2005都可以。
接下来根据测试结果编写测试报告，测试人，时间，结果，用例，是否通过，格式网上一大把，每个公司的格式也不一样就不说了。
-
白盒测试（转）
2009-03-02 11:09:59
-
黑盒测试与白盒测试（转）
2009-03-02 11:03:38
-
黑盒测试比白盒测试更难，技术要求更高？（转）
2009-03-02 11:01:02
-
白盒测试方法（pdf文档）
2009-03-02 10:56:12
-
“白盒”静动测试两齐全（转）
2009-03-02 10:53:58
-
如何挑选白盒测试工具（转）
2009-03-02 10:51:44
如何挑选白盒测试工具
白盒测试目前主要用在具有高可靠性要求的软件领域，例如：军工软件、航天航空软件、
工业控制软件等等。白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、
嵌入式软件的测试、测试的可视化等。对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析
与语法分析、静态错误分析、动态检测等。但是对于不同的开发语言，测试工具实现的方式和
内容差别是较大的。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、
Java、Visual J＋+等。代码的覆盖深度：从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖
标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆
盖。·语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆
盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执
行一次。语句覆盖是很弱的逻辑覆盖。·判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。判定覆盖的
含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，
或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为
分支覆盖。·条件覆盖 在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻
底地实现逻辑覆盖，可以采用条件覆盖（Condition Coverage）的标准。条件覆盖的含义是：
构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。·多条件覆盖 多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得
每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足
判定覆盖、条件覆盖和条件判定组合覆盖的。·修正条件判定覆盖 修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制
定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这
个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两
个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定
到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、
or）连接的布尔条件，每个条件对于判定的结果值是独立的。不同的测试工具对于代码的覆盖能力也是不同的，通常能够支持修正条件判定覆盖的测试
工具价格是极其昂贵的。嵌入式软件的测试：对于嵌入式软件的测试，我们还需要一方面进一步考虑测试工具对于
嵌入式操作系统的支持能力，例如DOS、Vxworks、Neculeus、Linux和Windows CE等；另一方
面还需要考虑测试工具对于硬件平台的支持能力，包括是否支持所有64/32/16位CPU 和 MCU，
是否可以支持 PCI/VME/CPCI 总线。测试的可视化：白盒测试是工作量巨大并且枯燥的工作，可视化的设计对于测试来说是十
分重要的。在选购白盒测试工具时，应当考虑该款测试工具的可视化是否良好，例如：测试过
程中是否可以显示覆盖率的函数分布图和上升趋势图，是否使用不同的颜色区分已执行和未执
行的代码段显示分配内存情况实时图表等，这些对于测试效率和测试质量的提高是具有很大的
作用的。 （B6）用户观点
为了更直接地了解IT测试的应用情况，记者在2005年IT测试技术研讨会的现场采访了9名
与会人员，而他们对IT测试的看法可以分为三类。第一类：有想法，要多了解信息
这种想法在很多中小企业中存在，他们已经意识到了IT测试的重要性，但是限于各种条
件，现在还处于收集信息的阶段。部分用户代表希望有价格便宜的第三方测试机构来帮助自己
进行测试。北京青云航空仪表公司 黄迪生
我们目前比较需要网络测试和软件测试的设备。但因为此前对测试技术和产品不太熟悉，
目前更多地是想了解一下最新的技术和产品。我们希望厂商能有一些具体的演示和应用案例。北京京能热点股份有限公司信息中心 夏骥
在此前的IT项目中，我们还没有使用过专门的测试工具软件和设备。但我们对新的测试工
具软件和设备比较感兴趣，目前我们正在做网络改造，所以想先了解一下这方面的产品和技
术。某小型软件企业创始人
公司目前的产品主要面向交通行业，例如公交系统的控制方面。公司自己成立了专门的软
件测试部门，以对产品进行测试。目前，还没有把产品进行外包测试的想法。北京图易得系统工程技术有限公司总经理 叶涛
我们公司所开发的软件产品主要面向畜牧业、农业等行业的信息化建设。目前，由于应用
到项目的程序并不是特别庞大，所以相应的软件产品的规模也有一定的限度，在这种情况下软
件测试主要还是由自己进行。公司组建了专门的测试部以进行测试。对于软件产品的测试，我们也非常重视，只不过由于规模问题，我们还没有达到更进一步
的测试需求。中国五矿化工进出口商会信息部副主任 刘京娴
我们作为直接的产品使用者考虑，成本是一个很重要的因素。实际我们最近希望能够进行
网络测试，因为我们现在常常遇到网络故障，但又找不到原因。如果以后有专业的第三方测试
提供价格合理的测试项目，我们会考虑选用。第二类：使用过工具，但是价格等因素限制了进一步使用
这类用户基本都是一些专业的IT公司，他们对测试工具有明显的渴求，但是现在的条件限
制了应用。中科辅龙计算机技术有限公司技术管理部经理 林志丹
我们用过一些网络测试和软件测试的工具软件，有一些感觉。网络测试和软件测试都是工
具软件，它们面临同样的问题，就是专业性强，用户少，而厂商为了盈利就不得不将价格定得
较高；其次是这类软件大多比较难以上手，需要专门的培训，但这样的培训却往往不是免费
的。例如Rational相信就不是人人都用得起，用得好。业界是否可以采用一些新思路，将这类
工具软件采用服务或者租借的形式向用户提供呢？长城软件系统集成公司许哲源
我们平时所做的测试基本上都是功能测试。20个人以下的可以从网上免费下载。
在开发成本可以承受的情况下，项目团队当然愿意选择性价比高的测试工具。
第三类：对测试非常了解，同时经常使用IT测试工具
这些用户每年都会投入一定的费用用于产品运维和新产品购买，他们对于IT测试的认识也
是最为深入的。点击科技产品测试部部长 陶锋
让测试工具发挥作用的关键在于人，这里一个团队的领导至关重要，而项目中每个人的水
平也决定了测试工具能否真正发挥作用。例如IBM的测试工具，要想使用起来，要求每个成员
至少有两年的使用经验。这对人员专业技能的要求很高。在测试阶段发现错误可以让这个软件
更加健壮。选择第三方咨询机构，可以避免客户对开发方的测试报告产生质疑。从某种程度上讲，第
三方咨询的介入保证了软件开发能够公正客观顺利地进行。理想的状态是测试贯穿整个项目开
发过程.只有这样才能真正让测试成为提高软件质量的利器。总之，工欲善其事，必先利其器。好的开发工具可以让软件开发事半功倍，好的测试工具
可以起到同样的效果。北京信息安全测评中心测试实验室主任助理 刘海峰
我们作为第三方测试机构，主要提供信息安全方面的测试，平时主要使用的都是网络测试
工具，软件测试接触不太多。我们每年都会有专门的费用用于工具的运维，同时也会购买一些
需要的新产品。我们单位2000年成立，主要面向北京市的党政机关服务，去年正式进入市场，在这几年明
显能够感觉到市场在慢慢增长。同时由于政府的法律法规以及一些项目实施流程，让大家意识
到测试的重要性，逐渐为测试拨出专项的费用。
-
白盒测试－《软件测试艺术》读书笔记(17)(转)
2009-03-02 10:49:23
-
白盒测试中的六种覆盖方法（转）
2009-03-02 10:39:52
白盒测试中的六种覆盖方法
摘要：白盒测试作为测试人员常用的一种测试方法，越来越受到测试工程师的重视。白盒测试并不是简单的按照代码设计用例，而是需要根据不同的测试需求，结合不同的测试对象，使用适合的方法进行测试。因为对于不同复杂度的代码逻辑，可以衍生出许多种执行路径，只有适当的测试方法，才能帮助我们从代码的迷雾森林中找到正确的方向。本文介绍六种白盒子测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
白盒测试的概述
由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行, 而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的，因此我们要进行白盒测试。
白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。
白盒的测试用例需要做到：
·保证一个模块中的所有独立路径至少 被使用一次
·对所有逻辑值均需测试 true 和 false
·在上下边界及可操作范围内运行所有循环
·检查内部数据结构以确保其有效性白盒测试的目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。
白盒测试的实施步骤：
1.测试计划阶段：根据需求说明书，制定测试进度。
2.测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。
3.测试执行阶段：输入测试用例，得到测试结果。
4.测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。白盒测试的方法：总体上分为静态方法和动态方法两大类。
静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。
白盒测试的优缺点
1. 优点
·迫使测试人员去仔细思考软件的实现
·可以检测代码中的每条分支和路径
·揭示隐藏在代码中的错误
·对代码的测试比较彻底
·最优化2. 缺点
·昂贵
·无法检测代码中遗漏的路径和数据敏感性错误
·不验证规格的正确性六种覆盖方法
首先为了下文的举例描述方便，这里先给出一张程序流程图。（本文以1995年软件设计师考试的一道考试题目为例，图中红色字母代表程序执行路径）。
1、语句覆盖
1）主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
2）用例设计：（如果此时将A路径上的语句1—〉T去掉，那么用例如下）
X Y 路径 1 50 50 OBDE 2 90 70 OBCE 3）优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
4）缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。在本例中去掉了语句1—〉T去掉，那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支，那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行，而往往这种错误会经常出现。再如，在Do-While结构中，语句覆盖执行其中某一个条件分支。那么显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。
2、判定覆盖
1）主要特点：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
2）用例设计：
X Y 路径 1 90 90 OAE 2 50 50 OBDE 3 90 70 OBCE 3）优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
4）缺点：往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
3、条件覆盖
1）主要特点：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
2）用例设计：
X Y 路径 1 90 70 OBC 2 40 OBD 3）优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。
4）缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
4、判定/条件覆盖
1）主要特点：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
2）用例设计：
X Y 路径 1 90 90 OAE 2 50 50 OBDE 3 90 70 OBCE 4 70 90 OBCE 3）优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。
4）缺点：判定/条件覆盖准则的缺点是未考虑条件的组合情况。
5、组合覆盖
1）主要特点：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
2）用例设计：
X Y 路径 1 90 90 OAE 2 90 70 OBCE 3 90 30 OBDE 4 70 90 OBCE 5 30 90 OBDE 6 70 70 OBDE 7 50 50 OBDE 3）优点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。
4）缺点：线性地增加了测试用例的数量。
6、路径覆盖
1）主要特点：设计足够的测试用例，覆盖程序中所有可能的路径。
2）用例设计：
X Y 路径 1 90 90 OAE 2 50 50 OBDE 3 90 70 OBCE 4 70 90 OBCE 3）优点：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。
4）缺点：由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如：
If （!A）B++；
If （!A）D--；这两个语句实际只包括了2条执行路径，即A为真或假时候对B和D的处理，真或假不可能都存在，而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。
总结
白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径，即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。
那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。
-
白盒测试及如何挑选白盒测试工具(转)
2009-03-02 10:25:18
