制定测试策略是软件测试架构师最核心的技能，但是要想做好这项工作并不是一件容易的事情。我将围绕理解测试策略，编写测试策略的总体思路，制定测试策略相关的技术、模型和方法来展开说明。
一、“测试策略”通俗来讲就是6个字“测什么”和“怎么测”。
测试的对象和范围是什么？
·测试的目标是什么？
·测试的重点和难点是什么？
·测试的深度和广度？
·如何安排各种测试活动（先测试什么，再测试什么）？
·如何评价测试的效果？
说人话就是测试策略就是指我们将如何开展我们的测试活动。
二、测试策略不等于测试方案
测试方案主要解决的是产品的功能在测试设计和测试执行方面的问题；
测试策略要解决的是产品测试的六大问题。显然，测试方案要解决的问题没有那么“高大上”，就是如何对功能进行测试设计和如何安排这个功能的测试执行，具体包括对功能的需求、场景、设计进行分析，提取测试点。
·对测试点选择合适的测试设计方法（如使用怎样的测试设计模型、测试数据的选择），生成测试用例。
·接口测试设计。
·测试执行时需要按照怎样的顺序来执行这些测试用例。
三、3步制定测试策略
1、明确产品质量目标
对测试来说，我们的测试目标就是让产品在发布的时候，能够满足事先约定的质量目标。我们制定测试策略，也就是为了让产品经过各种测试后，最后能够达到质量目标，可以发布。
然后就是围绕产品质量目标进行刚刚好的测试我们先来做一个小测试。下述情况是否和你有相符的地方呢？
·这是一个新开发的功能，大家都不熟悉，要作为重点好好测试一下。
·这个功能，感觉没有什么用吧，随便测试一下就好了。
·这个功能，使用的技术还比较新，要作为重点好好测试一下。
·这个功能还是很有意思的，好好测试一下。
·我想在这个功能中试试××测试方法。
如果答案是肯定的，说明你充满好奇心，是个技术控。但如果你在
制定测试策略的过程中，过多地被这些因素左右，你的测试将很有可能偏离本来的测试目标，变成了“凭感觉”的测试。
“不凭感觉”，“理性”的测试是这样的：
·产品质量要求高的是测试重点，反之为非重点。
·产品质量要求高的测试投入大，反之小。
产品质量要求高的要测得深，反之浅。
总而言之，要“围绕产品质量”进行。我们并不需要试图将每个地方都测试得全面深入，“刚刚好”才是我们真正需要追求的测试状态。
2、进行风险分析
想要顺利完成测试策略并不是一件容易的事情，总有各种问题会阻碍测试工作正常进行的事。提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整测试策略。
举例：实际项目中测试活动无法顺利开展的一些例子
例1：在需求阶段，未能提供全面的产品需求文档，导
致测试设计时场景缺失，无法达到测试设计的预期效果。
例2：在测试设计时，开发未能提供相关的设计文档，或是文档未能及时更新，导致测试设计遗漏或不准确，无法达到测试设计的预期效果。
例3：在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按照计划进行测试执行。
例4：在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期。
例如，对例1，我们可以考虑开展需求澄清会、加强对需求的评
审、明确需求的验收条件等活动来应对风险。对例2，我们可以考虑加强对文档的评审和跟踪、开发和测试进行设计澄清、让开发参与测试用例评审等活动来应对风险。
基于风险来加强和降低测试投入，一般来说，我们的产品中会存在全新开发的功能和老功能。对一个新开发的版本来说，老功能在老版本中已经被测试过，质量的起点相比全新开发的功能要高，失效的风险更低。即使全新开发的功能和老功能的质量目标是一样的，我们也没有必要等同投入资源——理想的状态是测试能够基于风险来进行测试：
·对高风险的部分加强测试投入。
·对低风险的部分降低测试投入。
因此我们完全可以减少那些质量情况较好的老功能测试，而将测试重点放到老功能中风险大的地方。
3、根据研发流程来安排测试活动
测试策略中具体的内容，也需要和研发流程保持一致，确保测试和开发的节奏能够彼此吻合。
测试在各个阶段的活动和开发的活动是能够配合起
来的。例如，在开发人员进行产品设计的时候，测试人员的主要活动应该是测试分析，而不应该是测试执行。开发人员在进行功能集成的时候，测试人员的主要活动应该是测试执行，而不应该是测试设计。要达到这个大层面的吻合，是比较容易的。相对比较困难的是，是在版本测试阶段，开发活动和测试活动彼此配合的问题。简单地说，就是开发人员在做计划的时候是否考虑了测试活动：
是否只是提交了一个“中间层”而非最后用户可见的功能？提交的功能是否可测？
·测试能否有足够的时间进行测试准备？
·测试能否在下个版本提交之前完成测试？
这就需要软件测试架构师能够做好版本测试策略，能够和开发人员进行有效沟通，使得双方能够理解彼此的节奏，达到更好的配合。
