软件测试的艺术The Art of SoftWare Testing 读书笔记

知识改变命运 勤奋塑造成功

整理人	落叶
时间	2011-4-15

天才是百分之九十九的勤奋加百分之一的灵感
The Art of SoftWare Testing》读书笔记（1）_引子

有关自己与软件测试之间的渊源而言，获悉这个领域的时间不长，接触的时间就更可谓短暂，但仔细想来，还要从大学期间说起比较好。

软件测试这个概念第一次出现在我的眼前时，是大四上学期开的软件工程这个科目中所涉及到的一点点。由于某些因素，使我在大学期间忽略了对测试领域相关知识的储备。第二次面对它时，是考研复习准备阶段。那时，我对测试这个领域也仅仅只是知道，就是中文书面表达的“测试”这两个汉字的含义而已。

工作的前两年里，或许是因为从事的是有关算法方面性质的工作，所以并未对测试这个领域给予过多的关注，还好，或多或少还是接触到了一些。直到最近一年多来，由于一个大型项目人手不够的缘故，所以临时从自己负责的另一个研究项目中抽过来（刚好该项目阶段性完成），负责有关此项目的测试部署与规划。而这个时候，才能说是：真正意义上接触到了软件测试这个领域。

虽然，在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。但，从这个项目阶段性结束后自己的体会而言，给我感悟最深的还是有关软件测试这个领域的。通过在这个项目里的工作，让我真正体会到了：软件测试是一门艺术。恰恰也是因为这个缘故，这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。


《The Art of SoftWare Testing》读书笔记（2）_前言

喜欢在网上书店中遛达，看到不错的书就买下。为什么不去书店？一个字，懒呗！总觉得，有那去书店的时间，完全可以好好睡一美觉，亦或可亲手烹制一顿美味可口的美食。哎，反正就是，懒得走出家门去逛街！

恰巧，此次浏览书籍时，无意间看到了《The Art of Software Testing》这本书。在看了大家所给予它极高的评价留言后，虽然有些疑惑（毕竟这个时代，枪手太多了！），但我深信：一本书能够“活”25年，应该还是很不简单的。于是，就半信半疑的订购了这本书，期望能够从这本书中获悉到有用的知识，来丰富一下自己面对这个领域时的贫乏困境，亦作为知识储备。

晕，这么薄！这是我拿到这本书后的第一反应。真的！没有预料到这书会这么薄！原以为这本经典的书，会诸如《C++ Primer》、《The C++ Programming Language》、《Programming Windows》等这些著作那么厚。而当翻看了几章后，觉得确实很经典，也明白了为什么这本书会“活”了25年。于是，就诞生了我对这本书的第二感觉：薄而精！看来是需要自己多花些时间去慢慢的品味，这样才方可体味到最纯最美的底酝。

打住自己对这本书的侃侃而谈（怕跑题太远，拽不回来），还是关注一下软件测试这个领话题吧！

软件测试，怎么说呢？就自身经历而言，确实如书上所说：测试依然是软件开发中的“黑色艺术”。大学期间，计算机课程开的不少，没听说有专门开一门关于测试的课程。所以，在学生阶段，测试就属于是个被抛弃掉的名词！毕业时，不是做软件就是去搞网络，没有听到一个同学去应聘测试的！工作中，有专门的测试组（或部门），就更不用自己怎么上心去研究了！如今的氛围就是：红的够红，黑的够黑！那叫一个“专”！哎，为什么不实行“两手都要抓，两手都要硬”的政策呢（一己之见，偏颇在所难免）？或许，我还不明白：“术业有专攻”的深刻含义吧！

算了，最后还是谈谈对这本书的总观吧！
1. 该书是针对测试这一主题进行的实践探讨，而不是理论研究，顺便捎带了些对新的语言和过程的探讨；
2. 前言中提到了一个最为重要而又是长期、基本的指南：如何确保所开发的所有软件做了其应该做的，并且同样重要的是，未做其不应该做的？
3. 引言里指出一条著名的经验：即在一个典型的编程项目中，软件测试或系统测试大约占用50%的项目时间和超过50%的总成本。
《The Art of SoftWare Testing》读书笔记（3）_一次自我检测

有创意！这是我对该书第一章的评价，也是唯一一次在看新书开篇时，能够把第一章给透透彻彻看完的。为何？还不是实在不能恭维有些书籍在开篇就进行枯燥而繁多的总结性、介绍性的文字。虽心里也清楚这些文字存在的重要性。但每每，还总是先粗略瞄过，在通读全书后，才会再次认认真真的看那些文字（这时，才真的能感悟到“提纲携领”的中文含义啊）。

创意在于：它只通过展示一次自评价测试，就能吸引我的眼球，并涌出一种想继续向下读的冲动；更能引起对自身一些有关逻辑思维（考虑欠周全、缜密，存在盲点）、联想能力（需拓展思维，要富于联想与想像，即：思维“活”起来）、角度问题（要巧妙转换角度）等方面，所可能存在的不足进行深思。当然，能够引起深思的缘故，还不是在于那个评价测试嘛！提起来，汗颜！依据所谓的测试用例（即：特定的数据集合）自测试后，发现自己只能考虑到11项（总14项）需要测试的关键点。

文尾，谈谈作者对“软件测试”这个概念的定义吧。所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。软件应当是可预测且稳定的，是不会给用户带来意外惊奇的。

《The Art of SoftWare Testing》读书笔记（4）_初次探究
　　
　　“软件测试是一项技术性工作，但同时也涉及经济学和人类心理学的一些重要因素”，这是该书第二章中最吸引我的话，耐人深思。而对于该章的内容，我个人觉得可概括为以下三个方面：
o 心理学角度：驳斥了一些社会普遍存在的错误认识，并给出了测试的正确定义及在含义上进行了延伸。（用写文章上常用的术语来说，是：先破后立。）
o 经济学角度：验证软件测试不能够发现“所有”的错误。（术语是：各个击破。）
o 归纳了软件测试中的一些基本原则（术语是：归纳与演绎。），及三个重要的测试原则：
1. 软件测试是为发现错误而执行程序的过程；
2. 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性；
3. 一个成功的测试用例能够发现某个尚未发现的错误。
　　文尾，值得一提的是：在本章能明显感到作者侧重于从心理学角度来分析一些潜在的问题。
The Art of SoftWare Testing》读书笔记（5）_心理学视角解析（上）

先谈谈从心理学角度所需要分析的问题。在章节的开始，作者就明确的给予了一个认知：要成功地测试一个软件应用程序，测试人员也需要有正确的态度。在某些情况下，测试人员的态度可能比实际的测试过程本身还要重要。并且，分析了现在社会上普遍存在的两种“本末倒置”的错误认识。
· 针对程序员：一开始就把“测试”这个术语的定义搞错了。所以可想而知，作者肯定要先破其错误的根源和弊端，然后再立其正确的认知，为了能更深入的理解和在实践上的把握，作者又对正确的认知给予了进一步延伸的阐述；
· 针对项目经理：针对测试方面而言，对“成功的”和“不成功的”的理解认识上的错误。
文尾，值得一提的是：作者在这引荐一个病人去医生那里看病的例子，于是将一些绕人的关系和原理，刹那间弄的清晰易懂了。看来恰当适宜的举例还是比枯燥的讲解概念间的区别与联系要容易的多，也生动的多，并且使人也能理解的更加深刻。
《The Art of SoftWare Testing》读书笔记（6）_心理学视角解析（中）

上次谈到了两个错误认识，那就继续这个话题吧。

先分析与项目经理有关的这个错误认识吧。因为这个因素可能会导致一些在测试问题上的根本性错误的认识。作者主要是从“成功的”和“不成功的”这两个方面来剖析的：
· 指明了错误认识的本源：“成功的测试”是指没有发现错误的测试用例；而“不成功的测试”是指发现了某个新错误的测试。
· 明确正确认识的本质：如果在测试某段程序时发现了错误，而且这些错误是可以修复的，就将这次合理的设计和由此得到有效执行的测试称为是“成功的”；并对如果在本次测试中可以最终确定再无其他可查出的错误，同样也被称作是“成功的”；而对未能适当地对程序进行检查，且在大多数情况下，未能找出错误的测试被称为是“不成功的”。
· 引荐病人去找医生看病的这一生动的例子，加以引申理解并给予了结论：能发现新错误的测试用例不太可能被认为是“不成功的”，相反，能发现错误就证明它是值得设计的。一个“不成功的”测试用例，会使程序输出正确的结果，但不能发现任何错误。
细想：如果规划的测试用例是能使程序输出正确的结果，但不能发现任何错误的话，那是多么的可怕阿。那么测试就等于没有测试，或者是在徒劳。而潜在的错误还依然潜在，这会开发人员跟用户来说，都是有不小的隐患的。
这才真正认识到：发现测试真的是一门需要去潜心研究的艺术。不仅仅是为了我们开发人员自己，也为了用户，更为了将来软件能够更好的维护跟升级。
　
《The Art of SoftWare Testing》读书笔记（7）_心理学视角解析（下）

接着，来谈谈程序员方面会产生的错误认识吧！这个方面可能在具体实践中显的更重要。

由于作者在开篇就先把三个错误认识给摆到读者的眼前；然后就立马表明了其正确的定义，并给予了分析和对错误认识的驳斥。洋洒洒的写了许多，条理上未免会有些混乱。因此，我就按照自己理解的来小结一下吧！

首先，测试的正确定义是：测试是为发现错误而执行程序的过程。该定义暗示了两层含义：
· 软件测试是一个破坏性的过程，甚至是一个“施虐”的过程。（就自己的亲身经历而言，大部分的开发人员在测试期间，对测试人员或多或少都会暂时产生一点厌烦或恐惧的心态。主要是会让开发人员的代码改的面目全非的，且这个过程是反反复复的。）
· 对于一个特定的程序，应该如何设计测试用例（测试数据）、哪些人应该而哪些人又不应该执行测试。（这是有关测试人员构成的问题。就自己的亲身经历而言，这一点很重要，因为测试人员的态度要比测试的过程更为重要。）
然后，明确测试的正确含义后，探究了一下现今面临的三个错误认识并逐一给予了充分的驳斥。
· “软件测试就是证明软件不存在错误的过程”。
1. 若目的仅是为了证明程序中不存在错误，就会在潜意识中倾向于实现这个目标；即，会倾向于选择可能较少导致程序失效的测试数据；若目标在于证明程序中存在错误，设计的测试数据就有可能更多地发现问题。后者肯定比前者会更多地增加程序的价值。
2. 心理上，对于证明不存在是一个不可能完成的任务，无论该工程多么小；但若是一个寻找错误的任务，是可以完成的。就心理承受而言，也是更容易接受的。

· “软件测试的目的在于证明软件能够正确完成其预订的功能。”
3. 心态上，不要本着只是为了证明程序能够正确运行而去测试程序，而应该一开始就假设程序中隐藏着错误（这种假设对于几乎所有的程序都成立）。这样测试程序时，才能够发现尽可能多的错误。
4. 要清楚这样一个道理：每当测试一个程序，实质上是想为其增加一些价值。通过测试来增加程序的价值，及是指测试提高了程序的可靠性或质量。而提高了程序的可靠性，就是指找出并最终修改了程序的错误。

· “软件测试就是建立一个‘软件做了其应该做的’信心的过程。”
5. 错误认识的关键在于：程序即使能够完成预定的功能，也仍然可能隐藏错误。即，当程序没有实现预期功能时，错误是清晰地显现出来的。但如果程序做了其不应该做的，这同样也是一个错误。
6. 而后一方面一般都会人为的想当然，认为系统不会做那些事情的。但不通过实践去证明，一切都是不可预计到的。
总体而言，软件测试更适宜用来作为一个试图发现程序中错误（假设其存在）的破坏性的过程。一个成功的测试用例，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。当然，最终还要通过软件测试来建立某种程度的信心；软件做了其应该作的，未做其不应该作的。通过对错误的不断研究是实现这个目的的最佳途径。

需要明确的一点是，针对有人可能会声称“本人的程序完美无缺（不存在错误）”的这种情况而言，建立起信心的最好办法就是尽量去反驳他，即努力发现不完美指出，而不只是确认程序在某些输入情况下能够正确地工作。

文尾，我想到了高尔基先生在《海燕》里边的一句话：让暴风雨来的更猛烈些吧！不妨，让测试变的更加疯狂一些吧！
《The Art of SoftWare Testing》读书笔记（8）_经济学视角解析

　　再从经济学视角来分析一下吧。
　　
　　需明确：对一个复杂的应用程序进行完全的测试，将耗费大量的时间和人力资源，以致于在经济上是不可行的。即，从经济学的角度来说，软件测试是不能够发现“所有”的错误。换言之，要发现程序中的所有错误是不切实际的，也常常是不可能的。这也体现了测试人员对被测试软件的期望和对测试用例的设计方式。由此，有了两种策略，即：黑盒测试和白盒测试（均从三个方面进行阐述：原理、方法、利弊）。

　　黑盒测试（又称为数据驱动的测试或输入/输出驱动的测试）
o 原理：将程序视为一个黑盒子，测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。
o 方法：测试数据完全来源于软件规范（不需要去了解程序的内部结构）。如果想用这种方法来发现程序的所有错误，判定的标准就是“穷举输入测试”，将所有可能的输入条件都作为测试用例。
o 利弊：穷举输入测试是无法实现的。原因有二：一是无法测试一个程序以确保它是无错的；二是软件测试中需要考虑的一个基本问题是软件测试的经济学，即，测试投入的目标在于通过有限的测试用例，最大限度地提高发现的问题的数量以取得最好的测试效果。
　　白盒测试（又称为逻辑驱动的测试）
o 原理：允许我们检查程序的内部结构的。这种测试策略对程序的逻辑结构进行检查，从中获取测试数据（但常忽略了程序的规范）。
o 方法：穷举路径测试。即，如果使用测试用例执行了程序中所有可能的控制流路径，那么程序有可能得到了完全的测试。
o 利弊：程序中不同逻辑路径的数量可能会达到天文数字，那么穷举路径测试就同穷举输入测试一样，非但不可能也是不切合实际的。
　　文尾，值得提一下一个错误认知：“穷举路径测试即完全的测试”。因为，即使可以测试到程序中的所有路径，但是程序可能仍然存在着错误。其原因有三：
o 即使是穷举路径测试也决不能保证程序符合其设计规范；
o 程序可能会因为缺少某些路径而存在问题，可穷举路径测试不能发现到底是缺少了那些必需路径；
o 穷举路径测试可能不会暴露数据敏感错误。
《The Art of SoftWare Testing》读书笔记（9）_原则解析

　　该章最后，作者给予了十大测试原则：

o 测试用例中一个必需部分是对预期输出或结果的定义。
　　一个测试用例必需包括两个部分：对程序的输入数据的描述和对程序在上述输入数据下的正确输出结果的精确描述。

o 程序员应当避免测试自己编写的程序。
　　原因有三：
1. 当程序员“建设性”地设计和编写完程序之后，很难让他突然改变视角以一种“破坏性”的眼光来审查程序，即，他们无法改变思维方式来尽力暴露自己程序中的错误；
2. 程序员可能会下意识地避免找出错误来，担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚；
3. 由于程序员错误地理解了疑难定义或规范，导致程序中存在错误。如果是这种情况，程序员可能会带着同样的误解来测试自己的程序。需要指出的是：“调试”还是由程序的编写人员来完成会更加有效的。
　　
o 编写软件的组织不应当测试自己编写的软件。
　　应该是由客观、独立的第三方来进行测试。理由雷同于上条规则中所涉及到的。
　　
o 应当彻底检查每个测试的执行结果。
　　在项目测试的时候，总是会发现在后续测试中发现的错误，往往是前面的测试遗漏掉的。

o 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况。
　　其实在软件产品中暴露出来的许多问题是当程序以某些新的或未预料到的方式运行时发现的。所以这条原则的重要性可能在测试中的地位还应该是更要值得引起注意的才是。

　　
o 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。

o 应避免测试用例用后放弃，除非软件本身就是一个一次性的软件。
　　在交互式系统上来测试的话，这条原则可能就会显现的更加重要了。这条原则体现的会更加省时省力。因为如果对程序的更改导致了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的。保留测试用例，当程序其他部分发生更动后重新执行，这就是我们所谓的“回归测试”了。

o 计划测试工作时不应默认假定不会发现错误。

o 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
　　作者所说的而言，错误总是倾向于聚集存在，而在一个具体的程序中，某些部分要比其他部分更容易存在错误。那么为了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。

o 测试是一项极富创造性、极具智力挑战性的工作
《The Art of SoftWare Testing》读书笔记（10）_人工测试技术
　　
　　本书第三章作者着重讲述了测试领域里的一个与机器测试相当重要，且在机器测试之前进行，也与之相辅相成的技术，即：人工测试技术。该技术共涉及四种方法：代码检查、代码走查、桌面检查、同行评审；其更着重详细讲述的是第一个方法。

　　同时，作者在开章也提到一种错误认识：人工测试技术由于包含了人为因素在内，导致很多方法的正规性要差于由计算机执行的数学证明，所以人们可能会怀疑某些如此简单和不正规的东西是否有用。反之亦然。就个人经历而言，确实这种认知普遍存在，并且对人工测试技术没有给予足够的重视。

　　文尾，有必要记叙一下，人工测试技术的重要性。它会在两个方面显著地提高软件测试的功效和可靠性。
o 错误发现得越早，改正错误的成本越低，正确改正错误的可能性也越大；
o 程序员在开始基于计算机的测试时似乎要经历一个心理上的改变。压力会急剧增长，且要“尽可能快地修正这个缺陷”。由于这些，所以，程序员在改正某个基于计算机测试发现的错误时所犯的失误，可能要比改正早期发现的问题时所犯的失误会更多一些的。
《The Art of SoftWare Testing》读书笔记（11）_优之共通
　　
　　上篇，提到人工测试技术的四种方法。其中，代码检查和代码走查稍略胜一筹。于是，作者在本章着重讲了这两个方法。其实，这两种方法很类似，那就先看看这两种方法的优之共通点吧！具体可分为一下几个点：
o 方法：组成一个小组来阅读或直观检查特定的程序；并在“头脑风暴会”上要形成统一的目标：找出错误，但不必找出改正错误的方法。换句话说，是测试，而不是调试。该组开发人员（三至四人为最佳）是对代码进行审核，其中参加者当中只有一人是程序编写者；也可以说它是对过去桌面检查过程的改进。
o 优点：一旦发现错误，就可以在代码中对其进行精确定位，这就降低了调试的成本；还通常可以发现成批的错误，这样就可以一同得到修正，这也优于机器测试，因为后者只能暴露出错误的某个表症。
o 效果：通常是能够有效地查找出30%-70%的逻辑设计和编码错误，但不能有效地查找出高层次的设计错误。
o 地位：是与计算机的测试互补的，缺少其中任何一种错误检查的效率都会降低。
　　值得提出的是：该处的错误发现率，并不是说所有错误中多达70%可能会被找出来，而是讲这些方法在测试过程结束时，可以有效地查找出多达70%的已知错误。

　　应始终记住的是：程序中的错误总数始终是未知的。否则就会浪费大量的精力跟人力，也会在经济效益上或多或少有一些损失的。不过，就经验而言，修改一个现存的程序比编写一个新程序更容易产生错误，这依据于以每写一行代码的错误数量来计的。
《The Art of SoftWare Testing》读书笔记（12）_ 代码检查

代码检查，怎么说呢？经验而言，我挺喜欢用的。因为，跟项目经理（或设计人员）读设计，能够非常容易发现设计上的逻辑错误或遗漏的问题等等。因此，有必要好好叙述下。

· 定义上：所谓的代码检查，其实就是以组为单位阅读代码，是一系列规程和错误检查技术的集合。该过程通常将注意力集中在发现错误上，而不是纠正错误。
· 成员组成：一个代码检查小组通常是由四人组成，其中一人发挥着协调作用、一人是该程序的编码人员、一人是其他成员通常是程序的设计人员、一人是测试专家。
这里，值得一提的是：那个发挥着协调作用的成员。该协调人应该是个称职的程序员，但不是该程序的编码人员，不需要对程序的细节了解得很清楚。协调人的职责包括几点：为代码检查分发材料、安排进程；在代码检查中起主导作用；记录发现的所有错误；确保所有错误随后得到改正。

有关代码检查的具体流程，个人归纳为一个流程表，就不在这里详述了。不过，这里需要值得注意的是代码检查这个过程。
1. 在代码检查的时间和地点上的选择上，应避免所有的外部干扰；
2. 代码检查会议的理想时间应在90-120分钟之内；
3. 大多数的代码检查都是按每小时大约阅读150行代码的速度进行；
4. 对大型软件的检查应安排多个代码检查会议同时进行，每个代码检查会议处理一个或几个模块或子程序。
除此之外，还需要从心理学角度给予提前的心理筹备。因为，要使检查过程有成效，还必须树立正确的态度。其心理因素必须要提前分析正确，否则事倍功半。假设程序员将代码检查视为对其个人的攻击、采取了防范的态度，那么检查过程就不会有效果。而正确的做法应该是：
· 一方面：提出的建议应针对程序本身，而不应针对程序员，即：软件中存在的错误不应被视为编写程序的人员本身的弱点，且这些错误应被看做是伴随着软件开发的艰难性所固有的；
· 另一方面：程序员必须怀着非自我本位的态度来对待错误检查，对整个过程采取积极和建设性的态度：代码检查的目标是发现程序中的错误，从而改进程序的质量。
正因为这个原因，大多数人建议应对代码检查的结果进行保密，仅限于参与者范围内部。尤其是如果管理人员想利用代码检查的结果，那么就与检查过程的目的背道而驰了。

文尾，顺便提一下代码检查附带的几个有益的作用吧。
· 程序员通常会得到编程风格、算法选择及编译技术等方面的反馈信息；
· 其他参与者也可以通过接触其他程序员的错误和编程风格而同样受益匪浅；
· 代码检查还是早期发现程序中最易出错部分的方法之一，有助于在基于计算机的测试过程中将更多的注意力集中在这些地方。
《The Art of SoftWare Testing》读书笔记（13）_错误列表

　　在代码检查过程中，一个重要的部分是需要对照一份编程错误列表，来分析程序是否存在常见的错误。于是，作者接下来就给出了一份错误列表，该份错误列表在很大程度上是独立于编程语言的，即：大多数的错误都可能出现在用任意语言编写的程序中的。并建议读者可以把自己使用的编程语言中特有的错误，以及代码检查发现的错误补充到这份错误列表中去。

　　作者给出的该列表比较详细，因此，不在这里详述，只是给出该错误列表的总的构架。该列表共分为八个部分：数据引用错误、数据声明错误、运算错误、比较错误、控制流程错误、输入/输出错误、接口错误、其他检查。
《The Art of SoftWare Testing》读书笔记（14）_代码走查

　　说完代码检查，现在来谈谈代码走查。从定义上来讲，代码走查是以小组为单元进行代码阅读的，同样也是一系列规程和错误检查技术的集合。且代码走查也采用了持续一至两个小时的不间断会议的形式。代码走查的小组成员的构成而言，一般是由三至五人组成，其中一人扮演“协调人”；一人担任秘书角色，负责记录所有查处的错误；还有一人担任测试人员。不过最佳的组合应该是：
o 一位极富经验的程序员；
o 一位程序设计语言专家；
o 一位程序员新手（可以给出新颖、不带偏见的观点）；
o 最终将维护程序的人员；
o 一位来自其他不同项目的人员；
o 一位来自该软件编程小组的程序员。
　　至于测试的流程跟代码检查很类似，类似之处就不多谈，只说一下不同之处吧。稍有不同的是代码走查的任务：就是参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。且在会议期间，每个测试用例都在人们头脑中进行推演，即：把测试数据沿程序的逻辑结构走一遍，并把程序的状态（如变量的值）记录在纸张或白板上以供监视。

　　这里，需指出：这些书面的测试用例必须结构简单、数量较少，因为人脑执行程序的速度比计算机执行程序的速度慢上若干量级。之所以提供这些测试用例，目的不是在于其本身对测试了关键的作用，而是其提供了启动代码走查和质疑程序员逻辑思路及其设想的手段。因为，在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。

　　文尾，至于代码走查所需要从心理学角度给予提前的心理筹备、后续过程和附带的几个有益的作用，都与代码检查的类似，所以在这里就不提了。
　
《The Art of SoftWare Testing》读书笔记（15）_桌面检查与同行评分
　　
　　在本章的最后，作者附带提了一下桌面检查和同行评分这两个方法。

　　首先，来谈下桌面检查。桌面检查可视为由单人进行的代码检查或代码走查；并由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据。由此，我觉得桌面检查可以说是上述两种方法的一个内核或者说是雏形吧。所以也可知其效率是相当低的。

　　然后，看一下同行评分。需指明：其该方法与测试并无关系，因为其目标并不是为了发现错误的，只是它与代码阅读的思想有一定的关联而已。
· 定义上：同行评分是一种依据程序整体质量、可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。不难看出，该技术的目的是为程序员提供自我评价的手段。
· 其小组成员的构成为：一位管理员，负责担任该评分过程的管理工作；6-20名参与者，并要保持匿名性，且要具备相似的背景。
· 评分的资料：由参与者自己挑出两个由自己编写的程序以供评审，其中一个应是自认为能代表其自身能力的最好作品；另一个是自认为质量较差的作品。
　　文尾，至于具体流程，就不再详叙了。
《The Art of SoftWare Testing》读书笔记（16）_浅谈测试用例

　　本书第四章主要讲述了白盒测试和黑盒测试的原理、具体方法，及一些测试策略的思考。就经验而言，个人觉得，测试软件中最重要的因素还是要：设计和生成有效的测试用例。所以，作者在开章之处特别提及测试用例，我认为是很必要的。

　　缘由：因为测试不可能是完全的，所以最显然的测试策略就是努力使测试尽可能完全。那么，由于考虑到时间和成本的约束，则一个最关键的问题就是：在所有可能的测试用例中，哪个子集最有可能发现最多的错误。很显然，在所有的方法中效率最低的就是随机输入的测试，那么就需要提出一套思考过程，让其有助于更加睿智地选取测试数据。

　　于是，便有了一种比较合理的测试策略：先使用黑盒测试方法来设计测试用例，然后视情况需要使用白盒测试方法来设计补充测试用例。
　 　
《The Art of SoftWare Testing》读书笔记（17）_白盒测试

　　先谈及、概括一下白盒测试。
　　
　　白盒测试，所关注的是：测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。因此，也可以认为是逻辑覆盖测试。具体方法有五个，按其逻辑覆盖的从弱到强依次列出：

o 语句覆盖（面）： 将程序中的每条语句至少执行一次，但实现不太可能，该准则有很大的不足，以至于它通常没有什么用处
o 判定/分支覆盖（线）： 必须编写足够的测试用例，使得每一个判断都至少有一个为真和为假的输出结果。即：每条分支路径都必须至少遍历一次。换句话说：所有判断的每个可能结果都至少执行一次，以及将程序或子程序的每个入口点都至少执行一次。需要指出的是：该准则满足语言覆盖准则。
o 条件覆盖（点）： 　编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。
o 判定/条件覆盖（点线结合）： 设计出足够的测试用例，将一个判断中的每个条件的所有可能结果至少执行一次，将每个判断的所有可能结果至少执行一次，将每个入口点都至少调用一次。需明确一点，该准则有一个极大的缺点：尽管看上去所有条件的所有结果似乎都执行到了，但由于某些特定的条件会屏蔽掉其他的条件，通常并不能全部都执行到。例如：该准则并不一定会发现逻辑表达式中的错误（与、或）。
o 多重条件覆盖（点线组合）：
　　
编写足够多的测试用例，将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。需要说明的是，满足多重条件覆盖准则的测试用例集，同样满足判定覆盖准则、条件覆盖准则以及判定/条件覆盖准则。需明确的是：在存在循环的情况下，多重条件覆盖准则所需要的测试用例的数量通常会远远小于其路径的数量。
　　文尾，作者小结了一下。
o 包含每个判断只存在一种条件的程序，最简单的测试准则就是：设计出足够数量的测试用例，将每个判断的所有结果都至少执行一次；将所有的程序入口都至少调用一次，以确保全部的语句都至少执行一次。
o 包含多重条件判断的程序，最简单的测试准则是：设计出足够数量的测试用例，将每个判断的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。
《The Art of SoftWare Testing》读书笔记（18）_黑盒测试之等价类划分

　　再概述一下黑盒测试。那么首先就是等价类划分法。

　　等价类划分，是一个最优子集的挑选过程。该子集必须具备两个特性：

o 严格控制测试用例的增加，减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量；即：每个测试用例都必须体现尽可能多的不同的输入情况，以使最大限度地减少测试所需的全部用例的数量；（经验而言，是用于生成有效测试用例的约束。）
o 覆盖了大部分其他可能的测试用例：使用或不使用这个特定的输入集合，哪些错误会被发现，哪些会被遗漏掉。即：应该尽量将程序输入范围进行划分，将其划分为有限数量的等价类，这样就可以合理地假设测试每个等价类的代表性数据等于测试该类的其他任何数据。（经验而言，是用于生成无效测试用例的约束的。）
　　具体步骤为：
1. 确定等价类：确定等价类是选取每一个输入条件，将其划分为两个或更多的组。这里可以借助表格来进行划分，并确定了两类等价类：有效等价类、无效等价类。
2. 生成测试用例。（具体三步就不再叙述了）
　　文尾，顺便提一点个人经验：依据规格说明确定输入条件时，一定要思维紧密和周全，否则会出现很大的遗漏性；且用单个测试用例覆盖无效等价类，是因为某些特定的输入错误可能会评比或取代其他输入错误检查。所以应：少而全、多而专。
《The Art of SoftWare Testing》读书笔记（19）_黑盒测试之边界值分析、错误猜测

　　边界值分析法，有较好的测试回报率。该法较简单，仅是用于考察正处于等价划分边界或在边界附近的状态。因此，只需明确边界条件这一定义即可。边界条件，是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。

　　错误猜测法，没有用到任何特殊的方法，只是利用直觉和经验猜测出错的可能类型，然后编写测试用例来暴露这些错误。基本思想是列举出可能犯的错误或错误易发情况的清单，然后依据清单来编写测试用例；并且在阅读规格说明时联系程序员可能做的假设来确定测试用例，也就是说规格说明中的一些内容会被忽略，要么是由于偶然因素，要么是程序员认为其显而易见。

　　文尾，需提及注意的是：边界值分析法，考虑到了结果空间的边界（因为输入范围的边界并不总是能代表输出范围的边界情况。）
《The Art of SoftWare Testing》读书笔记（20）_黑盒测试之因果图分析

　　因果图分析法，依作者而言，是为了解决边界值分析和等价划分的一个弱点：未对输入条件的组合进行分析。而因果图恰恰有助于用一个系统的方法选择出此类高效的测试用例集，并且可以指出规格说明的不完整性和不明确之处。

　　因果图，是一种形式语言（有严格语法限制的语言，计算机语言都是形式语言），是将自然语言描述的规格说明转换为因果图。实质上，是一种数字逻辑电路（一个组合的逻辑网络），但没有使用标准的电子学符号，而是使用了稍微简单点的符号。具体有六步（涉及到的每步具体过程及图样，由于篇幅，都在此略去）：
1. 将规格说明分解为可执行的片段；
2. 确定规格说明中的因果关系；
3. 分析规格说明的语义内容，并将其转换为连接因果关系的布尔图，即：因果图；
4. 给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”；
5. 过仔细地跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表；
6. 将判定表中的列转换成测试用例。
《The Art of SoftWare Testing》读书笔记（21）_测试策略

　　本章最后，作者给出了一个合理的测试策略：“测试用例涉及方法可以组合为一个整体的策略，即：每一种方法都可以提供一组具体的有用的测试用例，但是都不能单独提供一个完整的测试用例集，所以一组合理的策略为：
1. 如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法；
2. 在任何情况下都应使用边界值分析方法。应注意，是对输入和输出边界进行分析；
3. 为输入和输出确定有效和无效等价类，在必要情况下对确认的测试用例进行补充；
4. 使用错误猜测技术增加更多的测试用例；
5. 针对上述测试用例集检查程序的逻辑结构，即白盒测试的五种方法。可适当的增加足够数量的测试用例，以便覆盖准则得到满足。”
《The Art of SoftWare Testing》读书笔记（22）_ 模块（单元）测试

　　单元测试，是本书第五章讲述的重点。它是构建大型程序（>500 lines codes）测试的第一个步骤。可从三个方面给予了概括：

o 定义上：单元测试是对程序中的单个子程序、子程序或过程进行测试的过程，即：一开始并不是对整个程序进行测试，而是首先将注意力集中在对构成程序的较小模块的测试上面；
o 必要性上：它是一种管理组合的测试元素的方法手段；以减轻调试（准确定位并纠正某个已知错误的过程）的难度；并提供同时测试多个模块的可能，将并行工程引入软件测试中。
o 目的上：它是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。
　　文尾，需指明：单元测试的目标不是为了说明模块符合其规格说明，而是为了揭示模块与其规格说明存在着的矛盾。
《The Art of SoftWare Testing》读书笔记（23）_单元测试用例设计

　　单元测试用例的设计，需先明确两点：
o 单元测试设计测试用例时，需两种类型的信息，即：模块的规格说明、模块的源代码。
o 虽单元测试总体上是采用面向白盒测试的，但是其设计主导思想是：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。
　　文中，作者给予了实例讲解。从中可获悉：在使用白盒测试方法前，需要列举出程序中所有的条件判断；而在使用白盒测试方法时，应在开始就使用多重条件覆盖的方法；而在使用黑盒测试方法时，最好要使用边界值分析的方法，且不要依据边界值分析的结果来重写白盒测试的测试用例，最好黑盒测试的用例再单独写出来进行补充，不改动前边已经确认过的白盒测试的测试用例。

　　文尾，须明确两个观点：其一、多重条件覆盖准则要优于其他准则；其二、任何逻辑覆盖准则尚不足以胜任作为生成模块测试用例的惟一手段。同样，无论在白盒测试中判定状态或生成测试用例时都需要利用这样一个辅助手段：列表；即，状态判定表。
《The Art of SoftWare Testing》读书笔记（24）_增量测试与非增量测试

　　执行单元测试过程中，有两点需考虑：其一、如何设计一个有效的测试用例集；其二、将模块组装成工作程序的方式。前者涉及的内容在上篇已叙述过，而后者，涉及模块测试用例编写的形式、可能用到的测试工具类型、模块编码和测试的顺序、生成测试用例的成本以及调试的成本等。它有两种具体实现方法：增量测试（自顶向下和自底向上的开发或测试过程）、非增量测试。

o 增量测试：将测试的模块组装到测试完成的模块集合中，再进行测试。且必须要为每个模块准备一个驱动模块，但不需要桩模块。
o 非增量测试：先要独立地测试每个模块，再将这些模块组装成完整的程序。且测试单独的模块时，需一个特殊的驱动模块和一个或多个桩模块。
0. 驱动模块：人们编写的一个小模块，用来将测试用例驱动或传输到被测模块中，也可以用测试工具替代；还必须向测试人员显示该模块的结果。
1. 桩模块：被测模块可能调用到了其他的模块，所以还必须使用一个额外的组件，即：特殊模块，用于模拟被调用模块的功能。
　　文尾，需提及一个结论：增量测试要更好一些。原因如下：
§ 非增量测试所需的工作量要多一些；（桩模块）
§ 增量测试可以较早发现模块中与之不匹配接口、不正确假设相关的编程错误；
§ 增量测试，调试会进行得比较容易些；（调试）
§ 增量测试会将测试进行得更彻底；（可能会诱发先前测试完的模块出现新缺陷，且会经受更多的检验）
§ 非增量测试所占用的机器时间显得少一些；
§ 模块测试阶段开始时，非增量测试，就会有更多的机会进行并行操作，即：所有的模块可以同时测试。
《The Art of SoftWare Testing》读书笔记（25）_几个误解

　　在开始概述两种增量测试方法之前，作者对几个误解给予了澄清：
§ 自顶向下的测试、自顶向下的开发、自顶向下的设计被常用作近义词。
　
自顶向下的测试和自顶向下的开发确实是近义词，表示安排模块的编码和测试顺序的策略；而自顶向下的设计则完全不同并且是独立的概念，即：按自顶向下模块设计的程序既可使用自顶向下的方式，也可使用自底向上的方式进行增量测试。
§ 自底向上的测试（或自底向上的开发）常被错误得当作非增量测试；
　
原因在于自底向上的测试的开展方式与非增量测试是相同的，即：对底层或终端模块进行测试。
《The Art of SoftWare Testing》读书笔记（26）_自顶向下测试、自底向上测试

　　自顶向下测试，是从程序的顶部或初始模块开始。
o 测试开始之后，挑选哪一个后续模块进行增量测试没有惟一正确的方法；
o 惟一的原则是：要成为合乎条件的下一个模块，至少一个该模块的从属模块（调用它的模块）事先经过了测试。
o 该测试策略里边最关键的可能就是编写桩模块了。
o 它涉及到的几个关键点概括为：桩模块的返回信息一定要给予此次调用所希望的返回值，否则调用模块将会发生失效或是产生一个混乱的结果；早期，测试数据要通过其一个或多个桩模块提交给模块的。
o 需要指出一点，就是测试完一个模块后，就用一个实际的模块代替其中的一个桩模块，而该模块需要的桩模块也被添加起来。需要注意的是：不存在最佳的模块序列。但尽量让包含I/O操作的桩模块和重要的桩模块添入。

　　自底向上测试，是开始于程序的终端模块，此类模块不再调用其他任何模块。
o 测试完这些模块之后，同样没有最佳的方法来挑选要进行增量测试的下一个模块；
o 惟一正确的原则是：要成为合乎条件的下一个模块，该模块所有的从属模块（它调用的模块）都已经事先经过了测试。
o 需要指出的是，如果终端模块是多个的话，既可以进行串行测试，也可以进行并行测试。且每一个模块都需要一个特殊的驱动模块，即：包含着有效的测试输入、调用被测模块且将输出显示出来（或将实际输出与预期输出作比较）的模块。
o 对于测试序列也同自顶向下测试的一样。
《The Art of SoftWare Testing》读书笔记（27）_几个注意点

　　本章，最后作者给予了单元测试的其他部分的实际测试策略。
1. 应对测试用例进行测试。当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，存在两个可能的解释：要么该模块存在错误；要么预期的结果不正确（测试用例不正确），所以为了将这种混乱降低到最低程度，应在测试执行之前对测试用例集进行审核或检查。
2. 使用自动化测试工具可以使测试过程中的枯燥劳动减至最低；
3. 在准备单元测试时，要重温以下心理学和经济学原则，会有所裨益的；
4. 因为个人试图测试自己编写的程序所带来的心理学问题，也适用于模块测试。
《The Art of SoftWare Testing》读书笔记（28）_更高级别的测试

　　本书第六章,主要讲的是更高级别的测试，它最适合用于软件产品。可从两个层面来概述。
o 更高级别的测试
　　
当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。因而即使完成了一次非常完美的单元测试，仍然不能保证已经找出了程序中的所有错误，所以必须有这一测试环节。
o 软件开发过程与测试过程的对应
　　
软件开发过程在很大程度上是沟通有关最终程序的信息、并将信息从一种形式转换到另一种形式，因此，绝大部分软件错误都可以归因为信息沟通和转换时发生的故障。
　　现有三个补充的方法来预防或识别这些错误，它们分别是：
o 可以使软件开发过程更加精密，以防其中出现很多错误；
o 在每个阶段结束时，可以引入一个独立的验证过程，在进入下一个阶段之前尽可能多地发现问题；
o 对不同的开发阶段采用不同的测试方法。即：将每一个测试过程都重点针对一个特定的转换步骤，从而也针对一类具体的错误。（能在开发过程和测试过程之间建立起一对一的联系，能避免没有效果的多余测试，并使我们不会遗漏掉大量的错误类型。）
　　文尾，需注明的是：测试过程顺序并不一定意味着严格的时间顺序，多种测试在时间上是可以发生部分重叠测试的。但需要说明，集成测试往往并不作为一个独立的测试步骤，而且在进行增量模块测试时，它是模块测试的隐含部分。（开发过程与测试过程的对应关系图，由于篇幅的原因，在此就不再叙述。）
《The Art of SoftWare Testing》读书笔记（29）_功能测试

　　功能测试，作者从三个方面来概述：
o 定义上：是一个试图发现程序与其外部规格说明之间存在不一致的过程。
o 方法上：通常是一项黑盒测试，即：要依赖早期的单元测试的过程来实现理想的白盒逻辑覆盖准则。
o 过程上：需要对规格说明进行分析以获取测试用例集。
《The Art of Sof