测试策略 = 遵循测试方针 + 项目实际情况
测试方针是产品测试中的通用要求、原则和底线。
通用是测试方针的显著特点：它不针对某个特定产品，而是一个产品系列，并且在较长的一段时间内都是适用的。
测试方针举例：
1、测试用例中对需求文档中的需求覆盖率必须是100%
2、产品的缺陷修复率要达到75%以上，严重及以上的bug修复率必须是100%，才能发布
3、开发转给测试的版本需要自测，并给出测试结论
4、对发布版本，无论代码修改了多少，都要对基本功能进行回归测试
测试计划：
通过测试策略确定的测试活动，在测试计划中被拆解为一个个任务，并为每个任务确定工期，执行的先后次序和责任人。
细分制订者：
测试计划的制订者是测试经理，属于测试管理的范畴。而测试策略的制订者是软件测试架构师，属于测试技术的范畴。
四步测试策略制定法：
1、明确“产品质量目标”
产品质量目标：是测试过程中的标准，根据产品的轻重缓急，对将要测试的目标进行理性的测试，把控好自己的测试时间和测试程度。
场景举例：
这个功能没什么人会用的，随便点点就行。
这个功能点要不要做一个简单的并发逻辑测试
这个要不要做一个压测
在测试过程中不能被自己的个人情绪和喜好左右，要根据产品质量目标，进行有尺度的测试活动。不能太浅也不能太深。测的太浅产品质量可能不过关，测的太深浪费太多人力。我们的目标是保证产品准时稳定的发布上线。
如果发现问题，需要及时调整测试策略，保证测试活动在可控的范围内。
2、进行“风险分析”
作为测试负责人，需要提前识别项目中的可能会存在阻塞测试的风险。然后基于风险来调整我们的测试策略，增加一些测试活动或者质量保证活动。
可能出现的风险和解决方案：
Q（风险）：时间进度风险，用户需求发生重大的变更及设计计划的大幅度调整给测试带来的风险，导致测试时间、人力投入增加。
A（方案）：项目延期。项目分批上线。加班或者增加人力。
Q（风险）：对产品认识的风险：产品、测试、开发三方对产品质量需求或产品特性理解不准确，造成开发或者测试造成错误。
A（方案）：产品、测试、开发加强需求评审，明确需求的验收条件。用例评审，需求覆盖率达到100%，产品、测试、开发达到对需求统一认知。需求评审和用例评审加强对文档的维护和跟踪。
Q（风险）：质量目标风险，对产品的需求或产品的特性理解不准确，造成测试范围分析误差，出现过度测试或者测试盲区的错误。
A（方案）：实时调整测试策略，不以自己的喜好进行测试，理性测试。
Q（风险）：测试充分性风险，除需求覆盖度之外的测试用例设计不到位，忽略了部分边界值和深层次的逻辑，用户场景等。部分软件缺陷不易重现，回归测试一般不运行全部用例，有选择的执行部分用例。
A（方案）：对高风险的加强测试投入（回归），对低风险的降低测试投入（回归）。减少质量较好的老功能测试投入，测试重点放在老功能风险大的地方就行。着重测新功能。
Q（风险）：工具风险，能否及时准备相关测试工具，测试人员对新工具无法熟练运用等情况也有时发生。
A（方案）：给测试人员预留时间，熟悉该工具的员工帮扶。
3、适配“产品研发流程”
测试策略的结构：
测试策略需要指导后续的测试活动，所以制定测试策略的时间应该在项目初期，一些公司会要求在需求分析的阶段就开始投入准备测试策略的制定工作。
根据研发流程来安排测试活动：
测试策略中具体内容，需要和研发的流程保持一致，确保开发和测试的节奏吻合。在开发人员进行产品设计的时候，测试人员的主要活动就应该是测试分析，开发人员在进行功能集成的时候，测试人员的主要活动应该是测试执行。一般开发人员在做计划的时候是否考虑了测试活动：
是否只是提交了一个“中间层”而非最后用户可见的功能？提交的功能是否可测？
测试是否有足够的时间进行测试准备？
4、进行测试分层
测试分层是指将有共同测试目的的测试活动放在一起形成一个组，然后一组一组的逐一进行测试。
分好层后，我们只要决定先测哪层，再测哪层，就能把各种测试活动安排下去，对于软件测试架构师而言，这比一个个考虑先做什么测试活动，再做什么，效率高得多，也能够让测试整体思路变得更为清晰。
网友评论