第2章软件测试的策略与过程

有测试过程、规范、标准和测试计划 测试计划得不到实施 测试人员只热衷于找缺陷，报告开发人员 用户不信任测试过程，只好做验收测试
测试过程已被定义，单位但未得到有效执行
测试工作针对规格说明，重视问题的需求
测试结束时没有提供表明被测软件能否投入
使用的正式报告
32
不同等级的测试机构
4 5-8 5 0-4
先进的 测试机 构
——结论：应当对故障集中的程序段进行重点测
试 2020/6/18
4
无法进行完全测试的例子-1
M1
来自百度文库
D1
D2
D3
D4
M2
M3
M4
M5
M6
M7 D5
<=20次
循环次数
0
1
2……20
独立路径数 51+52+53+……+521≈1014 (1百万亿)
每个测试用例（考虑、执行、验证结果）5分钟
2020/6/18 共需测试时间
2020/6/18
1
第2章 软件测试策略与过程
2.1 软件测试的复杂性分析
2.2 排除软件缺陷的手段
2.3 软件测试方法与策略
2.4 单元测试
2.5 集成测试
2.6 确认测试
2.7 系统测试
2.8 验收测试
2.9 测试后的调试
2.10 面向对象的软件测试
2020/6/18
2
本章教学目标
• 理解软件测试的复杂性 • 理解软件测试的方法与策略 • 明确单元测试的主要任务和过程 • 明确集成测试的方法和确认测试的准则 • 明确系统测试的八个领域测试要点 • 明确验收测试的主要内容和相关配置
10亿年
5
2020/6/18
无法进行完全测试的例子-2
X Y
程序P
Z
若X、Y为所有可能的整数 在字长32位机上
测试
X1、Y1 ．Z1 ． ．
Xn、Yn Zn
n = 232232 = 264 1.84 1019
6
软件测试的复杂性分析（续）
4、不能修复所有的软件故障
——原因：没有足够的进行修复；修复的风险较大 ；不值得修复;可不算做故障的一些缺陷；“杀虫剂 现象”。
33
2.3 软件测试方法与策略
2.3.1 静态测试与动态测试 2.3.2 黑盒测试与白盒测试 2.3.3 软件测试过程 2.3.4 软件测试原则
Return
2020/6/18
34
软件测试策略
• 什么是软件测试策略？
——是为软件工程过程定义的一个软件测试的模 板，也就是把特定的测试用例方法放置进去的一系 列步骤。
13
软件项目评审
需 需 概 设 详 设 编 代 单 集 确 系测
求求要计细计
码 元 成 认 统试
分评设评设走
走 测 测 测 测评
析 审 计 审 计 查 码 查 试 试 试 试审
回归测试
单元测试计划
2020/6/18
14
软件生存期中缺陷的引入、传递与消除
需求 R 设计
引入 消除
R 编程
R
测试
UT IT ST AT
验收测试
系统测试
集成测试
回归测试
验证
确认
Do the right thing
系统测试 质量控制
2020/6/18
26
软件生存期各阶段的VV&T活动
1. 需求分析阶段
– 制定本项目的VV&T计划
– 设置基于需求的测试用例
– 对需求进行评审与分析
– 对用户手册初稿进行评审与分析
2. 概要设计阶段
– 修订VV&T计划
64%
2020/6/18
12
实际产品中的情况
Team
Exchange 2000 Windows 2000
Program
25
Manager
Developer
140
Tester
350
About 250
About 1700 About 3200
Tester / Dev
2.5
About 1.9
2020/6/18
• 软件测试策略包含的特征：
（1）测试从模块层开始，然后扩大延伸到整个基于 计算机的系统集合中。
（2）不同的测试技术适用于不同的时间点。
（3）测试是由软件的开发人员和（对于大型系统而 言）独立的测试组来管理的。
（4）测试和调试是不同的活动，但是调试必须能够
2020适/6/18应任何的测试策略。
35
软件测试充分性准则
12. 如已提出，它与商业风险有关吗？
13. 测试中发现的缺陷是否做了纪录和总结，使其用于改进 开发过程和测试过程？
14. 测试人员是否根据以前的工作经验判断可能的缺陷？
15. 是否有改进测试过程的办法？
16. 你为缺陷命名吗？
17. 是否利用缺陷记录、总结和事故数据来评价测试过程的 有效性？
18. 是否采用度量（如千行代码缺陷数）来计划和评价测试 过程？
6. 运行和维护阶段
– 软件评价 – 软件修改评价 – 回归测试
（引自美国国家标准局信息处理标准FIPS PUB101）
2020/6/18
28
如何正确对待测试工作
１．明确测试工作意义
２．加强责任心，疏忽可能造成恶果
３．学习——实践——钻研，积累经验， 努力提高业务水平
４．处理好与编程人员关系
2020/6/18
T：测试 R：评审 UT：单元测试 IT：集成测试 ST：系统测试 AT：验收测试
R
传递
2020/6/18
运行/维护 T R
15
缺陷跟踪
2020/6/18
16
缺陷的状态
• Microsoft
– Fixed – Duplicated – Postponed – By design – Not repro – Won't fix
7. 除规格说明以外，你能否确认用户的期望也能满足吗？
8. 测试人员能验证开发的阶段（如需求和设计）的精确性 和完全性吗？
9. 测试人员向开发人员报告缺陷以期进一步采取措施吗？
10. 在制定计划之前测试人员能估计业务风险吗？
2020/6/18
30
测试工作评估问题(续)
11. 针对被测软件是否提出了可度量的测试目标？
经济。 2020/6/18
7
软件测试的复杂性分析（续）
软
件
缺
陷
故
遗漏缺陷数目
障
数
量
测试中
测试工作量
优化测试量
测试费用
测试后
图2-1 测试工作量和软件缺陷数量之间的关系
2020/6/18
8
2.2 排除软件缺陷的手段
• 软件测试 • 软件项目评审
2020/6/18
9
软件测试
• 软件测试 ● 测试在软件开发中占有重要地位 ● 测试成本占总开发成本的近一半
19. 是否已建立了测试人员的培训制度？
20. 采用测试工具来支持测试过程吗？
2020/6/18
31
不同等级的测试机构
等 否个 级数
状态
特
点
1
1720
把测试工 作当作艺 术(art)
2
1316
把测试工 作当作技 艺(craft)
3 9-12
2020/6/18
执行已确 切定义的 测试过程
测试依赖于测试人员个人的技巧和创造性 对测试人员无指导，无要求 测试工作效果不稳定，有时好，有时糟 顾客和用户不能靠测试的有效性判断质量
• 其他
– 样本/范例，错误提示信息和产品支持信息等
2020/6/18
20
软件测试信息流
回归测试
软件配置
测试计划 测试用例｝测试配置 测试程序
测试工具
测试结果
错误
测试
评估 测试结果
预期结果
出错率
排错
修正的软件
建立可 靠性模型
可靠性模型
2020/6/18
21
为什么要实施测试评审
—回答：测试是否按计划实施
Closed
开发人 员
Deliverd
根据微软的Re经eodpe验n ，每修复Pe三ndi到ng 四个BFuixge一d 般就 会产生一个新的Bug。
Open
InAnalys is
Accepte d
2020/6/18
Reject
Unresol ved
18
测试对象
• 程序测试：发现程序中的缺陷
测试 数据
• 软件测试的充分性应该与软件的需求和软件的实现都相 关。
• 软件越复杂，需要的测试数据就越多。这一特性称为复 杂性。
• 测试得越多，进一步测试所能得到的充分性增长就越少
2020/6。/18 这一特性称为回报递减率。
36
2.3.1 静态测试与动态测试
1、静态测试
• 静态测试不实际运行软件，主要是对软件的编程 格式、结构等方面进行评估。
2020/6/18
3
2.1 软件测试的复杂性分析
1、无法对程序进行完全测试
（1）测试所需要的输入量太大
（2）测试的输出结果太多
（3）软件实现的途径太多
（4）软件规格说明没有一个客观标准
2、测试无法显示潜在的软件缺陷和故障
——通过软件测试只能报告软件已被发现的缺陷 和故障，无法报告隐藏的软件故障。
3、存在的故障现象与发现的故障数量成正比
2020/6/18
10
软件开发成本分布
软件类型 控制软件
开发成本按阶段分布%
需求与设计
实现
测试
46
20
34
航空航天软件
34
20
46
操作系统
33
17
50
科技计算软件
44
26
30
商业应用软件
44
28
28
2020/6/18
11
测试人员所占比例
微软软件开发人员一般配置表 测试人员 开发人员 项目经理
5% 31%
24
测试查错曲线
70
70
发
60
现 60
的
50
错 50
误
40
数 40
30
30
20
20
10
0 1 2 3 4 5 6 7周
10
0 1 2 3 4 5 6 7周
总缺陷数目
不同阶段的缺陷数目
2020/6/18
25
生存期各阶段V、V&T活动
分析
Do the thing right
设计 编码
测试
安装 维护
单元测试
– 制定基于设计的测试步骤
– 对概要设计进行评审与分析
3. 详细设计阶段
– 设置基于设计的功能测试数据
2020/6/18 – 对详细设计进行评审与分析
27
软件生存期各阶段的VV&T活动(续)
4. 程序编写和单元测试
– 完成测试用例说明书 – 进行单元测试 – 进行集成测试
5. 安装
– 进行系统测试 – 进行验收测试
最先进 的测试 机构
2020/6/18
有明确的测试目标，可优化利用测 试资源实现目标 重视测试过程薄弱环节的改进
测试工作基于降低风险，测试人员 工作有效 测试得到度量，过程得到很好定义 缺陷得到记录、分析和总结，且用 其改进过程 测试成本显著下降 顾客和用户相信测试过程，不依靠 验收测试取得满意产品
• 对任何软件都存在有限的充分测试集合。
• 如果一个软件系统在一个测试数据集合上的测试是充分 的，那么再多测试一些数据也应该是充分的。这一特性 称为单调性。
• 即使对软件所有成分都进行了充分的测试，也并不表明 整个软件的测试已经充分了。这一特性称为非复合性。
• 即使对软件系统整体的测试是充分的，也并不意味软件 系统中各个成分都已经充分地得到了测试。这个特性称 为非分解性。
29
测试工作评估问题
1. 你单位是否有专人负责测试工作？
2. 你们是否有、是否用测试计划规范？
3. 你们是否有、是否用单元测试规程？
4. 你们是否有、是否用测试报告规范？
5. 测试过程（包括计划和实施）与整个开发过程是否并行 开展？（测试在开发初期着手，在开发结束完成）
6. 测试能够确认规格说明得到正确的实现吗？
2020/6/18
• Athens Olympic Games System
– Open – In Analysis – Accepted – Rejected – Fixed – Delivered – Pending – Closed – Reopened – Unresolved
17
测试人 员
的问题
22
测试计划与测试评审的关系
软件测试
AP Testing C D AP CD
软件开发
2020/6/18
P：制定测试计划 D：执行测试 C：测试评审 A：解决测试评审发现的问题
23
2020/6/18
测试与开发前期工作的关系
决定软件与系 统的配合关系
需求分析 概要设计 详细设计
编码 单元测试 集成测试 确认测试 系统测试
——结论：关键是要进行正确的判断、合理的取舍 ，根据风险分析决定哪些故障必须修复，哪些故障可 以不修复。
5、软件测试的代价
——工作原则：就是如何将无边无际的可能性减小
到一个可以控制的范围，以及如何针对软件风险做出
恰当选择，去粗存精，找到最佳的测试量，使得测试
工作量不多也不少，既能达到测试的目的，又能较为
测试是否充分而有效地检验了功能、性能和使用要求
—体现PDCA循环
AP CD
P—Plan D—Do C—Check A—Action
2020/6/18
计划 实施 检验、审查 措施、行动
软件开发中：
P—SDP 软件开发计划 SRS 软件需求规格说明
D—软件设计、实现、编程 C—软件测试、软件评审 A—解决测试和评审中发现
程序P
结果数据
相符
预期数据
比较
不符 追查缺陷
2020/6/18
19
测试对象
• 文档测试：发现文档中存所在有的与软各件种产错品有误关，以及 各种文档之间的逻辑不一联致的测性部试分等的都对可象成！为被
– 需求规格说明 – 设计说明（概要与详细） – 程序（代码走查，编写的代码是否符合既定的规范
和标准等，不是指可执行的二进制代码） – 测试用例、测试计划、测试结果报告 – 用户手册、安装/配置手册、帮助文档等