软件测试基本理论和方法

5
2、测试的原则
• 一个好的测试用例具有较高的发现过去未被发 现过的错误的概率，而不应只表明程序运行正 常 • 自己不能测试自己编写的程序 • 对期望结果的描述是每个测试用例的必要组成 部分 • 杜绝不能重现或匆忙的测试 • 既要编写使用有效输入条件的测试用例，也要 编写使用非法输入条件的测试用例 • 深入细致地审查测试结果
CSIA软件测试工程师培训
软件测试基础理论与方法
1
引
言
软件测试是保证软件质量的重要技 术手段
– 测试理论和测试方法 – 测试过程及测试的管理 – 测试工具
2
测试的原则
原则一：穷尽测试是不可能的
原则二：测试工作具有创造性，但很困难
原则三：测试旨在防止错误的发生
原则四：测试是有风险的
原则五：测试需要有计划性
11
4.2、集成测试
• 集成测试的目的是当模块组装后查找模 块间接口的错误
12
4.3、确认测试
• 确认测试的目的是确定软件是否满足软 件需求规格说明所提出的所有需求
13
4.4、验收测试
• 用户参与的确认测试
14
5、测试方法
• • • • • 黑盒测试方法 白盒测试方法 自顶向下方法 自底向上方法 模拟用户操作测试方法
标识测试条件的活动最好与开发活动（即V模型
左边的活动）并行开展
30
测试活动 2 —设计阶段
内容：设计测试用例、预期结果

测试用例（test case）是按一定顺序执行的与测试目标
（test object, 测试理由或目的）相关的一系列测试。

测试用例设计将产生许多测试所包括的运行测试的有关 信息（如环境要求，也称为先决条件）、输入值、期望 结果。
15
5.1、黑盒测试方法
• 黑盒测试也称功能测试或数据驱动测试， 它是在已知产品所应具有的功能，通过 测试来检测每个功能是否都能正常使用。
Biblioteka Baidu16
6.5.2、白盒测试方法
• 白盒测试也称结构测试或逻辑驱动测试， 它是知道产品内部工作过程，可通过测 试来检测产品内部动作是否按照规格说 明书的规定正常进行。

测试脚本（test script）是具有正规语法的数据和指令的集合，在测 试执行自动工具使用中，通常以文件形式保存； 必须先完成测试用例的先决条件（precondition），然后再执行测试。 测试用例可能要求专门的硬件或软件，如网络环境或打印机等； 期望输出可以组成文件形式用于自动工具。 对于手动测试，期望输出仅仅只是简单地记录在手工测试过程或脚本 中。 对于自动测试，其期望输出比设置用于手工测试的期望输出复杂得多。 在自动工具中要求每项内容都要拼写正确，而在手工测试中要求没这 么严格。 测试开发的任何工作可以提前进行（相对V模型左边的活动进行），以 后可以节省时间。
Code and spec modification
8
Internal design verification
Integration validation
39
测试的生命周期

在软件开发生命周期中，软件是通过 迭代来不断加以完善的。 在这种环境中，对于每个作为测试目 标的工作版本，测试的生命周期还都 必须具有一种迭代方法。



35
软件测试与软件工程模型
V模型介绍 需求 概设 详设
测试
验收测试 系统测试 集成测试
测试
测试
编码
测试
单元测试
扩展：左边的每一部分还包括评审，也是测试任务。
36
测试设计基于需求分析
• 缺陷预防：是指各种错误遗留到后续开发阶段之前， 运用各种技术和过程来发现和避免这些错误。
• 最有效的测试工作应该开始于需求； • 对于每一条需求，如果可以设计出一个过程来执行所 测试的功能，若输出结果是可以预先知道的，并且能 够通过编程或者人工方法加以验证，则称该需求是可 测试的； • 测试人员需要彻底了解产品，只有这样他们才能设计 出更出色和更全面的测试计划，测试设计和测试过程 和测试用例。
1. 检测软件质量的有效性，是否能发现缺陷，或至少可 能发现缺陷； 2. 可仿效的测试用例可以测试很多内容，因而减少测试 用例的数量； 3. 经济性，测试用例的执行、分析和调试是否经济 4. 测试用例的可修改性，每次软件修改后对测试用例的 维护成本
如何实现？？
28
测试活动
计划 编制测试计划：标志测试条件（确定测试什么）和测试的优先级
将测试结果与期望输出进行比较

应该对每次测试的实际输出进行分析研究，判断软件功 能是否正确。
验证可以是测试者的主观判断，也可以是将实际输出与 期望输出进行严格准确的比较。 信息比较，如可以在执行测试时进行显示屏幕上的信息， 另一些输出比较，如修改数据库记录，只能在测试执行 结束后进行。 自动测试一般结合了信息比较的两种方法。
6
2、测试的原则
• 如果一段程序中发现的缺陷数量增加，则意味 着有更多未被发现的缺陷的可能性也在增加 • 让最优秀的人员去完成测试 • 保证软件可测试性是软件设计的一个重要目标 • 不要为了测试方便而修改程序 • 测试工作必须在任务建立之初就确定目标
7
3、测试的层次结构
白盒 黑盒 自顶向下 自底向上 模拟用户操作
Code and spec modification 11 System and acceptance validation
1 Requirements verification
Functional design specification 2 3
Product simulation 9 Usability test 6
原则六：测试需要有独立性
3
软件测试技术基础
6.1、测试的目的 6.2、测试的原则 6.3、测试的层次结构 6.4、测试阶段 6.5、测试方法 6.6、测试种类 6.7、测试自动化 6.8、小结
4
1、测试的目的
• 测试是通过运行程序来发现错误的过程 • 测试可以说明软件存在错误，但不能说 明它不存在错误 • 目的：用相对少的测试尽可能多地找到 程序中的缺陷
期望输出
显示订单确认信息 打印具有正确细目购 置订单 打印的新订单报表就 是新创建的订单 打印正确的取消购置 订单信息 无打印订单输出
测试条件
VB10 VB20 VB10 VB10 VB23 VB8 VB8
32
打印新订单报表 取消订单 打印新订单报表
测试活动 3—开发阶段
开发测试用例包括: 准备测试脚本、测试输入、测试数据以及期望输出。
阶段
验收测试 确认测试 集成测试 单元测试
方法
类型
举例： •功能 •算法 •正向 •反向 •可用性 •边界
8
4、测试阶段
• • • • 单元测试 组装测试 确认测试 验收测试
9
4.1、单元测试
• 单元测试的目的是在一个隔离环境中对 独立的软件模块进行测试以发现其中的 缺陷。
10
4.1、单元测试
• 效率。测试工具减少了执行测试案例的时间，有更
• 准确度和精确度。尝试执行百个测试用例之后，
注意力就会分散，开始犯错误。测试工具每次执行同 样的测试，并毫无差错地检查结果。
途而废。
• 坚持不懈。测试工具和自动化永远不会累倒或半
22
6.7.2、主要分类
• • • • • • • 回放类型自动测试工具 代码分析器：复杂度等 覆盖分析器 内存分析器 强度测试工具 web测试工具 其它——测试用例管理、文档管理、bug reporting、配置管理
17
6.5.3、自顶向下或自底向上方法
• 依据模块在模块层次中的位置，对模块 组装并测试，属于增量组装测试方法。
18
6.5.4、模拟用户操作测试方法
• 着重对那些用户可能发现的错误进行测 试及修改工作
19
6.6、测试类型
• • • • • • • • 功能测试 算法测试 正向测试 反向测试 可使用性测试 边界测试 平台测试 负载/强度测试
20
6.7、自动化测试
• • • • 6.7.1、属性及优点 6.7.2、主要分类 6.7.3、实现类型 6.7.4、注意的问题
21
6.7.1、属性及优点
• 速度。例如手工测试Windows计算器，假定平均每5
秒钟执行一个测试案例，那么数千个案例需要数小时 的时间。而自动化能够以成千上万倍的速度来执行。 多的时间进行测试计划考虑新的测试用例。
Code and spec modification 10 Function validation
Functional design verification
Internal design specification
4
Code 5 Code verification
Code and spec modification 7 Unit validation

期望输出包括应输出或建立的内容，应修改或更新或应 删除的内容。期望输出集可以是一个很大的集合。
31
测试活动
测试用例：POS1036 先决条件： 作为数据输入员注册到定单系统显示的主菜单 数据库系统必须含有标准数据集合 确保系统中没有其他活跃的新定单活动
步骤
1 2 3 4 5
输入
建立用任何一个标准 的订单项建立一个新 订单，设置订单数为 100 确认订单
设计
设计测试用例（确定怎么测试）
开发
测试开发（设计脚本、数据等）
执行
执行测试用例
评估
将测试结果与期 望结果进行比较
29
测试活动 1—计划阶段
内容：人员、进度、资源。
测试条件取决于被测试验证的项目或事件。
测试条件是被测环境的描述。可以用多种方式描
述：如简单的语言，表格项形式或类似于流图的
图表形式；
40
测试的生命周期
41
测试活动的信息流
被测模块 单元 测试 设 计 信 息
集成 测试
软 件 需 求
确认 测试
系统 其他 元素
客 户 参 与
验收 测试
被测模块
单元 测试
系统 测试
被测模块
单元 测试
已经测 试过的 模块
已集 成的 软件
已确 认的 软件
可交 付的 软件
42
测试阶段的信息流
测试阶段的输入信息有两类：
23
6.7.3、实现类型
• 宏录制和回放。
最基本的测试自动化类型时录制第一次执 行测试用例时的键盘和鼠标操作，然后在需 要重新执行时回放
• 可编程的宏
编写回放系统遵守的简单指令
• 完全可编程的自动测试工具
提供编程语言
24
6.7.4、注意的问题
• • • • • 软件变更 人眼和直觉是不可替代的 验证难以实现 容易过分依赖自动化 不要花费太多时间使用达不到测试软件目的的 测试工具和自动化 • 编写宏、开发工具都属于开发工作，应该遵守 要求程序员遵守的相同标准和规范 • 某些工具是侵入式的，可能导致测试的软件不 正常失败。
33

测试活动 4—执行阶段
执行测试用例
对于手动测试：
测试者按事先准备好的手工过程进行测试， 测试者输入数据、观察输出、记录发现的问 题。 对于自动测试： 可能只需要启动测试工具，并告诉工具执行 哪些测试用例； 测试执行只能在软件开发完成后进行，即V模 型右边的活动。
34
测试活动 5—评估阶段
25
6.8、小结
测试的目的 测试的原则 测试的层次结构 测试阶段 测试方法 测试种类 测试自动化
26
软件测试理解
1 软件测试活动
2 测试过程
3 测试方法
4 测试类型
5 测试策略
6 小结
27
1 软件测试活动
• 测试是从大量的测试用例中选择有限的测试用例 发现软件中的大部分缺陷的一种技术 • 好的测试用例的4个特性：
37
测试人员及早介入
• 避免在项目生命周期中的后续阶段对产 品的功能行为不理解 • 了解应用程序的哪些方面对最终用户而 言是最关键以及哪些元素的风险最大 • 测试重点放在应用程序中最重要的部分， 避免对不经常使用的部分过度测试而对 重要的部分又测试不充分。
38
Requirements specification
软件配置：这是测试的对象，包括
需求说明书 设计说明书 被测的源程序等。
测试配置：包括
测试计划 测试步骤 测试用例（测试数据） 具体实施测试的测试程序 测试工具等
43
RUP中 定义
测试的目的在于：





Finding and documenting defects in software quality. Generally advising about perceived software quality. Proving the validity of the assumptions made in design and requirement specifications through concrete demonstration. Validating the software product functions as designed. Validating that the requirements have been implemented appropriately.