假设现在有一个研发项目A开始了，我们的软件测试架构师也要投入项目了。此时项目产品的包需求已经基本完成，产品概念已经初步成型，如图1所示。

图1　研发项目A示意图

不过此时软件测试架构师对项目的了解还非常有限：

知道项目叫什么名字。

项目大致要做些什么内容。

领导期望项目在什么时候结束。

1　开始

此时，软件测试架构师对项目的了解还非常有限，在制定测试策略之前，收集了解更多的项目信息非常重要：

项目的范围。

人力投入。

历史情况。

……

2　初次使用“四步测试策略制定法”

当我们收集了一些项目信息，对项目有一定的了解后，就开始准备制定测试策略了。这也是我们初次在项目中使用“四步测试策略制定法”，如图2所示。

图2　对项目使用“四步测试策略制定法”

2.1　产品质量等级

产品质量评估模型，只能告诉我们该从哪些角度去评估产品质量，并没有告诉我们，怎样的评估结果可以被认为是好的质量，怎样的结果又是不好的质量。换句话说，我们还缺少一个评价质量的“刻度”，即产品质量等级。

从最终用户使用的角度，我们将产品质量分为如下4个等级。

第1级完全商用：特性完全满足用户的需求，有少量（或者无）遗留问题，用户使用时无任何限制。

第2级受限商用：特性无法满足用户的某些特定场景，有普通以上的遗留问题，但有规避措施。

第3级测试、演示或小范围试用：特性只能满足用户部分需求，有严重以上的遗留问题，且无有效的规避措施，问题一旦出现就会影响用户的使用，只能用于测试（如Beta）或演示，或者小范围试用。

第4级不能使用：特性无法满足用户需求，存在严重以上的遗留问题，会导致用户基本功能失效，且无规避措施，产品根本无法使用。

注意：产品质量等级虽然是在项目初期确定的，但定义的是产品在发布时的质量，而不是产品在测试过程中的质量，如图3所示

图3　定义产品发布时的质量

2.2　确定项目中各个特性的质量等级

按照四步测试策略制定法，我们先围绕明确产品质量目标来展开分析

此时，软件测试架构师需要对本项目中包含的特性，逐一确定它们的“产品质量等级”（表1）。

需要特别说明的是：

该项活动能够顺利进行的前提是产品的特性已经基本确定完成了。

这项活动不应该仅由软件测试架构师来进行，需要需求工程师、研发经理等研发核心团队共同进行，对不同特性的产品质量等级能够达成一致。

2.3　对项目整体进行风险分析

按照四步测试策略制定法，在这个阶段，软件测试架构师需要从项目整体角度进行风险分析。

此时，我们可以按照7.1节中介绍的“风险评估清单”，来对项目整体进行一次风险评估，并参考“风险应对”来考虑应对措施，增加一些质量保证活动。

在确定风险应对措施的时候，需要区分这些活动是针对项目整体的，还是针对具体特性的。可以直接记录在产品质量等级表中备忘（表1）。

表1　产品质量等级表

2.4　确定测试策略的结构

按照四步测试策略制定法，接下来我们将围绕产品开发流程来进行分析。

图4　总分式的测试策略结构

总体测试策略：确定产品质量目标，进行项目整体的风险识别，从产品层面来确定测试重点和测试难点、测试深度和测试广度，是测试策略的总纲。

阶段测试策略：确定测试设计策略和测试执行策略需要达到的质量目标（产品质量目标的分解）以及能够进行这些测试活动的入口条件。

测试执行策略：确定每个版本的测试目标、测试内容和每个版本的入口条件。

总体测试策略从概念阶段开始，在计划阶段前期完成比较合适。因为这时产品的需求、质量目标和整体形态都已经确定下来，已具备了制定总体测试策略的条件，而且也需要这样一份文档来总领后面的测试活动，让测试团队成员心中有数。

阶段测试策略在总体测试策略完成后随即展开，保证在开发阶段前期完成。这是因为，阶段测试策略最重要的目的，就是明确各个阶段的输入输出标准。在开发编码之前（或在前期）就把要求说清楚，可以让开发目标更明确，更有利于产品质量的提高。测试也可以根据双方达成的标准，准备接收测试用例、自动化测试环境等。如果阶段测试策略输出得过晚，这些活动可能就会来不及进行或者达不到期望的效果。

测试执行策略在测试执行阶段，每个版本转测试之前输出即可。测试执行策略除了对阶段测试目标进一步进行分解到每个版本的粒度，还需要根据上一个版本的测试执行情况，对测试策略进行调整。

图5　各类测试策略之间的关系

2.5　初步确定测试分层

按照四步测试策略制定法，接下来我们将进行与测试分层相关的分析。

对软件测试架构师来说，此时我们可以结合研发流程，来初步确定一个测试分层。假设此时我们采取经典V模型中的测试分层，然后将测试分层和研发流程，以及测试策略的结构放在一张图上，初步将三者的对应关系梳理出来了

图6 测试分层、研发流程和测试策略结构的对应关系

2.6　回顾

们先来总结一下到目前为止，软件测试架构师取得了哪些进展：

明确了特性的质量等级，并且和各个研发核心团队的成员就质量目标达成一致意见。

从项目整体角度进行了风险分析，有了需要做哪些质量保证活动的初步计划。

确定了测试策略的结构为总体测试策略—阶段测试策略—测试执行策略。

初步确定了测试分层，并且梳理出了测试分层、研发流程和测试策略结构的对应关系，初步建立了一个测试的框架。

通过这次实践，我们发现只使用一次四步测试策略制定法，是无法得到最终的测试策略的。

首先，这和项目所处的阶段有关。一些和测试策略制定相关的、必要的、重要的信息，只有到项目的某些阶段才会清晰，所以我们需要按照测试策略的结构，在项目的不同阶段多次使用四步测试策略制定法来制定测试策略，如图7所示。

图7　多次使用四步测试策略制定法制定测试策略

其次，四步测试策略制定法中的4个步骤之间并不是瀑布式的单向关系，而是全网状的双向关系。图8更为准确地表达了这4个节点之间的关系。

图8 4个节点间的关系

例如，产品质量目标变高了，对此我们可能会增加一些测试分层，这使得研发流程也发生变化，也引入了新的风险。

所以我们在使用四步测试策略制定法时，发现进行到某个步骤进行不下去了，可以将这个步骤停一下，进行下一个步骤，然后再回过头来进行这个没有做完的步骤，这时往往会有新的收获。

3　制定总体测试策略

接下来我们将在之前分析的基础之上，再次使用四步测试策略制定法来制定总体测试策略，如图9所示。

图9 制定总体测试策略

3.1　分解产品质量目标

我们可以对质量等级再进行分解，整体思路如图10所示。

图10分解质量等级

1. 根据质量等级来分解产品的质量目标

我们可以根据之前确定的产品质量等级，来为产品质量评估模型中的项目建立不同的质量标准，从而达到分解产品质量目标的目的。

我们可以根据项目的实际情况、历史情况和公司整体基线，确定出一个分级的标准，作为产品质量目标的分解项，见表2。

表2　定量指标分级标准

注：

“不涉及”指该项目可以不予关注；

可以根据项目和产品的实际情况选择部分分析项。

表3　特性—质量等级表

软件测试架构师不必对每个特性，都输出一个质量目标分解表，而是在“特性—质量等级”表中加入一个超链接即可。

2. 为每个测试分层确定测试目标

接下来我们需要根据各个质量等级的质量目标，再确定每个测试分层需要达到的质量目标。以“完全商用”为例，见表4。

表4　完全商用示例表

3.2　使用老功能分析法来对特性进行分类

在现在这个阶段，开发还没有开始对特性中的功能进行设计，所以我们还无法使用老功能分析法来对每个功能特性进行详细的分析，但是我们已经基本能够知道：

哪些特性是新开发的。

哪些是从老版本上继承而来的。

哪些特性的改动估计会比较大。

从老版本继承而来的特性的历史测试情况。

这时，软件测试架构师可以根据项目的实际情况，考虑上述几个方面，来将被测对象做一下分类，并对每一类确定一个测试策略。表5是一个例子，供大家参考。

表5 示例

3.3　基于质量和风险来确定测试深度与测试广度

1. 使用产品质量评估模型来初步确定测试深度

我们使用产品质量评估模型中的测试过程—测试方法项，基于不同的质量要求，来确定测试深度，见表6。

表6　确定测试深度

2. 考虑用老功能分析来更新测试深度

我们再根据前面老功能分析中的测试策略，更新老功能中的测试深度（可以考虑先标记出需要调整的地方），见表7。

表7 更新老功能中的测试深度

3. 基于老功能分析来初步确定测试广度

从产品质量评估模型的角度来说，无论产品的质量要求是高还是低，我们都希望在测试中能够对需求进行100%的覆盖，相应的所有测试广度都应该是100%覆盖。

但实际上，对一些老特性，特别是那些在新版本中没有改动，并且历史测试情况也不错的特性，我们可以考虑缩小测试范围，少测或者不测。不过毕竟现在我们还处于项目的概念或计划阶段初期，还没有进行详细的老功能分析，但这时我们还是可以初步分析出一些可以缩小测试范围的特性。

3.4　确定测试优先级

接下来软件测试架构师可以根据质量目标和分类来确定测试优先级。基本原则是质量等级越高，优先级越高；在相同的质量等级下，全新特性比老特性的优先级高；改动越多的老特性，优先级越高。

确定测试优先级的一个简单的方法是使用评分表。我们首先对质量目标和分类分别设置一定的分值，见表8和表9。

表8 质量目标分值表

表9 分类分值表

然后再准备一张优先级的分数范围表（表10）。

确定的测试优先级，将主要用于测试投入的安排上。我们可以根据优先级的等级，制定出一个测试投入的策略，见表11。

3.5　确定测试的总体框架

测试框架可以理解为如何组建测试。

们将测试框架构建为三层：策略层、活动层和保证层。

如果把测试整体看成一个“人”：

策略层就像是人的大脑，负责指挥测试该如何进行，确保测试做的是正确的事情；

活动层就像是人的身体，负责具体的执行；

保证层就像是人的五官，保证身体能够顺利地执行任务。

我们将测试策略和测试活动按照测试框架绘制出来，并按照研发流程和测试分层来组织这些测试活动的先后次序，作为测试的总体框架，如图11所示。

图11 测试总体框架

3.6　回顾

让我们回顾一下，到目前为止我们取得的进展：

分解了产品质量目标。

基于风险对特性进行了分类。

确定了测试深度和广度以及测试优先级，确定了测试投入策略。

确定了测试的总体框架。

事实上，进行到现在，我们可以认为软件测试架构师完成了总体测试策略的制定。

总体测试策略最后的输出究竟是什么呢？其实就是两张表和一幅图。

第一张表，是我们在文中一直模糊地称其为“特性—质量等级”表并不断向其中添加内容的那张表。现在我们终于可以为其正名了——其实它的真名叫“总体测试策略分析表”。

表12 总体测试策略分析表

第二张表是测试投入策略表，见表13。

最后的图就是我们的测试总体框架图，如图12所示。

图12 测试总体框架

4　制定阶段测试策略

图13 制定阶段测试策略

软件测试架构师在制定总体测试策略的时候基本处于“单打独斗”的状态，整个测试团队中可能就只有软件测试架构师投入。到了制定阶段测试策略的时候，测试团队中的其他成员才会开始投入，进行测试分析和设计。因此阶段测试策略需要能够向上承接总体测试策略，立马指导测试分析和设计，向下能够指导后面的测试执行。

4.1　测试设计策略

在制定总体测试策略的时候，软件测试架构师已经为产品特性确定了测试深度。但测试深度是从测试方法的角度去描述的，我们在测试执行的时候，并不会按照测试方法去测试，而是按照测试用例去测试。也就是说，我们需要按照测试深度来进行测试设计，然后我们再执行这些测试用例，以达到以特定的测试深度来进行测试执行的目的。

1. 使用“测试分析设计表”来保证测试设计符合测试策略

“测试分析设计表”是对每个功能或特性进行测试设计的辅助工具，使用测试分析表的好处是：

软件测试架构师可以通过配置“测试分析准备表”来控制测试设计的深度。

测试设计者能够在表中非常方便地记录下测试分析的过程。

评审者很容易看出设计者考虑了哪些地方，没有考虑哪些地方，考虑的深度是否合适。

“测试分析设计表”由3张表构成：“测试分析准备表”“测试类型分析表”和“功能交互分析表”。

1）测试分析准备表

“测试分析准备表”的主要作用是为被测对象配置在测试设计中需要考虑哪些“测试类型”（可以理解为测试方法，包括功能和非功能方面）和“功能交互”（可以理解为需要将哪些功能放在一起考虑，它们是否需要进行“多运行相互作用”和“多运行顺序执行”的测试）。

图14 示例

图14是一个示例。以其为例，这样配置的意思是：

被测对象需要从功能、配置、一致性、安全性、性能、压力、稳定性、兼容、升级、备份、易用性方面来考虑测试点。

被测对象需要分别和安全特性、VLAN等功能结合起来考虑测试点。

软件测试架构师可以通过配置“测试分析准备表”来控制测试深度。

2）测试类型分析表

“测试类型分析表”如图15所示。

图15 测试类型分析表

其中的“列”为待分析的需求，“行”为测试类型。至于行表头中会有哪些测试类型，这和我们在“测试分析准备表”中对测试类型表的配置有关——我们只对配置了的测试类型进行测试类型分析。

图16 参考实例

图17 分析结果汇总表

3）功能交互分析表

“功能交互分析表”和“测试类型分析表”类似，如图18所示。

“行”表头中显示的需要进行功能交互分析的功能，依然和“测试分析准备表”中的“开发特性表”保持一致。而“列”的内容就不是“原始的需求”了，而是测试类型分析结束后，我们识别出的需要再进行功能交互分析的测试点。

图18 功能交互分析表

图19 参考示例

2. 四步测试设计法和测试广度

通过“测试分析设计表”输出测试点，完成了测试分析活动后，测试设计者就可以使用四步测试设计法来对测试点进行测试设计，输出测试用例了。

此时，需要软件测试架构师制定一个测试设计中的路径覆盖策略

前面已经介绍了路径覆盖度评估的基本方法，我们可以参考其中步骤1和步骤2，用总体测试策略中优先级来定义不同的路径覆盖策略，见表14。

表14 用优先级定义路径覆盖策略

3. 测试用例等级

设计好了测试用例之后，建议软件测试架构师再让测试设计者对测试用例分一下级。我习惯将测试用例分为四级，每一级的定义，对应的测试深度和对应的测试分析设计表，见表15。

表15 测试用例分级

测试用例分级将会为后面的分层测试、回归测试、验收测试和自动化测试在如何选择用例方面，带来莫大的方便。

4.2　集成测试策略

集成测试位于产品研发流程的开发阶段。所谓“集成”，可以理解为不断开发功能并将功能集成到系统中，最后完成整个系统的开发过程。

1.“俄罗斯方块心”项目的集成开发

假设用户希望我们开发一款叫“俄罗斯方块心”的产品，如图20所示。

图20 俄罗斯方块心

通过分析，开发很快将产品划分为如下几个基本功能，如图21所示。

图21 基本功能

并制定了通过4个build来把功能开发完如图22所示。

图22 功能开发和系统集成计划

这样，每一个build后，产品的集成形态如图23所示。

图23 产品的集成形态

4个build完成后，我们的系统也就完全集成好了。

“俄罗斯方块心”虽然是个虚拟项目，却能帮我们很好地理解产品的集成开发过程，确定集成开发阶段的测试策略。

2. 集成测试的对象和测试目标

让我们再来仔细分析一下“俄罗斯方块心”的集成开发过程：

开发者按照计划，完成本build计划要集成到系统的功能开发后，需要通过单元测试来测试功能的正确性；测试通过后，开发者将功能集成起来，构造系统（这个过程有时候又叫“联调”）。构成完成之后的测试，就是我们的“集成测试”。

图24 build2的集成开发过程

其中单元测试是为了测试“新开发的功能和模块是否符合设计”，是“白盒测试”，使用内部接口进行测试。

而集成测试相当于是在测试验证“新合入功能能否在系统中被正确地装配起来”，是“黑盒测试”，也是系统级的测试，应该使用系统提供给用户的输入接口来进行测试，使用提供给用户的输出接口来判断接口的正确性。

“功能能够在系统中被正确装配”隐含了一个前提就是“功能是我们想要的那个功能”。而单元测试只能确认功能的实现是符合设计的，却不能保证功能恰好就是我们想要的。因此，集成测试需要测试的内容包括如下几项

使用黑盒测试的方法来确认新合入的功能是否正确。

验证功能集成后系统功能的正确性。

确认原来的系统功能没有被新合入的功能所破坏。

3. 入口准则——何时可以开始进行集成测试

集成测试的入口准则等同于“第一个集成计划中提交的功能能否进行集成测试”。

条件1：第一个集成计划中的功能开发完成，并完成了单元测试。

条件2：第一个集成计划中的功能集成完成，并可测。条件2的重点在于“可测”，即开发需要提供基于用户的输入输出接口，而不能是内部的函数接口，确保测试能够进行系统级的黑盒测试。

条件3：测试团队已经做好了测试准备。

测试用例已经输出，并通过了评审。

测试资源已经到位。

测试环境已经准备好。

4. 测试用例选择

明确了测试内容，测试用例的选择就变得容易了

针对功能确认的测试，可以选择相关功能level 1的测试用例。

针对“测试新功能集成”的测试，可以选择相关功能level 2的测试用例和部分level 3的测试用例。

针对“确认原系统”的测试，可以选择相关功能中level 1的测试用例。

其中“部分level 3的测试用例”是指在集成测试后期，系统已经相对比较成熟和稳定的时候，也可以适当选择一些性能、稳定性和压力方面的测试用例来进行测试，以避免这些“非功能”方面的问题在系统测试阶段密集爆发。

5. 出口准则

当我们达到了集成测试阶段的目标后，就可以退出集成测试。

出口准则包括：

系统需要集成的功能已经全部开放、集成完成。

计划执行的测试用例已经完成。

缺陷分析的结果符合预期。

达到了集成测试阶段的产品质量目标。

4.3　系统测试策略

从系统测试开始，产品研发流程进入到测试阶段。

1. 系统测试的对象和测试目标

我们可能会有这样的疑问：在集成测试结束的时候，这个心形图案就已经完成了，并且我们也进行了测试，为什么还要再进行系统测试呢？或者说这个问题从测试的角度来看，就是已经在集成测试中执行了的测试用例，在系统测试中还需要再执行一遍吗？集成测试和系统测试的差异主要在哪里？

做集成测试的时候：

目光是紧盯着新开发的功能的。而且随着功能的不断集成，系统的复杂性开始急剧膨胀，我们很难（或者说没有足够的测试时间，或是说系统还不够稳定）来把和功能相关的所有组合都验证完。

更重要的是，集成测试主要还是针对功能的集成，在集成测试中我们无法（或者说没有足够的测试时间，或是说系统还不够稳定）对被测对象的其他非功能方面的质量来进行测试验证。、

在系统测试中需要测试的主要内容包括：

从系统角度来验证测试功能的正确性。

从系统角度来验证各种非功能的质量的正确性。

2. 入口准则——何时可以开展系统测试

系统测试的入口准则，就是集成测试的出口准则，再加上一条：测试团队已经做好了测试准备，包括测试用例、测试资源和测试环境都已到位。

3. 测试用例选择

现在我们来回答本节开头提的问题：我们在集成测试中执行了的测试用例，在系统测试中还需要再执行一遍吗？

答案是，系统测试和集成测试的测试用例肯定会有相同的部分，但并不是简单地重复一遍，而是存在一定的选择策略。

针对“系统角度的功能测试”：可以选择level1和部分level2的测试用例。

针对“非功能的质量的正确性”：可以选择level3的测试用例和level4的测试用例。

4. 测试执行顺序

我们在集成测试中并没有讨论测试执行顺序，是因为集成测试的测试对象很单一，就是“功能”。虽然后面我们提到在集成测试的后期，可以考虑增加一些“非功能方面”的测试，但是总的来说这并不会给测试带来先执行什么再执行什么的困扰。

软件测试架构师在考虑测试执行顺序的时候，可以基于如下几点：

有些测试方法本来就需要满足一些条件才能进行。例如，满规格测试需要在基本功能正常的情况下才能进行，否则将很难区分问题到底是出在规格上，还是功能上。这就需要我们按照测试方法本身的条件来安排测试执行顺序。例如，先进行稳定测试，再进行压力测试，然后进行恢复测试。

如果有两种测试方法，都能对测试对象进行测试，先进行复杂的，再进行简单的。或者说，尽量先执行复杂的、难的测试用例，再进行简单的测试用例。这样考虑的原因是，希望缺陷能够尽量在测试的前期发现，另外先执行难的测试用例也能保证这些测试用例有充足的测试时间。

可以考虑组合多种测试方法，或者说让测试者想办法把一些测试用例放在一起执行。例如，可以将功能测试的测试用例和满规格的测试用例放在一起进行，在满规格的情况下测试功能。这种测试执行顺序特别适合系统测试中需要重复执行、集成测试中已经执行过的那些测试用例，往往可以发现很多新的问题。

5. 出口准则

当我们达到了系统测试阶段的目标后，就可以退出系统测试。

出口准则包括：

计划执行的测试的用例已经完成。

缺陷分析的结果符合预期。

达到了系统测试阶段的产品质量目标。

4.4　验收测试策略

验收测试是产品在发布前的一种测试，它是对用户需求的确认事实上，我们进行验收测试已经不再是为了发现产品的问题，而是为产品能够正常发布建立信心。

验收测试的对象是需求，需要基于用户场景来测试。

验收测试包含Alpha测试和Beta测试两种。

1. Alpha测试

Alpha测试是由测试人员模拟用户进行的测试。

1）谁来进行Alpha测试

理想的Alpha测试人员，应该是不太了解产品实现细节，但是对用户非常了解的人。按照这个标准，市场人员、系统工程师或是技术支持人员都可以是理想的Alpha测试人员，他们可以站在用户的视角，对产品质量再次进行审视。

让测试组员相互进行交叉验收，似乎是个不错的选择——这确实可以消除“审美疲劳”，发现一些问题，但是交叉验收却很难达到从用户的角度再去审视一次产品的效果。与交叉测试相比，更有效的方法是，测试部专门成立一个“验收测试组”，由测试部中比较有经验、测试能力强，且对行业、对用户都有一定了解的测试人员来担任，让他们来作为产品发布前的最后一道防线，这无疑是最能保证Alpha测试效果的做法。

2）Alpha测试策略

Alpha测试不是系统测试的延续，它是产品交付的序曲，它的测试重点应该放在“确认在用户真实的环境下，用户的业务、用户的使用习惯是否能够满足”需求上。模拟用户的真实环境，把自己催眠为用户，能够以用户的思路来看待产品，是Alpha测试不折不扣的难点。

下面的清单也许可以帮助我们进行Alpha测试分析，找到产品在Alpha测试中需要关注的重点内容：

用户将会如何学习产品？

产品提供的资料（如手册、指南、视频）是否能够对用户提供切实的帮助？

用户会将产品安装部署在怎样的环境中（包括用户会使用到的硬件、操作系统、数据库、浏览器等）。

在用户的环境中能否正确升级？升级对业务的影响是否在用户容忍的范围内？升级对已有功能的影响是否符合用户需求（如升级后不能丢特性）？

产品在用户的环境中能否被正确移除？

产品在用户环境中的上下游设备是什么？在这样的环境中，产品能否正常使用？

用户环境中可能会有哪些业务？哪些业务是我们产品需要关注的，哪些业务是我们产品不需要关注的？对那些我们不需要关注的业务，我们的产品会怎么处理？

用户的环境中可能会有哪些故障？对这些故障，我们的产品会怎么处理？

用户会怎么管理、配置产品？

用户会如何使用产品的日志、告警、审计、报表等和运维相关的功能？

2. Beta测试

Beta测试是由用户参加的测试。常见的方式有如下两种：

在产品正式发布之前将产品提前发给用户，收集用户的反馈。

在产品开发完成后，交由用户对产品进行验收。

第一种方式下的Beta测试的困难之处在于确定测试的时间和参与者。对测试者来说，倒不需要对上面两个问题做出决策，而是分析、复现参与者发现的问题，将问题整理为bug报告，直至确认bug被解决。

第二种方式下的Beta测试，需要保证产品能够通过用户的验收测试，能够交付给用户使用，这时的测试需要围绕用户的验收方案进行，并结合用户的使用习惯和用户所在的行业特点，做好充分的准备。

3. 入口准则——何时开始进行验收测试

验收测试的入口准则，就是系统测试的出口准则再加上：

Alpha测试的人员、方案已经选好。

Beta测试的用户已经确定。

4. 出口准则——何时可以退出测试，发布产品

当我们根据产品质量评估模型，确认产品已经达到总体测试策略中的产品质量目标后，就可以退出测试。

4.5　回顾

现在软件测试架构师已经走到了图25中所示的位置

图25　完成阶段测试策略的制定

我们还是先来总结一下，到目前为止，软件测试架构师已经确定了哪些内容：

确定了测试设计策略，通过《测试分析设计表》来保证测试团队的测试设计都能符合测试策略，并确定了测试用例的等级。

确定了各个测试阶段的测试策略。

从2节开始，我们就没有说明当前的活动对应的是四步测试策略制定法中的哪个步骤了，而是在尽量按照四步测试策略制定法的思路来组织文章的内容。

到目前为止，还没有进行产品测试，这使得我们的测试策略多少还是有点儿“纸上谈兵”的意思。进入产品测试阶段后，测试策略的效果立马就可以通过缺陷分析呈现出来，这时软件测试架构师的工作模式将变为图7-42所示的样子。

图26 软件测试架构师的工作模式