2020/07/20
NO.67
点击上方蓝色字体，关注“蒲公瑛姑娘”
GO!
*全文4847字 ，预计阅读时间 13 分钟*
1
背景
最近有个项目，开发工时在1000+h，测试这边预估的工作量在400h左右，但按照项目截点算，预留给测试的时间只有200h左右。(这里先不考虑开发可能提前交付，以及项目截点延期) 纵观，整个项目的研发过程，我们总会遇到测试资源和时间很有局限的情况： 一是：在项目截点固定的前提下，可能受到产品、开发部分工作进度的压缩； 二是：测试工作本身需要终止点，可能是上线时间到了，也可能是发现的问题都解决了。 测试工作最大的挑战就是在有效的时间内发现较多的缺陷，从而使软件达到一个相对可靠的质量(不敢说绝对可靠，毕竟发现的问题越多隐藏的问题也就越多)。 这就要求我们测试要有策略性的测试，那么什么是测试策略呢？ 从上述背景看，测试策略的诞生就是要平衡效率与质量，为了以最低的成本，最大程度发现产品的质量问题，而使用的最合理的工作方式、方法或者过程。 策略是软件测试工程师最核心的技能，制定好测试策略的第一步就是理解它。
什么是测试策略？
“测试策略”通俗的来讲就是6个字“测什么”和“怎么测” ，具体来讲有六个方面：
测试的对象和范围是什么？
测试的目标是什么 ？
测试的重点和难点是什么 ？
测试的深度和广度 ？
如何安排测试活动(先测试什么，再测试什么)？
如何评价测试的效果？
我们需要一套方法来指导我们制定测试策略的整个过程，四歩测试策略制定法应运而生。
2
明确产品质量目标
产品质量要求高的是测试重点，反之为非重点；
产品质量要求高的测试投入大，反之小，牢记测试方案不是粒度越细越好，好的测试人员应掌握测试粒度；
产品质量要求高的要测得深，反之浅 ；
如下图，将目标-行为-评估形成闭环
首先，我们将产品质量评估模型作用于具体的产品，得到产品质量目标；
其次，我们根据产品质量目标来制定测试策略，确定接下来的测试活动；
最后，对测试效果进行评估，评估产品的质量目标是否达到 。
此时，我们的目标(产品质量目标)，行为(测试活动)和评估(质量评估)会形成一个闭环。这时测试策略就好像一艘船上的舵，一旦返现没有达到产品质量目标，我们就调整测试策略，让整个测试始终保持在达到产品质量目标的航线上
3
进行风险分析
机会成本告诉我们，要想用有限的资源获得最大的收益，就需要我们优先处理最可能会发生，影响(如损失)最大的事件。这就需要我们对识别出来的风险点进行评估，确定风险优先级，然后优先处理高风险的问题 。 我们总结一些项目中常见的风险和应对这些风险比较通用的思路 1.需求类风险 a.风险举例：产品需求在业务场景上描述不够完整清晰，不能有效指导开发人员和测试人员的工作 风险应对思路： (1)加强对业务场景的评审 (2)加强开发、测试和需求工程师对业务场景的沟通、讨论，保证开发、测试和需求方对场景的验收条件的理解是一致的 b.风险举例：开发人员在进行产品设计之前并没有充分理解产品需求，特别是在易用性和性能需求方面 风险应对思路： (1)开发人员或者测试人员需要逐一根据需求编写验收测试用例，并组织三方用例评审，确保需求能够正确实现，无遗漏 (2)开发人员针对易用性进行低保真、高保真设计，并和需求方进行评审确认 (3)在需求中需要明确产品的性能目标 (4)测试人员尽早展开和产品性能相关的摸底测试 2.设计类风险 a.风险举例：产品使用了新技术 风险应对思路： (1)将新平台和旧平台进行差异性分析，确定变化点 (2)针对变化点进行专项测试 b.风险举例：产品中存在需要多人(或者多业务线)才能配合完成的功能，且缺少这个功能的总体责任人 风险应对思路： (1)建议开发增加一位总体责任人，负责确认接口、整体协调等 (2)建议开发对该功能设计自测用例，并在评审用例时进行确认 (3)将该功能作为接收测试用例，避免该功能造成测试阻塞 3.流程类风险 a.风险举例：开发自测不充分 风险应对思路： (1)和开发约定，在提测功能时，提供详细的自测报告 (2)评估开发人员自测用例质量，必要时提供用例设计指导或者直接提供测试用例 (3)驱动开发进行单元测试覆盖 (4)搭建自动化测试环境，供开发人员自测使用 4.需求变更类风险 管理需求变更的目的不是为了要避免变更，而是有序控制变更，减少和降低需求变更对产品开发的影响，包括成本、进度和质量的影响。总结的集中典型情况如下：
1)病情一：产品经理自己缺少经验，说白了就是还没真的想好就说设计已经完成。就开始开发。
症状：开发过程中研发常常询问细节逻辑，产品经理常常改变原有需求。
危害：让所有的评审工作的成果付之东流，让测试参考的依据化为乌有，实在百害无一利，这就是典型的欲速不达
对策：客观的放映情况，如果您在公司有足够的权利，把这些稚嫩的产品经理调到不足轻重的小项目中去磨练。
诸葛亮尚且可以挥泪斩马谡，我们也不愿意看到长平之战的赵括毁了一个项目。
实在没办法，我们只能强制要求评审需求，多问问几个“你确定嘛”
2)病情二：当初设计太多完美，以至于提出了很多研发技术不能实现的炫酷效果。
症状：产品经理为了成品高大上，设计很理想的效果，但是实际的情况不理想，导致一直僵持PK，需求不断调整
危害：可能消磨团队的斗志和信心，有很大的延期风险。
对策：诚知，毕其功于一役乃产品大忌，其实凡事讲究实事求是，硬要在现在安卓手机上实现iPhone类似的指纹 识别功能似乎不太现实。其实软件设计大多是带着镣铐跳舞。即便是所谓的研发大牛，也是用人家的API吧。
我们测试人员，要合适的时候晓以利害，让产品经理明白，快速迭代积极改进，才是互联网的制胜之道。
此外，可以加强概要设计评审，以加强需求能实现的评估。
3)病情三：产品缺少主见，觉得这样也行，那样也行。设计出多套方案相对比，选取更好的。
症状：一次设计出多套方案，让研发测试都实现，最后选取效果最好的一套。
危害：有目的的尝试是好的，盲目的尝试大多徒劳无功。
对策：我挺多有很多人鼓吹，我们的产品多么精致，我们的图标是从一百张里面一张张的筛选出来的。
我承认精益求精的品质。但更相信中庸之道，过犹不及，所有的事情都要因地制宜，因时制宜。
对此我们可以强调项目的实际情况，可以综合考虑时间，人力，技术经验等因素，制定出合理方案。
实际工作中可能还有各种各样的情况，只要我们勤于总结，勤于思考，总能找到一条适合自己的应对之策略。其实还有个大前提就是传统互联网和移动互联网，传统互联网项目周期长，可以凭借强有力的评审制度，有效的控制需求变更。移动互联网求快为主。这只是希望大家记得磨刀不误砍柴工的道理。与此同时也要不断的革新。比如你身处移动互联网公司，可以将传统的几个小时的需求评审，压缩到晨会的十几分钟。当然这也提出了对人员的要求，要求你对需求足够敏感。能及时的提出问题，切莫让敏捷流于口号，切莫让晨会流于形式。
关于应对需求变更，其中的技巧和经验还有很多，相信只要大家有心，也能积累更多的经验。
5.组织和人 a.风险举例：测试人员是新人，没有测试经验 风险应对思路： (1)在进行测试设计之前，找优秀的测试用例作为例子 (2)增加测试用例设计评审检查点，如对测试分析、测试标题和测试内容分别进行评审 b.风险举例：测试工具不具备，需要购买 风险应对思路： (1)定期跟踪工具购买进展 (2)寻找是否有替代工具 6.历史类风险 风险举例：基线版本中，开发人员修改引入缺陷，导致缺陷趋势无法收敛，在继承性版本中，可能存在相同风险 风险应对思路：对基线版本该特性的缺陷进行分析，分析那些测试手段容易发现该特性的问题，据此增加探索式测试
4
适配产品研发流程
测试策略中具体的内容，也需要和研发产品流程保持一致，确保测试和开发的节奏能够彼此吻合。 例如，在产品概念阶段和开发人员技术方案设计阶段，测试人员的主要活动是测试分析和风险评估，在开发人员在进行功能集成时，测试人员的主要活动是测试用例设计，测试方案制定及组织用例评审，在测试验证阶段，测试人员的主要工作应该是测试执行和bug跟进而不是用例设计。
5
测试分层
测试分层是指将有共同测试目的的测试活动放在一起形成一个组，然后一组一组地逐一进行测试。 对于测试团队来说，分层测试后，每次的测试内容、测试重点和测试方法都会有所不同，可以减少测试团队总是感到在重复执行相同内容的困惑。但是这些都不是测试分层最大的价值。 测试分层最大的价值在于： 1.通过测试分层，我们能够将一个大的测试目标，分到不同层次中分阶段去完成。 2.合理的测试分层能够让测试目标SMART化。能够让我们将目标(产品质量目标)-行为(测试活动)-评估(质量评估)的闭环，真正在产品测试中落地。 最经典的测试分层就是V模型
对V模型而言，每个测试分层测试图测试的重点为：
单元测试：从产品实现的函数单元的角度，验证函数单元是否正确，一般的测试手段是使用单测框架，该层质量一般由开发来保证 ；
集成测试：从产品的模块和功能的角度，验证功能模块和模块之间的接口是否正确，一般的测试手段是使用接口自动化框架(testng,httprunner,jmeter等)或者接口测试工具(postman，curl命令，soupui或者现成的调试平台工具等)；
系统测试：从用户的角度验证功能是否正确，验证系统的非功能属性是否能够满足用户的需求(一般包含性能测试，并发测试，安全测试，并发测试，探索测试法)；功能测试的方法有单运行正常值输入法、单运行边界值输入法、多运行顺序执行法、多运行相互作用法 ；
可靠性测试法有异常值输入法、故障植入法、稳定性测试法、压力测试法等；
验收测试：从用户的角度，确认产品是否能够满足用户的业务需求(一般使用场景测试+回归测试)
6
质量评估
版本测试结束后，在进行下个版本测试之前，软件测试架构师需要停一下，对版本的测试情况进行回顾和总结，对版本进行质量评估 我们将从3个方面来建立软件产品质量评估模型，对产品质量进行分析、确定和评估。
具备出色的测试策略设计能力，你可以非常明确地回答出测试过程中遇到的这些关键问题：
1.测试要具体执行到什么程度；
2.测试需要借助于什么工具；
3.如何运用自动化测试以及自动化测试框架，以及如何选型；
4.测试人员资源如何合理分配；
5.测试进度如何安排；
6.测试风险如何应对。
培养出色的测试策略设计能力，不是一朝一夕的事情，通常需要经过大量项目的实际历练，并且你还要保持持续思考，主动去提炼共性的内容。
不像测试技术，你可以通过培训或者网上资料的学习而有快速的提升，测试策略设计能力一定是需要你在大量实践的基础上潜移默化形成的。
我认为，测试策略设计能力是功能测试工程师最核心的竞争力，也是最难培养的。
总结
透过上述内容，不难看出，最终策略的重点在于：就当前现状进行梳理分析，并与相关人员沟通互动，从而在效率、进度、质量、投入上达成一致，并按要求输出。
测试工作本身就需要谋定而后动，面对有效的资源，制定相应的策略，将核心精力放在价值更高，优先级更高，使用场景最多的事情上，最大限度的保障产品的质量。
在提升效率与质量上一直奔走，是作为测试工作者的不变使命。往期推荐
彻底弄懂|Cookie、Session、Token的“爱恨情仇”
2020-05-06
接口|你想知道的接口测试姿势--这里都有
2020-04-16
手把手教你写简历|测试工程师QA
2020-04-14
软件测试工程师的核心竞争力是什么？
2020-05-18
Linux|常用命令及Linux三剑客
2020-06-28
Bash编程语法
2020-07-05
时光
每一份荣光
都是未来的眼光
点赞鼓励一下
扫一扫
910
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
