《软件测试的艺术》第2章：软件测试的心理学和经济学

• 软件测试的心理学

书中此部分首先辨析了两个概念：软件测试的定义、成功的测试和不成功的测试。

软件测试的定义：

测试是为发现错误而执行程序的过程，我们应当假设程序是存在bug的；由于证明程序不存在错误的过程是一项看起来不太可能完成的工作，从心理学角度将软件测试定义为发现错误的动作，而不是证明程序不存在错误。软件测试的效果之一是对程序具有一种信心：软件做了其应该做的，未做其不应该做的。

成功的测试和不成功的测试：

如果在测试某段程序时发现了错误，而且这些错误是可以修复的，就将这次合理设计并得到有效执行的测试称作是“成功的”。如果本次测试可以最终确定再无其他可查出的错误，同样也被称作是“成功的”。

所谓“不成功的”测试，仅指未能适当地对程序进行检查，在大多数情况下，未能找出错误的测试被认为是“不成功的”，这是因为认为软件中不包含错误的观点基本上是不切实际的。

• 软件测试的经济学

存在软件测试的经济学问题的根源在于：软件测试不能发现“所有”的错误。即使是规模很小的程序。一般说来，要发现程序中的所有错误也是不切实际的，常常也是不可能的。为了应对测试经济学的挑战，应该在开始测试之前建立某些策略。黑盒测试和白盒测试是两种最普遍的策略。

黑盒测试：又称为数据驱动的测试或输入/输出驱动的测试。将程序视为一个黑盒子，测试目标与程序的内部机制和结构完全无关。在这种方法中，测试数据完全来源于软件规范。如果想用这种方法来发现程序的所有错误，判定的标准就是“穷举输入测试”将所有可能的输入条件都作为测试用例。

白盒测试：或称逻辑驱动的测试，允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构进行检查，从中获取测试数据(遗憾的是，常常忽略了程序的规范)。建立起与黑盒测试中穷举输入测试相似的测试方法：即将程序中的每条语句至少执行一次，这种方法通常称为穷举路径测试。

• 软件测试原则

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

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

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

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

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

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

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

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

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

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

验证芯发现：

1. 和软件测试相同，芯片的验证空间也是无限大的，发现所有的bug似乎也是不可能的。既然发现所有的bug几乎是不可能的，那验证的追求、目标或者交付的标准是什么呢？

   笔者认为，验证的目标总是尽可能多地发现代码缺陷，最终的验证交付也是在质量、风险和时间三者之间做一个平衡。最终RTL模块验证的是否“完备”，则是现在大家都比较认可的覆盖率驱动验证流程（CDV）。

   

2. 成功的验证用例是什么？首先肯定不是用例pass了，验证用例能够有效地发现代码问题，或者证明代码没有问题。实际中可能会有所谓的“太平盛世”现象：测试用例回归PASS，其实并没有发现真正的问题，并且认为验证已趋于收敛。验证用例能够发现代码问题，其中蕴含了验证用例的有效性。一个验证用例的有效性可以从对覆盖率的贡献和发现问题的可能性分析。

   

3. “程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比”，笔者认为这个整体性的原则在芯片验证中也同样成立。在实际项目，也会经常发现，有问题的模块总是有问题，没有问题的模块总是风平浪静。针对bug的重灾区模块，则需要重点考虑设计和验证的质量，当然也需要注意"风平浪静"的模块验证用例有效性。

4. "软件测试是一项极富创造性、极具智力挑战性的工作"，芯片验证的价值是什么？这个问题对于从事验证几年左右的工作者来说，是一个非常让人困惑的现象，验证看似重复枯燥的工作，我们的成就感，存在感在哪里呢？

---

验证芯发现：《软件测试的艺术》第2章https://mp.weixin.qq.com/s?__biz=Mzg3ODczNDg0NA==&mid=2247483683&idx=1&sn=9ea2ba51138ded047532649eac41198e&chksm=cf0e7db0f879f4a688afda348e0cd6b9fa0ca4ad02ef69d225e6aa4f7d12486b1690830fa9b4&token=1931400576&lang=zh_CN#rd