《软件测试的艺术》读书总结

本文通过软件测试基础、测试用例设计、测试的种类、互联网应用测试、敏捷中的测试、调试六个方面进行总结。

一. 测试的基础

定义：测试是为发现错误而执行程序(文档测试就不是执行程序)的过程。
目标：通过有限的测试(用例)，最大限度的提高发现问题的数量，以取得最好的测试效果。

软件测试最普遍的两种手段

黑盒测试：数据驱动的测试或者输入/输出驱动的测试，’穷举输入’；
白盒测试：逻辑驱动的测试，检查程序的内部结构

软件测试10项原则

测试用例中一个必须的部分是对预期输出或结果的定义
程序员应当避免测试自己编写的程序
编写软件的组织不应当测试自己编写的软件
应当彻底检查每个测试的执行结果
测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况
检查程序是否’未做其应该做的’仅是测试的一半，测试的另一半是检查程序是否‘做了其不应该做的’
应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
计划测试工作时不应默许假定不会发生错误
程序某部分存在更多错误的可能性，与该部分已发生错误的数量成正比
软件测试是一项极富创造性，极具智力挑战性的工作

二. 测试用例的设计

包括白盒测试，黑盒测试，错误猜测，测试组合策略

白盒测试：语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，多重条件覆盖

If A and B then Action1
If C or D then Action2

语句覆盖：保证程序中的语句都执行一遍即可
A=true B=true C=true
判定覆盖：保证程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假均曾被满足
（1）A=true，B=true，C＝true，D=false（2）A=true，B=false，C＝false，D=false
条件覆盖：保证每个判断中的每个条件的可能取值至少满足一次
A=true/false B=true/false C=true/false D=true/false, so （1）A=true，B=true，C＝true，D=true（2）A=false，B=false，C＝false，D=false
判定/条件覆盖：保证判断中每个条件的可能结果至少执行一次，每个判断的所有可能结果至少执行一次
（1）A=true，B=true，C＝true，D=false（2）A=true，B=false，C＝false，D=false （3）A=false，B=true，C＝false，D=true
多重条件覆盖：将每个判定中的所有可能的条件结果的组合，以及所有入口点都至少执行一次
（1）A=true，B=true，C＝true，D=false（2）A=true，B=false，C＝false，D=false （3）A=false，B=true，C＝false，D=true（4）A=false，B=false，C＝true，D=true

黑盒测试：等价划分，边界值分析，因果图
等价划分：1）确定等价类(‘有效’，‘无效’)；2）生成测试用例
边界条件：输入和输出等价类中那些恰好处于边界，或者超过边界，或在边界值以下的状态

检查结果空间的边界很重要，因为输入范围的边界并不总能代表输出范围的边界情况（三角正弦函数sin)

因果图：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可
以通过因果图转换为判定表，从而设计相应的测试用例。

错误猜测：利用直觉和经验猜测出错的可能类型，然后编写测试用例来暴露这些错误
测试组合策略：多种测试用例设计组合而成的一个整体的策略(例如白盒和黑盒测试用例设计的组合测试)。

组合策略要求：

规格说明中包含条件组合的情况，应首先使用因果图分析方法
任何情况下都应使用边界值分析方法
应为输入和输出确定有效和无效等价类
使用错误猜测技术增加更多的测试用例

三. 测试的种类

从传统的开发模式，执行测试的顺序和粒度，分为单元测试，集成测试，功能测试，系统测试，验收测试，安装测试

开发过程与测试过程的对应关系：

测试与开发过程对应关系图.jpeg

1. 模块(单元)测试

单元测试：是对程序中的单个子程序，子函数或过程进行测试的过程。

目前大多数的单元测试其实都是黑盒测试，包括开发人员自己写的单元测试也是黑盒测试，只有像自动扫描这种对每行代码逻辑的测试才是真正使用的白盒测试，彻底的单元测试需要使用增量策略

2. 集成测试(增量测试)：

分为自顶向下的增量测试与自底向上的增量测试
测试单独的模块需要有个特殊的驱动模块和一个或多个桩模块。自顶向下测试更侧重于编写桩模块，自底向上测试更侧重于编写驱动模块
增量测试的优缺点：
1）非增量测试所需的工作量要多一些（需要更多的驱动模块和桩模块，而自顶而下的增量测试只需要桩模块，自底而上的增量测试只需要驱动模块）
2）增量测试可以尽早发现模块中与不匹配接口，不正确假设相关的编程错误，容易调试（由于可以尽早地对模块组合进行集成测试）
3）增量测试使用先前测试过的模块，取代了非增量测试中使用的桩模块或驱动模块，所以实际模块经受了更多的检验
4）模块测试阶段开始时，若使用非增量测试，就会有更多机会进行并行操作

3. 功能测试

功能测试通常是一项黑盒操作。用来发现程序与其外部规格说明之间存在不一致的过程。常用等价类划分，边界值分析，因果图分析和错误猜测方法。

4. 系统测试

系统测试的目的就是将系统或程序与其初始目标进行比较。含义：

系统测试不局限于系统，可能是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程
根据定义，如果产品没有一组书面的，可度量的目标，系统测试也就无法进行。

系统测试分类：

分类	说明
能力测试	确保程序的目标功能实现(目标和用户文档进行比较)
性能测试	评估程序的响应时间及吞吐量瓶颈
强度测试	发现在大规模负载，高强度不间断持续的数据处理中的异常
容量测试	发现处理大容量数据时的程序异常
安全性测试	试图攻破程序的安全防线
兼容性测试	评估新版本能否兼容老的版本
可用性/用户体验测试	评估最终用户在使用软件与软件交互时的可用性问题
存储测试	确保程序可以正常处理其对存储的需求，包括系统的存储和物理上的存储
可靠性测试	评估程序能达到规格说明中运行时长和平均故障间隔时间要求
可恢复性测试	测试系统恢复相关的功能是否按照设计要求实现
可维护性/服务测试	评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需
配置测试	检查程序是否能在推荐配置上流畅运行
安装测试	确保能够在所有支持的平台上安装软件
文档测试	校验所有的用户文档是否准确
过程测试	对软件系统操作或维护所设计的流程进行评估和确定

三种测试的区别：

模块测试的目的是发现程序模块与其接口规格说明之间的不一致

功能测试的目的是为了证明程序未能符合其外部规格说明

系统测试的目的是为了证明软件产品与其初始目标不一致

系统测试中的可用性(用户体验)测试
是一种黑盒测试。测试从功能缺陷到不符合人机工程学的设计失误。

准备真实、可重复的试验场景 -> 测试人员选取(优秀的测试员、用户) -> 数据采集(沟通、调查问卷等)

目标：

是否容易上手
对用户操作是否及时作出反应
系统是否存在太多选项（流程的简易性）
是否有助于用户的准确输入
是否在众多的功能和菜单中来回切换不发生意外

5. 验收测试

验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程。该测试通常是由程序的客户或最终用户来进行。

6. 安装测试

安装测试的目的不是为了发现软件中的错误，而是为了发现在安装过程中出现的错误。

四. 互联网应用测试

基于web的应用系统基本结构分为表现层，业务层，数据层

挑战

用户群庞大而五花八门(能力、使用浏览器、操作系统、设备种类、访问网站的信道速率等)。
业务环境(电商网站考虑计算税率，判断运输成本，跟踪用户资料等问题)。
地点(国际化问题，语言翻译、时差及货币兑换等)。
安全性(防止黑客攻击，导致系统瘫痪，丢失信息等)。
测试环境(使用和软件运行相同的环境)。

测试策略

表现层

内容测试。包括字体，色彩，内容，布局，分辨率等。
web站点结构。检查无效的link或者image。
用户环境。测试不同浏览器版本，系统配置，兼容性等。

业务层

性能。能够满足规格说明，包括响应时间和吞吐量等。
数据有效性。发现从客户那采集到的数据的有效性。
事务。发现事务处理过程中的错误。包括信用卡处理，电子邮件验证等。
不仅需要测试内部业务过程，也要测试外部接口

数据层

响应时间。量化查询语言SQL语句的消耗时间。
数据完整性。验证数据存储适当且正确。
容错性和可恢复性。验证最大化的平均故障间隔时间(MTBF)和最小化的平均故障恢复时间(MTTR)。

五. 敏捷中的测试

敏捷：无固定的开发过程。三个特性：依赖客户参与、测试驱动、紧凑的开发周期
敏捷中的测试：通过持续的测试反馈推动项目前行，帮助开发这修复bug，改变需求设计以及其他一般性质量提升。敏捷测试依赖于自动化测试(及时反馈，更可靠)。
极限开发中的测试：单元测试和验收测试(自动或者非自动化)组成（在创建开发代码库之前创建）

六. 调试

执行测试用例成功捕获错误之后需要进行调试，找到错误根源。
调试种类

蛮力调试。程序中插入打印语句或debug工具等
归纳调试。从错误症状或线索起步，进行全局归纳分析
演绎法调试。通过排除法，逐层分析，定位错误
回溯法调试。从程序错误的地方往前回溯，定位错误
测试法调试。通过测试用例来发现错误所在。通常和归纳法或演绎法一起使用。