前言：20年毕业，毕业一年半，从事软件测试工作，第一家公司待了一年零一个月，日常工作主要是按照给定的用例编写自动化脚本，然后审核提交到脚本库，机器批量执行脚本，执行后失败的自动化用例根据日志查找原因，主要两个原因：一个是脚本有问题，需要维护脚本；第二个是发现bug，确定bug且提交bug（但是工作一年零一个月，一个bug也没找到过），对业务对其他的流程一窍不通。所以21年9月份辞职换工作，经熟人引荐和多轮面试进了一个线上教育公司，继续从事软件测试工作，在这里短短几个月学到了很多，相对来说是一个完整的测试流程，下面我按照时间点从前到后梳理一下

需求的产生

我们客服老师需要知道免费直播课程里面有没有购买产品意向的同学，从而决定是否开设这门课程，直播课程结束后手动查找聊天记录时间太慢，成本过高。希望产品经理可以在工作人员使用的后台提供一个较快的路径或者入口，可以在课程结束后很短的时间内拿到筛选好的有效的信息表格

需求的评审

需求评审前，产品经理汇编写好初步的需求文档，然后会在工作软件上拉个群，涉及的人员大概是产品经理、开发（开发的负责人和此需求的前后端开发人员）、测试（测试领导和负责此需求的测试小兵）。产品经理会根据自己的时间召开大家开一个会议——需求评审会议，主要是和大家同步且确定一下这个需求的实现（并不是产品经理设计出来的开发就能实现），产品经理和开发商讨具体实现为什么样子的时候，我们测试也需要清楚我们测试的范围或者是偏重点（偏重测试后台还是偏重测试前台还是都需要），大部分一次需求评审会议就能确定下来具体的实现方案，有时候需要再次的会议来商讨确定实现方案。

用例的编写

用例的编写在需求评审会议结束之后就可以找时间开始编写了，编写的主要依据就是产品经理提供的需求文档和自身对需求的理解，编写用例切勿钻牛角尖，不然可能越写越偏执；一般自己公司的测试部门都有统一的的编写用例的规范，根据用例编写规范来编写测试用例，省时省力而且方便大家阅读，这是我第一次编写测试用例（我们用的是xmind编写用例），真的叫一个惨不忍睹。
刚开始组长告诉我这是一个小需求，大概写几十条用例就差不多了，我写了几十条之后让组长帮我把一下关，组长看完我的用例之后沉默了，然后当天晚上九点多的时候开始做我旁边给我讲一个需求怎么编写用例，从哪些点出发，她平时怎么写需求用例的，如何覆盖的更全面且不冗余，组长对我很是好了，一个很好的小姐姐；我然后按照组长的编写方法开始写我的需求测试用例，痛苦与煎熬中写完了这个需求的测试用例，最后也就写了两百来条，但是感觉自己空了，然后让组长再帮我瞅了一眼，组长看完之后说没啥问题；
用例评审下一节讲，用例评审完之后，我们测试组的大领导——测试经理（一个大姐姐），对我的测试用例那是非常的失望，我的工位刚好和我们测试经理的工位挨着坐，然后当天晚上我们测试经理就给我整了一个测试用例的编写模板，然后给我开始讲我的整个测试用例有哪些问题，主要是**嫌我的测试用例写的太冗余了，测试用例写的废话太多，然后没人愿意看，浪费大家（测试领导、产品经理&开发）的时间，**然后亲自动手给我删枝剪叶了一部分，另一部分让我按照她规定的来，我当天晚上马不停蹄的赶，第二天弄好之后给测试经理看，领导看了觉得可能还不满意，但是可能觉得我第一次写然后就放过我了，但是拉了一个小群（测试经理、前面的小组长、我），目的是：每次用例评审之前需要她们先看一下，通过了才能去开评审会议（可能觉得我第一次的用例太丢脸了，凭我一己之力拉低了测试组的整体水平，太尬了）
大家要引以为戒，在新公司开始工作前需要注意熟悉这些规范，尤其是新同学，本身就没编写测试用例的经验，不要靠着自己的臆想来编写，不然最后可能就和我一样。用例编写没有什么捷径，大家接的需求或者项目多了，写的多了自然就熟悉了，我们不要怕丢人，但是不能一直丢人，一切都会好的。

用例的评审

测试用例编写完成之后就准备开始用例的评审，此处我们需要注意的是，预约会议之前和前后端的开发还有产品经理（需要参加会议的人）预约好时间，然后再发会议通知，不要愣头青直接发会议通知，然后开发大佬或者产品经理任何一个人不能参见会议，那你就要取消重新预约了，这样的话就等于浪费了大家的一部分时间，因为大家都很忙，时间都排的比较满，并不是所有人都在等我们
用例评审的时候——也就是你一个人开始表演的时候，开发和产品经理时不时插几句话；我的第一次测试用例写的非常之烂，烂到我们测试经理差点不知道怎么说，幸亏测试经理也是当了很久的领导，我这样的可能也见过，然后就强忍着开完会，然后会后给我指导测试用例（见上一小节）

需求的排期

需求的排期就是测试预计需要花费的时间，这个大家看起来可能觉得挺简单，随便写呗，想摸鱼的话，两天能测完的排期写两天半或者三天，摸鱼半天或者一天；大家这么想就过于简单了，因为排期合不合理，大家都能看到，开发拢共开发三天，你测试两天，怕是说不过去吧；要是无惧他人的眼光，你可以这么干；但是，合理的测试排期和你的绩效直接挂钩，也就是和钱挂钩，大领导会看各个需求和项目的排期，不合理的排期可能直接降低你的绩效或者找你谈话，裁员的话也是优先考虑你；但是并不是让你加班加点的测试，合理正常的安排即可。

功能的测试

功能提测之前开发会发邮件通知到你，收到邮件之后记得回复一下邮件，象征性礼貌，主要是让领导知道你在干活，知道你干的什么活。
这部分呢主要就是按照你编写的测试用例来执行，执行完一条用例，在后面做一个标记，然后遇到问题直接和开发沟通，开发确认是问题直接提bug；开发认为不是的时候，你需要在需求文档中找到证据来说服开发，如果还不行就找产品，时间宝贵，也不要识图做无畏的抗争，也没必要，因为你说的真的真的不算，等你说一句话有人听的时候在考虑。

功能的提交验收（内网-预发-线上）

我的第一次功能验收只有内网和线上，没有预发这个环节，因为我这个功能不适合在预发环境验证；内网验收没有任何问题，然后重要的一个点：上线的时候可能需要测试部署预发环境或者是线上环境，需要做一些操作，虽说不难，但是你不知道的时候就是一脸懵逼，就需要请教其他同事怎么操作，牢牢记住这些操作步骤；
当时我负责的需求线上验收的时候出了一些小问题，然后产品经理和开发沟通，开发改代码，然后测试内网测试，没有问题后重新在部署线上环境，然后线上回归；循环往复这个步骤，循环的越多，说明测试的质量越差。
需求提交验收的时候，需要发送邮件，一般验收邮件也有模板，按照模板来编写，主送人当然是产品经理了，最好是提前准备一些测试数据，这样方便验收，不要等着产品经理给你发消息让你造数据你才开始，这样你会很累，还会不开心，你提前准备该准备的数据，他需要什么你直接给他，提高自己的效率，不要让自己手忙脚乱，一切从自身考虑，这些能力的提升都会为你节约时间，也会让你有时间思考更多的东西