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

2016-12-22   出处: 腾讯移动品质中心TMQ  作/译者: 卢少娜  

                

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

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

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

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


一、读需求

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

1

多想--想破坏,扣字眼

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

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

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

NLP典型案例解析

2

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

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

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


二、读代码

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

1

多听---手段1 CR

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

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

  •   这个可能会出现异常?这样子字符串转换会出现crash。

  •   这里函数会有性能问题?为什么要前台进程执行?

  •   这里会不会存在安全性问题?

  •   这个API可能会有性能问题,提取MD5的时间比较长

  •   这里的try catch 的范围不对,这里锁的范围不准

       ……

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

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

2

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

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

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

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

3

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

自已看开发每日更新代码

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

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

每日code 关注

4

多看---手段2 看svndiff

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

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

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

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

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

5

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

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

6

多写多动手

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

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

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


三、总结

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

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

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



欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
161°|1610 人阅读|0 条评论

登录 后发表评论