职业经验 测试开发之路--喷喷埋雷的事,吵吵代码的情

孙高飞 · September 06, 2016 · Last by 戴眼镜的熊 replied at September 27, 2019 · 3156 hits
本帖已被设为精华帖!

前言

大家好,还是我,朋友给我起了个外号叫他姥爷(别问我典故。。。都是眼泪,我媳妇现在一听这三字就笑的惨绝人寰的。。。),今天他姥爷想跟大家聊聊基础。本来基础的我实在懒得说,而且也没什么逼格是不(哈哈哈,俺很虚荣的)。但现在我说一下吧,因为偶然想以前的东家的一些事。我觉得跟大家讲一下这些事挺有借鉴意义的。之所以收录到测试开发之路中,算是给想走测试开发这条路的新人们一个借鉴吧。

第一件事

在老东家的时候有段时间推接口测试。把基础的架子搭好以后便急急忙忙的去测性能去了。留下业务线的一个同事继续跟着那个项目。后来转过头来看他写的东西,顿时一脸黑线的感觉。我就说最简单的一个点吧。接口返回中有一个字段对应着错误信息,这些error message都是RD的同学互相约定好的定义在他们的项目中的一个枚举中。但我的同事自己并没有将这些错误信息也定义在一个枚举中,而是直接以字符串的形式赋值到期望结果中,数个case中的错误信息都是这么写死的。
我问:为啥不存到一个枚举里或者你随便弄个接口里也行啊。
他说:有啥啥区别啊,没必要。
结果过了一周多的样子吧,开发那边改了一个错误信息。他这边好几个case挂了。然后跑到工程里手动改了好几处。又过了几天,另一个错误信息也改了。他这边10几个case挂了。他又手动改了10几处。类似的事情还出现在各种约定的状态值,字段名等等等等。

第二件事

公司一直有UI自动化测试,case的量积累的还不少。page object这东西我是真不想说。。但还是得说,因为我发现很多小伙伴们的page object 就只是类似下面这个样子。

public class MainPage{
public static By createProjectSpan= By.xpath("//span[contains(@class,'ProjectTree__blueAdd')]");

上面我就随便写写吧,也有用page factory的。反正就是把页面元素的查找方式封装起来了。 然后呢? 然后就木有然后了。。。。。每个页面的逻辑,甭管它有多通用,统统都在case里写。 看着一坨一坨的重复代码我就忍不住的蛋疼。。于是乎开发那会随便改改逻辑,改改页面。。小伙伴们就蛋疼的去改N的N次方个case去了。

第三件事

其实应该是第二件事的后续吧,就是我终于说服小伙伴们把逻辑封装在page object了。 但是后来我又蛋疼了。因为我发现小伙伴们封装的方法中,参数清一色的都是基本数据类型,一个对象都没有。我问他你为啥不把参数都封装在一个对象里。小伙伴们还是一句没必要吧。我接着劝服说:这个逻辑所在的页面要是加功能了呢,随便加一个必填的选项。你就得改所有脚本吧。 你要是用对象当参数,需求变动时加选项还是减选项你在类里修改属性给个默认值就行了。很多case都不用改。小伙伴看来是懒惰木有心思重构。然后某个时间他又蛋疼的跑去一个个改脚本去了。

第四件事

在上个东家,一个跟我一样做测试开发的小伙伴负责写测试管理平台。偶然间我去看他的代码的时候,我也顿时一脸黑线。一个方法里无数个if else,N层for循环while循环的。还半行注释都没有。只为了遍历一个xml。。。。。 跟我他推荐了几种模式去重构代码,或者使用开源的工具包处理xml。可能我说的太直了伤到他了吧,也可能我比他年轻太多他没把我当回事。也可能他是没时间重构代码。 然后一个需求改变,xml的结构也变了。。。 而且代码是他好几个月前写的。。。 我都不忍直视他改自己代码的时候有多蛋疼的样子了。。。

一个故事

之前曾经在朋友圈里看有人发过一个故事。大概意思是3个人:菜鸟,老手,高手。他们三个人各自过一片雷区。菜鸟很自信的立刻就说我要一天就能走过这个雷区了,老手在观察了些许时间后说我需要一周的时间。这时候菜鸟很诧异的看着他,觉得老手在搞笑么。 最后高手也观察了一会后说我需要三天。菜鸟和高手都不约而同的看着他不说话。菜鸟觉得你俩都在搞笑。老手觉得高手怎么这么有把握。 于是三人分别出发了,菜鸟在路程上频频触雷,伤痕累累,最后前功尽弃,放弃了穿越这片雷区。 老手亦步亦趋,小心翼翼,铲掉了很多累但是仍有触雷的情况。身上也是带伤,但他确实在一周的时候准时穿越了这篇雷区。但这时候高手早已在终点悠闲的喝茶了。菜鸟和老手问高手:你是怎么解决那些雷的。高手回答道:我当初就没给自己埋雷。

接下来我们扯扯淡,嘲嘲讽吧

故事说完了,大家到这应该也懂了。我上面说的4个事都是再给自己埋雷的典范。有些时候我们觉得维护自动化成本很高,觉得自动化的投入大产出小。这其中固然有互联网创业之期需求变化快,产品不稳定的因素。但是我们不要把所有的黑锅都扔给他背。公司除非死掉,否则也终有业务稳定的一天。届时你还能把黑锅推给谁背?别说变化太快。没有软件是不变化的,这一行里唯一不变的就是需求永远在变。而问题是,你适应的了变化么?别说产品不能自动化,我就没见过不能自动化的产品,每个产品是有几个模块不适合自动化,但我就不信处处都不适合自动化。而问题是,你是合适做自动化的那个人么?别说自动化发现的bug少不值得做,自动化测的是之前存在的功能,发现的bug要是比你测新功能都多那你们的开发也就可以集体自刎了。做自动化前你得知道自动化的目的。而问题是,你懂自动化么?

我们之前把太多的失败因素都归结于需求,归结于产品,归结于没有文档,归结于开发不配合甚至归结于自动化根本没用等等等等。
该醒醒了
老实承认吧,你就是不懂代码
老实承认吧,你就是懒的学习
老实承认吧,你就是懒的思考
老实承认吧,你就是自以为是
老实承认吧,你就是low

知道自己low是好事,因为它激励着你前进。2年前我承认我自己low,所以我才能努力的变成今天这样不那么low了。

痛点

测试这个行业一开始都不会代码的,大家都认为面试的时候面试代码是在装逼。但是后来有了各种自动化,性能,安全等等。大家有了共识那就是测试也是需要会写代码的。我记得monkey还说过行业在这方面好转了。但是我依然可以听到类似这样的声音:怎么问这个,我来面试测试的。又或者:要求这么高,你招开发还是测试啊,再或者:问这些你要招全占工程师么。 但实际上我可能只是问了一句单例模式怎么写,而且我也没说这么一道题就决定候选人的去留吧。我到底怎么戳到这么多人的痛点了?

起码要以初级开发的水平要求自己

说到底我们对自己的要求还是太低,虽然我们号称技术工种但我们却没有用真正的技术工种该有的技能要求我们自己。

我们总是纠结某某技能是开发该会的,不是我们该会的。我就问你,你是不是写代码的?是,那你凭什么说自己不该会。
我们总是纠结某某事情不是QA该做的,我就问你,这事能提升质量不?能,那你凭什么说自己不该管
我们总是纠结某某公司没有人教你,我就问你,你是来给公司创造价值的不?是,那你凭什么认为你是来当学生的。

做一个测试开发,起码要以一个初级开发工程师的水平要求自己,否则这活你干不好。写自动化测试,就是写代码,就是在开发。我之所以说初级开发工程师,是因为我也知道人的精力是有限的,我们有很多其他杂七杂八的事情要做。但是如果说你达不到初级开发工程师的水平,那这活太难干了。不是说会写两行代码你就是懂开发了,能干活了。就像我上面说的那几个例子。我直接以为我们倒退到了C语言刚开发出来那会了。我也没说你一定得玩转设计模式,架构模式这些看着高大上的东西(我也玩不转)。但起码你得让我知道你是在用高级语言干活吧。封装这个我们绝对是第一个学的特性。已经被多少人忘到脑后了?我列举的前三个例子哪个不是可以用很简单的方式把变化封装起来的?这已经不是什么编程技能了,这就是最起码得编程习惯。基础到不能再基础的程度。

自动化的工程跟开发的工程一样,需要设计,需要架构,需要策略。你可以为了快速应对变化先糊出来一个,但是之后也要适当重构,再重构。否则人家开发那边高内聚,低耦了。我们测试这边连各种hard code都漫天飞呢。你觉得你怎么变的过开发。需求一个改变人家可能改一行代码,你这得改100行。 你说你这还玩什么了。为啥我在很多地方都说我反感关键字驱动和录制回放的框架。最大的原因就是这玩意根本应对不了变化。小项目用用还行,case一多就痛苦死你。

当然了,开发能力不仅仅体现在应对变化上。好的开发水平能帮助你实现复杂的功能,优化框架,理解产品等等等等。这些都是有助于你的工作的。

自动化的选择

在写代码的事上说了这么多。。。我也是够啰嗦的。很多情况下自动化的成败也并非是代码的问题。 是策略的问题,是权衡利弊的问题,是衡量得失的问题。每个产品都不一样,很难总结出个通用惯例。我就说说大家总在纠结的自动化测试发现的bug少,做自动化有啥用的问题吧。 因为最近总是听到大家在纠结。

首先,觉得自动化测试发现的bug少就质疑自动化测试的人,从根本上就把自动化的目的搞错了,自动化本不是为了发现bug的。这么说吧,你决定自动化的东西肯定是在一定程度上趋于稳定的东西或者是你认为即使变化你也可以快速应对的模块。这种功能出现bug的几率本就不大,就像我刚才说的,要是这种模块还整天搞出一堆bug出来那你们开发真可以自刎谢罪了。所以不要对自动化发现的bug数量期望太高。我之前一个公司6,7千的脚本。每天跑ci的时候也没见有多少bug测出来。

OK,那我们搞自动化干嘛的,其实这不废话么,节省成本啊。以前运行这些测试用例要3个人,现在我两个人就搞定了。那么这个自动化就是有效的。一切不以节省成本为目的的自动化都是在耍流氓。 有些人也许会问你自动化的那些case根本没发现多少bug啊。好,那我问你,即便这些case没发现什么bug,可能你就觉得这功能已经很稳定了,出bug的几率不大。那你测试不?如果答案是测,那不就得了。我还需要再多说什么么? 你跟老板说你要搞自动化的时候,你觉得老板是关心你搞自动化能发现多少bug么?他关心的是你搞自动化能给他省多少成本。

其实自动化不仅仅是测试,还有自动化部署,上线,备份,管理等等等等。不要以为这些事跟QA没啥关系,还是那句话,能提升质量的跟你都有关系。

总结

总结啥呢,貌似我通篇说了一堆没啥营养的话。我们还是好好学习天天向上吧。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 54 条回复 时间 点赞

最后一句鸡汤很毒啊,哈哈哈,希望领导也能看到这文章

希望多点人在意封装...也不太指望下属了解设计模式。。。

#2楼 @jiazurongyu 问题是很多人连最基本的封装都不在意了。

#3楼 @ycwdaaaa 这就没办法了。

踩过多少坑才有这么多的总结,看着怎么这么的心酸。

一直在关注你的测试开发之路系列。

顶一个

我觉得这些该踩的还是要自己踩一次才知道痛,别人说了其实很难听得进去。

踩了雷,知道痛,只要能改还是OK的,慢慢的就会成长了

测试回帖 点我头像试试

加我微信吧. seveniruby . 拉你到社区的一个技术高手群

思寒_seveniruby 将本帖设为了精华贴 07 Sep 10:54

加精理由: 在测试开发和自动化测试用例管理上的经验有借鉴意义.

还是那句话,能提升质量的跟你都有关系。--测试就是操心的命

#8楼 @wyb199026 嗯,你说的有道理

确实是的,其实还是思想的问题,就像在测试的时候是一味的按着测试用例还是不断总结抽取一定的模式和技巧,提高测试效率,在做自动化也一样,你做的东西是不是有意义,提高了效率和质量还是仅仅为了自动化而自动化

“能提升质量的跟你都有关系”学习

说的字字珠玑,这是踩过了多少坑才得出的结论,赞

好腻害 做测试几年了啊

能提升质量的跟你都有关系,这句话我喜欢~

#20楼 @klxiaoqi 6年了,其实还是在努力摸索和提高的状态~ 谈不上多厉害

自动化测试时基于一定的环境和项目需求,对于刚入门的新手,还是扎实测试用例,这个才是测试的核心,作者的分享很用心!

忽略了基础。基础不扎实,写代码的时候是没法想那么远的。学习ing。
@seveniruby 社区技术高手群有门槛么😂

自动化测试还是应该针对核心稳定的产品流程,优势应该是回归快速,节省时间,减少人为疏漏。
恩,我主要是来凑回帖的。。。竟然不能发帖。。。

#24楼 @xuxu 有门槛, 但是你可以. 加我微信, 微信群刚组建

这东西你带换个角度去想,他这次坑不睬,就不会长记性,下次还待踩。

看完你这篇文章,我觉得自己现在low爆了。

一切不以节省成本为目的的自动化都是在耍流氓。

全都理解 肺腑之言

加上一个监控,codereview

这些坑真正实践下来的人应该都或多或少踩过,但是像你说的你给了建议他们并不采纳而是一个个去改的,我比较汗颜
至于说用自动化来发现bug或者嫌发现的bug少的,难道在做之前没有想为什么要做?

#32楼 @dancingcat_ 可能每个人的目的和预期都不一样吧。有的人为了学习,有的人听说自动化了就要在自己的团队里搞。各有各的目的

孙高飞 [Topic was deleted] 中提及了此贴 26 Sep 14:49

自动化还是建议在项目相对稳定了做,或者只做相对稳定的模块,不然 page object封装,就算写得再灵活,还是要去维护,最基本的页面对象捕获这些经常变动。如果每测试一次自动化都需要维护脚本,还不如不搞

#35楼 @lingcizhisheng 这个都得看你case的重复执行度。如果平均人家一周变动一次页面,但你一天就必须得执行一次case。那即使不太稳定我也会选择去自动化它。一切都是权衡的。如果改变的成本低于每天执行用例的成本。 还是有自动化的价值的

思路一点一点积累,坑一点一点的填,填多了,有经验了,以后的路就平了

反感关键字驱动和录制回放的框架

关于:反感关键字驱动和录制回放的框架
录制回访确实不方便。
但是关于关键字,想了解作者都使用怎样的方式进行自动化的设计

顶一个

#39楼 @early 我都不用关键字的。我觉得最好的方式就是老老实实的写代码,使用良好的代码设计应对变化即可。

#5楼 @becky 哈哈 前任踩坑 后人乘凉

—— 来自TesterHome官方 安卓客户端

顶一个顶一个

作为一篇作文,能给90分,作为一篇技术性分享真的一声叹息,可能80%的人会认同你的文章,我相信还有20%的人和我一样,这个比例就是行业现状。

现实就是这样,很多公司里面,你要想找到能写代码的测试不容易。
就算能写,大部分都是停留在写那种又长又臭的代码,维护成功极高,基本上是一次性使用的。
而真的能好好设计,并且重构的好,形成框架,易于维护的,在一般公司中可以说是凤毛麟角(我不说绝对没有),而且这些人基本上都往BAT倾斜了。又或者,有这样的能力的,早就去做开发了,还干测试干嘛。

所以,这就是为什么自动化,尤其是UI自动化一直搞不起来,没办法有声有色的。
很多人有很好的想法,想出不错的点子弄个框架出来,但是一想到身边测试同事的水平都是停留在手工的测试,你让他写个冒泡排序也非大半天劲都没搞好(PS:测试入门门槛低,很多人都是非科班出身,本来就没什么编码能力。或者即使是计算机专业,大学的课程有多无用,又有多少人在大学不是混日子,或者当初就是因为自己编码能力就是烂才有了做测试的意向的。这些人占的比例可高了)。面对着这样的队友,你写出来的框架他们能理解吗?他们会懂的用吗?给他们玩也是相当于杀鸡用牛刀,最后弄巧成拙。

时至今日,很多测试还对QTP念念不忘,那是为什么,就是因为能录制回放,不用怎么动手写代码。
你让这类人用selenium,那你想办法求一下他们的心理阴影面积吧。

发个牢骚,就这样。

#41楼 @ycwdaaaa
是的,关键字驱动、录制脚本,都是用来忽悠低水平的测试人员,进入自动化的领域。
但是很多人都是不思进取,碰到问题的就放弃了。
感觉这种傻瓜式的关键字驱动和脚本录制,其实并不利用自动化的良性发展

为什么自动化要归到测试开发呢 业务测试更了解逻辑 更能明白业务的覆盖重点在哪 而且说到底 覆盖自动化 本来就是为了节省业务逻辑的人力物力 至少我目前在这样尝试 负责部分业务 负责自动化维护和重构 虽然不知道结果如何 但是也没办法 因为没人做 但不能不做 就是因为一直做功能测试的人员只要手工就好了 才会造成很多人说的当前测试水平底下吧

#47楼 @cloudhuan 自动化测试其实也是可以算是一种开发任务,如果你这样看的话。问题有出来了,这个任务的需求是否清晰呢?

#36楼 @ycwdaaaa 楼主这个说得对,但是如果向我们目前的状态:老板开发进度直接指定上线时间,不考虑中间的任何开发测试问题,在明天上线了,今天还在变更需求的时候(有时候还是主逻辑),这种自动化的代价太大了。。

#49楼 @lingcizhisheng 新的需求是不建议立刻做自动化的,因为不稳定。 如果做了,也是你有自信能立刻应变的。例如变了某些东西你有自信在很短的时间内作出改变。 你看在需求变动的时候受影响最大的肯定是开发而不是测试。为什么开发人员能快速变化,测试人员不能呢,很多时候是因为设计问题,开发人员在写代码前都会设计很多东西来应对未来的变化。 而测试人员就我所知基本没什么设计,上来就写。 所以这就是问题所在了。

孙高飞 测试开发之路--QA 的能力 中提及了此贴 21 Nov 20:53

写得好,回想自己当初对qtp比较了解,自认为对测试界都拥入囊中的感觉,甚至想着自己已经在测势界的最高峰,然而并不是,自己几斤几两,能写几个正规点的代码,甚至想转管理,转产品,都是逃避

#52楼 @leoling 我也有同感 想当初 感觉qtp就是一切 现在回头看看 觉得自己当初太井底之蛙了。

#10楼 @seveniruby 菜鸟可以加吗?

#44楼 @quqing 我很赞同,我也是这么过来的,辗转反侧。

谢谢前辈的指点,看了这篇文章真的很开眼的,谢谢您。

PS:
”高手回答道:我当初就没给自己埋雷。“
哈哈哈,太搞笑了。

写得很好,在开始写自动化前都要先设计一下,该封装的就要封装...看了你的文章我突然想到了最近的自己,用例其实可以拿来封装的,结果没有封装,然后开发改了东西,我就改了很多重复的东西,刚才在地铁上写了一下,用例可以封装,今天上班就去把它封装了

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up