第1个回答 2022-06-06
这篇文章主要总结了我对于敏捷项目中总体测试策略的理解，主要来自于工作上的实践和思考。
先看下维基百科上关于 test strategy 的定义
归纳上面的定义，我们可以得出测试策略的最终目的是通过定义项目会采用的测试活动，尽可能得暴露和消除产品缺陷，减轻产品风险。除此之外，由于软件开发时常伴有交付压力，测试的时间和资源都是无法保证甚至可能被压缩的，所以测试策略还会从最低成本揭露产品质量风险出发，选择出最合理的测试方法和测试过程。
基于上面的定义，可见测试策略解决了两个大问题：
在详细点就是：
要说不同，先看定义上的不同。
由上可见，其实测试策略的内容已经被包含在测试计划里面了。测试策略定义应该做什么样的测试而测试计划包含所有关于测试策略该如何执行的信息，这些信息在测试计划里面被很好的组织起来。
一个公式可以进一步说明他们的关系 test plan = test strategy + test logistics 。所以test strategy可以被看做是test plan的一部分。 Test logistics 是指测试环境设置以及人力资源等等。
在James Bach的博客 A Question About Test Strategy 中，他把三者描述如下
让我们先来看下QA在敏捷项目中的主要工作，如下图所示
那你可能问“咦，怎么没有测试策略相关内容呢”。其实，整个开发测试流程就体现了测试策略的内容。上图所示的迭代开发流程里面包含了"Automated Acceptance Tests" & “Story Testing” & “System Testing”这些测试活动，那么为什么项目需要这些测试活动？这些活动如何具体如何开展？分别在哪一个项目阶段进行？这些问题都属于测试策略的范畴，是由测试策略定义和落地的。
敏捷开发模型下，迭代式的开发具有周期短和交付压力大的特点，对于如何快速响应新需求，保障新需求的质量以及已实现需求的回归测试都将是测试的挑战。如果没有一个匹配项目上下文，合理规划了测试活动的测试策略，这些挑战就会持续困扰着团队，所以标题的答案是当然需要。测试策略在敏捷开发模型下，通过详细定义项目的测试活动，能够更加合理地利用测试资源和统一项目对测试的认知。
此外，测试策略也是敏捷项目质量保障体系中重要的一节。
在传统瀑布开发模式下，测试计划test plan被认为是项目测试流程的关键部分，因为它指导着整个测试活动的开展，既然被认为是项目中的一个must have，于是有人会花很多时间很多精力去把测试计划给写好写完整。那么我们真的在敏捷开发模式的项目里需要一份测试计划吗？这真的能给项目质量带来价值吗？
敏捷宣言说过：
在敏捷项目中，产品范围也就是发布内容在spring进行之前就被讨论，所以QA们对于测试对象和测试范围一直都是清楚的，不需要特别地花时间去写一个详细的文档来阐述。同样地，agile ceremony会让QA们清楚地知道测试对象是什么，范围是什么，重点是什么，测试环境是什么而不需要一个单独的文档来进行详细的描述。甚至，所有关于测试的信息还可以被记录被故事卡中。在开发进行编码实现功能的时候，QA们会进行测试用例设计以及自动化测试编写，因为时间的紧迫，QA除了这两项测试活动，再去写一个详细测试计划是不经济的且价值不大，这两项测试活动才是敏捷项目中价值最高的，况且随着迭代的进行，测试计划的维护还需要时间精力。
综上所述，在敏捷项目中因为时间紧迫和避免重复劳动，价值不高的测试计划不是一个must have，个人甚至认为也不是一个nice to have。但是这并不是代表我们不需要"planning"，而是不是需要"document planning"，"planning"的实施发生在迭代中的各类活动。
最终我们还是需要一个“计划”来指导迭代中的测试流程和方法，这就是测试策略是一个must have的原因。在敏捷项目中，“小而精”的测试策略比起“大而全”的测试计划而言，最大的优势就是测试策略定义的内容(“怎么测”)是不会轻易受影响改变的，并且在迭代中没有类似的重复活动。
具体到项目里，测试策略推荐在项目刚启动的时候制定。测试策略需要在项目早期就制定下来，用来指导项目的测试活动和方法，从而确定需要的测试资源和保证质量体系的建立。但也不能在产品和技术都还没有确定的时候就制定，因为只有在产品需求范围，技术架构和交付计划大致确认的情况，测试策略才能更加准确，从而减少维护成本。
因为测试策略会涉及到很多具体的测试技术和方法，也会要求制定人员具有对质量和测试非常深的理解，所以QA在敏捷团队中应该承担制定测试策略的主要责任，但是这并不意味“只有”QA来编写制定测试策略，测试策略的制定是一个团队活动，QA需要从不同角色收集到不同的信息
从多方收集信息能够保证业务、技术和质量三者对齐，避免误解和冲突，共同发挥最大的作用。
当测试策略制定完成以后，还需要给项目团队进行讲解，确保团队所有相关人员对项目中的测试活动和测试方法有着一致的理解,这样才能保证实施阶段的顺利。
接下来会涉及到QA制定测试策略的具体活动及流程。总的来说，大体流程可以如下
上面提到了QA可以从不同角色收集到不同的信息，除此之外，使用启发式测试计划语境模型 Heuristic Test Planning Context Model和启发式测试策略模型 Heuristic Test Strategy Model也是一个有效的渠道。具体如何使用这两个模型，请参考 htsm 和 htcpm 。
通过分析 htsm 中“项目环境”和“产品元素”的关键词和启发式问题，QA可以了解关于产品和项目的各类信息来帮助制定测试策略。 htcpm 也提供了大量的关键词来启发QA去分析了解产品需求、项目环境、测试小组和测试资源。
可以收集的信息大致可分类如下
只有从不同的维度收集到足够的项目信息并且很好的理解这些信息对项目质量和测试活动的影响，才能帮助我们少走弯路，制定出适合项目和团队的测试策略。
在具体思考“怎么测”之前，我们需要确定项目的质量目标。这个质量目标会对齐项目所有相关人员对于项目质量的理解和期望，明确质量范围也就是测试策略会覆盖的范围。同时，质量目标也要与产品目标对齐，因为质量的最终目的也是保证产品的成功。根据产品在不同阶段都有不一样的目标，质量目标有会随之变化。
那质量目标如何设定？主要是参考软件质量特征列表和软件质量模型，建立符合项目上下文的产品质量模型，从而确定项目质量目标
要建立项目产品的质量模型首先就需要先知道一个软件产品的质量属性或特征分别有什么，对应的质量模型是什么样的。幸运的是现在已经有很多可以参考的模型了
ISO/IEC_25010的质量模型大致如下：
从上面的质量特征列表或是模型可以看出，一个软件产品的质量由多个质量特征或标准组成，每个质量特征又可以进一步分解为子特征。通过这些已有的质量模型来启发哪些质量特征是对项目产品重要的，哪些质量标准适用于本项目产品，最后得出符合项目上下文的产品质量模型。
比如 我们创建的产品质量模型可以包含以下粗粒度特征：
上面的质量模型定义了产品质量特征和标准，而这些特征和标准就是我们应该完成的目标！除了上面说到的质量模型，一些具体的metrics也可以被引入来保证项目质量，成为项目质量目标的一部分。举个例子
上面提到的标准都是可以通过集成到持续集成流水线的质量工具或测试框架来实现。
此外，还有团队也会使用测试策略目标宣言来打造团队文化。
有了质量目标，接下来我们要考虑要怎么达成这个目标了！也就是说，我们应该有哪些测试类型来覆盖每一个质量目标？
测试类型按照不同维度可以有很多种分类，比如说
当然，上面只是列出了一部分。
此外，HTSM中的 Test Techniques 提供了九种通用的九种测试技术来启发对可应用的测试类型的思考。敏捷测试四象限也提供了敏捷项目可以参考的测试类型,这个测试技术分类系统可以帮助我们快速定位某测试类型在软件开发中的位置，根据项目产品情况选择合适的测试类型。
就以我们上面假设的质量目标为例，我们来看看可以应用哪些测试类型
值得注意的是，并不是每一个项目都需要覆盖上面所列出的测试类型。我们应该根据产品的目标和特点以及其他实际情况选择与之对应的测试覆盖类型，也就是说，不同项目根据测试类型的不同，测试广度是不一样的。同事，根据测试的难点和重点，测试深度也是不同的。所以，一切都要基于项目的上下文来思考和制定。
自动化测试金字塔用来指导敏捷项目中自动化测试的策略。
根据金字塔理论，项目应该在底层的单元测试和集成测试(API测试)投入更多的精力。
自动化测试项目会被集成在持续集成流水线里面，由上游项目自动触发。为了减少持续集成的反馈时间，一个普遍的做法是把庞大的自动化测试套件集依据重要性优先级放在不同的流水线里面，可以被上游项目触发也可以定时触发，下面描述了一个比较好的实践：
确定测试类型之后，我们就知道了整个项目的测试活动会有哪些。对于某些测试类型，特别是自动化相关的测试，我们需要对应的测试工具或是框架来支撑我们的测试。所以我们需要对每一个测试类型都去思考下如何进行测试，是否需要相应的测试工具和框架的支持。
拿一个web程序来举例
这个环节我们需要确定在项目开发生命周期的每个阶段做什么样的测试，使得测试类型与项目的开发流程充分结合，这样就能最大发挥所有测试活动的效果来达到我们的质量目标。因此，我们可以做出类似下面这样的表格来表现每个阶段的测试类型及其实施方法。
至此，测试策略解决的两个问题“测什么”和“怎么测”都可以找到大致答案了。
那如何衡量测试策略的有效性呢？质量度量可以告诉我们产品的质量情况和用户满意度，从而反应出测试策略是否有效和高效。
软件质量的度量没有什么最佳实践，也没有最准确和科学的度量，有的只是项目上积累的成功经验；但是这些成功经验又由于项目差异化太大而变得复用性很差。所以根据项目的上下文，我们需要制定出自己的质量度量标准。结合本文敏捷项目的背景，我们可以大致使用下面常用的度量：
同时，实例化的质量目标也是很好的项目质量的工具。对于质量模型，我们可以看下每一个质量元素我们是否做到；对于具体的指标metrics，要随时监控反馈。
一旦测试策略被确定，一般来讲不会经常变化，因为测试策略设置了一些测试标准。如果测试标准频繁地变动，这会让具体计划的执行变得困难，同时带来更多的资源浪费，最终影响了项目的质量。
在项目中我们会经常遇到“变化”：比如说
这些变化对测试的影响是被测对象的范围以及项目资源的调配。对于项目的质量目标、测试类型、测试阶段影响不大。所以，测试策略一旦被制定出来，变化不会太大。
不过这不代表测试策略的一成不变和缺乏改进，QA需要在每个迭代中观察测试策略实施的效果来决定当前的测试类型和实施手段是否满足项目需求。比如当项目集成测试(API Testing)经常fail，且协调工作耗时费力，QA可以考虑采用契约测试来代替现有的集成测试，提高整个项目组的生产率和质量；比如发现Internet Edge突然用户量增多且有关于Internet Edge的production bug被raise，QA需要把Internet Edge加到兼容性测试中，并且设置相关的测试环境；比如测试进度落后，交付压力增大，QA需要及时调整测试范围和测试重点，进行风险分析。
在实际项目中，往往会出现各种各样的问题来阻碍测试策略的顺利落地和执行。这些问题有些是测试策略自身的问题，但也有项目带来的问题。这时候，风险分析显得格外重要。
对于测试策略的风险分析，这个是应该贯穿整个测试策略制定周期里面的，我们需要通过项目风险清单提前识别项目中可能阻塞测试的风险，并通过风险优先级(风险暴露的概率*风险暴露的损失)来评估风险，最终基于风险调整测试策略，把测试重点放到风险高优先级高的地方。
测试策略是影响质量的重要因素，但不是全部，下面列出了部分会影响质量的因素作为参考，在此文中不会展开来讲
上面详细阐述了我如何理解敏捷项目中的测试策略以及制定测试策略的具体步骤。由于IT项目的多样性和复杂性，这个总结不可能适用于有着不同上下文的项目，因地制宜地制定测试策略才能保证测试策略在项目中的可用性和合理性。