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

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