一、开始

此时，软件测试架构师对项目的了解还非常有限，在制定测试策略之前，收集了解更多的项目信息非常重要：
·项目的范围。
·人力投入。
·历史情况。
·……

二、初次使用‘四步测试策略制定法’

2.1 产品质量等级

从最终用户使用的角度，我们将产品质量分为如下4个等级:
第1级完全商用：特性完全满足用户的需求，有少量（或者无）遗留问题，用户使用时无任何限制。
第2级受限商用：特性无法满足用户的某些特定场景，有普通以上的遗留问题，但有规避措施。
第3级测试、演示或小范围试用：特性只能满足用户部分需求，有严重以上的遗留问题，且无有效的规避措施，问题一旦出现就会影响用户的使用，只能用于测试（如Beta）或演示，或者小范围试用。
第4级不能使用：特性无法满足用户需求，存在严重以上的遗留问题，会导致用户基本功能失效，且无规避措施，产品根本无法使用。

特别说明：产品质量等级虽然是在项目初期确定的，但定义的是产品在发布时的质量，而不是产品在测试过程中的质量

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

需要特别说明的是：
·该项活动能够顺利进行的前提是产品的特性已经基本确定完成了。
·这项活动不应该仅由软件测试架构师来进行，需要需求工程师、研发经理等研发核心团队共同进行，对不同特性的产品质量等级能够达成一致。

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

针对风险来制定应对措施，可以建立风险对应表。

2.4 确定测试策略的结构

明确测试策略分几次输入，何时输出，每次输入的关注点是什么。

参考结构:总分式结构

·总体测试策略：确定产品质量目标，进行项目整体的风险识别，从产品层面来确定测试重点和测试难点、测试深度和测试广度，是测试策略的总纲。
·阶段测试策略：确定测试设计策略和测试执行策略需要达到的质量目标（产品质量目标的分解）以及能够进行这些测试活动的入口条件。
·测试执行策略：确定每个版本的测试目标、测试内容和每个版本的入口条件。
总体测试策略从概念阶段开始，在计划阶段前期完成比较合适。因为这时产品的需求、质量目标和整体形态都已经确定下来，已具备了制定总体测试策略的条件，而且也需要这样一份文档来总领后面的测试活动，让测试团队成员心中有数。
阶段测试策略在总体测试策略完成后随即展开，保证在开发阶段前期完成。这是因为，阶段测试策略最重要的目的，就是明确各个阶段的输入输出标准。在开发编码之前（或在前期）就把要求说清楚，可以让开发目标更明确，更有利于产品质量的提高。测试也可以根据双方达成的标准，准备接收测试用例、自动化测试环境等。如果阶段测试策略输出得过晚，这些活动可能就会来不及进行或者达不到期望的效果。
测试执行策略在测试执行阶段，每个版本转测试之前输出即可。测试执行策略除了对阶段测试目标进一步进行分解到每个版本的粒度，还需要根据上一个版本的测试执行情况，对测试策略进行调整。

2.5 初步确定测试分层

2.6 回顾

至此，我们按照四步测试策略制定法的思路，完成了一次分析。我们先来总结一下到目前为止，软件测试架构师取得了哪些进展：
·明确了特性的质量等级，并且和各个研发核心团队的成员就质量目标达成一致意见。
·从项目整体角度进行了风险分析，有了需要做哪些质量保证活动的初步计划。
·确定了测试策略的结构为总体测试策略—阶段测试策略—测试执行策略。
·初步确定了测试分层，并且梳理出了测试分层、研发流程和测试策略结构的对应关系，初步建立了一个测试的框架。

三、制定总体测试策略

3.1 分解产品质量目标

整体思路如图所示：

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

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

注：1.‘不涉及’指该项目可以不予关注；

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

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

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

在现在这个阶段，开发还没有开始对特性中的功能进行设计，所以我们还无法使用老功能分析法来对每个功能特性进行详细的分析，但是我们已经基本能够知道：
·哪些特性是新开发的。
·哪些是从老版本上继承而来的。
·哪些特性的改动估计会比较大。
·从老版本继承而来的特性的历史测试情况。
这时，软件测试架构师可以根据项目的实际情况，考虑上述几个方面，来将被测对象做一下分类，并对每一类确定一个测试策略。

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

“测试深度”和“测试广度”虽然都是用于描述测试策略的，但确实是两个完全不同的概念：
·测试深度是指在测试过程中需要使用的测试方法。
·测试广度是指测试的范围。

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

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

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

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

3.4 确定测试优先级

基本原则是质量等级越高，优先级越高；在相同的质量等级下，全新特性比老特性的优先级高；改动越多的老特性，优先级越高。

3.5 确定测试的总体框架

如果把测试整体看成一个“人”，策略层就像是人的大脑，负责指挥测试该如何进行，确保测试做的是正确的事情；而活动层就像是人的身体，负责具体的执行；保证层就像是人的五官，保证身体能够顺利地执行任务。

3.6 回顾

让我们回顾一下，到目前为止我们取得的进展：
·分解了产品质量目标。
·基于风险对特性进行了分类。
·确定了测试深度和广度以及测试优先级，确定了测试投入策略。
·确定了测试的总体框架。
事实上，进行到现在，我们可以认为软件测试架构师完成了总体测试策略的制定。
总体测试策略最后的输出究竟是什么呢？其实就是两张表和一幅图。
第一张表，是我们在文中一直模糊地称其为“特性—质量等级”表并不断向其中添加内容的那张表。

特性—质量等级表
现在我们终于可以为其正名了——其实它的真名叫“总体测试策略分析表”
第二张表是测试投入策略表。

测试投入策略表
最后的图就是我们的测试总体框架图，如图所示：

测试总体框架图

四、制定阶段测试策略

4.1 测试设计策略

测试深度是从测试方法的角度去描述的，我们在测试执行的时候，并不会按照测试方法去测试，而是按照测试用例去测试。也就是说，我们需要按照测试深度来进行测试设计，然后我们再执行这些测试用例，以达到以特定的测试深度来进行测试执行的目的。

1）使用‘测试分析设计表’来保证测试设计符合测试策略

“测试分析设计表”是对每个功能或特性进行测试设计的辅助工具，使用测试分析表的好处是：
·软件测试架构师可以通过配置“测试分析准备表”来控制测试设计的深度。
·测试设计者能够在表中非常方便地记录下测试分析的过程。
·评审者很容易看出设计者考虑了哪些地方，没有考虑哪些地方，考虑的深度是否合适。

测试分析表由三张表构成：

（1）测试分析准备表

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

·被测对象需要从功能、配置、一致性、安全性、性能、压力、稳定性、兼容、升级、备份、易用性方面来考虑测试点。
·被测对象需要分别和安全特性、VLAN等功能结合起来考虑测试点。

（2）测试类型分析表

其中的“列”为待分析的需求，“行”为测试类型。

“测试类型分析表”的使用方法是，对待分析的每一条“需求”，逐一分析在这些测试类型下是否有测试点。

分析完成后，我们将分析结果进行简单整理，生成原始需求经过测试类型分析后的测试点，再对这些测试点进行筛选，得到需要后续进行功能交互分析的测试点。

（3）功能交互拆分表

完成功能交互分析后，我们需要将功能交互分析中得出来的测试点，整理后再和测试类型分析中得到的测试点合并，就完成了被测对象的测试点分析。

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

四步测试设计法会影响我们测试策略中的测试广度，特别是流程类中的路径分析法，使用不同的路径覆盖策略（语句覆盖、分支覆盖、全覆盖和最小线性无关覆盖），测试广度的差异会非常大。此时，需要软件测试架构师制定一个测试设计中的路径覆盖策略，以保证测试者设计的测试用例能够符合测试策略中的测试广度。

3）测试用例等级

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

4.2 集成测试策略

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

1）俄罗斯方块心项目的集成开发

用户期望的产品：

功能划分：

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

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

集成测试需要测试的内容包括以下几项：

·使用黑盒测试的方法来确认新合入的功能是否正确。
·验证功能集成后系统功能的正确性。
·确认原来的系统功能没有被新合入的功能所破坏。

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

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

条件3：测试团队已经做好了测试准备。
这里的测试准备，主要包括：
·测试用例已经输出，并通过了评审。
·测试资源已经到位。
·测试环境已经准备好。

4）测试用例选择

·针对功能确认的测试，可以选择相关功能level 1的测试用例。
·针对“测试新功能集成”的测试，可以选择相关功能level 2的测试用例和部分level 3的测试用例。
·针对“确认原系统”的测试，可以选择相关功能中level 1的测试用例。

5）出口准则

当我们达到了集成测试阶段的目标后，就可以退出集成测试。
出口准则包括：
·系统需要集成的功能已经全部开放、集成完成。
·计划执行的测试用例已经完成。
·缺陷分析的结果符合预期。
·达到了集成测试阶段的产品质量目标。

4.3 系统测试策略

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

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

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

只通过集成测试无法对系统进行全面的测试，系统测试是有必要的，在系统测试中需要测试的主要内容包括：

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

2）入口准则—何时开展系统测试

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

3）测试用例选择

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

·针对“系统角度的功能测试”：可以选择level1和部分level2的测试用例。
·针对“非功能的质量的正确性”：可以选择level3的测试用例和level4的测试用例。

4）测试用例执行顺序

考虑测试执行顺序的时候，可以基于如下几点：

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

·如果有两种测试方法，都能对测试对象进行测试，先进行复杂的，再进行简单的。

·可以考虑组合多种测试方法，或者说让测试者想办法把一些测试用例放在一起执行。例如，可以将功能测试的测试用例和满规格的测试用例放在一起进行，在满规格的情况下测试功能。

5）出口准则

当我们达到了系统测试阶段的目标后，就可以退出系统测试。
出口准则包括：
·计划执行的测试的用例已经完成。
·缺陷分析的结果符合预期。
·达到了系统测试阶段的产品质量目标。

4.4 验收测试策略

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

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

1）Alpha测试

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

（1）谁来进行Alpha测试

理想的Alpha测试人员，应该是不太了解产品实现细节，但是对用户非常了解的人。

该功能的测试责任人并不适合作为Alpha测试人员，因为他们对自己测试的系统多半已经出现了“审美疲劳”，这会阻碍他们再进行有效的Alpha测试。

让测试组员相互进行交叉验收，似乎是个不错的选择——这确实可以消除“审美疲劳”，发现一些问题，但是交叉验收却很难达到从用户的角度再去审视一次产品的效果。

与交叉测试相比，更有效的方法是:

测试部专门成立一个“验收测试组”，由测试部中比较有经验、测试能力强，且对行业、对用户都有一定了解的测试人员来担任，让他们来作为产品发布前的最后一道防线，这无疑是最能保证Alpha测试效果的做法。

（2）Alpha测试策略

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

Alpha测试中需要关注的重点内容：

·用户将会如何学习产品？
·产品提供的资料（如手册、指南、视频）是否能够对用户提供切实的帮助？
·用户会将产品安装部署在怎样的环境中（包括用户会使用到的硬件、操作系统、数据库、浏览器等）。
·在用户的环境中能否正确升级？升级对业务的影响是否在用户容忍的范围内？升级对已有功能的影响是否符合用户需求（如升级后不能丢特性）？
·产品在用户的环境中能否被正确移除？
·产品在用户环境中的上下游设备是什么？在这样的环境中，产品能否正常使用？
·用户环境中可能会有哪些业务？哪些业务是我们产品需要关注的，哪些业务是我们产品不需要关注的？对那些我们不需要关注的业务，我们的产品会怎么处理？
·用户的环境中可能会有哪些故障？对这些故障，我们的产品会怎么处理？
·用户会怎么管理、配置产品？
·用户会如何使用产品的日志、告警、审计、报表等和运维相关的功能？

2）Beta测试

Beta测试是由用户参加的测试。常见的方式有如下两种：
·在产品正式发布之前将产品提前发给用户，收集用户的反馈。
·在产品开发完成后，交由用户对产品进行验收。

第一种方式下的Beta测试的困难之处在于确定测试的时间和参与者。对测试者来说，倒不需要对上面两个问题做出决策，而是分析、复现参与者发现的问题，将问题整理为bug报告，直至确认bug被解决。
第二种方式下的Beta测试，需要保证产品能够通过用户的验收测试，能够交付给用户使用，这时的测试需要围绕用户的验收方案进行，并结合用户的使用习惯和用户所在的行业特点，做好充分的准备。

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

验收测试的入口准则，就是系统测试的出口准则再加上：
·Alpha测试的人员、方案已经选好。
·Beta测试的用户已经确定。

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

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

5)回顾

已经确定了哪些内容：
·确定了测试设计策略，通过《测试分析设计表》来保证测试团队的测试设计都能符合测试策略，并确定了测试用例的等级。
·确定了各个测试阶段的测试策略。

《测试架构师的修炼之道》七—测试策略实战相关推荐

【测试人生】《测试架构师修炼之道》阅读笔记
<测试架构师修炼之道>一书,笔者入行一年多的时候拜读过.虽然这本书主要偏向业务测试.质量管理的方向,而并非技术测试.测试开发的方向,但只要是测试行业从业者,笔者认为都值得一看. 从笔者本人 ...
测试架构师修炼之道_学习笔记
测试工程师职业发展管理路线测试组长测试经理.测试主管测试总监技术路线产品测试技术把产品测试的更好的技术专项测试技术不针对具体的产品,而是测试领域普遍适用的技术产品测试专家(即测试架 ...
《测试架构师修炼之道》阅读总结
这本书是小编去年阅读的一本书,觉得很不错当时就将其中的一部分内容整理总结了一下,绘制了下图在团队内部进行了分享. 最近又温顾了一下,还是很受启发. 决定将总结分享给大家,也方便小编经常打开来回顾一下( ...
重读《从菜鸟到测试架构师》-- 开发团队做的远不仅是开发
上回说到小艾跟着导师修炼了一段基本功之后,也明确了自己的专业技能学习道路,却在几次转头的瞬间发现身边的每一个人都似乎在做着不同的事情,不是说好的一个团队嘛,为什么你做这个,他做那个呢?小艾还真是疑惑, ...
【书】测试架构师-必备的6个能力
进入现有的公司后,发现自己的语言能力真的是极差,同样的一件事情,别人能说的很高端,且有理有据,自己却说不出来,就算硬说也说的很苍白无力,毫无说服力. 例如,当自己很忙的时候,告诉领导自己忙不过来,但是 ...
测试架构师应该做和不应该做的事情
内容大纲原文解读测试架构师是产品测试专家,是测试团队的灵魂人物,也是测试工程师在软件测试技术上的一个重要发展方向. 在需求分析阶段,首先要理解产品的商业目标和核心价值,了解我们的公司.客户及商务, ...
数字中国·星火文集 | 架构师的修炼
架构师的修炼神州信息王保育经常会听到,现在金融科技在发生巨变,开源的技术.云化的服务.标准化的架构模式设计等,服务是由云厂商提供,开发是由服务组合或API 调用实现,那么架构师岗位或是在简历上印 ...
测试架构师的目标和价值
网友邮件问我2个问题:测试架构师的价值怎么量化体现?能否用最少的词描述测试架构师对产品测试组支撑时最主要的工作目标是什么? 问题1回复: 你一切的活动提升产品线整体10%的的测试质量,10%的测试效率 ...
【软件测试】资深测试聊一聊，测试架构师是怎么样的，做一名成功的测试工程师......
目录:导读前言一.Python编程入门到精通二.接口自动化项目实战三.Web自动化项目实战四.App自动化项目实战五.一线大厂简历六.测试开发DevOps体系七.常用自动化测试工具八 ...

《测试架构师的修炼之道》七—测试策略实战