概念：测试策略
http://ir.hit.edu.cn/~car/programming/rup/process/workflow/test/co_testr.htm
项目测试部分的测试策略描述测试活动的一般测试方法和目标。
1要进行的测试阶段（单元测试、集成测试和系统测试）
2要执行的测试类型（功能测试、性能测试、负载测试、强度测试等）。
该策略定义：
- 要使用的测试方法和工具。
- 测试完成和测试成功所采用的评价标准。例如，当成功执行 95% 的测试用例后，该标准可能允许软件进行验收测试。另一个标准是代码覆盖。在安全至上的系统中，该标准可能要求测试应该覆盖 100% 的代码。
- 影响资源要求或涉及进度的特殊考虑，如：
l 测试与外部系统之间的接口。
l 模拟物理损坏或安全威胁。
有些组织具有自行定义的公司测试策略。在这种情况下，需要将相应策略应用到特定的项目上。
PS:
测试策略要考虑的内容
1 进进行的测试阶段
2 要选择的测试类型，及选择后测试类型的具体执行办法：
(1)测试方法和工具
(2)测试成功所采用的评价标准
(3)影响资源要求或涉及进度的特殊考虑
制定测试计划活动应该侧重的最重要的维度如下：
l 处于什么迭代之中以及迭代的目的是什么。
l 正在执行什么测试阶段（单元测试、集成测试或系统测试）。可以在一次迭代中执行所有测试阶段。
现在来看一下测试活动的特征可以如何根据您所处的上述“测试维度”而变更。当然，可以查看的特征很多，如需要的资源和花费的时间，但在此处，请专注于定义测试策略的重要元素：
l 测试类型（功能测试、强度测试、容量测试、性能测试、可用性测试、分布测试等）。
l 使用的评估标准（基于代码的测试覆盖、基于需求的测试覆盖、缺陷数量、平均故障间隔时间等。）
l 使用的测试方法（手工和自动）
测试类型在测试生命周期上没有通用的分布模式。根据迭代次数、迭代大小、项目种类的不同，可以重点执行不同的测试类型。
测试覆盖
l 系统测试阶段十分注重确保覆盖所有通过测试用例集表示的可测试需求。这意味着测试的完成标准将主要侧重于基于需求的测试覆盖。
l 在集成测试和单元测试阶段，您将发现基于代码的测试覆盖是更合适的完成标准。下图显示在进行软件的新迭代时，这两类测试覆盖评测标准的使用是如何变化的。
测试计划应该定义单元测试、集成测试和系统测试的完成标准集。
可以针对各次迭代采用不同的完成标准集。
您在项目中应该考虑尽量自动执行测试，尤其对于需要多次重复执行的测试（回归测试）。但需要切记的是，创建并维护自动测试需要花费时间并占用资源。在各个项目中始终都会有一定数量的手工测试。下图说明了在什么时间和什么测试阶段可能会执行手工测试。
示例：
下表显示何时区分不同的测试类型，并提供要定义的完成标准的示例。第一个表显示的是“典型的”MIS 项目：
|
迭代 / 测试 |
系统测试 |
集成测试 |
单元测试 |
|
迭代 1 |
用于所有用例的自动性能测试。
PS: 1 性能要达标 2严重性为 1要FIXED 3 所有用例已执行 |
无 |
非正式测试 |
|
迭代 2 |
用于所有新用例的自动性能和功能测试，以及作为回归测试的此前测试。
PS: 1 新补充的用例被执行 2 回归测试PASS 3严重性为 1 和 2要FIXED |
无 |
非正式测试 |
|
迭代 3 |
用于所有新用例的自动性能和功能测试，以及作为回归测试的此前测试。
PS: 1 新补充的用例被执行 2 回归测试PASS 3 95%的用例PASS 4 无严重性为 1、2 和 3 缺陷都已发现 |
自动测试，70% 的代码覆盖。 |
非正式测试 |
|
迭代 4 |
用于所有用例的自动功能测试和负面测试，用于所有没有自动执行的部分的手工测试，以及作为回归测试的先前测试。
PS: 1负面测试 2 回归测试PASS 3 100%的用例PASS |
自动测试，80% 的代码覆盖。 |
非正式测试 |
第二个表显示应用于“典型”的安全至上系统的测试类型和完成标准：
|
迭代 / 测试 |
系统测试 |
集成测试 |
单元测试 |
|
迭代 1 |
用于所有用例的自动性能测试，100% 的测试用例覆盖。 |
无 |
无 |
|
迭代 2 |
用于所有用例的自动性能、功能和负面测试，100% 的测试用例覆盖。 |
自动性能测试 |
非正式测试 |
|
迭代 3 |
用于所有用例的自动性能、功能、负面可用性和文档测试，100% 的测试用例覆盖。 |
自动性能测试以及作为回归测试的先前测试 |
自动测试，70% 的代码覆盖 |
|
迭代 4 |
用于所有用例的自动性能、功能、负面可用性和文档测试，100% 的测试用例覆盖。 |
自动性能测试以及作为回归测试的先前测试 |
自动测试，80% 的代码覆盖 |