所在的位置： java >> 历史起源 >> 四步测试策略制定法测试架构师修炼之道

四步测试策略制定法测试架构师修炼之道

点击上方“蓝字” 　　通过上一节的叙述，大家可能会认为，我们只需要像做论述题一样，把测试策略需要　　该在什么时候开始制定测试策略？如果在项目开头进行，你会发现很多和测试策略相关的内容根本就还不明了，无从下手；如果在项目后期进行，内容是明了，但是做测试策略的意义又在哪里呢？

　　测试策略中的每个问题看起来都不难，但要想答好却不简单，有没有方法或模型可以帮助我们来进行系统的思考和分析？

　　如何让测试策略真正起到指导测试的作用？

　　可见，我们还是需要一套方法来指导我们制定测试策略的整个过程，“四步测试策略制定法”应运而生，如图6-3所示。

　　1.明确“产品质量目标”

　　明确“产品质量目标”是我们在制定测试策略过程中十分关键的一个步骤。对我们而言，不仅需要　　1）我们的测试目标就是让产品在发布的时候能够满足事先约定的质量目标

　　对测试来说，我们的测试目标就是让产品在发布的时候，能够满足事先约定的质量目标。我们制定测试策略，也就是为了让产品经过各种测试后，最后能够达到质量目标，可以发布。

　　在操作层面上，“产品质量评估模型”可以用来帮助我们确定产品的质量目标。关于这个模型的具体内容，将在6.3节中为大家详细描述。

　　2）围绕产品质量目标进行刚刚好的测试

　　我们先来做一个小测试。下述情况是否和你有相符的地方呢？

　　·这是一个新开发的特性，大家都不熟悉，要作为重点好好测试一下。

　　·这个特性，感觉没有什么用吧，随便测试一下就好了。

　　·这个特性，使用的技术还比较新，要作为重点好好测试一下。

　　·这个特性还是很有意思的，好好测试一下。

　　我想在这个特性中试试××测试方法。

　　如果答案是肯定的，说明你充满好奇心，是个技术控。但如果你在制定测试策略的过程中，过多地被这些因素左右，你的测试将很有可能偏离本来的测试目标，变成了“凭感觉”的测试。

　　“不凭感觉”，“理性”的测试是这样的：

　　·产品质量要求高的是测试重点，反之为非重点。

　　·产品质量要求高的测试投入大，反之小。

　　·产品质量要求高的要测得深，反之浅。

　　总而言之，要“围绕产品质量”进行。我们并不需要试图将每个地方都测试得全面深入，“刚刚好”才是我们真正需要追求的测试状态。

　　这部分内容，我们还将在第7章中为大家详细讨论。

　　3）将目标—行为—评估形成闭环

　　产品质量目标也使得产品质量评估变得可行。对此，我们的思路是这样的，如图6-4所示。

　　首先，我们将产品质量评估模型作用于具体的产品，得到产品质量目标。

　　其次，我们根据产品质量目标来制定测试策略，确定接下来的测试活动。

　　再次，执行各种测试活动。

　　最后，对测试效果进行评估，评估产品的质量目标是否达到。

　　此时我们的目标（产品质量目标）、行为（测试活动）和评估（质量评估）会形成一个闭环。这时测试策略就好像一艘船上的舵，一旦发现没有达到产品质量目标，我们就调整测试策略，让整个测试始终保持在达到产品质量目标的航线上。

　　这部分内容，我们还将在第8章中为大家详细讨论。

　　2.进行“风险分析”

　　对产品而言，质量目标可能最后都是能够满足用户的商用需求。虽然产品质量评估模型可以帮助分解质量目标，让我们能够基于质量目标来制定测试策略，保证产品发布时的质量可控、可评估，但是我们在执行测试策略的时候，却总能感到些许困惑和无奈：

　　·想要顺利完成测试策略并不是一件容易的事情，总有各种问题会阻碍测试活动的进程。

　　·我们要做的测试活动总是很多，整个测试策略感觉很笨重。

　　这说明我们在制定测试策略的时候，一定漏掉了一些重要的东西。没错，我们漏掉了“风险分析”。

　　1）提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整测试策略

　　实际项目中真的有很多问题，都会让我们的测试变得举步维艰。

　　举例：实际项目中测试活动无法顺利开展的一些例子

　　例1：在需求阶段，需求工程师未能提供全面的产品需求文档，导致测试设计时场景缺失，无法达到测试设计的预期效果。

　　例2：在测试设计时，开发未能提供相关的设计文档，或是文档未能及时更新，导致测试设计遗漏或不准确，无法达到测试设计的预期效果。

　　例3：在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按照计划进行测试执行。

　　例4：在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期。

　　“骨感”的现实告诉我们，需要提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整我们的测试策略，增加一些测试活动或者质量保证活动。

　　例如，对例1，我们可以考虑开展需求澄清会、加强对需求的评审、明确需求的验收条件等活动来应对风险。对例2，我们可以考虑加强对文档的评审和跟踪、开发和测试进行设计澄清、让开发参与测试用例评审等活动来应对风险。

　　接下来，我们将在6.7节中为大家详细介绍风险分析技术，在第7章中为大家详细介绍如何制订风险应对措施。

　　2）基于风险来加强和降低测试投入

　　一般来说，我们的产品中会存在全新开发的功能和老功能。对一个新开发的版本来说，老功能在老版本中已经被测试过，质量的起点相比全新开发的功能要高，失效的风险更低。即使全新开发的功能和老功能的质量目标是一样的，我们也没有必要等同投入资源——理想的状态是测试能够基于风险来进行测试：

　　·对高风险的部分加强测试投入。

　　·对低风险的部分降低测试投入。

　　因此我们完全可以减少那些质量情况较好的老功能测试，而将测试重点放到老功能中风险大的地方。后续我们还将在6.7.2节中为大家介绍老功能分析技术。

　　3.适配“产品研发流程”

　　通过前面的讨论，我们了解到制定测试策略需要围绕质量目标，充分考虑风险，根据风险来对测试活动进行调整，但是有两个问题我们一直没有提及，就是：

　　·何时开展测试策略的制定活动？

　　·制定测试策略是一次到位，还是要分几次完成？

　　这就需要我们将测试策略的制定和研发流程结合起来。

　　1）测试策略的结构

　　如果我们希望测试策略能够统领并指导后续的测试活动，制定测试策略的时间就应该是在项目初期。据我所知，一些公司会要求在需求分析的阶段就开始投入准备测试策略的制定工作。

　　但是制定测试策略投入得越早，项目的各种不确定的因素也就越多。软件测试架构师很难在项目的需求分析阶段，就制定出一份非常详尽的测试策略。如果测试策略的内容只是一些大方向、大原则，那么到执行层面很容易就变形，也就违背了我们制定测试策略的初衷。

　　解决这个问题的方法是，按照产品研发流程，根据在哪个阶段项目能够确定到哪种程度的实际情况，来为测试策略设计一个符合这种进程的结构。

　　图6-5是一个传统研发流程示意图。针对这个研发流程，我们设计了总体测试策略—阶段测试策略—测试执行策略这样的测试策略结构。

　　有了这样的结构，我们能够将当前的测试策略总是控制在“当下”，即项目的情况总是在比较确定的范围内，避免我们过于纠结“未来”。

　　这样操作还有一个好处，就是我们能够真正将测试策略贯穿于测试，甚至研发项目的始终，做到既能包含大方向、大原则，又能细到对版本和功能测试的指导与控制，实现测试策略的价值。

　　有些公司的测试组织可能会事先就帮我们设计好了测试策略的结构，我们只需在每个节点输出符合要求的测试策略即可。在这种情况下，这个步骤自然可以省略。当然，我们也可以结合项目的实际情况，来对组织建议的测试策略结构进行裁剪。

　　我们还将在第7章继续和大家一起来深入讨论和测试策略的结构相关的问题。

　　2）根据研发流程来安排测试活动

　　测试策略中具体的内容，也需要和研发流程保持一致，确保测试和开发的节奏能够彼此吻合。

　　从大层面来说，测试在各个阶段的活动和开发的活动是能够配合起来的。例如，在开发人员进行产品设计的时候，测试人员的主要活动应该是测试分析，而不应该是测试执行。开发人员在进行功能集成的时候，测试人员的主要活动应该是测试执行，而不应该是测试设计，如图6-6所示：

　　要达到这个大层面的吻合，是比较容易的。相对比较困难的是，是在版本测试阶段，开发活动和测试活动彼此配合的问题。简单地说，就是开发人员在做计划的时候是否考虑了测试活动：

　　·是否只是提交了一个“中间层”而非最后用户可见的功能？提交的功能是否可测？

　　·测试能否有足够的时间进行测试准备？

　　·测试能否在下个版本提交之前完成测试？

　　这就需要软件测试架构师能够做好版本测试策略，能够和开发人员进行有效沟通，使得双方能够理解彼此的节奏，达到更好的配合。

　　除此之外，我们即将要介绍的测试分层，也能帮助我们更好地制定版本测试策略。

4.进行“测试分层”

　　到目前为止，我们已经能够综合考虑研发流程、风险，并基于产品质量目标来制定测试策略。通过上面的分析，我们可以得到很多测试活动，会发现有那么多要做的事情，现在的问题是我们该以什么策略去安排这些测试活动？

　　这个问题的最佳答案就是进行“测试分层”。

　　测试分层是指将有共同测试目的的测试活动放在一起形成一个组，然后一组一组地逐一进行测试。

　　分好层后，我们只要确定先测哪层，再测哪层，就能把各种测试活动安排下去了。对软件测试架构师来说，这比一个个去考虑先做什么测试活动，再做什么，效率要高很多，也能够让测试的整体思路变得更为清晰。

　　对测试团队来说，分层测试后，每层的测试内容、测试重点和测试方法都会有所不同，可以减少测试团队总是感到在重复执行相同内容的困惑，增加新鲜感。

　　但是，这些都不是测试分层最大的价值。测试分层最大的价值在于：通过测试分层，我们能够将一个大的测试目标，分到不同层次中分阶段去完成；合理的测试分层，能够让测试目标SMART化。能够让我们将目标（产品质量目标）—行为（测试活动）—评估（质量评估）的闭环，真正在产品测试中落地。

　　我们还将在6.8节中为大家继续讨论分层测试技术，在第7章中为大家介绍分层测试策略。

　　5.“四步测试策略制定法”中的测试技术

　　通过前面的介绍，我们了解到在使用四步测试策略制定法来制定测试策略时，会使用到一些方式或者模型。总的来说，如图6-7所示。

　　本章接下来的部分，将先为大家详细介绍这些模型和技术，为我们后面进行测试策略实战做好准备。

　　6.3　产品质量评估模型

　　产品质量评估模型将用在测试目标的确定和评估上，它是整个测试策略的基础。在介绍这个重要模型之前，我们想先花一点笔墨来讨论一下一个优秀的产品质量评估模型应该具备哪些特征。

　　6.3.1　优秀的产品质量评估模型的特征

　　单纯从质量评估的角度来说，下面的场景也许大家并不会陌生：

　　产品质量评估中的几个场景

　　场景1：项目计划的时间到了，就发布产品。

　　场景2：将缺陷修复率作为产品的质量目标。产品必须达到一定的缺陷修复率，才能发布。

　　场景3：我们为产品建立了很多指标来作为质量目标，如缺陷修复率、测试代码覆盖率等。产品必须达到制订的质量目标，才能发布。

　　场景1说明测试团队当前还没有产品质量评估的具体办法，于是只有将“时间”作为底线。改善方法之一就是引入质量评估的方法。

　　场景2和场景1相比，已经有了判断标准，可以说是有质的改变，但场景2也有“软肋”，就是评价的标准太过于单一。而对一个产品来说，要想对它的质量进行客观准确的评价，并不像我们在超市中买水果，要判断这个水果好不好，咬一口尝一尝这么简单，产品质量本身涉及的属性就有六大类，和开发过程及测试过程也息息相关，单纯通过一个指标很难判断准确。

　　场景3看起来很好，但是在实际操作的时候，我们往往会发现，我们费时费力地对这些指标进行了统计、分析和跟踪，最后也都达到了，但是我们对产品质量的好坏依然感到心里没底——这实在太让人沮丧了。

　　我分析出现场景3中的问题，主要原因有3点：

　　第一，这些指标覆盖的维度可能不全，我们可能遗漏掉了一些重要的考察项。

　　第二，“指标”本身比较容易被“聪明人”绕过去，变得形同虚设。

　　第三，整个质量评价体系中全是指标，缺少定性的分析。

　　例如，我们以测试的代码覆盖度要达到90%作为一项质量目标。为了达到这个目标，我们可能会选择一些容易进行测试“覆盖”，但实际上风险并不大的地方进行测试。虽然最终能达到90%的测试覆盖目标，但是没有被测试到的10%那部分情况如何，是否真的不需要测试，可能会有哪些风险，对我们来说都是“未知”的。未知正是心里没底的源头。

　　如果我们将这个问题从评估引申到目标的层面，如果我们在制订目标的时候，考虑的不仅仅是指标，而能包含一些如“对重要特性，要达到%的测试覆盖”“测试方法要包含语句覆盖、判断覆盖、路径覆盖”等的描述，以此作为要达到的质量目标，不仅能解决上述的问题，还能更好地帮助我们确定要进行的测试活动。

　　综上，一个优秀的产品质量评估模型，应该具备如下特质：

　　·多维度：能够覆盖质量评估的各个纬度，能够帮助评估者全面分析和考虑。

　　·定量+定性：指标和分析相结合，能够有效避免在只有指标的情况下，被“绕”过去，变得形同虚设。

　　·过程+结果：不仅评估测试的结果，还对过程进行分析和评估。

　　6.3.2　软件产品质量评估模型

　　我们将从3个方面来建立软件产品质量评估模型，对产品质量进行分析、确定和评估（图6-8）：

　　测试覆盖度评估：对测试范围及测试的深度与广度进行分析和评估。

　　测试过程评估：对测试过程和测试的投入情况来进行分析与评估。

　　缺陷分析：对测试结果进行分析和评估。

　　1.测试覆盖度评估

　　测试覆盖度评估包括需求覆盖度评估和路径覆盖度分析两个方面，从“需求”和“实现”两个纬度来对测试的全面性进行分析和评估，属于定量指标。