白盒测试方法文档格式.docx
《白盒测试方法文档格式.docx》由会员分享，可在线阅读，更多相关《白盒测试方法文档格式.docx（17页珍藏版）》请在冰点文库上搜索。
代码检查法主要检查代码和程序设计的一致性，代码结构的合理性，代码编写的标准性、可读性，代码逻辑表达的正确性等方面。
检查方式包括桌面检查、代码走查、代码审查三种方式。
目的：
检查程序是不是按照某种标准或规范编写的。
目标：
发现程序缺陷，改进软件的质量。
需要的文档：
程序设计文档、程序的源代码清单、编码规范、代码缺陷检查表等。
在进行代码检查时，代码缺陷检查表就是测试用例，检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误。
优缺点：
代码检查法能快速找到缺陷，一旦发现错误，能够在代码中对其进行精确定位，从而降低了错误修正的成本。
代码检查看到的是问题本身而非问题的征兆。
但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。
2.2代码审查和走查
两种方法的形成、流程一样，规程、方法不一样。
具体来说：
代码审查和走查都是以小组为单位阅读代码，它是一系列规程和错误检查方法的集合。
审查或走查小组通常由不需要对程序细节很了解的协调人员、程序的编码人员、程序的设计人员、测试专家四人组成。
都是以会议的形式进行。
会议理想时间为90-120分钟之间，按照每小时阅读150行代码的速度进行。
对大型软件应安排多个会议同时进行，每个会议处理一个或几个模块或子程序。
代码审查规程和方法：
在代码审查会议上，程序作者逐条语句讲述程序的逻辑结构，参与人根据“代码缺陷检查表”分析程序，检查内容包括编码标准规范和错误列表。
编码规范是指团队根据自己的经验和风格进行设置的一些规范。
错误列表一般是代码潜在的bug，由于某种代码写法虽然没有语法错误，但是可能存在错误，比如会导致线程死锁，这些都是错误列表应该检查的。
程序员之间可以隔一定的时间抽取代码进行审查。
结束会议后，把这些经验汇成列表，作为下次代码审查的依据，并针对错误修正进行跟踪。
输出文档是“代码检查记录表”，此表主要内容日期、住持人、参与人员、范围、发现的问题、问题处理、跟踪检查等。
代码走查规程和方法：
在代码走查会议上，参与者参考“设计规格书”使用计算机来执行代码。
测试人员准备一些简单的测试用例，它的作用是提供启动代码走查和质疑程序员逻辑思路及其他设想的手段。
在会议期间，把测试数据沿程序的逻辑结构走一遍，程序的状态记录在纸或白板上以供监视。
在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。
2.3桌面检查
桌面检查是一种传统的检查方法，由程序员检查自己编写的程序。
程序员在程序通过编译之后，对源程序代码进行分析、检验，并补充相关文档，由于程序员熟悉自己的程序及其程序设计风格，桌面检查由程序员自己进行可以节省时间，但应避免主观片面性。
桌面检查的效果逊色于代码检查和走查，但桌面检查胜过没有检查。
3、逻辑覆盖测试
3.1简介
测试覆盖率：
用于确定测试所执行到的覆盖项的百分比。
其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。
测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。
但覆盖率不是目标，只是一种手段。
测试覆盖率包括功能点覆盖率和结构覆盖率，功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。
结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等。
逻辑覆盖法：
以程序内部的逻辑结构为基础的用例设计方法，它通过对程序逻辑结构的遍历实现程序的覆盖。
根据覆盖目标的不同，逻辑覆盖分为语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定-条件覆盖（分支-条件覆盖）、条件组合覆盖、路径覆盖六种覆盖测试方法。
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定/分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定-条件覆盖同时满足判定覆盖和条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
它们发现错误的能力呈由弱至强的变化。
3.2举例说明
以下举例说明六种覆盖测试方法：
51Testing软件测试网9Vb（g!
A,jj^1~q5E:
pgP3v{f9s&
m-zW612044如源代码（C语言）：
intlogicExample（intx,inty）
{
intmagic=0;
if（x>
0&
&
y>
0）
magic=x+y+10;
//语句块1
}
else
{
magic=x+y-10;
//语句块2
}
if（magic<
0）
magic=0;
//语句块3
returnmagic;
//语句块4
一般逻辑覆盖测试不会直接根据源代码，而是根据流程图来设计测试用例，在没有设计文档时，要根据源代码画出流程图：
3.2.1语句覆盖
特点：
6ZSb5Y"
|CU+M&
d6}Nw1K{&
[612044语句覆盖要求设计足够多的测试用例，运行被测程序，使得程序中每条语句至少被执行一次。
在本例中，可执行语句是指语句块1到语句块4中的语句。
51Testing软件测试网~2sNQc/tL
D/biw:
z1e612044用例设计：
数据
语句
{x=3,y=3}
1、4
{x=-3,y=0}
2、3、4
通过这两个测试用例即达到语句覆盖的标准（测试用例组不是唯一的）。
51Testing软件测试网5c/`6w4A,I优点：
可以很直观地从流程图得到测试用例，可以测试所有的执行语句。
51Testing软件测试网eT!
_wC'
]u（iD
51Testing软件测试网'
Fh7}9bL|8JK缺点：
语句覆盖不能准确的判断运算中的逻辑关系错误。
假设第一个判断语句if（x>
0）中的“&
”被错误地写成了“||”，即if（x>
0||y>
0），使用上面设计出来的一组测试用例来进行测试，仍然可以达到100%的语句覆盖。
在六种逻辑覆盖标准中，语句覆盖标准最弱的。
51Testing软件测试网）|!
`&
A1guipM8c6J
3.2.2判定覆盖
M&
kFn#R]1q612044特点：
判定覆盖（分支覆盖）要求设计足够多的测试用例，运行被测程序，使得程序中的每个判断的“真”和“假”都至少被执行一次。
即：
程序中的每个分支至少执行一次。
在本例中共有两个判断if（x>
0）（记为P1）和if（magic<
0）（记为P2）。
+U&
g;
NrF|1|kS612044用例设计：
P1
P2
T
F
F
两个判断的取真、假分支都已经被执行过，所以满足了判断覆盖的标准。
f]umhe\McG[612044
51Testing软件测试网）Vu;
AGE1Hfc优点：
由于可执行语句要不就在判定的真分支，要不就在假分支上，判定覆盖比语句覆盖要多几乎一倍的测试路径，所以，只要满足了判定覆盖标准就一定满足语句覆盖标准。
因此，判定覆盖比语句覆盖强。
51Testing软件测试网$QrUn#X缺点：
判定覆盖会忽略条件中取或（or）的情况。
”被程序员错误地写成了“||”，使用上面设计出来的一组测试用例，仍然可以达到100%的判定覆盖，所以判定覆盖也无法发现上述的逻辑错误。
51Testing软件测试网Aj|!
L-o,^
h*fs'
p
3.2.3条件覆盖
4P*}9LsqJ`~61204451Testing软件测试网hn2U!
W（p&
`z特点：
条件覆盖要求设计足够多的测试用例，运行被测程序，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
在本例中有两个判断if（x>
0）（记为P2），共计三个条件x>
0（记为C1）、y>
0（记为C2）和magic<
0（记为C3）。
/OD+Ya.Jrb612044\P-}）M.ttJ612044用例设计：
C1
C2
C3
三个条件的各种可能取值都满足了一次，达到了100%条件覆盖的标准，同时也到达了100%判定覆盖的标准。
但并不能保证达到100%条件覆盖标准的测试用例（组）都能到达100%的判定覆盖标准，看下面的例子：
数据
{x=3,y=0}
{x=-3,y=15}
既然条件覆盖标准不能100%达到判定覆盖的标准，也就不一定能够达到100%的语句覆盖标准了。
/X&
_?
）i7oZ612044
6T,P5}^xt#z4I$D612044优点：
显然条件覆盖比判定覆盖，增加了对符合判定情况的测试。
51Testing软件测试网OKvYW5agPI^
51Testing软件测试网Q0T$\#@El[缺点：
要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。
3.3.4判定-条件覆盖
ns}6N%bDV&
fYR612044特点：
设计足够多的测试用例，运行被测程序，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值也至少被满足一次。
即同时满足100%判定覆盖和100%条件覆盖的标准。
用例设计：
所有条件的可能取值都满足了一次，而且所有的判断本身的判定结果也都满足了一次。
51Testing软件测试网7M%?
?
7v0Y7Q0D优点：
达到100%判定-条件覆盖标准一定能够达到100%条件覆盖、100%判定覆盖和100%语句覆盖。
判定-条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。
51Testing软件测试网W+z4U-B?
N
51Testing软件测试网1g[c*JTXZ缺点：
未考虑条件的组合情况。
51Testing软件测试网A0\6?
8atso-~6@
3.3.5条件组合覆盖
Hem{Nnf6120447^P!
i$pxR~
Z$bHJ612044特点：
要求设计足够多的测试用例，运行被测程序，使得被测试程序中每个判定中条件结果的所有可能组合至少执行一次。
注意：
1）条件组合只针对同一个判断语句内存在多个条件的情况，让这些条件的取值进行笛卡尔乘积组合。
2）不同的判断语句内的条件取值之间无需组合。
3）对于单条件的判断语句，只需要满足自己的所有取值即可。
C1和C2处于同一判断语句中，它们的所有取值的组合都被满足了一次。
C|,[
qIpNf'
c612044优点：
多重条件覆盖准则满足判定覆盖、条件覆盖、判定-条件覆盖准则。
5m&
N;
D.?
E-g*N612044缺点：
线性地增加了测试用例的数量。
但上面的例子中，只走了两条路径a-c-e-f和a-b-d-f，而本例的程序存在三条路径。
所以条件组合覆盖不能保证所以的路径被执行。
3.3.6路径覆盖
m2x$~sK/piz5I:
_612044特点：
设计足够的测试用例，运行被测程序，覆盖程序中所有可能的路径。
51Testing软件测试网,g|`.H/|cO4SC
51Testing软件测试网{\a（`J用例设计：
:
^K（d,_-`\a|
W7}!
J6120
路径
这条路径不可能实现
a-b-d-f
{x=-3,y=3}
a-c-d-f
a-b-e-f
a-c-e-f
所有可能的路径都满足过一次。
51Testing软件测试网7`lj#Z8`优点：
这种测试方法可以对程序进行彻底的测试，比前面五种覆盖面都广。
100%满足路径覆盖，一定能100%满足判定覆盖标准（因为路径就是从判断的某条分支走的）。
51Testing软件测试网/U）A0]4h!
[{"
D
9MqYOJdMFcx3~612044缺点：
100%满足路径覆盖，但并不一定能100%满足条件覆盖（C2只取到了真），也就不能满足100%条件组合覆盖。
经过分析，它们之间的关系可以用下图表示（路径覆盖在该图无法表示）：
从上例可知，单独采用任何一种逻辑覆盖方法都不能完全覆盖所有的测试用例，任何一个高效的测试用例，都是针对具体测试场景的。
逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。
所以在实际测试用例设计中，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。
要根据不同需要和不同测试用例设计特征，将不同的设计方法组合起来，交叉使用，以实现最佳的测试用例输出。
4、基本路径测试法
4.1简介
基本路径测试法包括4个步骤，在程序控制流图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
设计出的测试用例要保证在测试中程序的每个可执行路径至少执行一次。
以下举例具体说明这4个步骤：
4.2举例说明
4.2.1画出控制流图
可将流程图映射到一个相应的流图。
程序的控制流图是对程序流程图简化得到的，它可以更加突出的描述程序控制流的结构。
控制流图只有二种图形符号，
圆称为流图的节点，代表一个或多个语句，流程图中一个处理方框序列和一个菱形决测框可被映射为一个节点。
箭头称为边或连接，代表控制流，类似于流程图中的箭头。
一条边必须终止于一个节点，即使该节点并不代表任何语句。
由边和节点限定的范围称为区域，计算区域时应包括图外部的范围。
如图所示：
如果判断中的条件表达式是由一个或多个逻辑运算符（or,and）连接的复合条件表达式时，要为每个条件创建一个独立的节点，包含条件的节点被称为判定节点，一个判定节点发出两条或多条边。
例如：
1）ifaorb
2）x
3）else
4）y
对应的逻辑为：
4.2.2计算圈复杂度
通过对控制流图的分析和判断来计算环形复杂度。
圈复杂度也成为环形复杂度、程序环境复杂度，是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有路径至少执行一次的测试数量的上界。
有以下三种方法计算圈复杂度：
1）流图中区域的数量对应于环型的复杂性。
2）给定流图G的圈复杂度V（G），定义为V（G）=E-N+2，E是流图中边的数量，N是流图中节点的数量。
3）给定流图G的圈复杂度V（G），定义为V（G）=P+1，P是流图G中判定节点的数量。
4.2.3导出独立路径
从程序的环路复杂性可导出程序的独立路径条数。
一条独立路径是指，和其他的独立路径相比，程序中至少引进一个新的处理语句集合或一个新判断条件的程序通路。
即独立路径必须至少包含一条在定义路径之前不曾用到的边。
如果只是已有路径的简单合并，并未包含任何新边，则不是独立路径。
此例可得出四个独立的路径。
V（G）值正好等于该程序的独立路径的条数。
路径1：
4-14
路径2：
4-6-7-14
路径3：
4-6-8-10-13-4-14
路径4：
4-6-8-11-13-4-14
4.2.4设计测试用例
根据独立路径，来设计输入数据，使程序分别执行到上面四条路径。
为了确保基本路径集中的每一条路径的执行，根据判断节点给出的条件，选择适当的数据以保证某一条路径被测试到，满足上面例子基本路径集的测试用例是：
5、其他方法
1）静态结构分析：
主要是以图形的方式表现程序的内部结构。
测试者通过使用测试工具分析程序源代码的系统结构、数据结构、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、函数内部控制流图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表（包括控制流分析、数据流分析、接口分析、表达式分析），检查软件是否存在缺陷或错误。
2）静态质量度量法：
根据ISO/IEC9126质量模型作为基础，我们可以构造质量度量模型，用于评估软件的各个方面。
该模型从上到下分为3层：
质量因素、分类标准和度量规则。
度量规则：
度量规则使用了代码行数、注释频度等参数度量软件的各种行为属性，度量规则参数表。
分类标准“软件的可维护性采用以下四个分类标准来评估：
可分析性、可修改性、稳定性、可测性。
每个分类标准由一系列度量规则组成，各个规则分配一个权重，由规则的取值与权重值计算出每个分类标准的取值。
质量因素的取值与分类标准的计算方式类似：
依据各分类标准取值组合权重方法计算。
3）循环覆盖测试法：
目的就是检查循环结构的有效性。
通常，循环可以划分为简单循环、嵌套循环、串接循环和非结构循环4类。
三、总结
在实践中发现，静态白盒测试和基于计算机的动态测试是互补的，缺少任何一种，都会降低错误检查的效率。
项目组可根据项目的实际情况，来决定哪种白盒测试方法更适合。
升级会员 