（2）Fault：即从代码的角度看，代码的什么错误导致了软件的问题。

　　例如，代码在输入为某种情况下访问了非法的内存地址——0X0000000C。

　　（3）Root Cause：错误根源，即导致代码错误的根本原因。

　　例如，代码对于id1==id2的情况没有做正确判断，从而引用了未赋初值的变量，产生了以上的情况。

　　以下是一个完整的例子。

　　（1）Symptom：用户报告，一个Windows应用程序有时会在启动时报错，程序不能运行。

　　（2）Fault：有时候一个子窗口的handle为空，导致程序访问了非法内存地址，此为代码错误。

　　（3）Root Cause：代码并没有确保创建子窗口（在CreateSubWindow（）内部才做）发生在调用子窗口之前（在OnDraw（）时调用），因此子窗口的变量有时会在访问时为空，导致上面提到的代码错误。

　　2、Test Case：测试用例

　　测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等。

　　3、Test Suite：测试用例集合

　　即一组相关的测试用例。

　　提示：Suite发音念作“sweet”，不是念作“suit”，一大半的学生都念错。

　　从测试设计的方法分类

　　测试设计有两类方法：Black box（黑箱）、White box（白箱）。

　　这是每个接触过软件测试的人都会给出的答案。但这只是整个软件测试的入门知识。可以跳过去，直接讨论下面的内容。

　　问：我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础，还有哪一个更难，哪一个更有前途，等等。据说河曲数码在搞“灰箱测试”，是不是更高级？能不能简单讲一讲？

　　阿超：大家都有这些问题么？

　　杂曰：[略去对此问题热烈的争论500字]

　　阿超：听了大家的争论，看来我们的确得花不少时间统一认识。

　　所谓黑箱/白箱，是指软件测试设计的方法，不是软件测试的方法！注意“设计”二字。

　　黑箱：在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”，从软件的行为，而不是内部结构出发来设计测试。

　　白箱：在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。

　　在实际工作中，我们不应画地为牢，严格只用某一种方法来设计测试方法。在实际的测试中，当然是对系统了解得越多越好。所谓“灰箱”的提法，正是这一反映。有些测试专家甚至希望我们忘记全部的“箱子”和它们的颜色。

　　问：如果我是一个开发者，我能做“黑箱”么？

　　答：并不是要禁止懂得程序内部结构的人员来进行黑箱测试设计，只不过是在设计时有意不考虑软件的内部结构。例如：在测试程序内部基本模块的时候（单元测试），通常要求由对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基本模块的“行为”通常没有明确的定义。另一个例子是“易用性测试”，在设计此类测试的时候，没必要纠缠于程序的内部结构，而是着重于软件的界面和行为。但是软件易用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和“白箱”没有简单的高低之分。

　　一旦测试用例写出来之后，大可以忘了它们是从哪种颜色的箱子里出来的，用它可以了。

　　问：有人说“黑箱”，有人说“黑盒”，到底是“箱子”还是“盒子”？

　　答：在网上搜索了一下，“黑箱测试”有超过100万个记录，“黑盒测试”只有70多万。所以“箱子”赢了。

　　问：但是我听九条说他刚进公司实习的时候只能做“黑箱测试”，这是什么意思？

　　九条：我刚到公司实习的时候，两眼一摸黑，看到啥都是“黑箱”，即使测试用例是由懂得程序结构的开发人员写出来的，我还是只会机械地运行。我是知其然，不知其所以然，箱子当然是黑的。后来看得多了，学了一些东西，能够了解程序的结构和算法，箱子的颜色变浅了，好像能看到箱子里的东西一样。