Ch14测试用例的设计STMT
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
由于深入到程序编码，通常 开发人员协助测试人员书写 白盒测试用例
Zhu.Kerrygmail
基本路径测试
Goal: exercise each independent path at least once.
1. Using the code, draw a corresponding flow graph (First drawing the activity diagram
4. Prepare test cases that force the execution of each path in the basis set.
Example
Procedure: process records
1. Do While records remain
2.
Read record;
for an expression with n variables, 2n tests are required
条件测试 - Example
Zhu.Kerrygmail
start
N<0
yes
no
N := -N;
i:=i+1; result:=result+i;
(i<N) and
yes
(result<=maxint)
11
ELSE OUTPUT ( “too large” )
12
END.
Zhu.Kerrygmail
流程图复杂度－例子
Zhu.Kerrygmail
Region 4
6 7 Region 3 8
1
Region 1
2,3
4,5
Region 2
9 10
V(G)=4
11
Zhu.Kerrygmail
确定线性独立的路径集合
• Independent path ® any path that introduces at least one
11. End Do
End
Example (continued)
1
2
3
6
8
7
9
11
10
4 5
V(G) = 4
Zhu.Kerrygmail
基本路径测试:流程图
1
2,3
6
4,5
8
7
9 10
11
流程图复杂度确定
Zhu.Kerrygmail
Cyclomatic complexity: a quantitative measure of the logical
白盒测试用例设计方法
白盒测试用例的设计方法
逻辑覆盖：以程序的内部逻辑结构为基础，分为语句覆 盖、判定覆盖、判定-条件覆盖、条件组合覆盖等
基本路径测试：在程序控制流程的基础上，分析控制构 造的环路复杂性，导出基本可执行路径集合，从而设计 测试用例。
白盒测试用例注意事项
由于测试路径可能非常多， 由于时间和资源问题，选出 足够多的路径测试
Path2: 1-2-3-6-89-10-1-11
Path3: 1-2-3-4-510-1-11
Path4: 1-11
Zhu.Kerrygmail
测试用例覆盖集合中每条路径
• you do not need an activity diagram, but the picture will help
2020
Ch14测试用例的设计STM
Zhu.Kerrygmail
为什么需要测试用例（2）
功能模块的测试用例的通用化和复用化则会使软件测试易于开展， 并随着测试用例的不断细化其效率也不断攀升；
根据测试用例的操作步骤和执行结果，为分析软件缺陷和程序模 块质量提供依据；可以方便地书写软件测试缺陷报告；
new set of processing statements or a new condition
• Basis set ® set of independent paths through the code • Test cases derived from a basis set are guaranteed to
no
yesresult<=maxint no
output(result);
output(too large);
exit
But ( i = result = 0 ) :
maxint N i<N result<=maxint
-1 1 true false
1 0 false true gives condition coverage for all conditions
C TRUE, FALSE
Domain testing
True AND True
T. And F., F. And T., F. And F.
a>b TRUE, FALSE c<d TRUE, FALSE
for an expression E1 rel-op E2, test for E1 ≧ ≦ = < > ≠ E2
测试用例包含期望的正确的结果 待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰、格式一致、分类组织
测试用例的组成元素与范例
Zhu.Kerrygmail
测试用例编号ID 测试用例标题 测试的模块
• 测试输入条件 • 期望的输出结果 • 其它说明
Zhu.Kerrygmail
But it does not preserve decision coverage
always take care that condition coverage preserves decision coverage : decision / condition coverage
Zhu.Kerrygmail
when you trace component paths
• count each logical test—compound tests count as the number
of Boolean operators + 1 (i.e., count each simple predicate)
3
IF N < 0
4
THEN N := - N ;
5
WHILE ( i < N ) AND ( result <= maxint )
6
DO i := i + 1 ;
7
result := result &#esult <= maxint
10
THEN OUTPUT ( result )
可以根据测试用例的执行等级，实施不同级别的测试； 便于大型软件测试项目外包测试指导基础；
Zhu.Kerrygmail
良好测试用例的特征
可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定
3.
If record field 1 = 0 Then
4.
store in buffer;
5.
increment counter;
6.
Else If record field 2 = 0 Then
7.
reset counter;
8.
Else store in file;
9.
End If
10. End If
errors to test for include (incorrect/missing/extra): Boolean operator – relational operator Boolean variable – arithmetic expression Boolean parenthesis
• basis path testing should be applied to all components, if
possible, and to critical components always
Basis path testing does not test all possible
combinations of all paths through the code; it just tests every path at least once.
Zhu.Kerrygmail
条件测试
Goal: further exercises the true and false value of each simple
logical condition in a component.
Logical conditions Simple condition: (a rel-op b) where rel-op={<, ≤, =, ≠, ≥, >} (may be negated with NOT), e.g., a≤b; NOT(a≤b) Compound condition: two or more simple conditions connected with AND, OR, e.g., (a>b) AND (c<d) Relational expression: (E1 rel-op E2) where E1 and E2 are arithmetic expressions, e.g., ((a*b+c)>(a+b+c))
execute every statement at least one time during testing
• Basis set is not unique
Basis path test example
Zhu.Kerrygmail
1
2
3
6
4
7
8
9
5
11
10
Path1: 1-2-3-6-7-910-1-11
分支测试
Branch Coverage
Execute the enough test cases，attempting to cover all the paths in the software:
- Get both “True” and “False” - Go through each branch。
For example
IF b THEN s1 ELSE s2 CASE x OF 1 : …. 2 : …. 3 : ….
分支测试 - example
Zhu.Kerrygmail
1
PROGRAM som ( maxint, N : INT )
2
INT result := 0 ; i := 0 ;
条件测试 (2)
Zhu.Kerrygmail
Branch testing for a compound condition C, test true and false branches of C and every simple condition of C
e.g., for C = (a>b) AND (c<d) test:
for the code may help, but is not required)
2. Determine the cyclomatic complexity of the flow graph.
3. Determine a basis set of linearly independent paths.
guarantees detection of rel-op error if E1 and E2 are correct
to detect errors in E1 / E2, the difference between E1 and E2 for the tests E1 < or > than E2 should be as small as possible
V(G)
modules in this range are more error prone
V(G) =number of regions (areas bounded by nodes and
edges—area outside the graph is also a region)
V(G) = number of edges - the number of nodes + 2 V(G) = number of (simple) predicate nodes + 1
complexity of code, provides an upper bound on the number of paths
that need to be tested in the code
modules
Higher Cycloramic Complexity, more possibility in error
Zhu.Kerrygmail
基本路径测试
Goal: exercise each independent path at least once.
1. Using the code, draw a corresponding flow graph (First drawing the activity diagram
4. Prepare test cases that force the execution of each path in the basis set.
Example
Procedure: process records
1. Do While records remain
2.
Read record;
for an expression with n variables, 2n tests are required
条件测试 - Example
Zhu.Kerrygmail
start
N<0
yes
no
N := -N;
i:=i+1; result:=result+i;
(i<N) and
yes
(result<=maxint)
11
ELSE OUTPUT ( “too large” )
12
END.
Zhu.Kerrygmail
流程图复杂度－例子
Zhu.Kerrygmail
Region 4
6 7 Region 3 8
1
Region 1
2,3
4,5
Region 2
9 10
V(G)=4
11
Zhu.Kerrygmail
确定线性独立的路径集合
• Independent path ® any path that introduces at least one
11. End Do
End
Example (continued)
1
2
3
6
8
7
9
11
10
4 5
V(G) = 4
Zhu.Kerrygmail
基本路径测试:流程图
1
2,3
6
4,5
8
7
9 10
11
流程图复杂度确定
Zhu.Kerrygmail
Cyclomatic complexity: a quantitative measure of the logical
白盒测试用例设计方法
白盒测试用例的设计方法
逻辑覆盖：以程序的内部逻辑结构为基础，分为语句覆 盖、判定覆盖、判定-条件覆盖、条件组合覆盖等
基本路径测试：在程序控制流程的基础上，分析控制构 造的环路复杂性，导出基本可执行路径集合，从而设计 测试用例。
白盒测试用例注意事项
由于测试路径可能非常多， 由于时间和资源问题，选出 足够多的路径测试
Path2: 1-2-3-6-89-10-1-11
Path3: 1-2-3-4-510-1-11
Path4: 1-11
Zhu.Kerrygmail
测试用例覆盖集合中每条路径
• you do not need an activity diagram, but the picture will help
2020
Ch14测试用例的设计STM
Zhu.Kerrygmail
为什么需要测试用例（2）
功能模块的测试用例的通用化和复用化则会使软件测试易于开展， 并随着测试用例的不断细化其效率也不断攀升；
根据测试用例的操作步骤和执行结果，为分析软件缺陷和程序模 块质量提供依据；可以方便地书写软件测试缺陷报告；
new set of processing statements or a new condition
• Basis set ® set of independent paths through the code • Test cases derived from a basis set are guaranteed to
no
yesresult<=maxint no
output(result);
output(too large);
exit
But ( i = result = 0 ) :
maxint N i<N result<=maxint
-1 1 true false
1 0 false true gives condition coverage for all conditions
C TRUE, FALSE
Domain testing
True AND True
T. And F., F. And T., F. And F.
a>b TRUE, FALSE c<d TRUE, FALSE
for an expression E1 rel-op E2, test for E1 ≧ ≦ = < > ≠ E2
测试用例包含期望的正确的结果 待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰、格式一致、分类组织
测试用例的组成元素与范例
Zhu.Kerrygmail
测试用例编号ID 测试用例标题 测试的模块
• 测试输入条件 • 期望的输出结果 • 其它说明
Zhu.Kerrygmail
But it does not preserve decision coverage
always take care that condition coverage preserves decision coverage : decision / condition coverage
Zhu.Kerrygmail
when you trace component paths
• count each logical test—compound tests count as the number
of Boolean operators + 1 (i.e., count each simple predicate)
3
IF N < 0
4
THEN N := - N ;
5
WHILE ( i < N ) AND ( result <= maxint )
6
DO i := i + 1 ;
7
result := result &#esult <= maxint
10
THEN OUTPUT ( result )
可以根据测试用例的执行等级，实施不同级别的测试； 便于大型软件测试项目外包测试指导基础；
Zhu.Kerrygmail
良好测试用例的特征
可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定
3.
If record field 1 = 0 Then
4.
store in buffer;
5.
increment counter;
6.
Else If record field 2 = 0 Then
7.
reset counter;
8.
Else store in file;
9.
End If
10. End If
errors to test for include (incorrect/missing/extra): Boolean operator – relational operator Boolean variable – arithmetic expression Boolean parenthesis
• basis path testing should be applied to all components, if
possible, and to critical components always
Basis path testing does not test all possible
combinations of all paths through the code; it just tests every path at least once.
Zhu.Kerrygmail
条件测试
Goal: further exercises the true and false value of each simple
logical condition in a component.
Logical conditions Simple condition: (a rel-op b) where rel-op={<, ≤, =, ≠, ≥, >} (may be negated with NOT), e.g., a≤b; NOT(a≤b) Compound condition: two or more simple conditions connected with AND, OR, e.g., (a>b) AND (c<d) Relational expression: (E1 rel-op E2) where E1 and E2 are arithmetic expressions, e.g., ((a*b+c)>(a+b+c))
execute every statement at least one time during testing
• Basis set is not unique
Basis path test example
Zhu.Kerrygmail
1
2
3
6
4
7
8
9
5
11
10
Path1: 1-2-3-6-7-910-1-11
分支测试
Branch Coverage
Execute the enough test cases，attempting to cover all the paths in the software:
- Get both “True” and “False” - Go through each branch。
For example
IF b THEN s1 ELSE s2 CASE x OF 1 : …. 2 : …. 3 : ….
分支测试 - example
Zhu.Kerrygmail
1
PROGRAM som ( maxint, N : INT )
2
INT result := 0 ; i := 0 ;
条件测试 (2)
Zhu.Kerrygmail
Branch testing for a compound condition C, test true and false branches of C and every simple condition of C
e.g., for C = (a>b) AND (c<d) test:
for the code may help, but is not required)
2. Determine the cyclomatic complexity of the flow graph.
3. Determine a basis set of linearly independent paths.
guarantees detection of rel-op error if E1 and E2 are correct
to detect errors in E1 / E2, the difference between E1 and E2 for the tests E1 < or > than E2 should be as small as possible
V(G)
modules in this range are more error prone
V(G) =number of regions (areas bounded by nodes and
edges—area outside the graph is also a region)
V(G) = number of edges - the number of nodes + 2 V(G) = number of (simple) predicate nodes + 1
complexity of code, provides an upper bound on the number of paths
that need to be tested in the code
modules
Higher Cycloramic Complexity, more possibility in error