一、测试的核心是什么呢？
作为测试人员，掌握“业务知识”是必须的，但是“业务知识”并不能和“测试能力”画等号。“测试流程”或者说“测试管理”对测试来说很重要，但是否只要严格遵循它们就能做好测试了？
如果上述答案是否定的，那么什么才是测试的核心呢？又该如何去积累沉淀这方面的技能呢？
项目开发过程中，无论敏捷开发模式还是瀑布开发模式，对测试人员来说，产品都不亚于一个迷宫。对被测对象的准确把握，就是探索迷宫的罗盘。关键因素包括代码复杂度，开发人员的技能和经验准备度，需求的质量等。有了这些，就可以判断风险的所在，在把握失效规律和失效影响前提下，有的放矢的来开展各种测试活动。
而实际情况却是，太缺少对被测对象的分析和思考，做了很多看起来必要实际却很低效的事情。
所以，相对于自动化测试、测试设计、测试流程等相对固定的东西，测试人员还需要一个可以审时度势、动态分析和调整的技术，关键要能意识到，测试最核心的东西是动态的，是和整个研发过程和市场定位紧密捆绑的，即根据被测对象和测试团队制定合适的测试策略。
所以，我个人认为，测试的核心不是业务、不是测试方法、不是测试设计、不是自动化、不是测试管理、不是测试流程等，而是“测试策略”。
二、如何理解测试策略呢？
什么是策略策略？
通俗来讲，就是6个字，“测什么”和“怎么测”。
具体来讲，就是答好和产品测试相关的六大问题：
测试对象和范围是什么？
测试目标是什么？
测试重点和难点是什么？
测试深度和广度如何？
如何安排各种测试活动？
如何评价测试效果？
测试策略等于测试方针？
测试方针是产品测试中的通用要求、原则或底线。它一般针对一个产品族，或是一个产品序列，并且在较长一段时间内都是适用的，比如：
产品缺陷修复率要达到75%以上，才能发布
开发人员提测的版本，需要进行自测，并出具测试报告
对发布版本，无论代码修改了多少，都要对基本功能进行回归测试
产品升级后发现有功能丢失了，这类缺陷的等级为严重
测试策略仅针对当前特定的产品版本而言，并不具备通用性，可以这样理解：遵循测试方针+项目实际情况=测试策略
以“产品缺陷修复率要达到75%以上，才能发布”为例，如果当前某个特定产品版本，对质量要求特别高，在制定测试策略时，可以调整这条方针为“产品缺陷修复率要达到90%以上，严重以上缺陷修复率为100%”。
测试策略等于测试计划？
它们的关系是：通过测试策略确定的测试活动，在测试计划中被拆解为一个个任务，并为每个任务确定工期、执行次序和责任人，如下图所示：
测试策略等于测试方案？
1. 测试方案主要解决特性在测试设计和测试执行方面的问题，具体包括：
对特性需求、场景、设计进行分析，提取测试点
对测试点选择合适测试设计方法，生成测试用例
自动化测试设计
测试执行时需要按照什么顺序来执行这些测试用例
2. 测试方案需要遵循测试策略对具体某个特性的测试深度和广度要求
例如，某测试策略对特性A和特性B的测试说明，如下图所示：
在编写特性A的测试方案时，需要覆盖“车轮图”中所有的内容，而在编写特性B的测试方案时，只需要使用“车轮图”中的“单运行正常值输入法”和“单运行边界值输入法” 即可，如下图所示：
三、如何制定测试策略呢？
通过以上介绍，大家可能会认为，只要把测试策略需要关注的六大问题逐一答一遍，测试策略就可以制定好了。
但马上就会发现很多问题：
该在什么时候开始制定测试策略？如果在项目开头进行，和测试策略相关的内容还不明了，无从下手；如果在后期进行，内容是明了，但是做测试策略的意义又在哪里呢？
要想答好测试策略中的每个问题不简单，有没有方法或模型可以帮助进行系统的思考和分析呢？
如何让测试策略真正起到指导测试的作用？
所以，需要一套方法来指导制定测试策略的整个过程，“四步测试测试制定法”由此应运而生。
四步测试策略制定法是制定测试策略的步骤，其内容和核心理念，如下图所示：
Step1 明确产品质量目标
这是十分关键的一个步骤，不仅需要关注操作层面的具体方法，更要理解其中蕴含的测试策略思想，即测试目标是围绕“产品质量目标”来进行“刚刚好”的测试，如下图所示：
请特别注意对“刚刚好”的理解：
产品质量要求高的是测试重点，反之为非重点
产品质量要求高的测试投入大，反之小
产品质量要求高的要测得深，反之浅
与之对比的是：
这是一个新开发的特性，要作为重点好好测试一下
这个特性，感觉没什么用吧，随便测试一下就好了
这个特性，使用的技术还比较新，要作为重点好好测试一下
这个特性还蛮有意思的，好好测试一下
我想在这个特性中试试XX测试方法
大家可以感受一下在这两种不同的思路下，对测试重点的把握，以及对测试质量和效率的影响。
此外，需要特别注意的是“刚刚好”中的三个“反之”。对大多数测试人员来说，投入更多，做更深入的测试是容易做到的，有意识的减少测试却是相当难的。但如果只是一味的增加测试活动，而不敢于减掉一些测试活动，也不可能真正测得全面和深入。原理很简单，全是重点，也就等于没有重点。
Step2 进行风险分析
在执行测试策略时，在实际项目测试中经常碰到如下情况：
在需求阶段，需求工程师未能提供全面的产品需求文档，导致测试设计时场景缺失，无法达到测试设计的预期效果；
在测试设计时，开发未能提供相关的设计文档，或是文档未能及时更新，导致测试设计遗漏或不准确，无法达到测试设计的预期效果；
在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按照计划进行测试执行；
在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期；
前面讲到，测试最核心的东西是动态的，风险正是这种动态性最直接的体现。对风险进行分析，目的就是来识别项目中那些可能会阻塞测试顺利进行的因素，然后加强对高风险地方的投入，同时减弱风险低地方的投入。
风险分析分为“风险识别”，“风险评估”和“风险应对”三个步骤：
Step3 适配产品研发流程
无论用的是传统的瀑布开发模式还是敏捷开发模式，都会有产品开发节奏，也会碰到如下问题：
何时开展测试策略的制定活动？
制定测试策略是一次到位，还是要分几次完成？
这就需要将测试策略的制定和研发流程结合起来。
1. 测试策略的结构
这样能够真正将测试策略贯穿于测试，甚至研发项目的始终，做到既能包含大方向、大原则，又能细到对版本和功能测试的指导与控制，实现测试策略的价值，如下图所示：
2. 根据研发流程来安排测试活动
测试策略中具体的内容，需要和研发流程保持一致，确保测试节奏和开发节奏能够彼此吻合。
要达到这个大层面的吻合，相对比较困难的是，在版本测试阶段，开发活动和测试活动彼此配合的问题。即开发人员在做计划的时候是否考虑了测试活动：
是否只是提交了一个“中间层”而非最后客户可见的功能？提交的功能是否可测？
测试能否有足够的时间进行测试准备？
测试能否在下个版本提交之前完成测试？
这就需要做好版本测试策略，和开发人员进行有效沟通，使得双方能够理解彼此的节奏，达到更好的配合，如下图所示：
Step4 进行测试分层
到目前为止，已经能够综合考虑研发流程、风险，并基于产品质量目标来制定测试策略，现在的问题是该以什么策略去安排这些测试活动？
这个问题的最佳答案就是进行“测试分层”。
测试分层，就是把确定的活动进行归类，再在最合适的研发阶段执行相应的测试活动。
最经典的一个例子，就是V模型下的“单元测试”、“集成测试”、“系统测试”和“验收测试”。敏捷模型下的“单元测试”、“功能测试”、“非功能测试”、“探索式测试”也可以看作是一个测试分层的例子。
测试分层最大的价值在于：能够将一个大的测试目标，分到不同层次中分阶段去完成；合理的测试分层，能够让测试目标SMART化。能够将目标（产品质量目标）-行为（测试活动）-评估（质量评估）的闭环，真正在产品测试中落地。
四、如何落地测试策略呢？
前面分析了很多内容，大家可能会有个担心，就是测试策略的这些内容要如何落地？限于篇幅原因，接下来就简单讨论一下，测试策略是如何指导测试设计和测试执行的。
测试策略如何指导设计？
测试策略指导测试设计，其实只要测试团队按照测试策略的分类，按照需要分析的内容和方法，对具体的特性进行测试分析就可以了，如下图所示：
测试策略如何指导执行？
到了测试执行阶段，测试设计可以保证测试执行的内容，前期识别出来的需要补充开展的活动可以起到质量预防和风险应对的作用，测试策略中考虑的测试执行顺序，可以帮助大家按照最合适的方式来进行测试。
实际项目中，测试执行往往和计划有偏差，需要跟踪测试执行情况，评估当前的质量，根据版本实际情况动态调整测试策略，保障在项目结束时可以达成测试目标，如下图所示：
一般来说，在制定版本测试策略时，需要考虑的内容包括：
测试范围和测试计划相比的偏差
本版本的测试目标
需要重点关注的内容
测试用例的选择
测试执行顺序
试探性的测试策略
接收测试策略
回归测试策略
探索测试策略
自动化测试策略
跟踪测试执行时，需要关注以下两点：
跟踪测试用例的执行情况，特别是那些被阻塞的测试用例；
缺陷跟踪和分析，确定必须要在下个版本解决的问题、测试中发现缺陷的趋势是否符合预期和是否存在缺陷修改引入的问题；
最后，需要根据评估结果来调整测试策略，整体思路如下：
- END -
