敏捷测试- 快速俘虏产品 & 开发

快速互联网的状态下，测试的价值体现在哪里？俗话说，长江后浪推前浪，前浪拍死沙滩上。我们在新人面前标签应该不仅限于工龄属性上的增长，在经验累积上也是有加分项的。那么问题来了，能体现我们经验值的有什么呢？

今年比较喜闻乐见的词并且能体现测试的价值体现——测试分析。术业有专攻，每个行业都有行业的专长，个人认为“快准猛”是可以拿来衡量每个行业的价值所在，无论是传统行业，还是互联网行业。比如，医生可以很快的定位出病人的病痛；测试人员可以很快找到bug所在。而测试分析目的是为了通过分析，可以更快的找到bug。

怎么快速提升测试分析呢？我们测试分析的对象是产品的需求，是开发写的代码。那既然是读需求，读代码，如何用简单易用的办法快速提升自己准确的读需求，读代码能力？

这里插入一个段子，女朋友（产品）让男朋友（开发）做个需求：你回来的路上，去超市买点橙子回来；如果看到西瓜，就买个西瓜。男朋友在路上看到西瓜，就只买了西瓜回来。这可以说是程序员思维的if else，但是也是没好好读好需求，注孤生的节奏啊。今天手把手把产品跟开发拿下，无论说什么都能完美的理解。

一、读需求

文绉绉的需求，怎么快速的理解需求，并且转换成我们想要的内容呢？产品的少女心特别难俘虏跟读懂，从获取需求，定义需求的边界，获取业务用例是一个系列的过程，教你两招读心术：

1 多想--想破坏，扣字眼

破坏：读需求的时候，存在一万个怎么办，需要任何怎么办都需要有路径进行解决，这种办法可以比较快的确定需求的边界，这种可以选择典型的探索性摸索。要是产品MM要买西瓜的时候，如果没有西瓜呢，问一下要不买个苹果？还是不买了？

扣字眼：NLP语言是一种语言模型，讲一句话需求划分为很多种类型的词汇，通过对词汇的深刻理解，进行理解需求，也是目前做需求分析的很热门的一种方式。产品MM说要买一个苹果?纳尼，我要问问是6块钱一斤的苹果，还是6888一斤的那个苹果。 这两个都在TMQ里面是热门文章，有兴趣的人请详细阅读。

探索性日常采用的方法总结

NLP典型案例解析

2 多画---建立业务模型分析

产品MM哪天跟我说了好几个路径，又买苹果，又买橙子，又买西瓜的，我头都听大了，还要从中华广场买的苹果，从维多利亚买的橙子，在华景路买的西瓜，想想都心塞，最后她自己都不知道自己要什么。这个时候从需求分析的时候，动手建立业务模型。业务模型的建立，有易于我们对需求的理解，而且建立一个平等的可以互相理解的沟通平台。白纸黑字很多时候也会存在歧义，所以我们要对一个信息进行二次确认的时候，建议使用UML建模语言。

一份优秀的需求的特性是：完整的，正确的，精准的，可行的，必要的，无歧义的。从优秀的需求上出发，在做需求分析的过程中，我们就可以更好的理解需求的含义。

二、读代码

这是一门偷窥开发GG每日做什么的最佳手段，但是一般人肯定不想身边有个测试妹子碎碎问。所以要采用下面的几个读心术的工具，来知道我们的开发怎么实现某些功能。学习代码其实是上一门编程课程，但是我们的老师是谁呢？应该把我们的开发当做我们的老师，多听，多看他们是怎么实现需求。

多听---手段1 CR

CR全称叫做codereview，当我们完全没有基础的情况下，多上CR，认真听讲，认真做笔记，甚至CR后自己写一遍伪代码来学习功能模块。

CR面向的对象是全部人员，主讲人是开发，讲述的是新功能的实现逻辑，每个API是怎么封装的，每个跳转是怎么实现的，这个UI是怎么布局的。大家会有谈论环节，多人讨论主要讨论点：

• 这个可能会出现异常？这样子字符串转换会出现crash。
• 这里函数会有性能问题？为什么要前台进程执行？
• 这里会不会存在安全性问题？
• 这个API可能会有性能问题，提取MD5的时间比较长
• 这里的try catch 的范围不对，这里锁的范围不准

……

通过CR我们可以学习到需求是怎么实现的原理，还可以学习关于性能，安全的问题。在听讲的过程，不断思考自己的测试路径是否会覆盖到这些异常路径，测试过程是否存在优化。

比如这类型的CR结果，我们要学会是否在测试用例中能够覆盖，后续怎么避免该类型的问题，用例的设计以及选取方便是否可以更精简的路线

多听---手段2 根因分析

这里的根因分析面向的对象也是开发。每个版本末，开发对这个版本里面出现的bug的根因进行总结，并且给FT讲解。根因分析是CR的完美闭环，在项目开发过程中，发现bug的时间延后，版本质量风险更大，为此我们也在前期做了冒烟测试；做了bug总结分析，是否可以把bug提前发现，根因分析这类型的bug在CR是否可以被提前发现，是否有类似问题可以总结归纳成方法。比如上次通过UI适配的问题，总结了当前主要采用UI还原的集中方式主要有：

根因分析讲解的是bug为什么会出现，这个bug的实现逻辑是怎么样子的，怎么解决这个bug，是沟通问题？UI问题？需求问题？等

根因分析是测试分析的二次解读，是否自己的测试分析能够覆盖到这个路径；是否下次遇到类似问题，我们可以怎么减少时间去测试且不漏测。

多看---手段1 看更新代码

自已看开发每日更新代码

通过关注开发的提交的代码，大知识难消化，那么就切成多个小部分的查看。通过观察开发每日提交的代码，查看这个代码的修改点是什么，是否在自己的覆盖范围内，完善自己的测试分析。

在CR的累计基础上，小部分的代码消化会比较快，而且测试路径也比较准，测试分析的时候关注影响的测试范围点是什么。

每日code 关注

多看---手段2 看svndiff

如果你不懂某一行代码的意思，那么你就把这个代码给注释掉去运行，查看是否会有什么明显的变化。“对比“是一种很好的学习办法，svn diff 就是测试分析的利器，今天突然需求增加；今天突然砍掉这个功能；今天只修改了这个bug,你测试一下？what……

这里主要介绍两个svn diff 的利器，CR客户端&svnlog

CR客户端，是腾讯自研的一个客户端，

从上图可以看出，客户端里面可以根据一个svn的基版本跟右版本进行对比，并且输出对比文件，双击文件可以查看到diff 的内容。

Svnlog，是svn自带的工具，可以查看开发提交的日志，通过多选svn的记录，右键，copy to clipboard, 再拷贝到记事本里面,可以查看连续的几个开发的日志，并且修改的文件

多想---如果是你，你怎么做

大胆猜测如果你的角色是开发，你会怎么做实现这个功能，怎么抽象表结构，类方法，属性，页面等，从模型设计到接口设计。测试分析要做那么多么？如果是小需求的话，其实在脑海里能够转换就行了；如果是比较大的需求，我们可能需要多涂鸦，从整体上查看是否有实现漏洞，或者需要多关注哪一些环节的测试要点。

多写多动手

不会写程序的产品不是好测试，摆脱开发做根因分析

孰能生巧，这绝对不是说假的。一个不懂开发的人，写了10年的代码，也是可以写出一些代码来。实践是唯一快速上手的事情，从写一个helloword 开始，到写一个Log日志，到尝试协助开发定位问题，在这个过程也会受益良多，并且比自己看半天代码的收益会很多，并且在这个过程，你对每个API的使用会更加的熟练，评估内容更加准确。

摆脱开发做根因分析，以往我们可能常常问下开发，为什么这样子，为什么会出现那样子，如果学会自己定位，第一次可能定位到package的问题，第二次定位到class的问题，再定位到method，细化到哪一行，哪一个调用，哪一个根因。逐渐的提升自己的代码能力，对测试分析评估是起了很大作用。

三、总结

上述的动作，词汇可能很简单，但是做起来其实是有难度的，学习最好的过程就是放下身段把自己当做新人进行学习，多听少讲。

测试分析感觉听起来像是一个开发，其实不然，测试分析没有必要跟着开发一样实现代码，但是至少能看懂开发的代码，知道开发解决的是什么问题，会不会影响以前的逻辑，会不会造成其他的bug。这个也是开发跟测试岗位的术业与专攻，我们关注的是从代码里面发觉更准确的测试路径，提前把bug更早的发现。

巧妙的使用好上述手段，其实我们已经完美的俘虏了产品跟开发的内心，更好的合作的前提就是互相了解，互相读懂，才能更好的做下一步的操作，并且通过简单的操作提升测试自身的能力。