《软件测试的艺术》读书笔记（一）

这是一本于 1979 年出版的书，比大多数中国互联网从业者的年纪还要大，但其中的观念却仍然适用。
软件测试常常被计算机专业的毕业生当作自己能力不足以做开发工作的“备选”职位，似乎大家默认觉得这个岗位的要求会比程序员低。
事实也确实如此，从薪资来说，软件测试尤其是功能测试的待遇比程序员低很多。即使是需要编程基础的自动化测试，月薪也比同样工作经验的程序员低了三分之一到四分之一。但即便如此，就像大多数初级程序员普遍缺少编程系统知识一样，软件测试工程师们的资质也是良莠不齐。这不仅体现在基础工作技能如文档编写、沟通能力上，更体现在他们本应掌握的职业经验和思维上。或许很多人会觉得自己的测试水平不错，日常的测试任务也能很好的完成，没有出现重大的疏漏。然而，这样就算优秀的软件测试工程师了吗？

1 测试能力的自我评估

第一章作者先出了一道测验。

我们要求设计一组测试用例（特定的数据集合），适当地测试一个相当简单的程序。为此要为该程序建立一组测试数据，程序须对数据进行正确处理以证明自身的成功。下面是对程序的描述：

这个程序从一个输入对话框中读取三个整数值。这三个整数值代表了三角形三边的长度。程序显示提示信息，指出该三角形究竟是不规则三角形、等腰三角形还是等边三角形。

作为产品，我能想到的就是：

1. 提供几组有效数据，分别符合不规则三角形、等腰三角形和等边三角形的条件
2. 提供无效数据，例如只有 1 个或者两个整数，提供 3 个小数。

我们再来看看参考答案：

用你的测试用例集回答下列问题，借以对其进行评价。对每个回答“是”的答案，可以得 l 分：

1．是否有这样的测试用例，代表了二个有效的不规则三角形？（注意，如 1，2，3 和 2，5，10 这样的测试用例并不能确保“是”的答案，因为具备这样边长的三角形不存在。）

2．是否有这样的测试用例，代表一个有效的等边三角形？

3．是否有这样的测试用例，代表一个有效的等腰三角形？（注意如 2，2，4的测试用例无效，因为这不是一个有效的三角形。）

4．是否能少有三个这样的测试用例，代表有效的等腰三角形，从而可以测试到两等边的所有三种可能情况？（如 3，3，4；3，4，3；4，3，3）

5．是否有这样的测试用例，某边的长度等于 0？6．是否有这样的测试用例，某边的长度为负数？

7．是否有这样的测试用例，三个整数皆大于 0，其中两个整数之和等于第三个？（也就是说，如果程序判断 l，2，3 表示一个不规则二角形，它可能就包含一个缺陷。） 8．是否至少有三个第 7 类的测试用例，列举了一边等于另外两边之和的全部可能情况（如 1，2，3；1，3，2；3，1，2）？

9．是否有这样的测试用例，三个整数皆大于 0，其中两个整数之和小于第三个整数？（如 1，2，4；12，15，30）

10．是否至少有三个第 9 类的测试用例，列举了一边大于另外两边之和的全部可能情况？（如 1，2，4；1，4，2；4，1，2）

11．是否有这样的测试用例，三边长度皆为 0（0，0，0）？

12．是否至少有一个这样的测试用例，输入的边长为非整数值（如 2.5，3.5，5.5）

13．是否至少有一个这样的测试用例，输入的边长个数不对（如仅输入了两

个而不是三个整数）?

14．对于每一个测试用例，除了定义输入值之外，是否定义了程序针对该输入值的预期输出值？

如果你和我一样只得了 3~4 分，也很正常，因为据说高水平的专业程序员平均得分仅 7.8（满分 14）。

2.1 软件测试的心理学

很多人和我一样，陷入了一个误区，认为软件测试的目的是证明软件完美无缺，只有不存在错误的测试才是成功的。
而作者举了一个例子，假如你生病了去医院检查身体，什么样的检测结果才能称作成功？是明明你受到病痛的折磨，花费了金钱和精力做了大量检查，却没有发现任何问题，还是通过检查确定了问题，医生可以据此给出诊疗方案呢？软件测试也是如此，我们的目的应该是尽可能的发现错误并修复它，以此提高软件的稳定性和可靠性。要证明软件的完美无缺本身就是个“不可能完成的任务”，抱着这样的想法，软件测试人员就会倾向于适用更不容易产生错误的数据进行调试，从而避免出现更多错误，而这背离了软件测试的初衷。

“测试是为发现错误而执行程序的过程”。

2.2 软件测试的经济学

黑盒测试：不去管程序的内部逻辑，用所有符合条件的数据输入进行测试。但是，就拿常见的注册功能来说。仅仅是密码这一项，支持字母、数字和常见符号，要列出所有的可能性，光是数字和字母的排列组合就是个天文数字。就算是非测试人员也能看出来这样的测试会花费很长时间并且没有必要。白盒测试：在考虑程序内部逻辑结构的基础上，将每一条语句可能存在的逻辑路径都执行一遍。和黑盒测试一样，即使是一个简单的程序，逻辑路径的分支数量也十分庞大。况且，逻辑测试也存在缺陷，无法发现设计规范问题、缺少必要路径的问题和数据错误。
总之，从成本考虑，程序测试应该以数量最小的测试用例发现更多的问题，以最小的代价取得最大的成果。

2.3 软件测试的原则

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

常见的错误是对输入和输出的定义都很模糊，例如下面这个测试用例：

上图中存在以下问题：

1. 剪切的组件消失应该是预期结果而不是操作步骤。

2. 显示正确本身就是一个十分模糊的定义，应该使用更加精准的描述：其中包括组件行数、粘贴后选中状态、参数内容等。

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

在我还是游戏策划的时候，经常对程序员同事对错误的“视而不见”感到不可思议。
明明是只要按照正常流程使用就能立即发生的错误，居然到了测试阶段才发现。现在想来，除了工作流程的问题（当时的团队没有要求程序员自己按照使用流程对程序进行验收的步骤），更重要的是心理问题。
当我自己开始编写程序之后，测试提出的一些问题也让我觉得：我竟然犯了这样明显的错误。再后来看了一本书叫《看不见的大猩猩》，人的精力是有限的，当放在自认为更重要的事情上时，就很容易忽略别人看起来很明显的存在。这不是主观故意的忽视，而是客观存在的科学。当然也不排除某些同事确实存在偷懒的情况，没有完成开发测试。

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

直白点说，就是如果一个模块已经发现的 bug 数量明显多于其他模块，那么未来在这个模块发现 bug 的可能性仍然很高。
测试用例的设计也应该有所侧重，对已有 bug 数多的部分进行额外的测试。

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

大家倾向于认为在项目团队中最重要的是开发人员，其他岗位都是辅助性工作，但从市场营销的角度来说，团队中的每个位置都至关重要。
区别只在于所做工作对实现目标的重要性和可替代性，优秀的测试的重要程度并不亚于程序员。不管什么岗位，都需要不断的学习提升通用技能和专业能力。如果自己都不认同所在岗位存在的价值，认为无需努力提升自己，那不管在什么岗位都会被时代所淘汰。