测试与开发的爱恨情仇

原创
2020/11/24 09:10
阅读数 4K

大家好,我是安酱。

今天我们用一个小故事来聊一聊测试与开发之间的那些事儿。


 1 

小美到公司的时候已经九点半了,但是偌大的办公室室却还没几个人。早来的几位同事还都是跟自己同属一个组的QA同学。

互联网黑话:

QA:QUALITY ASSURANCE质量保障工程师,俗称测试。

RD:Research & Develop研发工程师,俗称开发。

「早呀各位!」小美热情的对身边的同事打起了招呼。小美对自己目前的工作还是挺满意的,她不太喜欢编程,但是又热爱着互联网行业,所以软件测试对于她来说是两全其美的岗位。

「不早了,都快十点啦。不过那群RD估计都还没出门呢。」一位同事抬起头打趣道,目光还朝旁边的区域瞅了一眼,那儿还是空荡荡的。

小美耸耸肩,努了努嘴,似乎在表示这不是很正常的情况嘛。随后从背包中掏出笔记本,开始整理一下今天要测试的需求。

过了一会,小美旁边那片区域慢慢的来人了,整个办公室开始变得嘈杂起来。

「卧槽,我昨晚两点才下班!本来十点就打算走了,没想到一个JIRA就过来了,跑都没跑掉!」

「别说了,我这还有几个历史遗留bug,你这么有空来帮我看看吧。」

「别别,那还是算了。」两位RD互相吐槽了一番,也没继续接茬了。办公室瞬间安静了下来。

 2 

众所周知,测试和开发之间始终保持着迷一样的关系,他们之间的联系最为紧密但又互相看不惯。作为质量保障人员,QA的工作就是发现并提交bug;而RD自然是对bug敬而远之。

小美不一会就开始测试今天的第一个需求。这是一个需要客户端及服务端联调的需求。经过了多次测试,她发现这是客户端稳定可复现的bug,问题就在于客户端并没有触发相应的接口请求。

她首先通过公司内部的通讯工具小窗了一下客户端开发的RD,将测试结果告知于他。同时,她熟练的打开JIRA平台,迅速的将这次测试的信息填上并提交,包括测试版本,问题描述,处理人,修复时间等。

等她搞定了这些操作后,发现她给RD同学发的那条信息还处于未读状态。她扭头看了下RD的位置,发现他正在位置上,皱着眉头正盯着屏幕。

算了,还是去找他吧。犹豫了片刻,小美还是决定起身去当面把这个问题描述清楚。

「你昨天提的MR有问题呀,那个接口请求就没有触发。我试过很多次了,抓包也没抓到。服务端是没问题的。」

「不可能吧,我自测都没问题的。我测的时候肯定抓到了,没道理的。反正在我这是好的。不信你看嘛!」

小美早就意料到会是这么个回复,但是脸上并没有显露出来。仍然一脸恳切的望着RD同学,看着他紧张的演示。

小美在入职之前其实并不理解QA是做什么的,听人说就是用鼠标在电脑上点点点,测测有没有响应什么,天天就是干重复的工作。但是也听说QA对于软件的更新换代至关重要。

只不过她现在也没空想这些问题了,专心的看着RD同学的演示。不一会儿,抓包工具还真弹出了一条网络包。

得,又是这样。在小美短暂的测试生涯里,经常出现这种所谓「无法稳定复现」的bug,有苦说不出。

小美觉得自己还是挺喜欢QA这个岗位的,入职以后才真正体会到找到Bug时的愉悦,但也偶尔能感受到开发提刀的冲动。

这不,RD同学经过一系列的操作,成功的证明了自己,的确在他那儿是没问题的。他扭头盯着小美,嘴角上扬,抖了下眉头。

「行吧,那可能是本地设置或者线上环境的问题。等我确认下再来找你。」小美也没啥办法,只能先去确认下两边的版本或环境有没有差异。

这估计是小美的工作日常了,毕竟很多bug的复现和定位都没那么容易。而事实上测试小姐姐每天除了和开发小哥哥讲道理「chao jia」之外,他们每天的工作内容主要是什么呢?

 3 

这里我们便去采访了下小姐姐,用她的亲身经验来告诉大家,在一个具体的测试项目里面,测试需要做的工作和流程有哪些。

大多数没有真正接触过软件测试的同学都有一个误区,觉得测试就只是点点点。那测试小姐姐就要问了,你知道为啥需要点点点?

为什么你看来这么简单的点点点还需要大量的测试人员去实现?你知道一个软件版本的发布没有测试人员的点点点,它的风险有多大嘛?

那在一个测试项目中测试人员需要做些什么呢?可以简单归纳为以下几点:

- 测试计划和方案
- 编写测试用例
- 搭建测试环境
- 执行测试用例
- 提交
Bug
- 管理跟踪bug
- 复测
- 稳定性测试、压力测试等
- 编写测试报告

以上步骤并不是固定的,可能会根据不同的公司不同的产品和性质有变化,一些较为成熟的测试项目大体上是一致的,具体的测试内容会不同。

测试计划和方案这里主要是测试负责人需要做的事情啦,包括人员安排、任务划分、进度安排、文档要求、测试工具等等的。(咱也不知道,咱也不敢问呀~)

编写测试用例,是测试人员的基本功也是硬实力呀,优秀的测试用例,不仅可以提高测试的质量,还能保证测试更加全面,尽可能地发现软件存在的问题和风险。

需要参考需求文档、设计文档等等,写好之后需要评审。至于如何写好测试用例,这里可以大作文章了,就先不铺开讲了。

搭建测试环境正所谓磨刀不误砍柴工,为了保证测试的顺利进行,那就要提前做好测试的准备工作。

这一步的目的是要保证测试环境的独立,确保测试环境稳定和版本的正确~万事具备,那就开始测试啦~

执行测试用例(有事找开发,没事找bug~)讲到这里不得不跟大家分享我踩过的坑。

 

许多人在执行测试用例上习惯按照顺序依次往下测,根本不管测试用例的优先级,实际上这样是不对的。一般应该先做冒烟测试,这是最为基本的,冒烟都没过,那些低优先级的也没必要继续测了。冒烟通过后,再依次按照高-中-低优先级依次执行,这是最为高效的测试方式。

管理跟踪Bug,测试过程中,难免会找出一个一个又一个的bug, 当遇到一个bug,首先应该确认并非因为自己测试方式或者操作不对造成的(别问我怎么知道的,开发小哥的眼神会让你明白的~),其次要确认是否满足需求文档中的要求。

如果确实不满足需求,那你可以理直气壮给开发小哥哥提bug, 如果需求文档中并没有涉及到,那就跟开发小哥一起评估,还是不能达成统一,那可能就需要找上级或者产品经理一起评估决定。

开发小哥按照你提交的bug记录进行版本的修复和更新,并给你最新的版本,你需要进行bug验证,验证通过后不要忘记更新bug的状态(并顺带夸奖一下开发小哥,毕竟他开心了,你也好意思督促他继续改Bug呀~);要是验证不通过,重新挂起(不要管开发小哥一个劲说着:在我这明明就成功的呀~)。

除此之外还需要进行稳定性测试、压力测试等,需要利用一些自动化测试工具完成,或者自己写一些测试脚本,分析测试数据,提出优化方案或存在的风险。

编写测试报告在不断的发现Bug-修改Bug-复测Bug- 关闭Bug,直到软件达到测试发布的要求,没有重大Bug的存在,那就需要整理测试报告,用客观和数据的方式总结和评估测试的情况。待测试报告通过评审后,就可以正式发布软件啦~

综上,测试也是需要全面发展的,比如,要有良好的沟通能力(避免跟开发小哥讲道理的时候不会吵起来~);要具备专业的技术能力,掌握测试技术更好的执行测试任务;要有定位分析能力,发现Bug可以分析问题进行准确定位,帮助开发小哥更好地修复Bug



作者简介:我是安酱,一个稀里糊涂地进了大厂的业余码农。讲解全栈技术,分享菜鸡的打怪升级之路。关注我,一起进阶!

推荐阅读:

干货| 天天念叨的「计算机基础」就只是计算机网络和操作系统吗?

超干货 | 这些概念可是操作系统的灵魂,你弄懂了几个?

「添加我为好友,拉你加入讨论群,一起努力进阶!」

本文分享自微信公众号 - 业余码农(Amateur_coder)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
1
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
1
分享
返回顶部
顶部