大厂测试流程是怎么样的？

测试积点老人

对于确定要转行的同学来说，在了解了软件行业的前景以及测试的基本日常工作之后，接下来首先要学习的就是测试流程了。


　　从一个版本的需求评审开始到上线结束，中间贯穿的整个测试流程其实就决定了一个软件测试人员日常工作是什么样子的。


　　除此之外，对于社招来说，一般你去面试，面试官首先喜欢问的第一个问题就是描述一下你上一家公司测试流程是什么样子的。


　　这个问题主要考察面试者是否对测试整体有一个清晰的认知以及是否具备主动推进测试流程的能力。


　　推进测试流程以及良好的交流沟通能力大概是除技术能力之外最重要的软实力了。


　　而且，对于管理者来说，除了给下级部署测试任务之外，很重要的日常就是去协调各个系统资源，宏观调控，推进整体进度。


　　对于不同公司来说，测试流程其实大同小异。当然，也不止一次的说过，对于一些创业公司来说，其实是没有测试流程的。


　　不需要查日志，也不校验数据库，甚至都不需要写测试用例，也不区分测试环境和生产环境。这样下来，几乎没什么成长，因此，最不推荐大家去这种公司。


　　接下来聊聊我目前待的这家公司的测试流程，当然主要是指常规需求的功能测试，自动化和性能测试不在日常版本排期之内，之后再谈。先介绍一下公司的整体情况吧。


　　公司规模大概一千多人，测试团队一百多人。世界排名二十左右，比不了BAT，字节一线互联网公司，但也算大公司了，基本上都知道，具体就不透露了。这家算是我待的几家公司测试流程最为规范的。


　　基本上和很多公司一样，每两周迭代一个版本，一个月两次。每个月月底版本结束之后，产品经理会将下个月的需求列表发给对应系统的开发经理和测试经理。


　　然后leader将需求分给对应开发和测试人员，一个版本就开始了。当然分配任务的时候，也会空出一部分人力做自动化测试和性能测试。具体可以参考下面流程。


　　1.需求评审。主要参与人员为负责这个需求对应系统和它的上下游系统的开发和测试，以及提出这个需求的产品经理。


　　2.产品经理需求排期。每月两个版本，排期两次。


　　3.测试经理分配任务。以版本为单位分配测试任务，一次排一个版本或者两个版本任务。


　　4.编写测试用例，用例评审。参与用例评审人员为这个需求所涉及系统的开发测试，以及产品经理，跟需求评审人员差不多。会议目的主要看用例场景是否有遗漏，需求是否理解错误。稍微大些的项目一般使用xmind梳理场景，再用excel细化每条用例。


　　5.录入track系统。记录测试需求以及信息的系统，主要录入提测时间，案例条数，是否冒烟通过等信息，也便于统计工作量。


　　6.开发提测，提测模版。开发部署代码到测试环境，然后发邮件给测试，邮件包含测试信息比如url，查找日志关键字，主要测试点等。


　　7.测试，提bug，复测，移动卡片。公司使用自研系统管理测试流程，拖动卡片来反馈测试进度，类似于禅道，jira之类的。


　　8.发邮件UAT验证。测试验证完之后发邮件给业务以及产品经理，验证功能是否符合需求，没问题需要回复邮件通过，时间一般为上线前两天。


　　9.发系统测试报告，代码封版。一般为上线前一天，测试没问题，代码封版，发系统测试报告，不允许再修改代码。如果封版之后发现有问题，需要发邮件给运维，申请解封。之后重新发送系统测试报告。


　　10.回归测试，发回归测试报告。一般为上线当天，封版之后对之前测试需求进行回归测试，防止开发合错代码以及漏发服务之类的，回归测试没问题发回归测试报告。


　　11.上线。时间一般为版本日当天晚上12点之后，此时对用户影响最小，有些项目采取灰度发布方式的话会早一些，一般九点左右。


　　12.生产验证。上线之后进行生产验证，一般为测试留守进行验证，或者开发自己验，不太重要的项目第二天上班之后进行验证。


　　以上测试流程，就是一个相对比较规范的流程了，其中每个环节都要严格遵守，防止万一出问题，追责时，如果没按照规范来就要背锅了。