《软件测试的艺术》读书笔记

1  一次自评价测试

所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该执行的功能。

2  软件测试的心理学和经济学

2.1  软件测试的心理学

软件测试是为发现错误而执行程序的过程。

2.2  软件测试的经济学

要想完全测试一个软件不论是从黑盒测试还是白盒测试的角度来看都是不可能的。那我们要做的就是如何提供性价比高的测试用例。

2.3  软件测试的原则

原则1：测试用例中一个必须的部分是对预期输出或结果的定义

原则2：程序员应当避免测试自己编写的程序

原则3：编写软件的组织不应当测试自己编写的软件

原则4：应当测底检查每个测试的执行结果

原则5：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况

原则6：检查程序是否“未做其应当做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”

原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件

原则8：计划测试工作时不应该默许假定不会发现错误

原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比

原则10：软件测试是一项极富创造性、极具智力挑战性的工作

3  代码检查、走查与评审

代码检查、走查以及可用性测试是三种主要的人工测试方法

3.1  代码检查

代码检查：以组为单位阅读代码

检查过程：1）由程序编码人员逐条语句讲述程序的逻辑结构。在讲述的过程中，小组的其他成员应提问、判断是否存在错误。

                   2）参考常见的编码错误列表分析程序（数据引用错误、数据声明错误、运算错误、比较错误、控制流程错误、接口错误）

3.2  代码走查

不同与代码检查，代码走查会对一些书面用例进行人脑推演

4  测试用例的设计

推荐的步骤是先使用黑盒测试方法来设计测试用例，然后视情况需要使用白盒测试方法来设计补充的测试用例

白盒测试的方法：1）语句覆盖。2）判定覆盖。3）条件覆盖。4）判定/条件覆盖。5）多重条件覆盖。

黑盒测试的方法：1）等价类划分。2）边界值分析。3）因果图分析。4）错误猜想。

4.1  白盒测试

白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度

语句覆盖：较弱的准则，将程序中的每条语句至少执行一次。
判定覆盖或分支覆盖：较强的逻辑覆盖准则，必需编写足够的测试用例，使得每个判断都至少有一个为真和为假的输出结果。也就是说每条分支路劲都必须至少遍历一次。
条件覆盖：比判定覆盖更强的准则，条件覆盖要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。
判定/条件覆盖：设计出充足的测试用例，将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。
多重条件覆盖：要求编写足够多的测试用例，将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。

4.2  黑盒测试

等价划分的步骤：1）确定等价类；2）生成测试用例。
        1）确定等价类：选取每一个输入条件（通常是规格说明中的一个句子或短语）并将其划分为两个或更多的组。有效等价类（代表对程序的有效输入）无效等价类（代表的则是其他任何可能的输入条件，即不正确的输入值）。
       2）生成测试用例：a）为每个等价类设置一个不同的编号。

                                      b）编写新的测试用例，尽可能的覆盖那些未被覆盖的有效等价类，直到所有的有效等价类都被测试用例覆盖（包含进去）。

                                      c）编写新的用例，覆盖一个且仅一个尚未被涵盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。
边界值分析：指输入和输出等价类中的那些恰好处于边界、或超越边界、或在边界以下的状态。
步骤：1） 与从等价类中挑选出任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试。

           2） 与仅仅关注输入条件（输入空间）不同，还需要考虑从结果空间（输出等价类）设计测试用例。
因果图：是一种形式语言，用自然语言描述的规格说明可以转换为因果图。因果图实际上是一种数字逻辑电路（一个组合的逻辑网络），但没有使用标准的电子符号，而是使用了稍微简单点的符号。生成测试用例的过程如下
步骤：1） 将规格说明分解为可执行的片段。
           2） 确定规格说明中的因果关系。
           3） 分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。所谓的因果图。
           4） 给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”。
           5） 通过仔细的跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例。
           6） 将判定表中的列转换成测试用例。

错误猜测：利用直觉和经验猜测出错的可能类型，然后编写测试用例来暴露这些错误。

4.3  测试策略

1）如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法。
2）在任何情况下都应使用边界值分析方法。

3）应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。

4）使用错误猜测技术增加更多的测试用例。

5）针对上述测试用例集检查程序的逻辑结构。

5  模块（单元）测试

模块测试的目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。这里测试的目标不是为了说明模块符合其规格说明，而是为了揭示出模块与其规格说明存在矛盾。

模块测试的步骤：1）测试用例的设计

                             2）执行模块测试和集成的顺序

模块测试的测试用例设计如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例

非增量测试：先独立地测试每个模块，然后再将这些模块组装成完整的程序。又叫“崩溃（big-bang）”测试。

增量测试：先将下一步要测试的模块组装到测试完成的模块集合中，然后再进行测试。又叫集成测试。1）自顶向下；2）自底向上。

6  更高级别的测试

模块测试的目的是发现程序模块与其接口规格说明之间的不一致。
功能测试的目的是为了证明程序未能符合其外部规格说明。
系统测试的目的是为了证明软件产品与其初始目标不一致。（外部规格说明不能作为获取系统测试用例的基础）

6.2  系统测试

能力测试：确保程序的目标功能实现
容量测试：发现处理大容量数据时的程序异常
强度测试：发现在大规模负载、高强度不间断持续的数据处理中的异常
可用性测试：评估最终用户在使用软件并与软件交互时存在的可用性问题
安全性测试：试图攻破程序的安全防线
性能测试：评估程序的的响应时间和吞吐率
存储测试：确保程序可以正确处理其对存储的需求
配置测试：检查程序是否能在推荐配置上流程运行
兼容性/转换测试：评估新版本是否能兼容老的版本

安装测试：确保能够在所有支持的平台上安装软件

可靠性测试：评估程序是否能达到规格说明中的运行时常和平均故障间隔时间要求

可恢复性测试：测试系统恢复相关的功能是否按设计要求实现

服务/可维护性测试：评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需

文档测试：校验所有用户文档是否准确

过程测试：对软件操作系统或维护所需涉及的流程进行评估和确定

6.3  验收测试

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

Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。开发者坐在用户旁边，这是在开发者受控的环境下进行的测试。由开发者随时记录下错误情况和使用中的问题。
Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，这是在开发者无法控制的环境下进行的测试。由用户记录下遇到的所有问题，定期向开发者报告。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试

6.4  安装测试

安装测试：1）用户必须选择大量的选项。2）必须分配并加载文件和库。3）必须进行有效的硬件配置。4）软件可能要求网络联通，以便与其他软件连接

6.5  测试的计划与控制

一个良好的测试计划应该包括：1）目标，必须定义每个测试阶段的目标。2）结束准则，必须制定准则以规定每个测试阶段何时可以结束。3）进度，每个阶段都必须有时间表。4）责任。5）测试用例库及标准。6）工具。7）计算机时间。8）硬件配置。9）集成。10）跟踪步骤。11）调试步骤。12）回归测试。

6.6  测试结束准则

有三类较为有用的准则。

第一类，但不是最佳的准则，根据的是特定的测试用例设计技术，
模块测试结束：测试用例来源于（1）满足多重条件覆盖准则，以及（2）对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的。
功能测试结束：测试用例来源于（1）因果图分析（2）边界值分析，以及（3）错误猜测，产生的所有测试用例最终都是不成功的。
第二类：也许也是最有价值的准则，是以确切的数量来描述结束测试的条件。预测错误（总数量，发现的个数，各个阶段的产生），用发现的错误与预测的比例来结束。
第三类：需要我们在测试的过程中记录每个单位时间内发现的错误数量，通过检查统计曲线的形状，常常可以决定究竟是继续该阶段的测试，还是结束它并开始下一测试阶段。

8  调试

调试：是执行一次成功的测试之后所要进行的工作，所谓成功的测试，是指它可以证明程序没有实现预期的功能。

调试的步骤：1）确定程序中可疑错误的准确性质和位置；2）修改错误。

蛮力法调试：不需要过多思考，是耗费脑力最少的方法，但同时也是效率低下，通常来讲不是很成功的。1）利用内存信息输出来调试。2）根据一般的“在程序中插入打印语句”建议来调试。3）使用自动化的调试工具进行调试。

归纳法调试：认真的思考能发现大部分错误，甚至不需要调试人员使用调试工具。归纳法是一种特殊的思考过程，可以从细节转到全局，也就是从线索出发，寻找线索之间的联系。1）确定相关数据。2）组织数据。3）做出假设。4）证明假设。

演绎发调试：从一些普遍的理论或前提出发，使用排除和精炼的过程，达到一个结论。1）列举所以可能的原因或假设。2）利用数据排除可能的原因。3）提炼剩下的假设。4）证明剩下的假设。

回溯发调试：在小型程序中定位错误的一种有效方法是沿着程序的逻辑结构回溯不正确的结果，直到找出程序逻辑出错的位置。

测试法调试：供测试的测试用例，其目的是暴露出以前尚未发现的错误；供调试的测试用例，其目的是提供有用的信息，供定位某个被怀疑的错误之用。

调试的原则：1）动脑筋。2）如果遇到僵局，就留到稍后解决。3）如果遇到了困境，就把问题描述给其他人听。4）仅将测试工具作为第二种手段。5）避免使用试验法----仅将其作为最后的手段。

修改错误的技术：1）存在一个缺陷的地方，很有可能还存在其他缺陷。2）应纠正错误本身，而不是其症状。3）正确纠正错误的可能性并非100%。4）正确修改错误的可能性随着程序的增加而降低。5）应意识改正错误会引入新错误的可能性。6）修改错误的过程也是临时回到设计阶段的过程。7）应修改源代码，而不是目标代码。

错误分析：1）错误出现在什么地方？2）谁制造了这个错误？3）哪些做得不正确？4）如何避免该错误的出现？5）为什么错误没有早些发现？6）该如何更早地发现错误？

9  敏捷开发模式下的测试

极限编程（XP）：XP模型高度依赖模块的单元和验收测试。对每个无论多小的递增的代码变更都必须进行单元测试，以确保代码库满足其规格说明书。1）聆听客户和其他程序员的谈话。2）与客户合作，开发应用程序的规格说明和测试用例。3）结对编码。4）测试代码库。

极限测试（TP）：该方法强调连续测试，包含单元测试和验收测试。

极限单元测试：多月代码模块中编码开始之前必须设计好单元测试用例，在产品发布之前须通过单元测试。
极限验收测试：目的是判断应用程序是否满足如功能性和易用性等其他需求。在设计/计划阶段，有开发人员和客户来设计验收测试。
极限测试的重点在于单元测试和验收测试，一旦代码库发生了变更，就需要进行单元测试，在重要的发布结点，有客户来执行验收测试。极限测试还要求在开始程序编码之前，根据程序的规格说明设计测试配件，在这种方式中，开发的程序要通过单元测试，从而提高程序满足其规格说明的可能性。

10  互联网应用测试

表示层的测试：1）内容测试；2）Web站点结构；3）用户环境

业务层的测试：1）性能；2）数据有效性；3）事务

数据层的测试：1）响应时间测试；2）数据完整性测试；3）容错性和可恢复性测试

11  移动应用测试

移动应用测试分类：

    安装/卸载，网络基础设施，来电和短信的处理，内存不足，按键，退出（关机），充电，电量，硬件资源

测试方法：

    真机测试

    基于模拟器的测试