大家好，我是安酱。

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

 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～)讲到这里不得不跟大家分享我踩过的坑。

 4 

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

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

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

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

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

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

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

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

推荐阅读：

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

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

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