1.1测试策略和计划
    在制定测试策略时，要基于被测软件的质量目标。质量目标就是测试的需求。它们决定了测试的阶段和质量的目标。要想最优化测试的活动并制定一个切实可行的测 试计划，需要将被测软件分解成为一个一个的业务功能。在进行业务功能分解时，要以黑盒的方法来看待被测软件的功能，即独立于软件的实现方法。若想计算测试 的效果并且保证测试的活动适合于特定业务的需要，则需要引入风险评估的手段。

1.1.1   需求
    测试的必要条件是要确定预期结果或者需求。为了能更好的了解需求，将需求进行分类是非常有帮助的。以我们的观点，可以将需求分为功能性需求和质量需求（非功能性需求）。功能性需求描述了在业务上期望如何使用新的软件系统，且该系统中应该包括哪些功能。质量需求包括的是软件系统的通用特性，且独立于功能。
1.1.1.1      功能性需求
    功能性需求以业务设计图的方式记录于文档中。为了在TestDirector中将需求作为测试的基础，需要将需求导入到TestDirector中。相应的业务设计图作为需求的附件存在，并作为将来测试活动的依据。
1.1.1.2             质量需求
    质量需求由两部分构成，一部分是为整个产品或者项目定义的质量目标，另一部分是每个业务功能的质量需求，这些业务功能的质量需求取决于风险评估的结果。
1.1.1.2.1       质量目标
1）适应性
组件被修改以适应新需求的难易程度。

2）完整性
组件实现所有需要的能力的程度。

3）正确性
a)        组件在规格分析、设计和实现过程中无错误的程度
b)        组件满足需求或者用户需要与期望的程度
c)        基于给定输入产生相应输出的能力，并且这个过程符合或者满足需求

4）有效性
当组件完成指定任务时，能最少使用所需资源的程度。

5）可维护性
组件被修改以纠正错误，提高性能或其他属性，或者适应被改变了的环境的难易程度

6）模块性
软件系统由离散的组件组成的程度，即改变一个组件时能将对其他组件的影响降至最低。

7）可移植性
软件系统或组件能被转移到其他硬件平台或者软件平台上的难易程度。

8）可靠性
组件在一定的时间内、一定的条件下执行所需完成功能的能力。

9）可用性
用户对软件组件的理解和操作的难易程度。

1）开发员自测试阶段（不在我们的考虑范围之内）
2）业务功能测试（单元测试）
3）业务流程测试（应用级的集成测试）
4）业务集成测试（端到端的集成测试）
5）性能测试
6）系统集成测试

下面的表中描述了每个测试阶段需要达到的质量目标：

   业务功能测试和业务流程测试是在软件项目开发过程中完成的。而业务集成测试和系统集成测试则组合成回归测试，用于软件系统上线前或者发布为产品前来检验软件的质量。