《软件测试的艺术》笔记

原创

RuiZhang0824 2014-05-22 16:33:05 ©著作权

©著作权归作者所有：来自51CTO博客作者RuiZhang0824的原创作品，如需转载，请与作者联系，否则将追究法律责任

第一次读书并摘抄笔记。个人感觉这是一种很不错的方法，我习惯于读过一遍书之后将一些我认为有用的内容提取出来。以前是直接在书上做标记，但是实体书携带不方便；而使用Kindle或者ipad看电子书又很难翻页（我喜欢把做笔记的地方折页）。于是干脆自己整理归纳笔记，把我觉得有用的内容归纳在一起，标上章节或者页码，方便查阅原文的时候翻阅。

至于笔记内容的话，没有什么针对性，主要还是用来给自己看的。在这里只是想分享一些学习的方法和心得，仅此而已。

===========================================================================================

《软件测试的艺术》笔记

1、所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。(C1)

2、每当测试一个程序时，总是想为程序增加一些价值。通过测试来增加程序的价值，是指测试提高了程序的可靠性或质量。提高了程序的可靠性，是指找出并最终修改了程序的错误。因此不要只是为了证明程序能够正确运行而去测试程序。相反，应该一开始就假设程序中隐藏着错误，然后测试程序，发现尽可能多的错误。(C2)

3、如果在测试某段程序时发现了错误，而且这些错误是可以修复的，就将这次合理设计并得到有效执行的测试称为“成功的”。如果本次测试可以最终确定再无其它可查出的错误，也可以称为“成功的”。所谓“不成功的”测试，仅指未能适当地对程序进行检查，在大多数情况下，未能找出错误的测试被认为是“不成功的”。(C2)

4、黑盒测试又称为数据驱动的测试或输入/输出驱动的测试。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。

5、穷举输入测试是无法实现的，一方面我们无法测试一个程序以确保它是无错的；另一方面软件测试中需要考虑软件测试的成本。(C2)

6、即使测试到程序中的所有路径，程序仍然可能存在着错误。原因有三：①即使是穷举路径测试也绝不能保证程序符合其设计规范；②程序可能会因为缺少某些路径而存在问题；③穷举路径测试可能不会暴露数据敏感错误。(C2)

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

8、一个测试用例必须包括两个部分：①对程序的输入数据的描述 ②对程序在上述输入数据下的正确输出结果的精确描述(C2)

9、如果对程序的更改导致了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的，保留测试用例，当程序其他部件发生更动后重新执行，这就是我们所谓的“回归测试”。(C2)

10、影响到特定的测试和调试工作需要人工阅读代码的可能性的因素：①软件的规模和复杂度 ②软件开发团队的规模 ③软件开发的时限 ④编程小组的技术背景和文化(C3)

11、代码检查与走查是两种主要的人工测试方法。代码检查与走查都要求人们组成一个小组来阅读或直观检查特定的程序。无论采用哪种方法，参加者都需要完成一些准备工作。参加者在会议上举行“头脑风暴会”。“头脑风暴会”的目标是找出错误，但不必找出改正错误的方法。换句话说，是测试，而不是调试。(C3)

12、在代码走查中，一组开发人员（3~4人）对代码进行审核，参加者当中仅有一个是程序编写者。(C3)

13、代码检查与走查的优点：①对过去桌面检查(在提交测试前有程序员阅读自己的程序的过程)的改进。②一旦发现错误，通常就能在代码中对其进行精确定位，降低了调试的成本。另外，这个过程通常能发现成批的错误。(C3)

14、一个代码检查小组通常由四人组成，其中一人作为协调员。协调员不需要对程序的细节了解的很清楚。协调人的职责包括以下几点：①为代码检查分发材料、安排进程 ②在代码检查中起主导作用 ③记录发现的所有错误 ④确保所有错误随后得到改正(C3)

15、代码检查进行时，主要进行两项活动：①由程序编码人员逐条语句讲述程序的逻辑结构。在讲述的过程当中，小组的其他成员应提问题，判断是否存在错误。②对着历来常见的编码错误列表分析程序。(C3)

16、代码检查错误列表——数据引用错误：(1)是否有引用的变量未赋值或未初始化？ (2)下标的值是否在范围之内？ (3)是否存在非整数下标？ (4)是否存在虚调用？ (5)当使用别名是属性是否正确？ (6)记录和结构的属性是否匹配？ (7)是否计算位串的地址？是否传递位串参数？ (8)基础的存储属性是否正确？ (9)跨过程的结构定义是否匹配？ (10)索引或下标操作是否有“仅差一个”的错误？ (11)继承需求是否得到满足？(C3)

17、代码检查错误列表——运算错误：(1)是否存在非算数变量间的运算？ (2)是否存在混合模式的运算？ (3)是否存在不同字长变量间的运算？ (4)目标变量的大小是否小于赋值大小？ (5)中间结果是否上溢或下溢？ (6)是否存在被零除？ (7)是否存在二进制的不精确度？ (8)变量的值是否超过了有意义的范围？ (9)操作符的优先顺序是否被正确理解？ (10)整数除法是否正确？(C3)

18、代码检查错误列表——数据声明错误：(1)是否所有的变量都已声明？ (2)默认的属性是否被正确理解？ (3)变量是否赋予了正确的长度，类型和存储类？ (4)数组和字符串的初始化是否正确？ (5)初始化是否与存储类相一致？ (6)是否有相似的变量名？(C3)

19、代码检查错误列表——比较错误：(1)是否存在不同类型变量间的比较？ (2)是否存在混合模式的比较运算？ (3)比较运算符是否正确？ (4)布尔表达式是否正确？ (5)比较运算式是否与布尔表达式相混合？ (6)是否存在二进制小数的比较？ (7)包含多个布尔运算符的表达式，运算顺序是否正确？ (8)编译器计算布尔表达式的计算方式是否被正确理解？(C3)

20、代码检查错误列表——控制流程错误：(1)是否超出了多条分支路径？ (2)是否每个循环都终止了？ (3)是否每个程序都终止了？ (4)是否存在由于入口条件不满足而跳过循环体？ (5)可能的循环越界是否正确？ (6)是否存在“仅差一个”的迭代错误？ (7)DO/END语句是否匹配？ (8)是否存在不能穷尽的判断？(C3)

21、代码检查错误列表——输入/输出错误：(1)文件的属性是否正确？ (2)OPEN语句是否正确？ (3)I/O语句是否符合格式规范？ (4)缓冲大小与记录大小是否匹配？ (5)文件在使用前是否打开？ (6)文件在使用后是否关闭？ (7)文件结束条件是否被正确处理？ (8)是否处理了I/O错误？ (9)输出信息中是否有文字或语法错误？(C3)

22、代码检查错误列表——接口错误：(1)形参的数量是否等于实参的数量？ (2)形参的量纲是否与实参的量纲相匹配？ (3)实参的属性是否与形参的属性相匹配？ (4)传递给被调用模块的实参个数是否等于其形参个数？ (5)传递给被调用模块的实参属性是否与其形参属性匹配？ (6)传递给被调用模块的实参量纲是否与其形参量纲匹配？ (7)调用内部函数的实参的数量、属性、顺序是否正确？ (8)是否引用了与当前入口点无关的形参？ (9)是否改变了某个原本仅为输入值的形参？ (10)全局变量的定义在模块间是否一致？ (11)常数是否以实参形式传递过？(C3)

23、代码检查错误列表——其他检查：(1)在交叉引用列表中是否存在未引用过的变量？ (2)属性列表是否与预期的相一致？ (3)是否存在“警告”或“提示”信息？ (4)是否对输入的合法性进行了检查？ (5)是否遗漏了某个功能？(C3)

24、代码走查不同于仅阅读程序或使用错误检查列表，代码走查的参与者“使用了计算机”。在会议期间，每个测试用例都在人们脑中进行推演。也就是说，把测试数据沿程序的逻辑结构走一遍。程序的状态（如变量的值）记录在纸张或白板上以供监视。(C3)

25、代码走查的测试用例本身并不起到关键的作用，它们的作用是提供了启动走查和质疑程序员逻辑思路及其设想的手段。(C3)

26、同行评分是一种依据程序整体质量，可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。该项技术的目的是为程序员提供自我评价的手段。(C3)

27、常见的黑盒测试方法有：等价类划分、边界值分析、因果图分析、错误测试。(C4)

28、常见的白盒测试方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。(C4)

29、语句覆盖：将程序中的每条语句至少执行一次。(C4)

30、判定覆盖(也称为分支覆盖)要求必须编写足够的测试用例，使得每一个判断都至少有一个为“真”和有一个为“假”的输出结果。换句话说，每条分支路径都必须至少遍历一次。分支或判定语句的例子包括switch，do-while和if-else语句。(C4)

31、条件覆盖：在条件覆盖的情况下，要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。因为，就如同判定覆盖的情况一样，这并不总是能让每条语句都执行到。因此作为对这条准则的补充就是对程序或子程序，包括ON单元的每一个入口点都至少调用一次。(C4)

32、虽然条件覆盖准则乍看上去似乎满足判定覆盖准则，但并不总是如此。如果正在测试判断条件IF(A&B)，条件覆盖准则将要求编写两个测试用例：A为真，B为假；A为假，B为真。但这并不能使IF语句中的THEN被执行到。(C4)

33、判定/条件覆盖准则：这种准则要求设计出充足的测试用例，将每个判断的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。(C4)

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

35、总的来说，对于包含每个判断只存在一种条件的程序，最简单的测试准则就是设计出足够数量的测试用例，实现：①将每个判断的所有结果都至少执行一次 ②将所有的程序入口都至少调用一次，以确保全部的语句都至少执行一次(C4)

36、对于包含多重条件判断的程序，最简单的测试准则是设计出足够数量的测试用例，将每个判断的所有可能的条件结果的组合，以及所有的入口点都至少执行一次(C4)

37、使用等价类划分方法设计测试用例主要有两个步骤：①确定等价类 ②生成测试用例(C4)

38、确定等价类是选取每一个输入条件并将其划分为两个或更多的组。有效等价类代表对程序的有效输入，而无效等价类代表的是其他任何可能的输入(即不正确的输入值)(C4)

39、确定等价类的指导原则：①如果输入条件规定了一个取值范围，就应确定出一个有效等价类和两个无效等价类 ②如果输入条件规定了取之的个数(整数)，就应确定出一个有效等价类和两个无效等价类 ③如果输入条件规定了一个输入值的集合，且有理由认为程序会对每个值进行不同的处理，就为每个输入值确定一个有效等价类和一个无效等价类 ④如果存在输入条件规定了“必须是”的情况，就应确定一个有效等价类和一个无效等价类。(C4)

40、使用等价类生成测试用例的过程：①为每个等价类设置一个不同的编号 ②编写新的测试用例，尽可能多的覆盖那些尚未被涵盖的有效等价类，直到所有有效等价类都被测试用例所覆盖 ③编写新的用例，覆盖一个且仅一个尚未被覆盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖(C4)

41、边界值分析方法与等价类方法存在两方面的不同：①边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试 ②除了关注输入条件，还要考虑从结果空间设计测试用例(C4)

42、使用边界测试的指导原则：①如果输入条件规定了一个输入值范围，那么应针对范围的边界设计测试用例，针对刚刚越界的情况设计无效输入测试用例 ②如果输入条件规定了输入值的数值，那么应针对最小数量输入值、最大数量输入值，以及一个比最小数量少一个、比最大数量多一个的情况设计测试用例。 ③对每个输出条件应用指南①。 ④对每个输出条件应用指南②。 ⑤如果程序的输出或输入是有序序列，应特别注意该序列的第一个和最后一个元素。(C4)

43、因果图有助于用一个系统的方法选择出高效的测试用例集，还可以指出规格说明的不完整性和不明确之处。(C4)

44、使用因果图生成测试用例的过程如下：①将规格说明分解为可执行的片段 ②确定规格说明中的因果关系。所谓“因”，是指一个明确的输入条件或输入条件的等价类；所谓“果”，是指一个输出条件或系统转换。 ③分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。这就是所谓的因果图。 ④给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”。 ⑤通过仔细地跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例。 ⑥将判定表中的列转换成测试用例。(C4)

45、一组合理的测试策略如下：①如果规格说明中包含条件组合的情况，应首先使用因果图分析法。 ②在任何情况下都应使用边界值分析法。 ③应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。 ④使用错误猜测技术增加更多的测试用例 ⑤针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能，那么增加足够数量的测试用例，以使覆盖准则得到满足。(C4)

46、模块测试(或单元测试)是对程序中的单个子程序、子程序或过程进行测试的过程，也就是说，一开始并不是对整个程序进行测试，而是首先将注意力集中在对构成程序的较小模块的测试上面。模块测试的目的是将模块的功能与定义的模块的功能规格说明或接口规格说明进行比较。(C5)

47、使用单元测试的原因：①由于模块测试的注意力一开始集中在程序的较小单元上，因此它是一种管理组合的测试元素的手段。 ②模块测试减轻了调试的难度，一旦发现某个错误，就知道他具体在哪个模块中 ③模块测试通过为我们提供同时调试多个模块的可能，将并行工程引入软件测试中。(C5)

48、模块测试的测试用例设计过程：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。(C5)

49、测试单独的模块需要一个特殊的驱动模块和一个或多个桩模块。(C5)

50、增量测试可以分为自顶向下的增量测试和自底向上的增量测试。(C5)

51、自顶向下测试的优点：①如果主要的缺陷发生在程序的顶层将非常有利 ②一旦引入I/O功能，提交测试用例会更容易 ③早期的程序框架可以演示，并可激发积极性(C5)

52、自顶向下测试的缺点：①必须开发桩模块 ②桩模块比最初表现得更复杂 ③在引入I/O功能之前，向桩模块中引入测试用例比较难 ④创建测试环境可能很难，甚至无法实现 ⑤观察测试输出很困难 ⑥使人误解设计和测试可交迭进行 ⑦会导致特定模块测试的完成延后(C5)

53、自底向上测试的优点：①如果主要的缺陷发生在程序的底层将会非常有利 ②测试环境比较容易建立 ③观察测试输出比较容易(C5)

54、自底向上测试的缺点：①必须开发驱动模块 ②直到最后一个模块添加进去，程序才形成一个整体(C5)

55、软件产品开发周期的流程：①将软件最终用户的要求转换为一系列书面的需求。这些需求就是该软件产品所要实现的目标 ②通过评估可行性与成本、消除相抵触的用户需求、建立优先级和平衡关系，将用户需求转换为具体的目标 ③将上述目标转换为一个准确的产品规格说明，将产品视为一个黑盒，仅考虑其接口以及与最终用户的交互。该规格说明被称为“外部规格说明” ④如果该产品是一个系统，而不仅是一个程序，那么下一步骤就是系统设计。该步骤将系统分割为单独的程序、部件或子系统，并定义它们的接口 ⑤通过定义每个模块的功能、模块的层次结构以及模块间的接口，来设计程序或程序集合的结构 ⑥设计一份准确的规格说明，定义每个模块的接口与功能 ⑦经过一个或更多的子步骤，将模块接口规格说明转换为每个模块的源代码算法(C6)

56、功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户角度对程序行为的精确描述。功能测试通常是一项黑盒操作。(C6)

57、系统测试并非是测试整个系统或程序功能的过程，而是将系统或程序与其初始目标进行比较。这意味着：①系统测试并不局限于系统。如果产品是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。 ②根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。(C6)

58、系统测试包括：能力测试、容量测试、强度测试、易用性测试、安全性测试、性能测试、存储测试、配置测试、兼容性/配置/转换测试、安装测试、可靠性测试、可恢复性测试、适用性测试、文档测试、过程测试。(C6)

59、能力测试用于判断目标文档提及的每一项能力是否都确实已经实现。能力测试的过程是逐条语句地检查目标文档。(C6)

60、容量测试使程序经受大容量数据的检验。换言之，容量测试的目的是为了证明程序不能处理目标文档中规定的数据容量。(C6)

61、强度测试使程序承受高负载或强度的检验。所谓的高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。(C6)

62、安全性测试是设计测试用例来突破程序安全检查的过程。(C6)

63、性能测试反映了在特定的负载和配置环境下程序的响应时间和吞吐率。(C6)

64、存储测试用来证明某些描述了程序使用的内存和辅存的容量，以及临时文件或溢出文件的大小的存储目标没有得到满足。(C6)

65、验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程。该测试通常由程序的客户或最终用户来执行，一般不认为是软件开发机构的职责。(C6)

66、一个良好的测试计划应包括：(1)目标。必须定义每个测试阶段的目标 (2)结束准则。必须制定准则以规定每个测试阶段何时可以结束 (3)进度。每个阶段都须有时间表，应指出何时设计、编写和执行测试用例 (4)责任。对于每一个阶段，应当确定谁来设计编写和验证测试用例，谁来修改发现的软件错误 (5)测试用例库及标准。在大型项目中，用于确定、编写以及存储测试用例的系统方法是必须的 (6)工具。必须确定需要使用的测试工具，包括计划由谁来开发或采购、如何使用工具以及何时需要使用工具 (7)计算机时间。计划每个测试阶段所需的计算机时间，包括用来编译应用程序的服务器、用来进行安装测试所需的桌面计算机、用来运行基于web应用程序的web服务器、联网的设备等等 (8)硬件配置。如果需要特别的硬件配置或设备，则需要一份计划来描述该需求，该如何满足需求以及何时需要满足 (9)集成。测试计划的一部分是定义程序如何组装在一起的方法。系统集成计划规定了系统集成的顺序、系统每个版本的功能以及编写“脚手架”代码以模拟不存在的部件的职责分工。(10)跟踪步骤。必须跟踪测试进行中的方方面面，包括对错误易发模块的定位，以及有关进度、资源和结束准则的进展估计 (11)调试步骤。必须制定上报已发现错误、跟踪错误修改进程以及将修改部分加入系统中去的机制。测试计划中还应包括进度、责任分工、工具以及计算机时间/资源等 (12)回归测试。回归测试再对程序作了功能改进或进行了修改之后进行，其目的是判断程序的改动是否引起了程序其他方面的退步。回归测试通常重新执行测试用例中的某个子集。回归测试计划规定了测试人员、测试方法和测试时间，它也是必需的。(C6)