写在前面：
相比于芯片验证，软件测试有着悠久的历史沉淀和更为完整的生态，和芯片验证在某些方面上几乎有着相同的思路和方法。因此从软件测试的视角出发，重新思考芯片验证的方方面面。第一个系列为《软件测试的艺术》学习。
第一章 一次自评价测试
书中第一章主要通过一个三角形判断的例子来测试读者对软件测试的认识。程序描述如下：
这个程序从一个输入对话框中读取三个整数值，这三个整数值代表了三角形三条边的长度。程序显示提示信息，指出该三角形是何种三角形:不规则三角形、等腰三角形还是等边三角形。
如果为上面这个小程序，设计一组测试的输入数据来验证程序功能是否正确，大家可以列出多少种测试输入数据，即测试用例集呢？
书中并没有给出具体的测试用例集，而是给出了需要考虑的用例种类,大家可以自行体会一下：
-
是否有这样的测试用例，代表了一个有效的不规则三角形?(注意，如1、、3和2、5、10这样的测试用例并不能确保“是”的答案，因为具备这样边长的三角形不存在。)
-
是否有这样的测试用例，代表一个有效的等边三角形?
-
是否有这样的测试用例，代表一个有效的等腰三角形?(注意，如2、2、4的测试用例无效，因为这不是一个有效的三角形。)
-
是否至少有三个这样的测试用例，代表有效的等腰三角形，从而可以测试到两等边的所有三种可能情况(如3、3、4;3、4、3;4、3、3)?
-
是否有这样的测试用例，某边的长度等于0?
-
是否有这样的测试用例，某边的长度为负数?
-
是否有这样的测试用例，三个整数皆大于0，其中两个整数之和等于第三个?(也就是说，如果程序判断1、23表示一个不规则三角形，它可能就包含一个缺陷。)
-
是否至少有三个第7类的测试用例，列举了一边等于另外两边之和的全部可能情况(如1、2、3;1、3、2;3、1、2)?
-
是否有这样的测试用例，三个整数皆大于0，其中两个整数之和小于第三个整数(如1、2、4;1215、30)?
-
是否至少有三个第9类的测试用例，列举了一边大于另外两边之和的全部可能情况(如1、2、4;1、4、2;4、1、2)?
-
是否有这样的测试用例，三边长度皆为0(0，0，0)?
-
是否至少有一个这样的测试用例，输入的边长为非整数值(如253555)?
-
是否至少有一个这样的测试用例，输入的边长个数不对(如仅输入了两个而不是三个整数)?
-
对于每一个测试用例，除了定义输入值之外，是否定义了程序针对该输入值的预期输出值?
书中最后的总结：
这个测验说明，即使测试这样一个小的程序，也不是件容易的事。因此，想象一下测试一个十万行代码的空中交通管制系统、一个编译器，甚至一个普通的工资管理程序的难度。随着面向对象编程语言(如Java、C++)的出现，测试也变得更加困难。举例来说，为测试这些语言开发出来的应用程序，测试用例必须要找出与对象实例或内存管理有关的错误。
从上面这个例子来看，完全地测试一个复杂的、实际运行的程序似乎是不太可能的。情况并非如此!尽管充分测试的难度令人望而生畏，但这是软件开发中一项非常必需的任务，也是可以实现的一部分工作，通过本书我们可以认识到这一点。
验证芯发现：
芯片验证的道理和上述是一致的，即使是一个小规模的模块，看似功能很简单，比如一个加法器、乘法器、FIR滤波器，或者I2C协议，如果真的要完全的验证充分，所需的投入成本都是“巨大”的。
验证芯发现：软件测试的艺术
https://mp.weixin.qq.com/s?__biz=Mzg3ODczNDg0NA==&mid=2247483671&idx=1&sn=c8281aab12a52cfbda481484a71845cf&chksm=cf0e7d84f879f492f79c437b4a0835ccafc57dc11066b9f5f4fcb4a2554b4b06d98addbb6313&token=1266482168&lang=zh_CN#rd
