测试模式

1. 黑盒测试模式(black box testing)
也称为功能测试(functional testing)、闭箱测试(closed box testing)。

通过设计符合独立需求的测试来保证软件符合要求，测试不必基于所实现的方式。

从某种意义上讲，不按照软件实现或者内在结构进行的软件测试称为黑盒测试。

2. 白盒测试模式
也称为明箱测试(clear box testing)

根据软件的内部结构来确定必要情况。一个完整的测试将测试软件所有可能经过的路径。

但并不真正的需要测试所有条件，可以根据软件的内部结构来决定哪些测试是必须的和有意义的。

注意：
² 需保证软件在所有情况下的正确实现
² 最低限度的测试集合必须满足下面的条件：确保软件在所有的条件下实现，并且自始至终覆盖软件实现的所有可能路径。
² 仔细分析与每条实现路径相关的边界条件(boundary condition)，有利于减少测试数目。

一些通用的边界条件：
² 导致一个数字数据类型发生溢出的值
² 导致一个数据结构发生溢出的值
² 导致布尔表达式在一个if条件可能为真或为假时的值

为了确保能够测试所有软件经过的路径，采用一个覆盖分析(coverage analysis)工具保存已经测试过的路径轨迹。

白盒测试的成本可能会非常高。

3. 单元测试模式
将程序中的一个单独的类从其它类中隔离出来进行测试。

一个类的完整单元测试可以改善它的可重用性(reusability)。

如果一个将要进行单元测试的类与另外一个类相互依存，并且创建另一类的虚拟版本不太显示，单元测试可以考虑将这两个类一起进行测试。

4. 集合测试模式
首次将单独开发好的类集合到一起进行的测试。

每个类进行了单元测试，第一次把他们组装到一起，并检验工作协调性的过程称为集成测试(integration testing)。

在开始时，先将少量的一些类集合到一起进行测试，然后再不断将一些类加入来进行测试，通过这种方法可以将集合测试的杂乱程度降到最低。

设计一个集合测试计划时，首先应道确定一个用于组织测试的程序结构。通用方法是：
² 以自上而下或者自下而上的模式组织类，或者同时采用这两种模式组合类。这种技术易于理解，但是应用于面向对象设计时可能会困难，因为大多数面向对象设计层次性不强。
² 将与一个通用程序特征相关的众多类合并到一起，或者使用案例
² 将与一个公共线程相关的类合并到一起。

对于小型或中型工程的集合测试来说，常很少要求为它们做测试规划，大型工程的集合测试需要相对正规的规划。

集合测试常比系统测试所花的时间少，比单元测试所花的时间多。

5. 系统测试模式
把程序当成是一个完整的实体，在一个与它运行的环境相似的环境中测试，确保它符合规范。

6. 回归测试模式

7. 验收测试模式(Acceptance Testing)
验收测试是为了确保发布的软件符合用户的需求。这种测试常由用户实现。

软件开发人员希望新开发的定制软件可以满足用户的需求，但是有些需求是用户从来没有向开发人员表述过的。

验收软件的手续必须面对实际，因为开发者无法决定用户用何种办法验收该软件。比如“屏幕要求美观”的测试会带有很多的主观因素，而验收一个程序的屏幕是否符合编写规范的要求会显得比较合适一些。

解决方案：
在开发者开始工程设计之前，经过讨论，在验收测试计划方面产生共识。

一个验收计划应包括下面的元素：
² 应包括一个指明验收测试范围的声明。如软件组件、操作环境或硬件。也可以明确验收测试的高级目标。一些经典的目标包括：
ü 新系统产生的结果应与现存系统产生的结果相同
ü 新软件必须具备没秒钟处理相当数量事务的工作能力
ü 必须采用一个最低级别精确度来实现计算
² 应当声明用于验收测试的测试数据。如可能，数据应当符合实际产品的数据
² 指出谁将负责开发必要的详细测试计划、测试环境和技术支持
² 还应说明谁来确保软件通过验收测试

负责验收测试的人员很自然的趋向于对将要测试的软件持怀疑态度。他们宁愿承认是软件缺陷导致出错也不愿承认是因为对软件的不熟悉而导致出错。
可预先做一些工作使验收测试人员熟悉软件。

制定验收测试计划可能需要一些时间，但是这时还处于测试的开始阶段，成员之间没有过多的争论，还心平气和，便于测试人员和开发人员讨论尚未达成的共识。

8. 静室测试模式
软件的设计人员和软件测试的人员不应当讨论他们的设计规范或实现过程。

软件开发和测试开发都同样受详细规范的约束。如果测试设计人员和软件设计人员采用相同的方式描述规范，那么测试将无法发现那些不确定的东西。

采用静室测试模式相互不会被对方引诱到规范中不确定的部分中。不过有可能在发现问题的测试进行之前，不容易发现某些规范的不确定部分。