在目前互联网产品迭代过程中，可能会出现上一个版本的需求被推倒重来，甚至整个已经实现的需求砍掉等情况，这些现象站在敏捷研发角度可能是正常且难以避免的，因为研发团队需要拥抱变化，快速响应迭代，但从研发过程成本来看，无疑是种重复消耗，这些消耗是需要有人买单的，开发需要再次进行方案设计、编码，测试需再次验证，过程反复有可能会增加团队的挫败感。然而这种看似合理，却又影响研发过程的“痛”，是不是真的只能逆来顺受，无从下手呢？
通过现象看本质，往往需求返工，大(多)数是因为需求本身出了问题，产品需求本身的价值最终可以体现在两方向：用户价值及商业价值，用户价值可以赢得好的品牌口碑及传播，商业价值则可以为业务团队带来长远的发展空间、资源。那么大家试想下，如果一件产品在最初设计的时候就是错误的，那么后续不管经过了多少轮开发，以及多久的测试验证，它始终是错误的，所以把控好整个研发过程的源头：“需求”就显的尤为重要，然而测试几乎位于整个研发过程的尾端，如何在需求阶段做更多的分析、挖掘及验证？如何实现测试“左移”这个动作呢？
其实，能够达到测试“左移”的方法有多种，大家可以从以下几个方面进行思考和扩展：
一、需求深度“理解”
多数测试同学，拿到需求时，几乎都是默认了该需求的正确性，对于需求的来源、演变、背景等了解不够深入，试问这又怎么能够算是理解了需求呢？接到需求时，应该多问几个为什么：为什么要做这个需求，为什么是这个逻辑，还有没有其他的点没有关注到？
需求理解至少要包括这几个维度：
需求必要性，很少有人在这方面提出质疑，需求真的是否有必要，是否还其它的方式能够更好的达到目标？如果不做这个需求会有什么样的影响？
需求背景，为什么要做这个需求，是填坑还是完善体验，如果是填坑那么后续针对类似的场景、需求就需要能够早早纠正和避免；
需求价值，该需求能够为用户带来什么样的价值，换位思考下，如果你是这个需求的用户群体，你希望这个功能是怎么样的；
需求诉求，不同用户对于需求的诉求是不同的，有的用户侧诉求可能是希望有“一站式”的体验，有的可能是希望有功能上的补全，只有真正清楚需求背后的诉求才能保证需求的正确性；
二、需求分析：测试建模
在深度理解需求的基础上，通过较为系统的方法对需求进行分析，一来可以让测试人中更好的认知需求本身，二来也可以在前期发现更多的问题，“测试建模”本身就是一种比较好的实践。
什么是模型？
“测试员在设计测试时，头脑中可能会有一个想像的图景，也可能有功能清单或某种图表。测试员会有谁是用户、用户关心什么的一些概念。所有这些都是模型。” – 《软件测试经验与教训》。
通过对需求关键信息的理解分析，从而形成某个“结论”，这个“结论”可以是手绘流程图，又或是某个图表组合，这些都可以理解模型，而形成模型的过程就是建模。
我们为什么要建模？
i. 测试建模可以让测试人员更系统更全面的认知需求本身，更早期的发现问题；
ii. 模型便于简化复杂系统，多角色交流更高效，测试方案评审更有效；
iii.通过模型有助于高效产生高质量的测试思路及用例，相对容易修改维护；
iv. 可视化模型可以产生更多创意，提升测试人员和洞察能力，更便于头脑风暴；
建模的方法都有哪些？
测试建模的方法有很多，如微软提出的HTSM模型，以及google的ACC模型，又或者批判式思维的NLP模型，这些都是比较成熟的模型，每个模型都有各自的优势，模型与模型间也可以组合、嵌套使用。
模型并不局限于表达的形式，建模过程比模型更为重要。
三、需求价值验证
对于需求价值的验证，一般测试同学都不太会去关注这个点，如何在早期就验证需求的价值，从而尽可能的避免返工，同时又能将需求价值最大化呢？然而，一般业务团队对于需求价值的验证价值方式有以下几种：
用户反馈验证：通过线上用户反馈来观察用户的满意度及接受度；
数据漏斗验证：在对应的业务节点上进行数据上报，从而分析出业务流程中，统计出对应的统计率、使用率及瓶颈，从而针对性的优化提升；
这两种方式是最为有效的验证方式，然而，也有着一定的局限性，相对而言阶段比较置后，也比较被动，实际上在需求进入研发流程前也可以利用众测用户或是外团用户来进行调研及摸底，对于用户信息再进行二次加工分析，让用户“决定”需求的正确性。此外，测试人员本身的用户思维角度也需要多多积累。也许做为一名测试工程师，决定不了产品的战略方向或是布局，但是可以把控需求本身，包括需求对于用户的价值以及需求本身的质量，基于这两个维度，测试仍然可以在需求侧做很多“左移”的事情。
除此之外，在“测试执行”层面也有多个维度可以“左移”，将风险前置：
codereview
很多时候一提到CR，测试同学会默认为是开发同学的份内事情，其实不然，测试的CR可以是有别于开发的，代码review的实施可以从以下几点思考：
开发阶段，要求开发及时提交代码，至少每天一次，查看代码变更可以明确本次需求涉及到的具体模块；
在正式提测前，可以使用代码编译出相关模块，提前体验实现效果，单步断点调试，有助于对实现机制深入理解或发现逻辑缺陷；
如果开发有给出流程图，review时可以帮助理解，有必要的话，可以帮助完善流程图细节（技术评审给的流程图不一定和实际代码一致）；
review可以帮助裁剪测试用例（代码review明显不需要测试的点）或指定用例优先级（关键节点优先级高）；
对于编码习惯不好的开发，提交的代码要着重review，及时发现低级错误，相似错误着重检查。
UT（UnitTest） & 框架开发
UT也是测试左移的方法之一，可以具体到某个核心类，也可以是接口类，类似在项目前期公共库函数建设时，UT的价值是很高的，往往可以发现很多隐藏性的风险，并且UT用例应该是集成在开发环境上，有代码变更时，开发能够直接在本地就验证，然而UT具体的实施角色建议是开发人员，那测试在UT阶段可以做些什么呢？
提供UT的用例给开发，由开发去实施，实现“测试驱动开发”；
框架开发，让开发代码具备更高的可测性；
功能自动化左移
很多时候功能自动化一般都是在提测后才开始脚本开发，而且有部分功能自动化是基于UI逻辑的验证，针对这部分的自动化左移是否真的有必要吗？
答案是肯定是需要的，左移可以从以下几个方面实施：
首先，前期在需求、代码实现分析的时候，可以分析出该需求的功能自动化路径及场景，包括自动化的可行性，如依赖环境、条件等等，都需要提前考虑到功能自动化因素中；
功能自动化多数是通过关键字识别控件，如控件名称、对象名等，在自动化框架成熟的前提下，可以尝试先实现功能脚本的主路径，待正式提测后更新控件库，即可同步上线，并且可以接入到持续集成中，减少回归成本；
http://tmq.qq.com/2016/11/move_left/
TMQ（腾讯移动品质中心）是腾讯最早专注在移动APP测试的团队
我们专注于移动测试技术精华，饱含腾讯多款亿级APP的品质秘密，文章皆独家原创，我们不谈虚的，只谈干货！
扫码关注我们
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
