《软件测试的艺术》 阅读整理（一）

软件测试概念：

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

第一章：一个自我评价的测试

举例 · 小测试：

 

第二章：软件测试的心理学和经济学

    软件测试是一项技术工作，但也和经济学以及人类的心理学有重要的关联。

• 在理想的情况下，我们会测试程序的所有的可能执行的情况。但是在实际工作中，大多数情况下，这几乎是不可能的，因即使是一个非常简单的程序，其输入输出的可能性会达到百种或是千种甚至更多，通通都测试完了，是不切合实际的，如若真的去完成一个复杂的程序的测试，将会消耗太大的时间和人力资源，经济上也是不可取的。
• 成功的测试的一个应用程序，我们测试人员必须要有正确的 “态度”，在某些情况下，我们的测试人员的态度可能比实际测试过程本身还要重要，

2.1 软件测试的心理学

 不要只是为了证明程序能够正确运行而去测试程序；相反，应该一开始就去假设程序中隐藏的错误（这种假设对于几乎所有的程序都成立），然后测试程序，发现尽可能多的错误。那么我们更应该把测试理解为：“测试是为了发现错误二执行的程序的过程”。

---

 

测试人员目的：

• 证明程序中不存在错误
• 证明程序中存在错误，设计出测试数据更多的去发现问题

更加通俗点的说，我们就是在对一个软件进行一个破坏性的‘施虐’，来去发现软件是不是可以正常运行，是不是达到了我们设计时的预期。

 成功的测试：

• 在测试某个阶段的程序时，我们发现了错误，这些错误是可以进行修改好的，我们将这次合理设计得到有效执行的测试，可以称作是“成功的”。

不成功的测试：

• 只是指没有对程序适当的进行检查，在多数情况下，没有找出错误的测试，可以说是“不成功的”。

• 一个“不成功”的测试用例，会使程序输出正确的结果，但不能发现任何错误。

知识点小结：

1. 软件测试更适合理解为是：去假设程序中有错误的问题破坏性的过程。
2. 一个成功的测试用例，通过诱发程序发生错误，在这个问题上加以调整后，是软件更加的好用。
3. 软件测试是测试不到完全没问题的

2.2 软件测试的经济学

2.2.1 黑盒测试

黑盒测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

作用：

黑盒测试方法着重测试软件的功能需求，是在程序接口上进行的测试，主要是为了发现以下错误：

1. 是否有功能错误，是否有功能遗漏。
2. 是否能够正确地接收输入数据并产生正确的输出结果
3. 是否有数据结构错误或外部信息访问错误
4. 是否有程序初始化和终止方面的错误

2.2.2 白盒测试

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。

目的

通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试。在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

原则

1. 一个模块中的所有独立路径至少被测试一次。
2. 所有逻辑值均需测试true和false两种情况。
3. 检査程序的内部数据结构，保证其结构的有效性。
4. 在取值的上、下边界及可操作范围内运行所有循环。

实施阶段

1. 测试计划阶段：根据需求说明书，制定测试进度。
2. 测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。
3. .测试执行阶段：输入测试用例，得到测试结果。
4. 测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。

分类

• 白盒测试的方法总体上分为静态分析方法和动态分析方法两大类。
• 静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致，有无冲突或者歧义。
• 动态分析是当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中，最重要的技术是路径和分支测试。

 2.3 软件测试的原则

1. 测试用例中一个必须部分是对预期输出或结果进行定义

2. 程序员因避免测试自己编写的程序

3. 编写软件的组织不应当测试自己编写的软件

4. 应当彻底检查每个测试的执行结果

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

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

7. 因避免测试用例用后即弃，除非软件本身就是一次性的软件

8. 计划测试工作时不应默许假定不会发现错误

9. 程序某部分存在更多错误的可能，与该不会已发现错误的数量成正比

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

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

——实际上是再说，一个测试用例必须是包含两个部分：a. 对程序的输入数据具体描述； b. 对程序在上述输入数据下的正确输出结果的精准描述。

如果某个测试用例的预期结果事先没有得到定义，当我们实际操作时，即使是得到的是错误的结果，也可能会被认为是正确的。

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

——大多数程序员都不能有效的测试自己编写的程序，因为他们无法改变思维方式来尽力的暴露自己程序中的错误；另外程序员会下意识的避免找出错来，担心受到同事、上司、客户、或正在开发程序或系统主管的惩罚。

就像是我们在精心的设置一个建筑，我们自己是很认可自己的设计的，觉得是没问题的，即使有问题，我们也会找出各种借口去解释，还是把检查的这个工作交给其他人，以他人视角去看待、去测试会更加的稳妥。

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

——与个体程序员会有相似的心理问题，会难以客观的测试自己的软件，并不说编程组织发现程序的问题是不可能的，只是说更经济的方法还是由独立的、客观的第三方来测试。

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

——这个原则字面很容易理解，也是常常会被忽视的，我们在工作中，即便是错误的症状在输出清单中清楚的看到了，但还是没有找出来这些错误。也就是说，很有可能我们在后续发现的错误，是往往前面的测试遗漏掉的，而这一块，也是我们习惯性的会容易忽视的。

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

——在实际测试时，我们习惯性的会把重点集中倾向于有效的和预期的结果上，反而会忽略了无效和未预料的结果上。但是，未预料到的和无效输入的结果的测试用例，似乎会比针对有效输入的那些个用例更容易发现问题的存在。

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

——这条原则也是上条原则的必然结果，从字面很容易理解，必须去检查下程序是否做了我们希望去做的负作用的运行。

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

——在交互式系统测试时最为常见。我们常常坐在终端前，慌忙的编写了测试用例，然后就将这些用例交由程序运行了。如果时程序运行结束后，测试用例就消失了，一旦软件又需要重新测试时（例如：当改正了某个错误或是做了某种改进），又必须重新设计这些测试用例。而保留了测试用例，当程序其他的部件发生变动后需重新执行，可以再次使用，也就是---回归测试了。

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

——这个问题是项目经理实际中容易出现的，这也是使用了不正确的测试定义的一个迹象，也就是说，假定“测试时一个证明程序正确运行的过程”。再次说下：测试—就是为了发现错误而执行程序的过程。

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

——假设一个程序由两个模块、类或子程序A 和 B组成，我们在 A中发现了5个错误，而 模块B中，我们只是找到了1个错误。我们可以说：模块A 和 模块B相比的话，有更多错误的可能性要大。另一个说法是，错误总是聚集存在。这种现象告诉我们，为了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。

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

——测试一个大型软件所需的创造性很可能超过开发该软件所需要的创造性。要充分的测试一个软件以确保所有错误不存在是不可能的。

小结：

三个重要的测试原则：

• 软件测试是为发现错误而执行的过程
• 一个好的测试用例具有较高的发现某个未发现的错误可能性
• 一个成功的测试用例能够发现某个未发现的错误

---