下载文档原格式
The Art of SoftWare Testing》读书笔记（1）_引子有关自己与软件测试之间的渊源而言，获悉这个领域的时间不长，接触的时间就更可谓短暂，但仔细想来，还要从大学期间说起比较好。
软件测试这个概念第一次出现在我的眼前时，是大四上学期开的软件工程这个科目中所涉及到的一点点。
由于某些因素，使我在大学期间忽略了对测试领域相关知识的储备。
第二次面对它时，是考研复习准备阶段。
那时，我对测试这个领域也仅仅只是知道，就是中文书面表达的“测试”这两个汉字的含义而已。
工作的前两年里，或许是因为从事的是有关算法方面性质的工作，所以并未对测试这个领域给予过多的关注，还好，或多或少还是接触到了一些。
直到最近一年多来，由于一个大型项目人手不够的缘故，所以临时从自己负责的另一个研究项目中抽过来（刚好该项目阶段性完成），负责有关此项目的测试部署与规划。
而这个时候，才能说是：真正意义上接触到了软件测试这个领域。
虽然，在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。
但，从这个项目阶段性结束后自己的体会而言，给我感悟最深的还是有关软件测试这个领域的。
通过在这个项目里的工作，让我真正体会到了：软件测试是一门艺术。
恰恰也是因为这个缘故，这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。
《The Art of SoftWare Testing》读书笔记（2）_前言喜欢在网上书店中遛达，看到不错的书就买下。
为什么不去书店？一个字，懒呗！总觉得，有那去书店的时间，完全可以好好睡一美觉，亦或可亲手烹制一顿美味可口的美食。
哎，反正就是，懒得走出家门去逛街！恰巧，此次浏览书籍时，无意间看到了《The Art of Software Testing》这本书。
在看了大家所给予它极高的评价留言后，虽然有些疑惑（毕竟这个时代，枪手太多了！），但我深信：一本书能够“活”25年，应该还是很不简单的。
于是，就半信半疑的订购了这本书，期望能够从这本书中获悉到有用的知识，来丰富一下自己面对这个领域时的贫乏困境，亦作为知识储备。
吹风吹到疯：《软件测试的艺术》读书笔记《软件测试的艺术》在长假的第四个悠闲的中午，灭掉了《软件测试的艺术》这本书，好像最近看的号称“艺术”的书比较多，《生活的艺术》，《项目管理的艺术》还包括这本《软件测试的艺术》。
一般来说，在IT行业一本书能够在25年之后出第二版的，那么这本书的生命力算是强的。
总的来说这本书讲的是中规中矩，感觉还是七十年代那种纯学术化的气息，让人联想到了大学的教科书。
书的开头还是非常精彩的，非常哲理化的开头，讲述了测试的本质，之后是一些看得头晕的名词和方法，最后的两篇关于调试和极限测试的不错，而新加的网站测试内容让人有点失望。
总的来说，对于想了解“软件测试”的同学还是可以去看看的，至于要学到什么的话，可能还要从其他地方继续深入了解。
不过就了解测试的目的，一些常用名词的意义，以及一些基本的原则来说，这本书还是不错的。
开头的经典：- 软件测试心理学：测试是为发现错误而执行程序的过程。
软件不是为了证明软件是好的，发现错误是他的目标。
- 软件测试经济学：软件中包含的错误的总和永远是个未知数，所以要找到软件中包含的所有的错误，几乎是不可能的。
- 原则1：测试用例中一个必需部分是对与其输出或结果的定义。
- 原则2：程序员应当避免自己测试自己编写的程序。
- 原则3：编写软件的组织不应当测试自己编写的软件。
- 原则4：应当彻底检查每个测试的执行结果。
- 原则5：测试用例的编写不仅应当根据有效和与其的输入情况，而且也应当根据无效的和未预料到的输入情况。
- 原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
- 原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
- 原则8：计划测试工作时不应默许假定不会发生错误。
- 原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
- 原则10：软件测试是一项极富创造性，极具智力挑战性的工作。
《软件测试》读书笔记（持续更新）⽂章⽬录#第⼀部分 软件测试综述##第⼀章 软件测试的背景###1.1臭名昭著的软件错误⽤例研究###1.2软件缺陷是什么####1.2.1软件失败的术语确实严重，甚⾄是危险的情况：故障（fault）、失败（failure）、缺点（defect）不那么尖锐，主要指未按预料运⾏，⽽不指全部失败：异常（anomaly）、事件，插曲（incident）、偏差（variance）最常⽤的术语：问题（problem）、错误（error）、缺陷（bug）其他术语：⽭盾（inconsistency）、特殊（feature）软件测试中出现的其他术语：产品说明书（product specification）：简称为说明（spec）或产品说明（product spec）。
它对开发的产品进⾏定义，给出产品的细节、如何做、做什么、不能做什么。
这种协定从简单的⼝头说明到正式的书⾯⽂档有多种形式。
之后《软件开发的过程》会讲述产品说明书和开发过程中的更多内容。
在每个公司，不同的开发⼩组⾥会有不同的术语，但在⽤词上过多的计较是没有意义的。
在这本书中，所有的软件问题都被称为缺陷####1.2.2软件缺陷的官⽅定义 ☟⾄少满⾜下列5个规则之⼀才称发⽣了⼀个软件缺陷（software bug）1）软件未实现产品说明书要求的内容（产品说明书：计算器能够准确⽆误的进⾏加减乘除；按下（+）键，没有反应，或者得到错误答1）软件未实现产品说明书要求的内容（产品说明书：计算器能够准确⽆误的进⾏加减乘除；按下（+）键，没有反应，或者得到错误答案）2）软件出现了产品说明书指明不应该出现的错误（产品说明书：计算器永远不会崩溃、锁死或者停⽌反应；狂敲键盘，计算器停⽌接受输⼊）3）软件实现了产品说明书未提到的内容（计算器求加减乘除还可以求平⽅根，这也是缺陷，虽然有了更好，但会增加测试的⼯作，甚⾄带来更多的缺陷）4）软件未实现产品说明书虽未明确提及但应该实现的⽬标（⽬的为了捕获那些产品说明书上的遗漏之处。
当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。
软件开发过程在很大程度上是沟通有关最终程序的信息，并将信息从一种形式转换到另一种形式。
由于这个原因，绝大部分软件错误都可以归因为信息沟通和转换时发生的故障、差错和干扰。
1、将软件最终用户的要求转换为一系列书面的需求。
这些需求就是该软件产品要实现的目标。
2、通过评估可行性与成本、消除相抵触的用户需求、建立优先级和平衡关系，将用户需求转换为具体的目标。
3、将上述目标转换为一个准确的产品规格说明，将产品视为一个黑盒，仅考虑其接口以及与最终用户的交互。
该规格说明被称为“外部规格说明”。
4、如果该产品是一个系统，而不仅是一个程序，那么下一步骤就是系统设计。
该步骤将系统分隔为单独的程序、部件或子系统，并定义它们的接口。
5、通过定义每个模块的功能、模块的层次结构以及模块间的接口，来设计程序或程序集合的结构。
6、设计一份准确的规格说明，定义每个模块的接口与功能。
7、经过一个或更多的子步骤，将模块接口规格说明转换为每个模块的源代码算法。
需求规格说明定义了为什么要开发程序。
目标定义了程序要做什么，以及应做得怎样。
外部规格说明定义了程序对用户的准确表现。
与后续阶段相关的文档越来越详细地规定了程序是如何建立起来的。
模块测试的目的是发现程序模块与其接口规格说明之间的不一致功能测试的目的是为了证明程序未能符合其外部规格说明系统测试的目的是为了证明软件产品与其初始目标不一致6.1、功能测试功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。
外部规格说明是一份从最终用户的角度对程序行为的精确描述。
6.2、系统测试将系统或程序与其初始目标进行比较。
给定这个目标之后，隐含两方面的含义：1、系统测试并不局限于系统。
如果产品是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。
2、根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。
1.1什么是软件测试软件测试：在可控的预置条件下操作软件的过程，其目的是拟定软件行为符合产品规格说明、发现错误和验证软件复符合用户的需求。
注意：目的不仅仅是发现软件存在缺陷没有发现缺陷的测试同样有价值测试是评估软件质量的一种方法1.2软件测试原则（1）尽早和不断的进行软件测试发现软件缺陷越早，其修复成本越低（2）重视无效数据和非预期使用习惯的测试缺陷高发区（3）充足注意测试中的群集现象缺陷扎堆（4）用例要定期评审，适时补充修改用例保持测试用例的活力（5）应当对每一个测试结果做全面检查发现隐含的缺陷（6）经济原则穷尽测试不也许，考虑成本（7）开发人员应避免测试自己的程序思维定势、心理作用1.3软件测试分类软件开发阶段：单元测试、集成测试、系统测试、验收测试测试方法：白盒测试、黑盒测试测试实行方：开发方测试、用户测试、第三方测试测试内容：功能测试、性能测试、安全性测试、兼容性测试、可靠性测试按软件开发阶段分类：（1）单元测试：模块测试，对软件中最小可测试单元进行检查、验证（2）集成测试：组装测试，对软件不同单元或部件的接口进行测试（3）系统测试：将软件与外设、网络等结合在一起，对整个产品系统进行的测试（4）验收测试：按照验收依据，对整个系统进行测试按测试方法分类：（1）白盒测试（结构测试、逻辑驱动测试）基于代码的内部逻辑知识，检测软件内部动作是否按照规格说明书的规定正的确现，检查软件中的所有结构和途径是否可以按预定规定对的工作。
（2）黑盒测试（功能测试、数据驱动测试）用的多把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，只检查程序功能是否按照需求规格说明书的规定正常使用，程序能否适本地接受输入数据，并产生对的的输出信息。
1.4软件测试方法黑盒测试：等价类划分法、边界值分析法、错误推测法、因果图法、鉴定表驱动法、正交实验法、场景法、功能图法白盒测试：代码走查、代码审查、静态分析、逻辑覆盖、基本途径测试、域测试、符号测试、程序插桩几种常用的测试方法（1）等价类划分法：一种重要的、常用的设计方法根据数据的需求，吧数据划分为有效等价类和无效等价类，进而从每个等价类中选取一个数据作为测试用例数据。
软件评测师教程（第一版）笔记第一篇理论篇第1章软件测试概论1.1概述早期的测试等同于“调试”。
测试是为发现错误而执行的一个程序或者系统的过程。
测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。
1.3软件测试与软件项目的关系软件测试的目的是为了发现软件中存在的错误，但是，其根本目的是为了提高软件质量，降低软件项目的风险。
软件的质量风险表现在两个方面，一种是内部风险，一种是外部风险。
内部风险是在即将销售的时候发现有重大的错误，从而延迟发布日期，失去市场机会；外部风险是用户发现了不能容忍的错误，引起索赔，法律纠纷，以及用于客户支持的费用甚至失去客户的风险。
软件测试只能证明软件存在错误，而不能证明软件没有错误。
软件公司对软件项目的期望是在预计的时间、合理的预算下，提交一个可以交付的产品，测试的目的就是把软件的错误控制在一个可以进行产品交付/发布的程度上，可以交付/发布的产品并不是没有错误的产品，因此软件测试不可能无休止地进行下去，而是要把错误控制在一个合理的范围之内，因为软件测试也是需要花费巨大成本的。
1.5第三方测试第三方测试是指独立于软件公司自身测试的测试。
第三方测试机构的测试除了发现软件问题之外，还有对软件进行科学、公正的评价的职能，这就要求第三方测试机构要保持公正、廉洁、客观、科学、独立的态度。
第2章软件测试基础1、什么是软件测试测试（test）被当作一个常规的检验产品质量的生产活动。
测试的含义为“为检验产品是否满足需求为目标”。
“软件测试”的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。
软件是由文档、数据以及程序组成的，那么软件测试就应该是对软件形成过程的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。
2、什么是软件质量ISO9126中定义的“软件质量”是：软件满足规定或潜在用户需求特性的总和。
ISO14598中“软件质量”定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。
代码检查，怎么说呢？经验⽽⾔，我挺喜欢⽤的。
因为，跟项⽬经理（或设计⼈员）读设计，能够⾮常容易发现设计上的逻辑错误或遗漏的问题等等。
因此，有必要好好叙述下。
⊙定义上：所谓的代码检查，其实就是以组为单位阅读代码，是⼀系列规程和错误检查技术的集合。
该过程通常将注意⼒集中在发现错误上，⽽不是纠正错误。
⊙成员组成：⼀个代码检查⼩组通常是由四⼈组成，其中⼀⼈发挥着协调作⽤、⼀⼈是该程序的编码⼈员、⼀⼈是其他成员通常是程序的设计⼈员、⼀⼈是测试专家。
这⾥，值得⼀提的是：那个发挥着协调作⽤的成员。
该协调⼈应该是个称职的程序员，但不是该程序的编码⼈员，不需要对程序的细节了解得很清楚。
协调⼈的职责包括⼏点：为代码检查分发材料、安排进程；在代码检查中起主导作⽤；记录发现的所有错误；确保所有错误随后得到改正。
有关代码检查的具体流程，个⼈归纳为⼀个流程表，就不在这⾥详述了。
不过，这⾥需要值得注意的是代码检查这个过程。
1.在代码检查的时间和地点上的选择上，应避免所有的外部⼲扰； 2.代码检查会议的理想时间应在90-120分钟之内； 3.⼤多数的代码检查都是按每⼩时⼤约阅读150⾏代码的速度进⾏； 4.对⼤型软件的检查应安排多个代码检查会议同时进⾏，每个代码检查会议处理⼀个或⼏个模块或⼦程序。
除此之外，还需要从⼼理学⾓度给予提前的⼼理筹备。
因为，要使检查过程有成效，还必须树⽴正确的态度。
其⼼理因素必须要提前分析正确，否则事倍功半。
假设程序员将代码检查视为对其个⼈的攻击、采取了防范的态度，那么检查过程就不会有效果。
⽽正确的做法应该是： ⊙⼀⽅⾯：提出的建议应针对程序本⾝，⽽不应针对程序员，即：软件中存在的错误不应被视为编写程序的⼈员本⾝的弱点，且这些错误应被看做是伴随着软件开发的艰难性所固有的； ⊙另⼀⽅⾯：程序员必须怀着⾮⾃我本位的态度来对待错误检查，对整个过程采取积极和建设性的态度：代码检查的⽬标是发现程序中的错误，从⽽改进程序的质量。
第二章测试心理学1.所谓的软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。
2.测试的定义：不是1）软件测试就是证明软件不存在错误的过程。
2）软件测试的目的在于证明软件能够正确完成其预订的功能。
3）软件测试就是建立一个‘软件做了其应该做的’信心的过程。
真正的定义是：软件测试时为发现错误而执行程序的过程。
3.心里学研究表明，当人们看是一项工作时，如果已经知道它是不可行的或无法实现时，人们的表现就会非常的糟糕。
软件测试更适宜被视为试图发现程序中错误（假设其存在）的破坏性的过程。
（软件测试心理学）4.黑盒测试和白盒测试是两种最普遍的测试策略。
黑盒测试：又称为数据驱动的测试或输入/输出驱动的测试。
将程序视为一个黑盒子。
测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。
（测试投入的目标在于通过有限的测试用例，最大限度的提高发现的问题数量，以取得最好的测试效果）白盒测试：称为逻辑驱动测试，允许我们检查程序的内部结构。
（条件覆盖，判定覆盖，语句覆盖）5.软件测试中的重要原则：一个成功的测试用例能够发现某个尚未发现的错误。
第三章代码检查、走查与评审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.回溯发调试：在小型程序中定位错误的一种有效方法是沿着程序的逻辑结构回溯不正确的结果，直到找出程序逻辑出错的位置。
