测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试等）。
测试策略的制定主要包含三个方面的内容：
（1）确定测试过程要使用的测试技术和工具；
（2）制定测试启动、停止、完成标准；
（3）进行风险分析和应对方案。例如测试与外部接口或者模拟物理损坏、安全性威胁。测试计划最关键的一步就是将软件分解成单元，按照需求编写测试计划。
策略很多，看你从什么角度了。比如按阶段分可以分单元测试，集成测试，系统测试；
按可见度分可以分白盒，黑盒；其中白盒又能按方法分，比如不同的覆盖率：条件覆盖，
路径覆盖等。还可以按动态和静态分，好比代码走读算静态，手动执行算动态。
还能按流程分，比如数据流测试，业务流测试。各种不同的策略也不是单一存在的，
是几种并存的。好比你用Nunit做单元测试，它就包含了几种策略，
首先它是单元测试阶段，其次，它可以走数据流，第三，它可以做函数等的条件覆盖，
再者，它是动态测试的一种等等。
16种测试策略：
功能测试，性能测试，压力测试，容量测试，安全性测试，GUI测试，可用性测试，安装测试，配置测试，
异常测试，备份测试，健壮性测试，文档测试，在线帮助测试，网络测试，稳定性测试
在：正常情况下测试；非正常情况下测试；边界测试；非法，极端测试；
项目测试部分的策略描述测试活动的一般方法和目标。其中包括要进行的测试阶段（单元测试、集成测试和系统测试）以及要执行的测试类型（功能测试、性能测试、负载测试、强度测试等）。
该策略定义：
- 要使用的测试方法和工具。
- 测试完成和测试成功所采用的评价标准。例如，当成功执行 95% 的测试用例后，该标准可能允许软件进行验收测试。另一个标准是代码覆盖。在安全至上的系统中，该标准可能要求测试应该覆盖 100% 的代码。
- 影响资源要求或涉及进度的特殊考虑，如：
- 测试与外部系统之间的接口。
- 模拟物理损坏或安全威胁。
有些组织具有自行定义的公司测试策略。在这种情况下，需要将相应策略应用到特定的项目上。
制定测试计划活动应该侧重的最重要的维度如下：
- 处于什么迭代之中以及迭代的目的是什么。
- 正在执行什么测试阶段（单元测试、集成测试或系统测试）。可以在一次迭代中执行所有测试阶段。
现在来看一下测试活动的特征可以如何根据您所处的上述“测试维度”而变更。
当然，可以查看的特征很多，如需要的资源和花费的时间，但在此处，请专注于定义测试策略的重要元素：
- 测试类型（功能测试、强度测试、容量测试、性能测试、可用性测试、分布测试等）。
- 使用的评估标准（基于代码的测试覆盖、基于需求的测试覆盖、缺陷数量、平均故障间隔时间等。）
- 使用的测试方法（手工和自动）
测试类型在测试生命周期上没有通用的分布模式。根据迭代次数、迭代大小、项目种类的不同，可以重点执行不同的测试类型。
您将发现，系统测试阶段十分注重确保覆盖所有通过测试用例集表示的可测试需求。这意味着测试的完成标准将主要侧重于基于需求的测试覆盖。在集成测试
和单元测试阶段，您将发现基于代码的测试覆盖是更合适的完成标准。下图显示在进行软件的新迭代时，这两类测试覆盖评测标准的使用是如何变化的。
- 测试计划应该定义单元测试、集成测试和系统测试的完成标准集。
- 可以针对各次迭代采用不同的完成标准集。
您在项目中应该考虑尽量自动执行测试，尤其对于需要多次重复执行的测试（回归测试）。但需要切记的是，创建并维护自动测试需要花费时间并占用资源。在各个项目中始终都会有一定数量的手工测试。下图说明了在什么时间和什么测试阶段可能会执行手工测试。
示例：
下表显示何时区分不同的测试类型，并提供要定义的完成标准的示例。第一个表显示的是“典型的”MIS 项目：
| 迭代 / 测试 |
系统测试 |
集成测试 |
单元测试 |
| 迭代 1 |
用于所有用例的自动性能测试。
· 所有已计划的测试都已执行。
· 所有严重性为 1 的缺陷都已经解决。
所有已计划的测试都已经重新执行，并且没有发现严重性为 1 的新缺陷。 |
无 |
非正式测试 |
| 迭代 2 |
用于所有新用例的自动性能和功能测试，以及作为回归测试的此前测试。
· 所有已计划的测试都已执行。
· 所有严重性为 1 和 2 的缺陷都已经解决。
· 所有已计划的测试都已经重新执行，并且没有发现严重性为 1 或 2 的新缺陷。 |
无 |
非正式测试 |
| 迭代 3 |
用于所有新用例的自动性能和功能测试，以及作为回归测试的此前测试。
必须有 95% 的用例通过测试。
· 所有已计划的测试都已执行。
· 所有严重性为 1、2 和 3 缺陷都已发现。 |
自动测试，70% 的代码覆盖。 |
非正式测试 |
| 迭代 4 |
用于所有用例的自动功能测试和负面测试，用于所有没有自动执行的部分的手工测试，以及作为回归测试的先前测试。
必须有 100% 的用例通过测试。
· 所有已计划的测试都已执行。
· 所有严重性为 1、2 和 3 的缺陷都已经解决。
· 所有已计划的测试都已经重新执行，并且没有发现严重性为 1 或 2 的新缺陷。 |
自动测试，80% 的代码覆盖。 |
非正式测试 |
第二个表显示应用于“典型”的安全至上系统的测试类型和完成标准：
| 迭代 / 测试 |
系统测试 |
集成测试 |
单元测试 |
| 迭代 1 |
用于所有用例的自动性能测试，100% 的测试用例覆盖。
· 所有已计划的测试都已执行。
· 所有严重性为 1 的缺陷都已经解决。
· 所有已计划的测试都已经重新执行，并且没有发现新的缺陷。 |
无 |
无 |
| 迭代 2 |
用于所有用例的自动性能、功能和负面测试，100% 的测试用例覆盖。
· 所有已计划的测试都已执行。
· 所有严重性为 1 或 2 的缺陷都已经解决。
· 所有已计划的测试都已经重新执行，并且没有发现新的缺陷。 |
自动性能测试 |
非正式测试 |
| 迭代 3 |
用于所有用例的自动性能、功能、负面可用性和文档测试，100% 的测试用例覆盖。
· 所有已计划的测试都已执行。
· 所有严重性为 1、2 和 3 的缺陷都已经解决。
· 所有已计划的测试都已经重新执行，并且没有发现新的缺陷。 |
自动性能测试以及作为回归测试的先前测试 |
自动测试，70% 的代码覆盖 |
| 迭代 4 |
用于所有用例的自动性能、功能、负面可用性和文档测试，100% 的测试用例覆盖。
· 所有已计划的测试都已执行。
· 所有严重性为 1、2 和 3 的缺陷都已经解决。
· 所有已计划的测试都已经重新执行并且没有发现缺陷。 |
自动性能测试以及作为回归测试的先前测试 |
自动测试，80% 的代码覆盖 |
1987 - 2001 Rational Software Corporation。版权所有。
|
