软件测试很简单么?

有个不是很好笑的笑话,说的是某某公司扫地的大妈都可以做软件测试,某某公司看门的大爷都可以做软件测试。导致现在还有很多人对测试的认知都停留在这个层面上。想当初,个人也靠着惠普的三大件(估计很多人都不知道,LR、QTP、QC),混了份不错的工作。伴随着对测试工作的不断深入(在这个行业混迹了 10 多年),越发感觉自己不懂的越来越多,测试,真的不简单。

1 外人眼中的测试

主要有两类观点,1 种是测试不就是点点么,没什么技术含量。还有 1 种是测试为什么要懂代码?如果代码能力很好,为什么不去做开发,还“赖”在测试圈?

先说说第一种:测试初期,确实大部分的工作都是在测试执行中度过的,这个时候点点点是我们工作的大部分内容。但是再往后呢,为什么要这么点,哪些可以点,哪些可以不点?有些人思考了,有些人没有,于是就产生了分层,测试思维的差距就出来了。然后有人会去想,为什么要手动点?多累啊,能不能自动点?能不能快速点?自动化就自然而然的出现了,然后带来更多地思考,带来更多的专项,也给测试带来了更多的可能。所以,作为测试人,不要看轻自己,外行人的评价并不能说明什么。很多人还觉得造车简单呢,不就一个发动机+4 个轮子的事么。

再说说第二点:测试人员的代码能力强了,就一定要转开发么?本人菜炒得还不错,那我就要放弃测试去做厨师么?测试多个能力伴身不香么?开发也不见得比测试好混啊。从薪资上来说,同等能力的测试不会比开发差太多。如果你用中等开发能力的人,来和基础测试的人做对比,那你不是在比较,是在耍流氓。

2 入门级的小陈

小陈作为刚入行的测试新人,每天除了执行老员工给的测试用例外,还会主动地去以下几件事,来帮助自己成长:

写测试用例:先看别人写的用例,然后通过自己的思考,也尝试去写测试用例,从用户的角度,从可用性的角度,从体验的角度去补充和完善更多的用例,同时培养独立思考的能力,慢慢培养自己测试思维。

记录 BUG:认真记录自己发现的 BUG,尽可能地去还原步骤,探查原因,多问问开发为什么会这样,是什么原因引起的。同时多看看同事记录的 BUG,想想他们是通过什么路径发现的这些 BUG。

做测试总结:定期做测试总结,看看自己学到了些什么新技能,还是对业务有了更深的了解,画画业务流程图、数据流向图、系统架构图等等。

学习测试技术:多混论坛,看看别人在玩什么,看看又出了哪些工具。哪些能帮助到自己。反正还年轻,最不缺的就是时间,折腾呗。得益于国内的各种破解氛围,基本上都主流的软件都能下,一步步跟着别人学习,并在自己测试的系统上去尝试,去验证,公司的项目就是好就地试验对象。

看看代码:有机会,就去看看开发写的代码,看不懂也没什么关系,多看,多问。现在系统性地学习某种开发语言的视频和博客不要太多。

就这样,小陈慢慢地变成了陈工。

3 不断升级的陈工

经过几年的磨练,小陈逐渐变成别人眼中的陈工,有自己的测试思维,能够更准确的定位 BUG 根因,和开发逐步变成了朋友。于是,小陈,哦, 是陈工,又开始思考了。

测试充分性:测试的时间总是被压缩,延期是不可能延期的,怎么办呢?有没有什么更好的测试策略,可以用更少的用例,覆盖更多的场景?能不能在测试前期做更多的准备,以便在测试执行的过程中能够更顺利些。

测试有效性:当下团队写的测试用例是否全是有效的呢?如何给臃肿的回归测试用例瘦身呢?没有发现 BUG 的用例,是无效用例?那些需要很复杂的步骤才能复现 BUG 是否是优质 BUG?测试是否覆盖全了呢?哪些没有测试到,依据是什么?

关于 BUG:都到测试阶段了,BUG 的修复成本太高,能不能早点发现 BUG 呢?经过这么长时间的测试积累了,BUG 一般会聚集在哪些功能点上?能不能提供一些典型的 BUG 给到开发,让他们多注意下,提升一下提测质量?BUG 的根因是什么,如何更好的避免这些 BUG 的出现?

关于自动化:测试金字塔提到的测试分层,应该如何落地到团队中去呢?每一层应该关注什么?重点测试什么?哪些可以让开发去执行验证。在什么场景下开展对应的自动化测试才是合理有效的?如何自动化产生真实的效益,而不是沦为 PPT 工程?

关于测试改进:当下团队的测试瓶颈点在哪里?如何去改善?业内有什么更流行的测试方法论或者测试技能,能够解决当下团队的问题?

(陈工想的这些问题,你都有答案么?)

4 眼界更高的老陈

人类一思考,上帝就会发笑。个人不思考,就无法进步,别用行动上的勤奋,来掩盖思维上的懒惰。“Hello word”你用不同的语言写了多少遍了?陈工通过自己的思考加上不断行动,逐步变成了对业务有一定认知的小高手。他的能力也不仅仅停留在测试的范围,他已经可以拉通好几个部门一起做事了,这叫“整合有限的资源,投入到无限的可能中去”。

质量内建:如果仅靠测试人员来保证产品质量,那一定会疲于奔命,发现 BUG 速度远跟不上写 BUG 的速度,有必要通过一定的手段来培养全员质量意识,让大家感知到质量不单单是测试人员的事,还是整个团队的事。质量需要端到端的去管理。

改进研发过程:有思想了,还要有工具,否则就是空想了。于是整个 DevOps 的研发过程就逐步去推进,需求实例化,代码分支管理、代码扫描、CICD、质量门禁、制品管理、生产监控等等一系列的内容,都需要老陈参与进去。

不断尝试新的技术:老陈穿梭于各种行业大会,观察更新更前沿的技术,看看哪些可以被团队吸收和落地,代码染色不错,可以帮助测试人员更好的确认被测试对象,测试覆盖率也可以,精准测试?混沌工程?契约测试?研发效能?。。。。。。

5 小结

老陈还在测试的道路上不断前进,各位看官,还觉得测试简单么,你们觉得老陈薪资几何?干一行爱一行。许多行业的入门要求都不高,但是要做得好,都不是简单的事。测试人员也不应当把自己局限在测试的职责范围内,不断扩充自己的边界,不好么?测试难不难,取决于你的自我要求,市场会给你真实的答案,没事多看看相关的招聘信息。

原文链接:https://mp.weixin.qq.com/s/SmApqbriZBsmo8HqXMvSDQ

本文文字及图片出自 InfoQ

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注