第二部分（章）软件工程与软件测试 §1 软件工程与软件测试模型 §2 软件缺陷和缺陷排除的两种重要手段 §3 软件测试的基本概念

Presentation on theme: "第二部分（章）软件工程与软件测试 §1 软件工程与软件测试模型 §2 软件缺陷和缺陷排除的两种重要手段 §3 软件测试的基本概念"— Presentation transcript:

1 第二部分（章）软件工程与软件测试 §1 软件工程与软件测试模型 §2 软件缺陷和缺陷排除的两种重要手段 §3 软件测试的基本概念
1. 软件测试 2. 软件评审 §3 软件测试的基本概念 1. 测试的目的 2. 测试的对象 3. 软件测试的原则 4. 软件测试信息流

2 §4 软件测试的一般性理论 §5 软件测试的挑战和问题 5. 为什么不可能做到穷举测试 6. 测试策略 （1）测试步骤
（2）生存期各阶段V and V&T活动 （3）测试查错曲线 （4）排除隐错的相对成本 §4 软件测试的一般性理论 §5 软件测试的挑战和问题

3 §1 软件工程与软件测试模型 一、什么是软件测试？ 1983年IEEE定义为：
使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。 作用 1、测试是为了要找出缺陷，但同时，也可以通过对缺陷的度量和统计，分析缺陷产生的原因和缺陷的分布特征，分析产品的质量、工作效率、诊断开发过程中的问题，并通过改进各个开发过程提高过程能力，最终降低缺陷数量和缺陷密度。 2、没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。

4 §1 软件工程与软件测试模型 你真的懂测试吗 编程大师说：没有错误的程序世间难求。 （《编程之道》）
你在学校里学过测试吗？（读到博士可能也不懂测试） 你所在的企业重视测试吗？ （小公司程序员的技能更加全面） 临时抱佛脚行吗？你以为有文档模板就会测试了吗？ 如果不懂得有效地进行测试，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。 职业软件工程师应当掌握需求开发、系统设计、编程、测试、维护 所有技能。

5 §1 软件工程与软件测试模型 二、软件测试阶段
单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。 单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。 集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。 系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。 验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。

6 §1 软件工程与软件测试模型 一般的软件测试过程 单元 测试 验收 系统 集成 被测模块 已经过测试的模块 已集成 的软件 已确认 可交付
概要设计信息 系统其它元素 软件需求 详细设计信息

7 §1 软件工程与软件测试模型 二、V模型介绍 如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系 。

8 Validate requirements customer, user, PM, technical support
§1 软件工程与软件测试模型 开发和测试过程的V模型 需求 Validate requirements 验收测试设计 customer, user, PM, technical support 验收测试 执行验收测试 系统规格描述 系统测试设计 系统测试 执行系统测试 框架设计 集成测试设计 集成测试 执行集成测试 详细设计 单元测试设计 单元测试 Design/Analysis 执行单元测试 Code

9 §2 软件缺陷和缺陷排除的手段 一、软件缺陷 二、缺陷排除的手段

10 一、软件缺陷 1、软件缺陷是对软件产品预期属性的偏离现象 2、缺陷有三种 3、软件缺陷不可能完全避免
对产品规格说明的偏离。如：规格说明规定了a+b=>c，而软件产品实际上做的不是。 对用户期望的偏离，即用户要求未体现在产品中（可能是规格说明有疏漏，也可能是实现中的问题。） 2、缺陷有三种 错误：未将规格说明正确实现。 遗漏：规定的或预期的需求未体现在产品中（可能未将规格说明全面实现，也可能在开发过程中追加了需求。） 额外的实现：规格说明并未规定的需求被纳入产品，得到实现。 3、软件缺陷不可能完全避免

11 一、软件缺陷 4、缺陷和事故 机械和建筑业的对比。 缺陷是软件内部的“裂缝”，在未影响到用户和系统运行的情况下是隐蔽状态，并未表现出来。
当缺陷引发运行错误或产生负面影响时，构成事故，造成损失或伤害。

12 二、排除软件缺陷的两种重要手段 1、软件测试 测试在软件开发中占有重要地位 测试成本占有开发成本的近一半

13 软件开发成本分布 软件类型 开发成本按阶段分布% 需求与设计 实现 测试 控制软件 46 20 34 航空航天软件 操作系统 33 17
50 科技计算软件 44 26 30 商业应用软件 28

14 2、软件项目评审 评审与走查 需求分析 需求评审 概要设计 设计评审 详细设计 设计走查 编码 代码走查 单元测试 集成测试 确认测试
测试评审 测试策划 评审与走查

15 §3 软件测试的基本概念 1、测试目的（J. Myers） 测试是程序执行的过程，目的在于发现错误（缺陷）
§3 软件测试的基本概念 1、测试目的（J. Myers） 测试是程序执行的过程，目的在于发现错误（缺陷） 好的测试用例能有效地发现别的测试用例未发现的错误（缺陷） 成功的测试是发现了未曾发现的错误（缺陷）

16 §3 软件测试的基本概念 2、测试的对象 1) 程序测试：发现程序中的缺陷 程序P 比较 结果数据 相符 预期数据 不符 追查缺陷 测试
1) 程序测试：发现程序中的缺陷 测试 数据 程序P 比较 结果数据 预期数据 相符 不符 追查缺陷

17 程序正确性的各种情况 a．程序编写无语法错误 b．程序执行中未发现明显的运行错误 c．程序中无不适当语句 例:某程序 ——————————
例:某程序 —————————— 说明部分 D ……L，…… 对Ｌ说明 语句部分 S …… L=3; 对Ｌ赋值　I M=L+5 对Ｌ引用　R —————————————————— 　D D R D D D D I R R I I 　R I I 　 ———————— 正常 异常

18 程序正确性的各种情况 d. 程序运行时能通过典型的有效测试数据，得到正确的预期结果。
e. 程序运行时能通过典型的无效测试数据，得到正确的结果。 f. 程序运行时能通过任何可能给出的数据，给出正确的结果。

19 2) 软件测试：发现程序及前期开发的缺陷 需求规格 说明 SRS 设计规格 说明 DS 程序 软件测试的对象

20 3、 软件测试的原则 在测试工作开始以前，不应设想程序中没有缺陷或找不出缺陷。（测试心理学） 测试以前应预知测试的结果数据。
3、 软件测试的原则 在测试工作开始以前，不应设想程序中没有缺陷或找不出缺陷。（测试心理学） 测试以前应预知测试的结果数据。 尽可能避免测试自己写的程序。坚持独立测试原则，必要的情况下建立独立测试机构。 测试用例应兼顾有效输入和无效输入。 不仅要检验程序是否做了该做的事，还应检验是否做了不该做的事。 测试的充分性。 测试的有效性。 限于人力、物力，测试工作适可而止。（测试经济学） 保留一切测试用例。 任何已测程序的变更都应重新进行测试。（回归测试）

21 4、软件测试信息流 ｝ 排错 评估 测试结果 测试 建立可 靠性模型 预期结果 修正的软件 可靠性模型 软件配置 测试配置 测试工具
错误 出错率 回归测试 测试计划 测试用例 测试程序 ｝

22 5、测试成本曲线 未发现的缺陷数 测试成本 最佳测试点 不足测试 过度测试 测试的程度 t

23 5、为什么不可能做穷举测试 M1 D1 D2 D3 D4 <=20次 M2 M3 M4 M5 M6 M7 D5
循环次数 0 1 2……20 独立路径数 ……+521≈1014 (1百万亿) 每个测试用例（考虑、执行、验证结果）5分钟 共需测试时间 10亿年

24 5、为什么不可能做穷举测试 程序P X Z Y 若X、Y为所有可能的整数 在字长32位机上 测试 X1、Y1 Z1 ． Xn、Yn Zn

25 6、测试策略 生存期各阶段V、V&T活动 分析 设计 编码 测试 安装 维护 单元测试 回归测试 验证 确认 系统测试 质量控制 验收测试
集成测试 回归测试 验证 确认 系统测试 质量控制

26 软件测试的基本过程

27 软件测试周期示意

28 验证与确认 验证（Verification）：
在软件生存期各个阶段，验证是指检测各个阶段结束时的工作产品是否满足对上一阶段的结束后的工作产品所定义的规格的验证过程。 需求 设计 编码 测试 验证

29 在软件生存周期各个阶段，确认是指检测各个阶段结束时的工作产品是否满足在软件生存周期初期在系统需求文档中描述的各项软件规格的确认过程。
验证与确认 确认（Validation）: 在软件生存周期各个阶段，确认是指检测各个阶段结束时的工作产品是否满足在软件生存周期初期在系统需求文档中描述的各项软件规格的确认过程。 需求 设计 编码 测试 确认

30 确认和验证的比较 验证 确认 验证是检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致，
确认是检测每一阶段的工作产品是否与最初定义的软件需求规格相一致。 软件测试既可用于验证，又可用于确认。 需求 设计 编码 测试 验证 确认

31 测试查错曲线 发现的错误数 周 周

32 排除隐错的相对成本 需求隐错 设计隐错 编码隐错 静态分析

33 §4 软件测试的一般性理论 一、黑盒测试与白盒测试
§4 软件测试的一般性理论 一、黑盒测试与白盒测试 黑盒测试（Black-box testing） 黑盒测试是从用户观点出发的测试，它又称功能测试（不全面，还包括功能测试）、数据驱动测试或基于规格说明书或用户手册的测试。它所依据的是程序的外部特性。 需求 说明 产生 被测程序 测试结果 输出 比较 测试用例 黑盒测试只关心输入与输出的对应关系，不关心被测程序的内部关系。

34 §4 软件测试的一般性理论 黑盒测试的准则 基于需求规格说明书的测试（需求矩阵） 需求列表 设计列表:概要设计和详细设计
§4 软件测试的一般性理论 黑盒测试的准则 基于需求规格说明书的测试（需求矩阵） 需求列表 设计列表:概要设计和详细设计 测试用例与需求的对照表

35 §4 软件测试的一般性理论 一、黑盒测试与白盒测试
§4 软件测试的一般性理论 一、黑盒测试与白盒测试 白盒测试（White-box testing） 白盒测试又称结构测试、逻辑驱动测试或基于程序的测试，其测试过程如图所示。 白盒测试要研究被测程序的源代码结构

36 §4 软件测试的一般性理论 一、黑盒测试与白盒测试
§4 软件测试的一般性理论 一、黑盒测试与白盒测试 白盒测试覆盖准则 语句覆盖 -在测试时，设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少执行一次。 分支覆盖 -在测试时，设计若干测试用例，运行被测程序，使程序中的每个判断真假的分支至少遍历一次。 条件覆盖 -在测试时，设计若干测试用例，运行被测程序，使程序中的每个条件的可能取值至少满足一次。 条件分支覆盖 -在测试时，设计足够的测试用例，使得判断中每个条件的所有可能取值至少出现一次，并且每个判断本身的判定结果也至少出现一次。 路径覆盖 - 设计足够多的测试用例，要求覆盖程序中所有可能的路径。

37 §4 软件测试的一般性理论 一、黑盒测试与白盒测试
§4 软件测试的一般性理论 一、黑盒测试与白盒测试 软件测试的衡量标准 需求的覆盖 需求追溯表/需求矩阵 缺陷数量 多、新 缺陷重现率 BUG能按照一定的测试过程稳定重现 效率 平均每人天发现的BUG数（5个/人天） 成本 少。合理的测试人力和软、硬件资源安排 重用价值 测试的数据或者样例可以重用

38 静态测试和动态测试 静态测试 程序代码的静态测试需要我们按照相应语言的代码规范模板来逐行检查程序代码
是指不实际运行被测程序，而只是静态地检查程序代码、界面或文档中可能存在的错误。 对于代码测试：主要测试代码是否符合相应的标准和规范。 对于界面测试：主要测试软件的实际界面与需求中的说明是否符合。 对于文档测试：主要测试用户手册和需求说明是否符合用户的实际需要。 程序代码的静态测试需要我们按照相应语言的代码规范模板来逐行检查程序代码

39 C语言程序的例子 #include<stdio.h> Main() { Max(float x,float y)
float z; Z=x>y?x:y; return (z); } Main() { float a,b; int c; scanf(“%f,%f”,&a,&b); c=max(a,b); printf(“max is %d\n”,c); }

40 必须修改的问题有三个 程序没有注释 子函数max没有返回值得类型 精度丢失问题
一般注释语句要占到代码总行数的1/5——1/4； 注释语句包括程序的基本信息如作者、版本号、创建日期等，以及主要功能模块。 子函数max没有返回值得类型 由于Z的值为单精度型，可以在max前面加一个float类型声明 精度丢失问题 注意语句 c=max（a，b），c的精度为整型，而max为float。

41 建议修改的问题也是3个 1行代码只定义1个变量 程序适当加一些空行 Main函数没有返回值类型和参数列表
建议改为：void main（void），表明main函数的返回值和参数都为空。 1行代码只定义1个变量 程序适当加一些空行

42 C语言编码规范（简易版） 规范编号 规范内容 是否通过 1 一行代码制作一件事情，如只定义一个变量，或只写一条语句，容易阅读和注释。 2
代码行的最大长度宜控制在70-80个字，否则不便于阅读和打印。 3 函数与函数之间，定义语句和执行语句之间最好加空行，空行不会浪费内存。 4 在程序的开头加注释，说明程序的基本信息；在重要的函数模块处加注释，说明各函数的功能。 5 低一层次的语句比高一层次的语句缩进一个tab键（4个字符），使程序结构更清晰。 6 不要漏掉函数的参数和返回值，如没有，则用void表示。

43 动态测试（dynamic testing）
顾名思义，是指实际运行被测程序，输入相应的测试数据，检查实际的输出结果和预期结果是否符合。 白盒测试黑盒测试、静态测试和动态测试只是一个测试的不同分类的角度而已。 黑盒测试可以是动态测试，也可以是静态测试； 白盒测试可以是动态测试，也可以是静态测试； 动态测试可以是黑盒测试，也可以是白盒测试； 静态测试可以是黑盒测试，也可以是白盒测试。

44 §4 软件测试的一般性理论 二、单元测试 什么是单元测试？ 是指对软件中的最小可测试单元进行检查和验证
§4 软件测试的一般性理论 二、单元测试 什么是单元测试？ 是指对软件中的最小可测试单元进行检查和验证 单元：人为规定的最小的被测试单元。如：在结构化语言中（C语言），单元指一个函数；在面向对象语言中（Java语言）单元指一个类；在图形化的软件中，单元也可以指一个窗口、一个菜单等。

45 §4 软件测试的一般性理论 二、单元测试 单元测试的内容： 单元测试方法： 1、模块接口测试 2、检查局部数据结构能否保持完整性
§4 软件测试的一般性理论 二、单元测试 单元测试的内容： 1、模块接口测试 2、检查局部数据结构能否保持完整性 3、模块边界条件测试 4、模块执行路径测试 5、检查模块内部错误处理是否有效 单元测试方法： 白盒测试为主

46 §4 软件测试的一般性理论 二、单元测试 单元测试或模块测试 对模块进行正确性检验的测试工作，测试用例以白盒测试为主、黑盒测试为辅.
§4 软件测试的一般性理论 二、单元测试 单元测试或模块测试 对模块进行正确性检验的测试工作，测试用例以白盒测试为主、黑盒测试为辅. 模块 出错处理 模块接口 局部数据结构 边界条件 执行路径 调用参数 全局量定义一致性 数据定义、 使用 循环边界 输入边界 重要路径 关键路径 非合理输入 系统异常

47 §4 软件测试的一般性理论 二、单元测试 单元测试检查单 逻辑和算法：正确实现了逻辑和算法
§4 软件测试的一般性理论 二、单元测试 单元测试检查单 逻辑和算法：正确实现了逻辑和算法 数据结构（全局和局部）：使用了全局数据结构？哪些？如果有，作了哪些关于全局数据的假设？这些假设正确吗？使用了局部数据？在算法执行的所有步骤期间，保持局部数据的完整性了吗？ 接口：来自调用模块的数据匹配被调用的模块的期望接收的数据？被调用模块的数据匹配调用的模块提供的数据？ 独立路径：标识了所有穿过模块的独立路径？执行了吗？ 边界条件：了解边界条件吗？进行了测试确保该模块在其边界条件上的适当的操作了吗？ 出错处理：所有出错处理路径均执行到了吗？

48 §4 软件测试的一般性理论 二、单元测试 什么时候进行单元测试？ 代码经过编译后，在前期要做准备工作，如：

49 §4 软件测试的一般性理论 三、集成测试 集成测试（Integration test）: 将通过单元测试的多个模块组合成更大的模块或子系统或产品，然后进行测试。 测试内容：各单元的接口是否吻合、代码是否符合规定的标准、界面标准是否统一等。 人员安排：既要求参与的人熟悉单元的内部细节，又要求他们能够从足够高的层次上观察整个系统。一般由有经验的测试人员和主要的软件开发者来完成集成测试的计划。

50 §4 软件测试的一般性理论 三、集成测试 集成测试计划：集成测试计划由系统设计人员在设计阶段制定，它是和设计规格说明同时完成的。内容有：
§4 软件测试的一般性理论 三、集成测试 集成测试计划：集成测试计划由系统设计人员在设计阶段制定，它是和设计规格说明同时完成的。内容有： 测试的描述和范围 测试环境 测试时间表 集成次序 测试用例以及测试的预期结果等 测试方法：集成测试阶段是以黑盒法为主。

51 §4 软件测试的一般性理论 四、系统测试 为了发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试
§4 软件测试的一般性理论 四、系统测试 经过集成测试之后，分散开发的模块被联接起来，构成完整的程序，其中各模块间接口存在的种种问题都已基本消除。测试开始进入到系统测试的阶段。 为了发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试 一般使用黑盒测试技术 一般由独立的测试人员完成

52 §4 软件测试的一般性理论 四、系统测试 系统测试(System test):
§4 软件测试的一般性理论 四、系统测试 系统测试(System test): 应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。这里所谓的系统不仅仅包括软件本身，而且还包括计算机硬件及其相关的外围设备，数据及其收集传输机构，甚至掌握计算机运行的人员及其操作等。 通常意义上的系统测试包括：功能测试、压力测试(Stress test)、性能测试(Performance test)、容量测试(Capacity test)、用户界面测试、兼容性测试等。

53 §4 软件测试的一般性理论 四、系统测试 压力测试：也称为强度测试。压力测试的目的就是在软件投入使用以前或软件负载达到极限以前，通过执行可重复的负载测试，预先分析出软件可承受的并发用户极限值和性能瓶颈，以帮助软件厂商或用户优化自己的程序。 容量测试: 对软件容量的测试，能让用户明白到底此软件能一次性承担多大访问量。有了对软件负载的准确预测，不仅能让用户对软件在实际使用中的性能状况充满信心，同时也可以帮助用户最经济地规划自己的网络配置，避免无谓的硬件投入，还可以减少网络系统的宕机时间和因此带来的经济损失。

54 §4 软件测试的一般性理论 四、系统测试 性能测试：对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能，系统性能测试就是为了完成这一任务。 压力测试、容量测试和性能测试的手段和方法很相似，有时可以交织在一起进行测试。压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷。容量测试和性能测试更着力于提供性能与容量方面的数据，以供制造者参考改进或进行广告宣传。

55 §4 软件测试的一般性理论 四、系统测试 功能测试

56 §4 软件测试的一般性理论 四、系统测试 用户界面的测试: 符合标准和规范 直观性 一致性 灵活性 舒适性 正确性 实用性

57 §4 软件测试的一般性理论 四、系统测试 兼容性测试/配置测试 例：网站测试用例设计矩阵表 向前和向后兼容 多版本的测试 PC
§4 软件测试的一般性理论 四、系统测试 兼容性测试/配置测试 向前和向后兼容 多版本的测试 例：网站测试用例设计矩阵表 PC Unix/Mac Win98 WinME WinNT Win2000 Solaris HP-UX OS IX OS X IE5 √ IE5.5 IE6 NS4.7 NS6.0 …

58 §4 软件测试的一般性理论 四、系统测试 其他还有一些关于测试的分类，例如：
§4 软件测试的一般性理论 四、系统测试 其他还有一些关于测试的分类，例如： 健壮性测试 容灾测试 内存泄漏测试 并发性测试 安全性测试 配套产品测试。 实际上，这些测试都是因为测试的目的不同，而在制定测试策略和测试设计的时候有不同的侧重点。

59 §4 软件测试的一般性理论 四、系统测试 测试规范 必做的测试： 可选的测试： 安装测试 功能测试 值域测试 界面测试 可用性测试
§4 软件测试的一般性理论 四、系统测试 必做的测试： 安装测试 功能测试 值域测试 界面测试 可用性测试 说明书测试 配置测试 加密问题测试 裸机测试 可选的测试： 内存泄漏测试 接口测试 性能测试 并发性测试 安全性测试 破坏性测试 配套产品测试 测试规范

60 §4 软件测试的一般性理论 四、系统测试 测试员的效率 平均每个工作日发现4-6个Bug 平均每修正3个Bug，会引进1个新的Bug
§4 软件测试的一般性理论 四、系统测试 测试员的效率 平均每个工作日发现4-6个Bug 平均每修正3个Bug，会引进1个新的Bug 平均75%的Bug会在单元测试阶段解决掉 平均20%的Bug会在集成测试和系统测试阶段解决掉 平均5%的Bug会被交付给用户

61 §4 软件测试的一般性理论 五、验收测试 系统测试结束后，在项目组看来开发和测试工作已经全部完成，可以交付使用，并与用户一起进行测试，以验证是否符合与用户事先约定的验收标准。 测试人员 产品经理或其他高级经理 开发工程师 测试工程师 用户

62 §4 软件测试的一般性理论 六、测试阶段与测试方法
§4 软件测试的一般性理论 六、测试阶段与测试方法 测试级 目的 执行者 测试环境 测试方法 单元 从单个模块中 发现逻辑、数据和运算缺陷 软件工程师 单独的；桩和支撑程序 白盒测试 集成 发现模块间接口缺陷 单独的和/或模拟；桩和支撑程序 Top-down, bottom-up, 或outside-in 系统 测定软件是否满足需求 软件质保组； 软件确认组 实际的环境（可能没有最终的硬件） 功能测试和ALAC 回归 确认软件经过一些小的变更或修改后是否仍满足所有的需求 验收 确定软件是否满足客户的需求 客户，软件质保组和/或项目组 实际的环境（通常在客户方） 功能测试和ALAC（客户可能有自己的测试方法）

63 测试阶段 主要依据 测试人员、测试方式 主要测试内容 单元测试 系统设计文档 由开发小组执行白盒测试 接口测试、路径测试 集成测试 需求文档 由开发小组执行白盒测试和黑盒测试 功能测试、性能测试 系统测试 由独立测试小组执行黑盒测试 功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试 验收测试 由用户执行黑盒测试

64 问题1：有了“黑盒”测试为什么还要“白盒”测试？
§4 软件测试的一般性理论 七、一些问题 问题1：有了“黑盒”测试为什么还要“白盒”测试？ 黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。 白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。

65 问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？
§4 软件测试的一般性理论 七、一些问题 问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？ 如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。

66 问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？
§4 软件测试的一般性理论 七、一些问题 问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？ 要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。

67 问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
§4 软件测试的一般性理论 七、一些问题 问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试? 不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。

68 §4 软件测试的一般性理论 七、一些问题 问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？
§4 软件测试的一般性理论 七、一些问题 问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？ 首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。 不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。

69 §4 软件测试的一般性理论 七、一些问题 问题6：能否将系统测试和验收测试“合二为一”？
§4 软件测试的一般性理论 七、一些问题 问题6：能否将系统测试和验收测试“合二为一”？ 系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。 系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。

70 §5 软件测试的挑战和问题 一、如何正确对待测试工作 １．明确测试工作意义 ２．加强责任心，疏忽可能造成恶果
３．学习——实践——钻研，积累经验， 　　努力提高业务水平 ４．处理好与编程人员关系

71 §5 软件测试的挑战和问题 对于测试人员的职业素质要求： 1、责任感 2、沟通能力、移情能力 3、独立的判断和自学习能力 4、耐心、自我督促
坚持原则、不放弃 有问题及时汇报 2、沟通能力、移情能力 与用户、项目组的沟通 3、独立的判断和自学习能力 坚持观点，不随声附和 喜欢探寻、钻牛角尖不一定是坏事情 4、耐心、自我督促 5、团队精神 与开发组整体为一个目标开展活动，有时需要妥协

72 §5软件测试的挑战和问题 二、测试工作评估问题 1. 你单位是否有专人负责测试工作？ 2. 你们是否有、是否用测试计划规范？
3. 你们是否有、是否用单元计划规范？ 4. 你们是否有、是否用测试报告规范？ 5. 测试过程（包括计划和实施）与整个开发过程是否并行开展？（测试在开发初期着手，在开发结束完成） 6. 测试能够确认规格说明得到正确的实现吗？ 7. 除规格说明以外，你能否确认用户的期望也能满足吗？ 8. 测试人员能验证开发的阶段（如需求和设计）的精确性和完全性吗？ 9. 测试人员向开发人员报告缺陷以期进一步采取措施吗？ 10. 在制定计划之前测试人员能估计业务风险吗？

73 §5 软件测试的挑战和问题 11. 针对被测软件是否提出了可度量的测试目标？ 12. 如已提出，它与商业风险有关吗？
13. 测试中发现的缺陷是否做了纪录和总结，使其用于改进开发过程和测试过程？ 14. 测试人员是否根据以前的工作经验判断可能的缺陷？ 15. 是否有改进测试过程的办法？ 16. 你为缺陷命名吗？ 17. 是否利用缺陷记录、总结和事故数据来评价测试过程的有效性？ 18. 是否采用度量（如千行代码缺陷数）来计划和评价测试过程？ 19. 是否已建立了测试人员的培训制度？ 20. 采用测试工具来支持测试过程吗？

74 三、不同等级的测试机构 否 状态 特点 1 17-20 把测试工作当作技艺(art) 测试依赖于测试人员个人的技巧和创造性
对测试人员无指导，无要求 测试工作效果不稳定，有时好，有时糟 顾客和用户不能靠测试的有效性判断质量 2 13-16 把测试工作当作工艺(craft) 有测试过程、规范、标准和测试计划 测试计划得不到实施 测试人员只热衷于找缺陷，报告开发人员 用户不信任测试过程，只好做验收测试 3 9-12 执行已确切定义的测试过程 测试过程已被定义，单位但未得到有效执行 测试工作针对规格说明，重视问题的需求 测试结束时没有提供表明被测软件能否投入使用的正式报告

75 三、不同等级的测试机构 4 5-8 先进的测试机构 有明确的测试目标，可优化利用测试资源实现目标 重视测试过程薄弱环节的改进 5 0-4
最先进的测试机构 测试工作基于降低风险，测试人员工作有效 测试得到度量，过程得到很好定义 缺陷得到记录、分析和总结，且用其改进过程 测试成本显著下降 顾客和用户相信测试过程，不依靠验收测试取得满意产品

76 §5 软件测试的挑战和问题 四、小结 １选择测试用例是测试工作的关键 ２测试的有效性不应被忽视测试后评审其充分性 ３重要的是何时停止测试 ４回归测试一定不可省

77 §5 软件测试的挑战和问题 五、经验之谈 测试能提高软件的质量，但是提高质量不能依赖测试。
§5 软件测试的挑战和问题 五、经验之谈 测试能提高软件的质量，但是提高质量不能依赖测试。 测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。 测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。 每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。 80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错 测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。