图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 软件测试架构师的工作模式
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
