0314-遗忘的角落，一文说清什么是测试策略

有多久，你没有再想起测试策略这个词了？又是从什么时候开始，测试策略从你的软件研发流程中弱化，甚至消失了？刚入测试的前几年，测试策略是研发过程中非常重要的一个阶段环节，指导着后续测试活动开展和实施，是测试人员专业技能必备要素之一。

今天，我们来重新聊一聊被逐渐忽略或遗忘在角落的测试技能测试策略。

 

1.1.什么是测试策略

测试策略通俗来讲，主要关注并围绕“测什么”和“怎么测”这两个问题，进行测试分析和测试方法等的设计。

测什么？主要指软件产品服务的本次的新增需求和变更需求的内容是什么，影响了哪些业务功能，以及对应的相关产品服务，从而针对业务需求和影响范围进行诸如页面样式、功能、软件交互、易用性等进行测试范围的界定；同时根据实际需要对软件产品服务的性能、安全等非功能性测试验证需求进行必要的测试需求分析，并明确相应的测试范围边界。

怎么测？主要指采用什么测试方法、测试工具等实现并保障软件产品服务的质量需求，同时也包括了软件质量保障所需遵循的软件研发测试流程、测试/预发/生产环境基础设施和相应的测试人员，以及测试验证所需的技术资源支持等。

 

1.2.测试策略内容

测试策略内容，主要明确本次测试的对象是什么，测试的范围是什么。测试对象和范围主要由业务需求、产品需求和软件设计作为测试基准依据，明确业务测试需求的对象（业务对象、软件产品服务等）和测试范围（本次新增或变更的业务内容、影响范围、受影响的软件产品服务等），并对测试边界进行清晰明确的定义。

 

1.3.测试策略目标

制定测试策略的目标是，规范测试活动内容、流程、方法和行为，以及相应所需的资源，尽可能多的发现软件产品中存在的未知缺陷，减少缺陷的生产发布，降低软件产品服务的质量风险，进而保障软件产品服务质量。

与此同时，测试非穷举测试，因而测试存在不完整性，无法发现并排除系统中所有的缺陷。存在一定的局限，需要在策略制定时，明确并选择合适的最优的测试粒度，尽可能通过设计最少的测试用例发现更多的未知缺陷。

 

1.4.测试分析

测试分析主要是进行测试方法、测试重点、测试难点、测试过程风险分析及应对。

测试方法主要为明确软件产品测试过程中的各阶段测试活动的安排，包含但不限于测试活动阶段定义、拆分、测试优先级、测试与研发进度配合、人工测试和自动化测试的需求比例，以及针对测试需求进行的测试方法设计和测试标准制定等。

针对测试内容和测试目标，分析测试过程中的存在的测试重点主要包含那些内容，对重点内容着重进行测试关注和测试设计执行；测试存在什么难点，针对难点需要什么样的技术、人力、环境等的资源支持，及时进行解决，防止测试难点阻碍测试进度，影响软件产品服务的项目交付。

针对软件产品服务的整个研发测试流程，结合实际情况及测试需求，进行风险分析，对可能或已知的风险，制定相应的风险解决方案或应对措施，并与项目组人员讨论确认，尽可能在软件研发测试前期发现、解决研发测试风险，通过各种方法或手段降低或避免风险的发生，保障软件产品质量和项目进度。

 

1.5.被忽视的原因

1、项目迭代周期短，没有时间。

当前互金等公司均采用敏捷研发模式，将业务需求进行了严格精细化的拆分，分成了多个迭代，在不考虑研发工作量的情况下规定了上线时间，因而每个迭代周期给予测试的时间会被极限压缩，导致测试没有时间进行测试策略的分析制定，以及测试策略文档的编写，测试策略的分析和文档编写的耗时，使得敏捷不在敏捷了，产生了理念的冲突，因而测试策略在很多敏捷研发过程中被逐渐的弱化（测试计划中小篇幅带过），甚至从测试过程中消失。

 

2、敏捷项目研发文档的规范

在敏捷开发中的每个迭代周期内，业务需求不断的被拆分、精简，通过产品文档进一步的实例化和影响范围描述，以及设计文档的设计内容和重点事项描述，使得每个敏捷迭代周期的测试内容更加清晰更加聚焦，因而原来测试策略中涉及的测试对象、测试范围、测试目标等均为已知事项，无需进行重复的分析。

 

3、过程惯性

通常项目的测试持续进行的，项目研发采用矩阵模式，在矩阵模式中又存在垂直模式，每个人负责的内容相对固定。在敏捷研发中，过程是持续进行、持续反馈的，项目成员均对项目整体有清晰的认知和把控，因而测试策略的分析在此时被弱化，在软件产品服务运行环境、项目周期、测试活动、测试方法等既定俗成，变的不再敏感，形成了一种过程惯性。

同时，过程惯性存在一定的软件研发风险，比如因测试策略敏感度的降低，可能导致产生测试分析不足、测试方法不合适等问题，影响项目迭代，甚至产生漏测导致生产事故等严重问题；另外，项目成员存在不稳定性因素，比如成员离职或临时事务导致的缺席，会引起项目迭代的不良反应。需要项目负责人提前做好风险预防。

 

1.6.是否需要

测试策略还是需要的，也是测试过程很重要的环节。同时，测试不可为了策略而策略，可根据实际测试需要把控，进行灵活适度变通。在非核心业务变更或简单需求变更中，可以减少测试策略比重，甚至在测试情况允许的条件下，不进行测试策略分析，减少不必要的工作量；在新软件产品服务、较为核心的业务变更或大的不可拆分的项目需求中，建议测试停下来，进行测试策略分析，好好思考如何更有效的开展测试，通过最小的文档篇幅，展示最优的测试策略，并进行项目团队的阅览和评审，达成统一的认知。

建议测试定期进行测试策略的复盘，在多个未进行测试策略分析的迭代周期之后，进行测试策略的分析复盘，进行查漏补缺，反思测试过程中有哪些地方是可以进行测试策略优化的，通过什么样的方法手段进行测试策略优化，以取得更好的测试效果，缩短测试周期，节省测试资源输出等。

 

1.7.写在最后

虽然现在很多时候，测试策略是写在测试计划中的，但测试策略不可等同于测试计划。测试策略先于测试计划，测试策略对于测试计划具有指导作用，测试计划是针对测试策略中的测试活动进一步的WBS分解，进行时间维度上的划分，并按照测试策略的指导完成测试计划的制定和实施。

测试策略也不是测试方案，测试策略关注的更大层面的测试问题，具备测试战略性的指导意义；测试方案更多的解决对测试内容或测试任务的测试设计和测试安排，比如对测试任务需求、场景等的提取，对测试点选择合适的测试设计方法，以及如何实现测试过程等。

在敏捷研发的测试过程中，大而全的测试策略分析文档，已经逐渐被弃用，我们提倡通过小而美的测试策略分析，保证软件产品服务项目测试需求的有效开展，指导测试人员更好的开展测试活动，明确如何更高效的进行测试，更好的把控软件产品服务质量，更早的防范软件研发测试交付风险，使用最低的成本发现软件产品服务的质量风险，从而测试过程的规范和测试结果的质量保证。

 

1.8.附录

简略版的测试策略文档，仅供参考。可根据公司实际要求进行增删，灵活变通。