我的读者好像刚接触测试不久/准备去面试的居多，然后大家最近问的比较多的一个话题就是大厂的工作流程，都比较好奇，整个流程是怎么操作的。
我也不多 BB 了，那下面就跟随暖男的脚步，走进大厂测试工作流程吧。
你刚去面试的时候，面试官就会问到：你能不能介绍一下你们公司的一个工作流程，首先这个问题就能够很好的反映你是否真的做过测试，你是不是一个测试小白，刚毕业或者刚转行。然后每个阶段的输出有哪些？
很多公司之前，对于测试。还有很多东西没有规范，他其实想招一个人，把产品和开发还有运维，这三个角色很多东西都规范起来，所以他需要招一个比较规范的测试，不管是文档方面，还有很多会议方面。
比如说完整规范的工作流程
首先会召开需求分析会议，工作流程一般的一周或者迭代，那参加人员必须有产品开发测试到位，探讨需求。这个会议开完之后，那肯定就会有一些输出。
每个会议，都要有输出有价值。
并不是说，你每天开早会，讨论一些没有什么具体意义的事。今天做什么明天要做什么，是不是像这种会开着很无聊？所以每开一个会，至少要得出一些东西出来。
比如说像我们需求分析会议，那就会把数据库表设计，接口设计，需求文档,提测时间，原型图。开完会，这些就要给到相应的人员。
第二个，开发就要去排期了对吧，然后编写计划
第三个，就是我们要去写用例了，用例一定要评审，有评审就会有修改，修改之后再整理，最终的用例版本。
这个功能测试用例，评审之后，它是自动化测试用例的参考，你公司以后要做自动化，自动化用例就来自于评审之后的最终用例版本，这个很重要。
因为公司可能现在没有做自动化，觉得用例评不评审都无所谓，你的组长让你写用例，呃，你就划划水，然后不写也没有关系，当然很多小公司是这样子，那么你到稍微大一点的公司，规范一点的公司，这个用例评审非常重要。不仅仅是自动化用例的参考，很多开发需要拿到这个用例去自测。
开发他不会去想怎么去测好，所以他就拿现成的用例去测试。
然后就是提测，我们去 Jenkins 部署构建，然后还要进行一个预测（冒烟测试）如果测试不通过，打回。
测试过程中，提交 bug，跟踪 bug，进行回归测试直至不存在严重 bug,满足用户需求，
测试完后编写测试报告;
产品发布上线后，关注项目是否正常运行，要进行常规的维护性测试。回归测试
输出:上线记录（新功能，修复了 xxbug) ，上线的新功能
上线了哪些新功能，修改了哪些 Bug 也都是我们需要去记录的。
虽然还有很多小细节没有完善，还算是比较规范的，但是如果问到你公司的流程，每个阶段有哪些输出，你按照我这样去说，绝对是没有问题的，套用你之前的项目就行了。
我们看一个软件测试流程思维导图，一凡就用自己接触的小米系的软件测试流程举例了，这也基本上是互联网大厂的软件测试流程了，可能细节有出入，但是绝对大同小异。
我问了下字节，多多，腾讯的朋友出入不大，所以还是具有代表性。
看完流程我们就一个个点的去看看每个环节干了些啥，我们测试同学在这个环节需要做啥，以及在每个环节的职能。
新功能:首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点;
输出:数据库表设计;接口设计，需求文档,提测时间，原型图
然后开发就排期进行开发，测试主管开始编写测试计划，对我们进行任务分配。
输出:测试计划，整理测试要点
我们参考需求规格说明书及原型图编写测试用例，写完之后会进行用例评审，有评审修改的就修改整理形成最终的用例版本（自动化用例的参考，开发拿到用例自测);
输出:测试用例
提测（测试去 Jenkins 部署构建)∶开发人员版本编译完成后，我们会先进行预测，主要对主新功能业务进行测试，新接口测试。如果主 (新）业务流程不通过，直接返回给开发进行修改。预测通过，依据测试用例进行系统测试。
测试过程中，提交 bug，跟踪 bug，进行回归测试直至不存在严重 bug,满足用户需求，
输出:测试完后编写测试报告
产品发布上线后，关注项目是否正常运行，要进行常规的维护性测试。回归测试
输出:上线记录 (新功能，修复了 xxbug) ，上线的新功能
关注一凡这个博主是-----↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
1、点赞，收藏。防止以后找不到，想看的时候，在自己主页就能找到了，很方便;
2、关注我。让我们成为长期关系，下一个内容会分享更多的硬核干货;
3、文章学习资源，均可以免费分享。
不要只做收藏从未停止，行动从未开始的人，很多事情，做着做着就无师自通了。如果在做的过程中还能稍微加点思考，稍微看一些别人的经验和做法，成长会更快，效果也会更好！加油吧，测试人！路就在脚下，成功就在明天！
我是一凡，用心输出有价值的内容！
创作不易，不想被白嫖，各位的「点赞」就是一凡创作的最大动力，我们下篇文章见！
