软件测试学习笔记

单元测试

单元测试即模块测试，模块测试是对程序中的单个子程序，子程序或过程进行测试的过程，也就是说，一开始并不是对整个程序进行测试，而是将注意力集中在对构成程序的较小模块的测试上面。

1.测试用例的设计

设计测试用例的时候需要使用两种类型的信息：模块的规格说明和模块的源代码，而规格说明一般都规定了模块的输入和输出参数以及模块的功能。

.模块测试总体上是面向白盒测试的，因此模块测试中测试用例的设计过程如下：

使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。

2.增量测试

在执行模块测试的过程中，我们主要有两点需要考虑：first，如何设计一个有效的测试用例集；second，将模块组装成工作程序的方式。第二点考虑很重要，因为它涉及以下内容：

模块测试用例的编写形式

可能用到的测试工具类型

模块编码与测试顺序

生成测试用例的成本以及调试的成本

增量测试或集成（先将下一步要测试的模块组装到测试完成的模块集合中，然后再进行测试）

非增量测试或崩溃（先独立的测试每个模块，然后再将这些模块组装成完整的程序）

测试单独的模块需要一个特殊的驱动模块和一个或多个桩模块。

对比结论：增量测试更好一些

1.非增量测试所需的工作量要多一些。

2.如果使用了增量测试，可以较早地发现模块中与不匹配接口，不正确假设相关的编程错误。

3.因此，如果使用了增量测试，调试会进行的更容易一些。

4.增量测试会将测试进行的更彻底。

5.非增量测试所占用的机器时间显得少一些。

6.模块测试阶段开始时，如果使用的是非增量测试，就会有更多的机会进行并行操作（也就是说，所有的模块可以同时测试）。

3.自顶向下的测试

自顶向下的测试是从程序的顶部或初始模块开始。唯一原则是：要成为合乎条件的下一个模块，至少一个该模块的从属模块（调用它的模块）事先经过了测试。

自顶而下测试不存在最佳的模块序列，但却有下面可供考虑的两项指南：

1.如果程序中存在关键部分，那么在设计模块序列时就应该将这些关键模块尽可能早的添加进去。所谓“关键部分”可能是某个复杂的模块，某个采用新算法的模块或某个被怀疑容易发生错误的模块。

2.在设计模块序列时，应将I/O模块尽可能早地添加进来。

4.自底向上的测试

自底向上的策略开始于程序中的终端模块（此类模块不再调用其他任何模块）。

要成为合乎条件的下一个模块，该模块所有的从属模块（它调用的模块）都已经事先经过了测试。

优缺点比较：

自顶向下测试

优点：如果主要的缺陷发生在程序的顶层将非常有利

          一旦引入I/O功能，提交测试用例会更容易

         早期的程序框架可以进行演示，并可激发积极性

缺点：必须开发桩模块

          桩模块要比最初表现的更复杂

          在引入I/O功能之前，向桩模块中引入测试用例比较困难

           创建测试环境可能很难，甚至无法实现

          观察测试输出很困难

           使人误解设计和测试可以交迭进行

           会导致特定模块测试的完成延后

自底向上测试

优点：如果主要的缺陷发生在程序的底层将会非常有利

         测试环境比较容易建立

          观察测试输出比较容易

缺点：必须开发驱动模块

          直到最后一个模块添加进去，程序才形成一个整体

5.5执行测试

当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，存在两个可能的解释：要么该模块存在错误，要么预期的结果不正确（测试用例不正确）。为了将这种混乱降低到最小程度，应在测试执行之前对测试用例集进行审核或检查（也就是说，应对测试用例进行测试）。

使用自动化测试工具可以使测试过程中的枯燥劳动减至最小。

因个人试图测试自己编写的程序所带来的心理学问题，也适用于模块测试。

应避免随意丢弃测试用例，应将它们按照某种格式记录下来，以便将来可以重新使用它们。

最后记住模块测试的目的不是证明模块能够正确的运行，而是证明模块中存在着错误。