今天我们用一个小故事（文中人物已化名）来聊一聊测试与开发之间的那些事儿吧。
1
小美（化名）到公司的时候已经九点半了，但是偌大的办公室室却还没几个人。早来的几位同事还都是跟自己同属一个组的 QA 同学。
互联网黑话：
QA： QUALITY ASSURANCE 质量保障工程师，俗称测试。
RD： Research & Develop 研发工程师，俗称开发。
「早呀各位！」小美热情的对身边的同事打起了招呼。小美对自己目前的工作还是挺满意的，她不太喜欢编程，但是又热爱着互联网行业，所以软件测试对于她来说是两全其美的岗位。
「不早了，都快十点啦。不过那群 RD 估计都还没出门呢。」一位同事抬起头打趣道，目光还朝旁边的区域瞅了一眼，那儿还是空荡荡的。
小美耸耸肩，努了努嘴，似乎在表示这不是很正常的情况嘛。随后从背包中掏出笔记本，开始整理一下今天要测试的需求。
过了一会，小美旁边那片区域慢慢的来人了，整个办公室开始变得嘈杂起来。
「卧槽，我昨晚两点才下班！本来十点就打算走了，没想到一个 JIRA 就过来了，跑都没跑掉！」
「别说了，我这还有几个历史遗留 bug ，你这么有空来帮我看看吧。」
「别别，那还是算了。」两位 RD 互相吐槽了一番，也没继续接茬了。办公室瞬间安静了下来。
2
QAbugRDbug
小美不一会就开始测试今天的第一个需求。这是一个需要客户端及服务端联调的需求。经过了多次测试，她发现这是客户端稳定可复现的 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 , 如果需求文档中并没有涉及到，那就跟开发小哥一起评估，还是不能达成统一，那可能就需要找上级或者产品经理一起评估决定。
bugbugbugBug
除此之外还 需要进行稳定性测试、压力测试等，需要利用一些自动化测试工具完成，或者自己写一些测试脚本，分析测试数据，提出优化方案或存在的风险。
编写测试报告在不断的 发现 Bug -修改 Bug -复测 Bug - 关闭 Bug ，直到软件达到测试发布的要求 ，没有重大 Bug 的存在，那就需要整理 测试报告 ，用客观和数据的方式总结和评估测试的情况。待测试报告通过评审后，就可以正式发布软件啦～
综上，测试也是需要全面发展的，比如，要有 良好的沟通能力 （避免跟开发小哥讲道理的时候不会吵起来～）；要具备 专业的技术能力 ，掌握测试技术更好的执行测试任务；要有 定位分析能力 ，发现 Bug 可以分析问题进行准确定位，帮助开发小哥更好地修复 Bug 。
最后|资源分享
下面这些是我的收集和整理的资料，对于开始学习【软件测试】或是技能进阶的朋友来说，绝对是最全面的教程仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你
微信公众号关注
程序媛木子，微信公众号测试资源将免费获取，技术交流群（644956177）群里有技术大佬的各种技术交流和经验之谈。
