第 1 章简介

我们为什么要测试软件？
软件是包裹我们文明的一层皮肤

引自 Mark Harman 博士

2
 软件故障
 2020 年：由于出发公告板和值机系统出现问题，伦敦希思罗机
场往返航班超过 100 架次中断
 2019 年： Facebook 、 Instagram 、 WhatsApp 因例行维护导致
Facebook 新闻提要问题停机 14 小时
 2019 年：波音 737 Max 因激进的软件飞行控制而坠毁
 2018 年：亚利桑那州一名行人因 Uber 汽车自动驾驶软件故障
被撞死
 2018 年：由于两年多来一直未发现故障，谷歌关闭了
Google+ ，导致近 50 万用户的数据遭到泄露
 2017 年：记录在案的软件故障有 606 起，影响了 37 亿
人、 314 家公司，财务损失达 1.7 万亿美元

3
 软件故障
 2016 年：日产因安全气囊传感器软件故障召回 400
万辆汽车
 2003 年：因能源管理系统中的报警系统故障导致美国
东北部大停电，影响美国 8 个州的 40 万人、加拿大安
大略省的 10 万人
 1999 年：美国宇航局的火星着陆器因单元集成故障而
坠毁
 1997 年：阿丽亚娜 5 号爆炸：异常处理错误导致首
飞时自毁（ 64 位到 16 位转换），造成 3.7 亿美元的
损失
 1986 年：由于安全关键软件测试不力， Therac-25 放
射机导致 3 名患者死亡

4
 软件故障条款
 Fault （故障） 、 failure （失败）和 defect （缺
陷）往往表示非常严重的情况，甚至是危险的。
– 将错误颜色的图标称为故障听起来不太对。
– 这些话也往往暗示着责备：“软件失败是他的错。”
 异常、事件和差异听起来并不是那么负面，通常用于
推断意外操作而不是全面失败。
– “ 总统表示，是软件异常导致导弹偏离了航线。”
 问题、错误和 bug 可能是最常用的术语。

5
 软件故障、错误和失败
 软件故障：软件中的静态缺陷

 软件故障：与要求或其他预期行为描述不符的外部、
不正确的行为

 软件错误：不正确的内部状态，是某些故障的表现

软件中的故障相当于硬件中的设计错误。
软件不会退化。

6
 故障及失败示例
 症状列表
– 失败
 医生试图诊断疾病的根本原因
– 过错
 医生可能会寻找异常的内部状况（高血压、心律不
齐、血液中的细菌）
– 错误

大多数健康问题是由于外部攻击（细菌、病毒）或随着年
龄增长的身体衰退引起的。
软件故障一开始就存在，并不会因为零件磨损而“出
现”。

7
 一个具体的例子
公共静态 int numZero （ int [ ] arr ）
{
// 效果：如果 arr 为空，则抛出
NullPointerException
arr 中 0 出现的次数

int 计数 = 0;
对于（整数 i = 1; i < arr.length ; i ++)
{
如果（ arr [ i ] == 0 ） a) 确定故障。
{ b) 如果可能的话，找出一个不执行故障的
计数 ++ ； 测试用例。
} c) 如果可能的话，找出一个导致错误但不
}
会失败的测试用例。
返回计数；
}
 一个具体的例子
错误：应该从 0 开始
搜索，而不是 1

公共静态 int numZero （ int [ ] arr ）

测试 1
{ // 效果：如果 arr 为空，则抛出 NullPointerException
[ 2, 7, 0 ]
arr 中 0 出现的次数
预期的： 1
int 计数 = 0;
实际的： 1
对于（整数 i = 1; i < arr.length ; i ++)
{ 错误：在第一次迭代
中， i 为 1 ，而不是 测试 2
如果（ arr [ i ] == 0 ） [ 0, 2, 7 ]
{ 0
失败：无 预期的： 1
计数 ++ ； 实际： 0
}
} 错误： i 为 1 ，不是 0
返回计数； 错误传播到变量 count
} 失败：返回语句中的计数为 0

9
 一个具体的例子

公共静态 int numZero （ int [ ] arr ）

{
// 效果：如果 arr 为空，则抛出 NullPointerException
arr 中 0 出现的次数

int 计数 = 0;
对于（整数 i = 1; i < arr.length ; i ++)
{ 数组 = [2, 7, 0]
计数 = 0
如果（ arr [ i ] == 0 ）
{
计数 ++ ； 我 =1
}
} 数组 = [2, 7, 0]
数组 = [2, 7, 0]
计数 = 0
返回计数； 我=1
计数 = 0
我 =0
} PC = 如果
 软件可测试性（ 3.1 ）
系统或组件促进建立测试标准和执行测试以确定这些标
准是否得到满足的程度

 坦白地说——在软件中发现错误有多难
 可测试性主要受两个实际问题的影响
– 如何向软件提供测试值
– 如何观察测试执行的结果

11
 可观测性和可控性
 可观察性
从程序的输出、对环境和其他硬件和软件组件的影响来
看，观察程序行为的难易程度

– 影响硬件设备、数据库或远程文件的软件可观察性较低
 可控性

就值、操作和行为而言，为程序提供所需输入的难易程
– 通过键盘输入即可轻松控制软件
度
– 来自硬件传感器或分布式软件的输入更难
 数据抽象降低了可控制性和可观察性

12
 测试用例的组成部分（ 3.2 ）
 测试用例是具有明确结构的多部分工件

 测试用例值
完成被测软件执行所需的输入值

 预期成绩
如果软件按预期运行，测试将产生的结果

– 测试预言使用预期结果来决定测试是通过还是失败

13
 影响可控性和可观测性
 前缀值
使软件进入适当状态以接收测试用例值所需的输入

 后缀值
发送测试用例值后需要发送给软件的任何输入

1. 验证值：查看测试用例结果所需的值
2. 退出值：终止程序或使其返回稳定状态所需的值或命令

14
 整合测试
 测试用例
被测软件完整执行和评估所需的测试用例值、前缀值、
后缀值和预期结果

 测试集

一组测试用例
 可执行测试脚本
以某种形式准备的测试用例，可在测试软件上自动执行
并生成报告

15
 故障与失效模型 (RIPR)
观察失败的四个必要条件

1. 可达性：程序中包含故障的位置必须能够被到达
2. 感染：程序状态一定不正确
3. 传播：受感染的状态必须导致程序的某些输出或最
终状态不正确
4. 揭示：测试人员必须观察程序状态中不正确的部分

16
 RIPR 模型

测试
最终程序状态
到达 观察到的最终
• 可达性 程序状态
观察到的最
过错 终程序状态
• 感染​ 错误的
最终状
感染
• 传播​ 态
传播 揭示
• 可揭露性 程序状态
不正确
测试预
言机
17
 测试和调试
 测试：通过观察软件的执行情况来评估软件

 测试失败：执行测试导致软件失败

 调试：在发生故障时查找故障的过程

并非所有输入都会“触发”故障并
导致故障

18
 Bug 一词
 Bug 被非正式地使用
 有时说话者的意思是故障，有时是错误，有时是失败 ...... 说话
者通常不知道这是什么意思！
 本课程将尝试使用具有精确、明确和无歧义含义的单词
“ 必须执行分析过程才能
为分析机提供必要的操作
漏洞 数据；而这也可能是一个
错误来源。即使实际机制
在其过程中没有错误，卡
片也可能给它错误的命
令。” – 艾达，洛夫莱斯
“ 我所有的发明都是如此。第一步是直觉，然 伯爵夫人（巴贝奇分析机
后突然出现，然后困难出现——这个东西失效 笔记）
了，然后‘ Bugs ’—— 这些小故障和小困难的
称呼——就会出现，需要数月的密切观察、研
究和劳动……” ——托马斯 · 爱迪生

19
 产品规格
 产品规范，有时简称为规格或产品规范，是软件开发
团队之间的协议。
 它定义了他们正在创建的产品，详细说明了它将是什
么、它将如何运作、它将做什么以及它不会做什么。

20
 Bug 的正式定义
 当以下五条规则中的一条或多条满足时，就会出现软
件错误：
– 软件没有执行产品规格所规定的某些操作。
– 软件做了产品规格中规定不应该做的事情。
– 该软件可以执行产品规格中未提及的一些操作。
– 该软件没有执行产品规格中未提及但应该执行的操作。
– 该软件难以理解，难以使用，运行缓慢，或者在软件测试人
员眼中，最终用户会认为它完全不正确。

21
 一个例子
 计算器的规格可能规定它能正确执行加、减、乘、除运算。产
品规格可能规定计算器绝不会崩溃、死机或冻结。
– 如果你作为测试人员收到计算器，按下 + 键，但什么也没发生，那么这
就是规则导致的一个错误 ？？
– 如果你答错了，那就是规则导致的一个错误 ？？
– 如果你敲击键盘，计算器却停止响应你的输入，那么这就是规则导致的
一个错误 ？？
– 假设你收到计算器进行测试，发现除了加、减、乘、除之外，它还能进
行平方根计算。这是功能还是由于规则而导致的缺陷 ？？
– 你开始测试计算器，发现当电池电量不足时，你不再能得到正确的计算
答案。这是由于规则导致的一个错误 ？？
– 您发现按钮太小。也许 = 键的位置使其难以使用。也许显示屏在强光下
难以阅读。所有这些都是由于规则造成的错误 ？？

22
错误在哪里？

23
修复故障的平均成本

24
 21 世纪的测试
 更加安全、实时的软件
 嵌入式软件无处不在……检查一下你的口袋
 企业应用程序意味着更大的程序、更多的用户
 安全现在全是软件故障
– 安全软件是可靠的软件
 Web 提供了新的部署平台
– 竞争力强，可供更多用户使用
– Web 应用程序是分布式的
– Web 应用程序必须高度可靠
 人工智能软件

工业迫切需要我们的发明！
25
 这是什么意思？

软件测试变得越来越重要

当我们测试时我们要做什么？
我们的目标是什么？

26
 确认与验证 ( IEEE )

 验证：在软件开发结束时评估软件以确保符合预期用
途的过程

 验证：确定软件开发过程某一阶段的产品是否满足前
一阶段建立的要求的过程

IV&V 代表“独立验证和确认”

27
 区分验证与核实的案例研究
 1990 年 4 月，哈勃太空望远镜发射升空，进入环绕地球的轨道。作为反射
式望远镜，哈勃望远镜主要使用一面大镜子来放大目标物体。
 测试它的唯一方法是仔细测量它的所有属性，并将测量值与规定值进行比
较。这项测试已经完成，哈勃望远镜被宣布适合发射。不幸的是，在它投入
运行后不久，人们发现它传回的图像失焦了。
 调查发现，镜子制造不当。镜子是按照规格磨制的，但规格有误。镜子非常
精确，但并不准确。测试确认镜子符合规格验证，但并未确认其符合原始要
求验证。
 1993 年，一次航天飞机任务修复了哈勃望远镜，通过安装“矫正镜片”来
重新聚焦由制造不当的镜子产生的图像。
 虽然这不是一个软件示例，但验证和确认同样适用于软件测试。永远不要假
设规范是正确的。如果您验证规范并确认最终产品，则有助于避免诸如哈勃
望远镜所遭遇的问题。

28
 根据测试过程成熟度确定测试目标
 级别 0 ：测试和调试没有区别

 级别 1 ：测试的目的是为了证明正确性
 第 2 级：测试的目的是表明软件无法运行
 第 3 级：测试的目的不是为了证明任何具体的事情，
而是为了降低使用该软件的风险
 第四级：测试是一种心理训练，可以帮助所有 IT 专
业人员开发更高质量的软件

29
 0 级思维
 测试与调试相同

 不区分不正确的行为和程序中的错误

 无助于开发可靠或安全的软件

这就是我们教授计算机科学本科生的内容

30
 第一层思维
 目的是证明正确性
 正确性是不可能实现的
 没有失败我们知道什么？
– 好的软件还是糟糕的测试？
 测试工程师没有：
– 严格目标
– 真实停止规则
– 正式测试技术
– 测试经理无能为力

这是硬件工程师经常期望的

31
 第二层思维
 目的是展示失败

 寻找失败是一种消极的行为

 让测试人员和开发人员陷入对抗关系

 如果没有失败会怎样？

这描述了大多数软件公司。
我们如何才能转向团队合作方式？

32
 第三层思维
 测试只能显示故障的存在

 每当我们使用软件时，我们都会面临一些风险

 风险可能很小，后果也不重要

 风险可能很大，后果可能很灾难性

 测试人员和开发人员合作以降低风险

这描述了一些“开明”的软件公司

33
 第四级思维
提高品质的心理训练

 测试只是提高质量的一种方法

 测试工程师可以成为项目的技术领导者

 主要职责：衡量和改进软件质量

 他们的专业知识应该可以帮助开发人员

这就是“传统”工程的工作方式
34
 你在哪里？

您处于 0 级、 1 级还是 2 级？

您的组织处于 0 级、 1 级还是 2 级工
作？
还是 3 ？

我们希望教会您成为工作场所的“变革推
动者”……
提倡第四级思维
35
 战术目标：为什么每次测试都要进行？
如果你不知道为什么要进行每次测试，那么
这对你没什么帮助
 必须记录书面考试目标和要求
 覆盖范围是多少？
 多少测试才够？

 共同目标——花掉预算 … 测试直至发货日期
……
– 有时被称为“日期标准”

36
 为什么要进行每次测试？
如果你在功能需求形成时没有开始规划每个测试，你永
远不会知道为什么要进行测试

 1980 年：“软件应该易于维护”

 阈值可靠性要求？

 每个测试试图验证什么事实？

 需求定义团队需要测试人员！

37
 不进行测试的成本
可怜的项目经理可能会说：“测试太
昂贵了。”
 测试是软件开发中最耗时且最昂贵的部分
 不检测的代价更高
 如果我们早期的测试工作量太少，测试成本就
会增加
 开发后的测试规划成本过高

38
 延迟测试的成本
60
假设每故障单位成本为 1000 美元， 100 个故障 万
50 25
36 美元
40 美 万
元
故障来源 (%)
三
2万 10
十 美 美元万 故障检测率（ % ）
20 1. 3 元
万
元 美 单位成本（ X ）
6,0
10 0 0
美
0 元

求 计 试 试 试 后
要 设 测 测 测 署
元 成 统 部
单 集 系
/
序
程

软件工程学院；卡内基梅隆大学；手册 CMU/SEI-96-HB-002
39
 Summary:
Why Do We Test Software ?

A tester’s goal is to eliminate faults as

early as possible

• Improve quality
• Reduce cost
• Preserve customer satisfaction

40
 本节课程目标

 理解软件测试的重要性；

 明确 fault 、 failure 、 error 、 bug 的具体含义和区别；

 分析代码中潜在的 fault 及其可能导致的 error 和

failure ；

 正确理解软件测试的作用和价值。

41