《软件测试的艺术》读书笔记 - 1

《软件测试的艺术（原书第三版）》

 

 

本书从第1版付梓到现在已经30余年，是软件测试领域的经典著作。本书结构清晰、讲解生动活泼，简明扼要地展示了久经考验的软件测试方法和智慧。

作 者：（美）梅耶（Myers, G. J.） 等著，张晓明，黄琳 译

出 版 社：机械工业出版社

出版时间：2012年3月

市图书签：TP311.55 481 000837340

---

译者序

序言

前言

第1章 一次自评价测试

 

10分钟编写测试用例：

序号	用例	预计输出
1	a 或 b 或 c = 0	不成立
2	a 或 b 或 c < 0	不成立
3	a = b = c 且 > 0	等边三角形
4	c ≥ a + b （×3，abc相互颠倒）	不成立
5	a = b 且 c < a + b （×3，abc相互颠倒）	等腰三角形
6	c < a + b （×3，abc相互颠倒）	不规则三角形
7	a、b、c 录入非Int类型字符（×6，abc相互颠倒）	不成立
8	a、b、c 只录其中入1个或两个值	不成立

 

三角形测验评价：

 

　　以我们的经验来看，高水平的专业程序员平均得分仅7.8分（满分14分）。

　　【笔者本次得分13分，缺少内容用红色标注了。】

 

　　测试用例即使满足了上述条件，也不能确保找出所有可能的错误。

　　这个测验说明，即使测试这样一个小程序，也不是一件容易的事情。因此，想象一下测试一个十万行代码的交通管理系统、一个编译器，甚至一个工资管理程序的难度。

---

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

2.1 软件测试的心理学

“软件测试就是证明软件不存在错误的过程。”

“软件测试的目的在于证明软件能够正确完成其预定的功能。”

“软件测试就是证明‘软件做了其应该做的’的过程。”

———— 这些定义都本末倒置的。

 

　　每当测试一个程序时，应当想到要为程序增加一些价值。通过测试来增加程序的价值。是指测试提高了程序的可靠性或质量。提高程序的可靠性，是指找出并最终修改了程序的错误。

　　因此，不要只是为了证明程序能够正确运行而去测试程序；相反，应该一开始就假设程序中隐藏着错误（这种假设几乎都是成立），然后测试程序，发现尽可能多的错误。

 

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

———— 如此定义更为合适。

 

　　这不是微妙了文字游戏，理解软件测试的真正定义，对于成功地进行软件测试有很大的影响。人类行为总是倾向于具有高度目标性，确立一个正确的目标有着重要的心理学影响。

    它暗示了软件测试是一个破坏性的过程，甚至是一个“施虐”的过程，这就说明为什么大多数人都觉得它困难。这种定义可能违反了我们的愿望；所幸的是，我们大多数人总是对生活充满建设性而不是破坏性的愿景。大多数人都本能的倾向于创造事物，而不是将事物破坏。它还暗示了对于一个特定的程序，应该如何设计测试用例（测试数据），哪些人应该而哪些人又不应该执行测试。

==================== 华丽的分割线 ========================

　　增进对软件测试定义的理解，分析一下“成功的”和“不成功的”：

当项目经理总结测试用例执行结果时，将没有发现错误的测试过程称为一次“成功的测试”，而将发现了某个新错误的测试成为“不成功的测试”。

———— 这又是一次本末倒置。

 

 

　　类比一下病人看医生的情况，病人因为身体不适而去看医生。如果以上对病人进行了一些检查和化验，却没有诊断出任何病因，我们就不会认为检查和化验是“成功的”，因为病人支付了昂贵的费用和精力，而病状却依然如故。病人会因此而质疑医生的诊断能力。但是，如果医生诊断出病人是胃溃疡，那么这次检测就是“成功的”，医生可以开始进行相应的治疗。

　　类推到软件测试中来，能发现错误的测试用例不太可能被认为是“不成功的”，也就是说，能发现错误就证明他是值得设计的。“不成功的”测试用例，会看到程序输出正确的结果而没有发现任何错误。

==================== 华丽的分割线 ========================

 

诸如“软件测试就是证明‘软件做了其应该做的’的过程。”
此类定义所带来的问题是：

 

　　程序及时能够完成预期功能，也仍然可能隐藏错误。也就是说，程序在没有实现预期功能时，其错误是清晰地显现出来的；如果程序做了其不应该做的，这同样是一个错误。

　　考虑一下第一章中的“三角形测试程序”，即使我们证明了程序能够识别不规则三角形、等腰三角形、等边三角形，但是在完成了不应执行的任务后（例如：将判断三边1、2、3为一个不规则三角形或将三边0、0、0说成等边三角形），程序仍然是错的。

==================== 华丽的分割线 ========================

总结一下：

 

• 软件测试更适宜被视为视图发现程序中错误（假设其存在）的破坏性的过程。

• 一个成功的测试用例，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。

• 最终我们还是要通过软件测试来建立某种程度的信心：

• 软件做了其应该做的，未做其不应该做的。

• 通过对错误的不断研究是实现这一目的的最佳途径。

 

---

 

2.2 软件测试的经济学

　　一般来说，要发现程序中的“所有”错误也是不缺实际的。这个基本的问题反过来暗示出软件测试的经济学问题、测试人员对被测软件的期望以及测试用例的设计方式。

　　为了应对测试经济学调整，应该在开始之前建立某些策略。黑盒测试和白盒测试是两种最普遍的策略。

2.2.1 黑盒测试

 

　　黑盒测试是一种重要的测试策略，又称为数据驱动的测试或输入-输出驱动的测试。

　　这种方法中，测试数据完全来源于软件规范（换句话说，不需要去了解程序的内部结构）。

　　如果想用这种方法来发现程序所有错误，判定标准就是“穷举输入测试”，即将所有可能的输入条件都作为测试用例。

 

　　若要穷举测试第一章的“三角形程序”，实际要创建无限的测试用例。如果程序中使用数据存储，不仅要测试所有有效和无效的事务处理，还要测试所有可能的事物处理顺序。

　　上述说明，“穷举输入测试”是无法实现的。一方面是我们无法测试一个程序以确保它是无错的；二是软件测试中需要考虑的是一个基本问题是软件测试的经济学。测试投入的目标在于通过有线的测试用例，最大限度的提高发现问题的数量，以取得最好的测试效果。

@ 对程序做些合理但非无懈可击的假设，这种思路将形成本书的第四章中的软件测试用例设计策略的部分方法。

 

 

2.2.2 白盒测试

　　另一种测试策略称为白盒测试或称逻辑驱动的测试，允许我们检查程序的逻辑结构，从中获取测试数据。

　　遗憾的是，常常忽略了程序的规范。

　　针对这种测试策略进行“穷举路径测试”，即如果使用测试用例执行了程序中所有可能的控制流程路径，那么程序有可能得到了完全测试。

　　“穷举路径测试即完全的测试”论断存在两个问题：

1. 程序中不同逻辑路径的数量可能达到天文数字。
2. 虽然可以测试程序中的所有路径，但是它可能仍然存在着错误：
   • 单纯的穷举路径测试，不能保证程序符合其设计规范（例如升序、降序效果反了）。
   • ……不能发现缺少哪些必须路径。
   • ……可能不会暴露数据敏感错误。

 

　　总之，尽管穷举输入测试要强于穷举路径测试，但两者都不是有效的方法，因为两者都不可行。也许有一种，将黑盒测试和白盒测试的要素结合起来，行程一个合理并不十分完美的测试策略。

@本书第四章将深入讨论。