1. 软件测试的目标

软件测试核心工作围绕发现和防止软件缺陷与软件故障为中心。

最常见形式的软件故障或缺陷在软件开发的编码、编译和崩溃循环中发现，这个循环过程是每个程序员都已经熟悉的，而且它已经成为我们在实际生产过程的所用的一种事实上的方法。

测试面向对象软件时，应该遵守几条重要的原则：

* 在软件系统还未进一步复杂化前及时测试；

* 将软件遇到的缺陷类型分门别类。

1.1 分而治之

应该对软件系统进行增量测试。如果可能，用最简单的形式测试软件，测试每个组件，然后测试组件组。测试单个组件属于所谓的单元测试。测试交互的组件组属于所谓的集成测试。

在程序员开始排除软件段中的缺陷前，应该知道这个软件段中可能存在的缺陷类型。应当对软件段中可能存在的每一种缺陷制定一个测试计划，即需要对每一类软件缺陷进行测试。

如下一些常见的缺陷类别：

* 竞争条件：发生在两个或更多线程或进程试图修改相同共享可修改数据块之时；

* 死锁： 线程或进程等待某件永远也不会发生的事件；

* 优先权倒置：当软低优先权线程阻塞较高优先权线程的执行，同步变量被使用或竞争资源时发生；

* 性能下降：当系统在反应灵敏性、执行时间长短、计算结果准确性等方面的性能下降时发生；

* 无限延迟：当系统无限推迟进程或线程的规划，同时其它进程或线程要接收通知和资源分配，此时发生无限延迟；

互斥量耗尽：当系统达到可以创建的最大数量互斥量时发生；

线程耗尽：当系统达到可以创建的最大数量线程时发生。

1.2 软件测试类型：

* 单元测试，强度测试，集成测试，递归测试，操作性测试（将软件组件放在一个真实的环境中，加载全部系统负荷进行测试。）规范测试（用作软件验证过程的一部分），可接受测试。

2. 对象的测试实例

在面向对象编程中，我们对评价以下方面的测试实例感兴趣：

a. 对象构建；b. 对象析构； c. 对象赋值； d. 对象复制； e.对象派生；f. 成员函数性能； g. 对象资源需求； h. 公有对象访问； i. 受保护对象访问； j. 线程化对象访问。

3. 测试多线程架构的问题

测试多线程架构的问题是目标环境难以在测试场合模仿。多线程环境中主要有以下两个原因：

a. 继承和多态可以创建开放层次； b. 线程规划对上下文和系统负荷敏感。

3.1 开放层次问题

对象的生产者不能预测用户将来使用继承和多态来特殊化该对象的方式。如果生产者的对象有公有构造函数和虚成员函数，则用户可以在派生类中特殊化此对象。当派生类的身份未知时，测试基类是否可靠是一项复杂的工作。

3.2 规划问题

如果某多线程进程连续执行了若干次，而且这个进程中包含多个具有中等优先权的线程，每次执行进程时，可能按不同的顺序执行线程。对于分派器来说，同等对待所有的线程。不过，对于测试器来说，这就带来了问题，因为在这种情况下，我们不能复制测试环境。如果我们不能复制测试环境，就不能正确重现软件故障，而如果不能重现软件故障，就不可能找出导致故障的原因。如果由于每个线程都具有相同的优先权，操作环境任意分派线程，此时就存在测试上的问题。

如果环境是一个动态环境，每次执行进程时，构建和析构不同的对象；如果架构以及架构存在的环境不断发生变化，而且由于继承和多态架构是末端开放的（open ended），那么，通过传统的方式证明程序的正确性极其困难。测试多线程应用程序的基础需要对说明性编程技术（declarative programming technique）、组合理论（combinatorial theory）、谓词演算（predicate calculus）以及逻辑语义（logic semantics）有充分的理解。

4. 使用常用模型和架构

测试模型用于系统验证。设计者在创建测试模型时可以利用域知识。在域中相对于在软件中来说，参数、限制、系统常态以及不合理状态都更容易识别。如果在域中识别它们，它们可能在为域建模的类组件中更容易理解。

对于多线程应用程序有多种常用模型：

* 主/次线程模型（primary/secondary thread model）；

通常在main()函数中创建的主线程将进程执行的工作分解成多个次线程。在主/次模型中，线程通常是分离的。这意味着它们只需要很少的通信或根本不需通信就可以一起同步执行。因为主/次模型将工作分解成基本上分离的任务，所以程序员不必担心复杂的同步情形。主线程可能会取消违规的线程。除了创建和取消线程外，主线程与次线程之间的责任或契约很少。

* 对等模型（peer model）；

* 工作管道模型（work pipe model）。