《软件测试》

1.4 软件缺陷的修复费用

随着时间的推移，从说明书、设计、编码、测试、发布阶段。修复软件缺陷的费用指数级地增长。

beta测试：将软件的初期版本分发给一小部分客户使用。

1.5 软件测试员的目标

尽可能早地找出软件缺陷，并确保其得以修复。

2.3软件开发的生命周期

软件开发生命周期模式：软件产品从最初构思到公开发行的过程。

• 大爆炸模式
• 边写边改模式
• 瀑布模式
• 螺旋模式

2.3.1 大爆炸模式

计划、进度安排和正规开发过程几乎没有，所有精力都花在开发软件和编写代码上。

• 优点：简单。
• 测试的作用：报告发现的问题让客户知道。

大爆炸模式几乎不可能进行测试的两个原因

• 一股脑交付软件，即使能够找出软件出现缺陷的原因，也非常困难。
• 软件缺陷众多、相互隐藏。即使发现了缺陷，还是会发现软件仍然不行。

2.3.2 边写边改模式

项目小组未刻意采用其他开发模式时默认的开发模式。

• 优点：由于开头几乎没有计划和文档编制，项目小组得以迅速展现成果，适合希望快速制作而且用完就扔的小项目，例如原型范例和演示程序。
• 测试员的挑战：频繁拿到新的软件版本并着手进行测试。新版本出来时，旧版本的测试可能尚未完成，而新版本还可能包含新的或者经过修改的功能。最后对几乎所有功能进行测试，直到发布软件。

2.3.3 瀑布模式

采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。

构思->分析->设计->开发->测试->最终产品

每个步骤结束时，项目小组组织审查，并决定是否进入下一步。直到项目准备好时才进入下一步。
注意：

• 瀑布模式非常强调产品的定义。开发或者代码编制阶段只是其中单独的一块。
• 瀑布模式各步骤是分立的，没有交叉。
• 瀑布模式无法回溯。
• 目标：在编写代码之前解决所有的未知问题并明确所有细节。
• 测试的便利：由于软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。因此测试小组得以制定精确到计划和进度。
• 缺点：测试仅在最后进行，一些根本性问题可能出现在早期，但知道准备发布产品时才可能发现，此时修复会带来巨大费用。

2.3.4 螺旋模式

总体思想：一开始不必详细定义所有细节，从小开始，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。重复上述过程，知道得到最终产品。
每一次循环包含6个步骤：

1. 确定目标、可选方案和限制条件。
2. 明确并化解风险。
3. 评估可选方案。
4. 当前阶段开发和测试。
5. 计划下一阶段。
6. 确定进入下一阶段的方法。

4. 检查产品说明书(静态黑盒测试)

4.1.1 黑盒测试和白盒测试

黑盒测试(功能测试或行为测试)：只关心软件要做什么。
白盒测试：可以访问软件内部代码。

4.1.2 静态测试和动态测试

静态测试：测试不运行的部分——检查和审核。
动态测试：使用和运行软件。

5. 动态黑盒测试

5.3 等价类划分

一个等价类或等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。

5.4 数据测试

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。
是所有这些数据得以测试的技巧是，根据一些关键的原则进行等价类划分：

• 边界条件
• 次边界条件
• 空值
• 无效数据

5.4.1 边界条件

由于软件容易在边界上产生缺陷，因此，如果要从等价划分中选择包含的数据，从边界条件中选择会找出更多的缺陷。
提出边界条件时，一定要测试靠近边界的有效数据，即测试最后一个可能有效的数据，同时测试刚超过边界的无效数据。
越界测试的做法通常是简单地对于最大值加一或者很小的数，以及对于最小值减一或者很小的数。

缓冲区溢出是由边界条件缺陷引起的，它是造成软件安全问题的头号原因。

5.4.2 次边界条件

上面讨论的普通边界条件在产品说明书中有定义，或者在使用软件的过程中很明显。而有些边界在软件内部，最终用户几乎看不到，但是软件测试员仍有必要进行检查。这样的边界条件称为次边界条件，或者内部边界条件。如ASCII码。

5.4.3 默认、空白、空值、零值和无

一定要考虑建立处理默认值、空白、空值、零值或无输入等条件的等价划分。

不能把他们与合法情况和非法情况混在一起，而要建立单独的等价划分。

5.4.4 非法、错误、不正确和垃圾数据

数据测试的最后一种类型是垃圾数据。这是失效性测试的对象。经过边界测试、次边界测试、默认值和空值等通过性测试证实软件能够工作之后，就该进行垃圾数据测试了。

5.5 状态测试

到目前为止，我们测试的是数据——数字、文字、软件输入和输出。软件测试的另一方面是通过不同的状态验证程序的逻辑流程。

软件状态是指软件当前所处的条件或模式。软件测试员必须测试程序的状态及其转换。

5.5.1 测试软件的逻辑流程

运用等价划分技术选择状态和分支。

1. 建立状态转换图
   状态转换图可能作为产品说明的一部分给出。否则就需要创建一个状态图。状态转换图应该表示出以下项目。
   • 软件可能进入的每一种独立状态。
   • 从一种状态转入另一种状态所需的输入和条件。
   • 进入或退出某种状态时的设置条件以及输出结果。
2. 减少要测试的状态及转换的数量
   • 每种状态至少访问一次。
   • 测试看起来是最常见和最普遍的状态转换。其依据是进行产品说明书的静态黑盒分析时收集到的信息。
   • 测试状态之间最不常用的分支。
   • 测试所有错误状态及其返回值。
   • 测试随机状态转换。
3. 进行具体测试
   确定要测试的状态以及其转换后，就可以定义测试用例了。测试状态以及转换包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等。

5.5.2 失败状态测试

以上探讨的状态测试都属于通过性测试，包括审查软件、描绘状态、尝试各种合法可能性、确认状态及其转换正常。和数据测试一样，相反的做法是找到是测试软件失败的案例：

• 竞争条件
• 重复、压迫和负重

1. 竞争条件和时序错乱
   此类测试难以设计，最好熟悉仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。尝试同时做几件事。迫使软件执行某一功能时出现与自己竞争的状况。
2. 重复、压迫和重负
   • 重复测试：不断执行同样的操作。检查是否存在内存泄漏。如果以前使用的某个程序在开始启动时工作状况良好，但是随后变得越来越慢，或者经过一段时间就表现得不稳定，原因就可能是内存泄漏缺陷。
   • 压迫测试：使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制调解器速率低等。观察软件对外部资源对要求和依赖程度。目的在于尽可能地限制软件的必要条件。
   • 重负测试：让软件处理尽可能大的数据文件。最大限度地发掘软件的能力，让其不堪重负。

6. 检查代码(静态白盒测试)

静态白盒测试是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构化分析。

7.动态白盒测试(结构化测试)

动态白盒测试是指利用查看代码功能和实现方式得到的信息来确定哪些需要测试、哪些不要测试、如何开展测试。
动态白盒测试不仅查看代码的运行情况，还包括直接测试和控制软件。包括以下四个部分：

• 直接测试底层函数、过程、子程序和库。
• 以完整程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试用例。
• 从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行。
• 估算执行软件时“命中”的代码量和具体代码，然后调整测试，去掉多余的测试用例，补充遗漏的用例。

总是首先基于对软件行为操作的认识程度来设计黑盒测试用例，然后利用白盒测试技术进行检查使其更加有效。在检查时，要谨慎去除黑盒测试的必要测试用例。

7.2 动态白盒测试和调试

动态白盒测试的目标是寻找软件缺陷，调试的目标是修复缺陷。
软件测试员应该把问题缩减为能够演示软件缺陷的最简化测试用例。如果是白盒测试，甚至还要包括那些值得怀疑的代码行信息。进行调试的程序员从这里继续，判断到底是什么导致软件缺陷，并设法修复。

7.3 分段测试

7.3.1 单元测试和集成测试

• 单元测试/模块测试：在底层进行的测试。
• 集成测试：单元经过测试，底层软件缺陷被找出并修复后，就集成在一起，对模块的组合进行集成测试。
• 系统测试：这个不断增加的测试过程继续进行，加入越来越多的软件片段，知道整个产品——至少是产品的主要部分——在称为系统测试的过程中一起测试。

这种递增测试有两条途径自底向上和自顶向下。

测试驱动和测试桩的差别

• 测试驱动用于自底向上的测试。它是代替高级软件，更有效地运行低级模块的测试代码。
• 测试桩用于自顶向下的测试。它用自己替换低级模块。其对于要测试的高级代码，外面和行为就像低级模块一样。

7.4 数据覆盖

数据包括所有的变量、常量、数组、数据结构、键盘和鼠标输入、文件、屏幕输入/输出，以及调制调解器、网络等其他设备等输入和输出。

7.4.1 数据流

数据流覆盖主要是指在软件中完全跟踪一批数据。如果在底层测试函数，就会使用调试器观察变量在程序运行时的数据。通过黑盒测试只能知道变量开始和结束的值。通过动态白盒测试，还可以在程序运行期间检查变量的中间值。根据观察结果就可以决定更改某些测试用例，保证变量取得感兴趣的、甚至具有风险的中间值。

7.4.2 次边界

仔细检查代码，并询问编写代码的程序员，找到次边界条件，并建立能测试它们的测试用例。

7.4.3 公式和等式

7.4.4 错误强制

7.5 代码覆盖

为了全面地覆盖，还必须测试程序的状态以及程序流程，必须设法进入或退出每一个模块，执行每一行代码，进入软件每一条逻辑和决策分支。这种类型的测试叫作代码覆盖测试。

利用代码覆盖率测试分析器的数据可以得到：

• 测试用例没有覆盖软件的哪些部分。如果某个模块中的代码从未执行，就需要额外编写测试该模块函数的用例。
• 哪些测试是多余的。如果执行一系列测试用例，而未增加代码覆盖率的百分比，那么这些测试用例就可能处于同一个等价划分。
• 为了使覆盖率更好，需要建立什么样的新测试用例。通过观察覆盖率低的代码，看它如何工作，做了什么，从而建立可以更彻底地测试它的新测试用例。

如果测试用例覆盖了软件的90%而未发现任何软件缺陷，就说明软件质量非常好。但根据杀虫剂现象——软件测试得越多，它对测试的免疫能力越强。所以也有可能是软件对测试具有了免疫能力，增加新的测试用例可能会暴露余下的10%具有非常多的缺陷。

7.5.1 程序语句和代码行覆盖

语句覆盖或者代码行覆盖是代码覆盖最直接的形式，其目标是保证程序中每一条语句最少执行一次。但即使全部语句都被执行了，也不能说走遍了软件的所有路径。

7.5.2 分支覆盖

试图覆盖软件中的所有路径称为路径覆盖。分支覆盖测试是路径覆盖最简单的形式。

大多数代码覆盖率分析器将根据代码分支，分别报告语句覆盖和分支覆盖结果。

7.5.3 条件覆盖

条件覆盖测试将分支语句的条件考虑在内。

代码覆盖率分析器可以设置为在报告结果时将条件考虑在内。如果测试条件覆盖，就能达到分支覆盖，顺带也能达到语句覆盖。

8. 配置测试

配置测试是指使用各种硬件来测试软件运行的过程。

如何保证软件永远不会有配置问题？

• 把硬件和软件打成一个包，软件只能在该硬件上运行，硬件必须完全密封，没有连接到外界对单独接口。

8.1.1 分离配置缺陷

判断缺陷是配置问题而不仅仅是普通缺陷最可靠的方法是，在另一台有完全不同配置的计算机上一步步执行导致问题的相同操作。

8.1.2 计算工作量

采用等价划分减少工作量。

8.2 执行任务

8.2.1 确定所需的硬件类型

用于等价划分硬件的原则有

• 流行程度
• 年头
• 地区和国家
• 客户或者业务

8.2.2 确定有哪些厂商的硬件、型号和驱动程序可用

8.2.3 确定可能的硬件特性、模式和选项

8.2.4 将确定后的硬件配置缩减为可控制的范围

8.2.5明确与硬件配置有关的软件唯一特性

不应该也没有必要在每一种配置中完全测试软件，只需测试那些与硬件交互时互不相同（不同等价划分）的特性即可。

• 首先进行黑盒测试，通过查看产品找出明显的特性。
• 然后与小组其他成员交谈，了解其内部的白盒情况。
• 最后找到这些特性与配置的关联。

8.2.6 设计在每种配置中执行的测试用例

8.2.7 在每种配置中执行测试

8.2.8 反复测试知道小组对结果满意为止

9. 兼容性测试

软件兼容性测试是指检查软件之间是否能够正确地交互和共享信息。

9.2 平台和应用程序版本

9.2.1 向后和向前兼容

向后兼容：可以使用软件的以前版本。
向前兼容：可以使用软件的未来版本。

进行向前兼容性测试的方法是，完整细致地将测试定义在可以作为标准之处，从而使该标准称为判定向前兼容性测试的手段。

9.2.2 测试多个版本的影响

新操作系统平台的兼容性测试：在开始兼容性测试任务之前，需要对所有可能的软件组合等价划分，使其成为验证软件之间正确交互的最小有效集合。
新应用程序：需要决定在哪个平台版本上测试软件，以及和什么应用程序一起测试。
决定要选择的程序的原则：

• 流行程度
• 年头
• 类型
• 生产厂商

9.3 标准和规范

9.3.1 高级标注和规范

如果某个应用程序声称与某平台兼容，就必须遵守该平台自身的标准和规范。

9.3.2 低级标准和规范

例如文件格式、通信协议、编程语言语法以及程序用于共享信息的任何形式都必须符合公开的标准和规范。

9.4 数据共享兼容性

10 外国语言测试

11 易用性测试

11.1 用户界面测试

用户界面或UI：用于与软件程序交互的方式。

11.2 优秀的UI

7个要素：

1. 符合标准和规范
   如果测试在特定平台上运行的软件，就需要把该平台的标准和规范作为产品说明书的补充部分，根据它建立测试用例。
2. 直观
3. 一致
   在审查产品时参考以下几个基本术语在整个软件或软件之间是否一致：
   • 快速键和菜单选项
   • 术语和基本命名
   • 听众
   • 按钮的位置
4. 灵活
   灵活性会影响到状态和数据的测试
   • 状态跳转
   • 状态终止和跳过
   • 数据输入和输出
5. 舒适
   • 恰当：软件对于想执行的任务既不要太夸张也不要太朴素。
   • 错误处理
   • 性能：提示信息不能一闪而过。如果操作缓慢，至少应该向用户反馈操作持续时间，并且显示它正在工作。
6. 正确
7. 实用

11.3 为残障人士测试：辅助选项测试

针对视力、听力、运动和认知障碍，测试键盘、鼠标、声音和显示的部分。

12 文档测试

12.1 软件文档的类型

• 包装文字和图形
• 市场宣传材料、广告以及其他插页
• 授权/注册登记表
• 最终用户许可协议
• 标签和不干胶条
• 安装和设置指导
• 用户手册
• 联机帮助
• 指南、向导和计算机基础训练
• 样例、示例和模版
• 错误提示信息

12.3 审查文档

两个的等级：

• 非代码：技术编辑或技术校对
• 和代码紧密结合：动态测试

仔细阅读，按照每个步骤操作，检查每个图形，尝试每个示例。如果有简单的代码，测试代码是否按照描述的方式运行。

13 软件安全性测试