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

最近一直在研读《软件测试的艺术》，无意间在网上找到《软件测试的艺术的笔记》，觉得非常好，分享给大家：

第二章  测试心理学

 

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

2. 测试的定义：不是1）软件测试就是证明软件不存在错误的过程。2）软件测试的目的在于证明软件能够正确完成其预订的功能。3）软件测试就是建立一个‘软件做了其应该做的’信心的过程。真正的定义是：软件测试时为发现错误而执行程序的过程。

3. 心里学研究表明，当人们看是一项工作时，如果已经知道它是不可行的或无法实现时，人们的表现就会非常的糟糕。软件测试更适宜被视为试图发现程序中错误（假设其存在）的破坏性的过程。（软件测试心理学）

4. 黑盒测试和白盒测试是两种最普遍的测试策略。

黑盒测试：又称为数据驱动的测试或输入/输出驱动的测试。将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。（测试投入的目标在于通过有限的测试用例，最大限度的提高发现的问题数量，以取得最好的测试效果）

白盒测试：称为逻辑驱动测试，允许我们检查程序的内部结构。（条件覆盖，判定覆盖，语句覆盖）

5. 软件测试中的重要原则：

    

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

6. 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。

一个成功的测试用例能够发现某个尚未发现的错误。

第三章  代码检查、走查与评审

7. 代码检查与走查是两种主要的人工测试方法，要求人们组成一个小组来阅读或直观检查特定的程序。头脑风暴，是测试而不是调试。

8. 代码检查错误列表：数据引用错误，运算错误，数据申明错误，比较错误，控制流程错误，输入/输出错误，接口错误，其他性检查。

9. 实际上，大多数的软件项目都应使用到以下的人工测试方法：1）利用错误列表进行代码检查。2）小组代码走查。3）桌面检查。4）同行评审。

第四章  测试用例的设计

10. 一般而言，在所有的方法中效率最低的是随机输入测试，即在所有可能的输入值中随机选取某个子集来对程序进行测试的过程。

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

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

13. 语句覆盖：较弱的准则，将程序中的每条语句至少执行一次。

判定覆盖或分支覆盖：较强的逻辑覆盖准则，必需编写足够的测试用例，使得每个判断都至少有一个为真和为假的输出结果。也就是说每条分支路劲都必须至少遍历一次。

条件覆盖：比判定覆盖更强的准则，条件覆盖要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。

判定/条件覆盖：设计出充足的测试用例，将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。

多重条件覆盖：要求编写足够多的测试用例，将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。

14. 总的来说，对于包含每个判断只存在一种条件的程序，最简单的测试准则就是设计出足够数量的测试用例，实现：1）将每个判断的所有结果都至少执行一次；2）将所有的程序入口（例如入口点或ON单元）都至少调用一次，以确保全部的语句都至少执行一次。而对于包含多重条件判断的程序，最简单的测试准则是设计出足够数量的测试用例，将每个判断的所有可能的条件结果的组合，以及所有的入口点都至少执行一次（加入“可能”二字，是因为有些组合情况难以生成）。

15. 等价划分：1）确定等价类；2）生成测试用例。

确定等价类：选取每一个输入条件（通常是规格说明中的一个句子或短语）并将其划分为两个或更多的组。有效等价类（代表对程序的有效输入）无效等价类（代表的则是其他任何可能的输入条件，即不正确的输入值）。

生成测试用例：1）为每个等价类设置一个不同的编号。2）编写新的测试用例，尽可能的覆盖那些未被覆盖的有效等价类，直到所有的有效等价类都被测试用例覆盖（包含进去）。3）编写新的用例，覆盖一个且仅一个尚未被涵盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。

16. 边界值分析：指输入和输出等价类中的那些恰好处于边界、或超越边界、或在边界以下的状态。

1） 与从等价类中挑选出任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试。

2） 与仅仅关注输入条件（输入空间）不同，还需要考虑从结果空间（输出等价类）设计测试用例。

17. 因果图：是一种形式语言，用自然语言描述的规格说明可以转换为因果图。因果图实际上是一种数字逻辑电路（一个组合的逻辑网络），但没有使用标准的电子符号，而是使用了稍微简单点的符号。

1） 将规格说明分解为可执行的片段。

2） 确定规格说明中的因果关系。

3） 分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。所谓的因果图。

4） 给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”。

5） 通过仔细的跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例。

6） 将判定表中的列转换成测试用例。

18. 因果图方法是一个根据条件的组合而生成测试用例的系统性的方法。可以替代这种方法的是特殊选取的条件组合，但在这个过程中，很可能会遗漏很多可由因果图方法确定的“令人感兴趣”的测试用例。

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

20. 测试策略：1）如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法。

2）在任何情况下都应使用边界值分析方法。3）应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。4）使用错误猜测技术增加更多的测试用例。5）针对上述测试用例集检查程序的逻辑结构。

第五章 模块（单元）测试

21. 模块测试的目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。这里测试的目标不是为了说明模块符合其规格说明，而是为了揭示出模块与其规格说明存在矛盾。1）测试用例的设计方式；2）模块测试及集成的顺序；3）建议。

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

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

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

25. 模块测试的目的不是证明模块能够正确地运行，而是证明模块中存在着错误。

第六章 更高级的测试

26. 当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。

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

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

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

30. 能力测试：判断目标文档提及的每一项功能是否都确实已实现。

31. 容量测试：使程序经受大容量数据的检验。

32. 强度测试：使程序承受高负载或强度的检验。

33. 易用性测试：1）每个用户界面是否都根据最终用户的智力，教育背景和环境要求进行调整。2）程序的输出是否有意义、不模糊且没有计算机的杂乱信息。3）错误诊断是否直接。4）整体的用户界面是否有语法、惯例、语义、格式、风格等方面是否完整统一和一致。

34. 安全性测试：设计测试用例来突破程序安全检查的过程。

35. 性能测试：很多软件都有特定的性能或效率目标，这些特性描述为主特定负载和配置环境下程序的响应时间和吞吐率。

36. 存储测试：内存和辅存档容量以及临时文件或溢出文件的大小。

37. 配置测试：不同的操作系统，不同的硬件环境的运行情况的测试。

38. 可靠性测试，兼容性测试，适用性测试，可恢复性测试、文档测试、过程测试

39. 系统测试的执行：1）不能由程序员来进行系统测试；2）在所有的测试阶段之中，这是唯一一个明确地不能由负责该程序开发的机构来执行的测试。

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

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

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

43. 测试结束准则：最常见的准则是：1）用完了安排的测试时间后，测试便结束。2）当执行完所有测试用例都未发现错误，测试便结束。通常这两个准则是无用的。

44. 有三类较为有用的准则。1）不是最佳的准则，根据的是特定的测试用例设计技术，

模块测试结束：测试用例来源于（1）满足多重条件覆盖准则，以及（2）对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的。

功能测试结束：测试用例来源于（1）因果图分析（2）边界值分析，以及（3）错误猜测，产生的所有测试用例最终都是不成功的。

45. 第二类：也许也是最有价值的准则，是以确切的数量来描述结束测试的条件。预测错误（总数量，发现的个数，各个阶段的产生），用发现的错误与预测的比例来结束。

46. 第三类：需要我们在测试的过程中记录每个单位时间内发现的错误数量，通过检查统计曲线的形状，常常可以决定究竟是继续该阶段的测试，还是结束它并开始下一测试阶段。

第七章 调试

47. 调试：是执行一次成功的测试之后所要进行的工作，所谓成功的测试，是指它可以证明程序没有实现预期的功能。1）确定程序中可疑错误的准确性质和位置；2）修改错误。

48. 暴力法调试：不需要过多思考，是耗费脑力最少的方法，但同时也是效率低下，通常来讲不是很成功的。1）利用内存信息输出来调试。2）根据一般的“在程序中插入打印语句”建议来调试。3）使用自动化的调试工具进行调试。在下列情况下使用暴力调试方法：1）其他的方法都失败了；2）作为我们下面将会讨论的思考过程的补充，而不是替代方法。

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

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

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

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

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

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

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

56. 分析的过程是很艰难的，但是找到的答案为改进后续的编程实践提供极其宝贵的价值。

第八章 极限测试

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

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

59. 极限单元测试：多月代码模块中编码开始之前必须设计好单元测试用例，在产品发布之前须通过单元测试。

60. 极限验收测试：目的是判断应用程序是否满足如功能性和易用性等其他需求。在设计/计划阶段，有开发人员和客户来设计验收测试。

61. 极限测试的重点在于单元测试和验收测试，一旦代码库发生了变更，就需要进行单元测试，在重要的发布结点，有客户来执行验收测试。极限测试还要求在开始程序编码之前，根据程序的规格说明设计测试配件，在这种方式中，开发的程序要通过单元测试，从而提高程序满足其规格说明的可能性。