大家好，我是安江。今天我们用一个小故事来说说测试和开发之间的事情。1小美到公司的时候已经九点半了，但是偌大的办公室里并没有多少人。先来的同事都是QA同学，和我是同组的。网络行话：QA：QUALITYASSURANCE质量保证工程师，俗称测试。RD：Research&Development研发工程师，俗称开发。“大家早上好！”小梅热情地和同事们打招呼。小梅对她现在的工作很满意。她不太喜欢编程，但又热爱互联网行业，所以软件测试对她来说是两全其美。“时间不早了，都快十点了。不过那些RD估计还没出去。”一个同事抬起头打趣的看了一眼附近，依旧是空无一人的区域。小美耸了耸肩，抿了抿唇，似乎在表示这不是正常情况。然后从背包里拿出笔记本开始整理今天要考的需求。过了一会，小美旁边的区域慢慢的来了人，整个办公室都变得嘈杂起来。“靠，我昨晚两点才下班！本来打算十点走的，没想到一个jira过来了，我没跑！”“别说了，我还有几个历史遗留的bug，有空过来帮我看看。”“别做了，算了。”两个RD互相吐槽，也没继续聊下去。办公室里一时安静了下来。2众所周知，测试和开发之间总是有着迷人的关系。他们之间的关系最亲密，但彼此并不熟悉。作为质量保证人员，QA的工作就是发现并提交bug；RD自然会与bug保持一定的距离。小美开始测试今天的第一个需求。这是需要客户端和服务端联调的需求。经过多次测试，她发现这是一个稳定且可重现的客户端bug。问题是客户端没有触发相应的接口请求。她先是通过公司内部通讯工具的小窗口查看了客户开发的RD，并将测试结果告知了他。与此同时，她熟练地打开了JIRA平台，快速填写并提交了测试信息，包括测试版本、问题描述、处理者、修复时间等。完成这些操作后，她发现她发给的消息RD仍然未读。她转头看向RD的位置，发现他就在那里，皱着眉头盯着屏幕。算了，我们去找他吧。犹豫片刻，小美还是决定亲自起身把问题描述清楚。“你昨天说的MR有问题，没有触发接口请求，我试了很多次，都没有抓到包，服务器没问题。”“不可能，我自测没有问题的。肯定是我测试的时候抓到的，没有意义。反正对我有好处。不信你看看！”小美早就料到会有这样的回答，只是脸上没有表现出来。依旧认真的看着RD同学，看着他紧张的示范。小梅在入职之前并不十分了解QA是做什么的。我听人说，她只是用鼠标在电脑上点了一下，看看有没有反应。她每天只是做着重复的工作。但我也听说QA对软件更新至关重要。只是她现在没有时间去想这些问题，专心的看着RD的演示。过了一会儿，抓包工具果然弹出了一个网络包。是的，又是这样。在小梅短暂的测试生涯中，经常出现这种所谓“无法稳定复现”的bug，说不出的痛苦。小美觉得自己还是很喜欢QA这个岗位的。入职后，她才真正体会到找bug的快乐，但偶尔也会有想开发一把刀的冲动。这不，RD同学已经通过一系列的操作成功证明了自己，对他来说确实是没问题的。他转头盯着小美，嘴角上扬，眉头挑了挑。“好的，可能是本地设置的问题，也可能是网络环境的问题，我确认后再给你。”小美只好先确认一下双方的版本或环境是否有差异。这大概就是小梅的日常工作了。毕竟，很多bug的重现和定位并不是那么容易的。其实，除了和开发人员“炒家”讲道理，身为测试人员的小姐姐，每天的主要工作是什么？3这里我们去采访了小姐姐，用她的亲身经历告诉大家，在一个具体的测试项目中，需要测试的工作和流程有哪些。大多数没有真正接触过软件测试的同学都有一个误区，认为测试就是一点点。那么测试小姐姐就要问了，你知道为什么需要圆点吗？为什么需要很多测试人员来实现这么简单的点？您知道软件版本是在没有测试人员的情况下发布的。风险有多大？测试人员在测试项目中需要做什么？可以简单概括为：-测试计划和方案-编写测试用例-搭建测试环境-执行测试用例-提交bug-管理跟踪bug-复测-稳定性测试、压力测试等-编写测试报告以上步骤不是固定的，可能会根据不同公司的不同产品和属性而有所不同。一些比较成熟的测试项目大体上是一致的。具体测试内容会有所不同。这里的测试计划和计划主要是测试负责人需要做的，包括人员安排、任务分工、进度安排、文档要求、测试工具等。（我们不知道，也不敢问~）写测试用例是测试人员的基本功和硬实力。优秀的测试用例不仅可以提高测试质量，还可以保证测试更加全面。识别软件问题和风险。需要参考需求文档、设计文档等，写完之后需要审核。至于如何写出好的测试用例，大家可以在这里大做文章，先不说了。搭建测试环境，正所谓磨刀不误砍柴工。为了保证考试的顺利进行，需要提前做好考试准备工作。这一步的目的是保证测试环境的独立性，保证测试环境稳定，版本正确~万事俱备，接下来开始测试~执行测试用例（有事找开发，没事就找bug~）在这里不得不和大家分享一下我踩过的坑。4很多人习惯在测试用例的执行中按顺序往下测试，而不考虑测试用例的优先级。其实，这是错误的。一般先做冒烟测试，这是最基本的。如果没有冒烟，就没有必要继续测试那些优先级低的。烟雾通过后，会按照高-中-低优先级依次执行。这是最有效的测试方法。管理和跟踪错误。在测试过程中，难免会发现一个又一个的bug。遇到bug首先要确认不是自己的测试方法或操作不当造成的（别问我怎么知道的，开发小弟的眼光会让你明白的~），其次确认需求是否符合要求在需求文档中得到满足。如果真的不符合要求，那你就可以放心的向开发者提bug了。如果需求文档中没有涵盖，则与开发人员一起评估。如果还是不能达成共识，可能需要一起找你的上级或者产品经理。评价决定。开发者会根据您提交的bug记录修复更新版本，给您最新的版本。您需要验证错误。验证通过后别忘了更新bug的状态（给开发者点个赞，毕竟他开心了，你还好意思催他继续修bug~）；验证不通过，再挂断（别管开发哥口口声声说：明明是我成功了~）。此外，还需要进行稳定性测试、压力测试等，需要使用一些自动化测试工具来完成，或者自己编写一些测试脚本，分析测试数据，提出优化方案或存在的风险。编写测试报告，不断发现bug-修改bug-重测bug-关闭bug，直到软件满足测试发布要求。在没有重大bug的情况下，需要以客观、数据的方式整理测试报告，对测试进行总结和评估。测试报告审核通过后，软件就可以正式发布了~综上所述，测试还需要全面的开发，比如良好的沟通能力（避免和开发小哥讲道理的时候吵架~）；具备专业技术能力，掌握检测技术，更好地完成检测任务；具备定位分析能力，发现bug，分析问题并准确定位，帮助开发者更好的修复bug。作者简介：我是暗江，一个迷迷糊糊钻进大厂的业余码农。讲解全栈技术，分享菜鸡的打怪升级之道。本文转载自微信公众号“业余码农”，可通过以下二维码关注。转载本文请联系业余码农公众号。
