项目流程：
一、面试提问（h模型）
1、你说下你们公司测试流程？
2、给你一个需求你会怎么做?
3、你讲下你的工作？
4、谈谈你是如何去测试？

答案：h模型

要求第一人称来写
讲解简化文字流程：
内容如下：
拿到需求------需求分析----编写测试计划—编写测试用例-----用例评审----导入用例管理工具—搭建环境–开发提交代码包–部署环境—冒烟测试----sit系统集成测试----提交bug—开发修改bug—进行sit2测试—冒烟-测试–
----以此类推到0bug，用例100%，输出测试报告（sit测试测完）----验收测试（uat测试）-----测试通过------封装版本----上线----线上测试------测试通过----测试完成
备注：
（1）写用例
（2）搭建环境
（3）测试报告
（4）测试计划

升级版本
拿到需求------需求分析----编写测试计划—编写测试用例-----用例评审----导入用例管理工具—搭建环境–开发提交代码包（开发合并分支）–jnnkins构建（部署），获取到代码包====
部署环境—冒烟测试----sit系统集成测试----提交bug—开发修改bug–jenkins构建（部署），获取到最新代码包—冒烟-测试–
----以此类推到0bug，用例100%，输出测试报告（ 表示sit测试完成）----验收测试（uat测试）-----测试通过------封装版本----上线----线上测试------测试通过----测试完成

讲解详细文字流程：
内容如下：
拿到一个需求（SRS）软件需求规格说明书
了解概要设计（测试文档）
了解详细设计（测试文档）
需求评审会议（测试，开发，产品）产品主持会议
编写测试计划（测试经理，测试组长，我）
根据测试计划，分配工作
编写测试用例 测试
用例评审（两种评审方式：1、组内评审 ：测试，开发，产品，交叉评审：测试同事之间评审）
用例通过，导入到用例管理工具中（禅道）
用例分配给对应的负责
部署环境（测试环境（测试），开发环境，线上环境）
部署：运维，测试经理，测试组长，自己
开发提测，也是提交代码包（达到准入的要求）
拿到代码包部署到环境中
冒烟测试（重点）
冒烟测试（称为版本验证测试，提交测试）是指：对新版本的主要功能，基本功能进行测试，如果通过，那么冒烟测试通过，如果冒烟识失败，那么就把版本打回给开发进行修改，直到冒烟通过；
每一次开发提交新版本，测试都需要在测试环境中进行冒烟测试；
冒烟测试通过以后才能进入sit测试（系统集成测试）；
sit测试（系统集成测试） 一般一个项目有三次，项目周期长可能4次，更多；
第一次sit测试是全量测试（所有编写的用例都要进行测试）；
测试小结：包括用例数，bug数，新增用例数等 ；
开发修改bug
第二sit测试
冒烟测试 ，sit2测试，（回归测试）
回归测试：是系统维护阶段进行的验证测试
区别：测试的阶段不同
冒烟测试是在版本提交时进行的第一个测试，回归测试是在维护阶段的测试；
用例来源：
1、冒烟测试的用例
2、验证上一个版本提交的bug用例；
3、测试和bug相关联的模块的用例
4、你认为可疑的测试用例或者是测试场景
5、测试补充的测试用例或测试场景
第二次测试小结
有bug转给开发
开发修改bug；
提交第三次版本
sit3测试
冒烟测试
测试用例
达到准出要求；（0bug，用例100%用例执行）
输出测试报告 -----表示sit测试完成

uat 验收测试 （uat环境） --通过uat通过
系统版本打包（封板：是封装版本）

上线
上线成功 ，上线失败，版本回退，继续用之前的版本
回退的版本要重新让开发修改，测试 ，上线

上线前会准备线上测试数据，上线后我们在线上测试下新版本；
如果线上没问题，上线完成，
如果有bug，首先分析bug对项目的影响，影响大，退回版本；影响小，开发和测试分析并上报，建议下一个版本修改。

补充点：
1.1,接口测试是在UI界面未形成之前。(在开发输出自测报告)也就是在功能测试前或同时
1.2包括补充的用例
1.3 UAT测试在sit测试通过并输出测试报告
1.4封装版本（简称封板）上线
1.5线上也准备账号，在线上进行测试（也可能业务测试，测试人员测，如有问题，退回版本，继续用上一个版本，数据回滚。）
1.6性能测试在什么时候？ （功能测试结束，才能做性能测试）
1.7自动化测试在什么时候？（在功能测试完成后，主要用来回归测试，节省时间）

(三)那就是我们现在的敏捷开发模式、迭代测试流程
缩短流程的讲解(一个需求一周开发，一周测试，在上线)
（四）工作中的流程，根据公司结构来讲
大型公司：（1）都是按照H模型规范操作
（2）有些公司，可能先上线在测试，在 补用例，
（3）有些公司是只写xmind的测试点，按照测试点进行测试，
（4）先简单测完上线，上线有问题在线上操作

注意注意点：
（1）讲解语速
（2）熟练
（3）讲解的主流程 （重点：环境部署，或搭建环境）
（4）封装版本上线

========================================================================
讲解要求：
1、第一人称
2、

=========================================================================
jenkins 自动化部署环境讲：
了解需求
编写计划
编写测试用例
评审用例
导入用例管理工具
搭建环境（开发环境，测试环境（我），生产环境）
开发提测（达到准出要求）
jenkins上构建，拉取项目包，测试
冒烟测试前一致和h模型
1、测试有bug就提交给开发，开发修改bug,提交代码
2、我们去jenkins构建下，拉取gitlab上的最新代码包
3、部署到测试环境中，就能测试最新的包，验证bug
4、直到用例100%，0bug，就输出报告
5、通知uat验收，验收通过
6、封装版本
7、等待上线
8、线上测试、线上通过
9、上线成功

案例：
流程：
先拿到需求------对需求进行评审------确定基线化文档-----深入了解需求-----编写测试计划------编写测试用例-----用例评审----导入用例管理工具-----搭建环境-----部署代码包------冒烟测试------sit系统集成测试------提交bug------开发修改bug-------进行sit2测试------冒烟----测试--------以此类推到0bug，用例100%执行，输出测试报告----进行验收测试-----验收测试通过------封装版本----上预发—测试-----上线----测试------测试通过----测试完成
案例：
简化版本：
我们先拿到需求，然后对需求进行评审，通过评审确定基线化文档；
测试经理编写测试计划，我们拿到计划后编写相应测试用例，所有人用例写完后进行用例评审，评审通过我们会将用例导入用例管理工具；
然后搭建环境，等待开发提测，提测我们首先进行冒烟测试，冒烟不通过打回修改，通过则进行sit系统集成测试，过程中发现提交bug给开发，开发修改bug这样完成一轮后，进行sit2测试，先冒烟测试，在对所有用例测试，这一轮还会增加测试用例因为bug修改后可能会影响相关模块的功能，所以要添加相应的测试用例；
以此类推进行多次sit测试直到0bug，以及用例100%执行，然后输出测试报告，通知产品进行验收测试，验收测试通过，封装版本，上预发，在预发再进行测试，没问题就可以上线，在正式版再测试，测试通过，测试完成。

详细版本：
产品拿到需求（SRS），软件需求规格说明书，
进行需求澄清会，（测试，开发，产品）产品主持会议，确定基线化需求文档
开发编写概要计划说明书和详细计划说明书，我们也会去参与概要设计说明书和详细设计说明书的评审
开发进行代码的编写，我们编写测试计划（测试经理，测试组长，我）
根据测试计划，分配工作
编写测试用例
用例评审（两种评审方式：1、组内评审 ：测试，开发，产品，交叉评审：测试同事之间评审）
用例通过，导入到用例管理工具中（禅道）
用例分配给对应的负责
部署环境（测试环境（测试），开发环境，线上环境）
部署：运维，测试经理，测试组长，自己
开发提测，也是提交代码包（达到准入的要求），我们拿到代码包部署到环境中
冒烟测试（重点）
冒烟测试（称为版本验证测试，提交测试）是指：对新版本的主要功能，基本功能进行测试，如果通过，那么冒烟测试通过，如果冒烟识失败，那么就把版本打回给开发进行修改，直到冒烟通过；
每一次开发提交新版本，测试都需要在测试环境中进行冒烟测试；
冒烟测试通过以后才能进入sit测试（系统集成测试）；
sit测试（系统集成测试） 一般一个项目有三次，项目周期长可能4次，更多；
第一次sit测试是全量测试（所有编写的用例都要进行测试）；
测试小结：包括用例数，bug数，新增用例数等 ；
开发修改bug
第二sit测试
冒烟测试 ，sit2测试，（回归测试）
回归测试：是系统维护阶段进行的验证测试
区别：测试的阶段不同
冒烟测试是在版本提交时进行的第一个测试，回归测试是在维护阶段的测试；
以此类推进行sit3测试 sit4…
直到达到准出要求；
输出测试报告 -----表示sit测试完成
--------然后
进行uat 验收测试 （uat环境） --通过uat通过
系统版本打包（封板：是封装版本）
----------之后上预发环境再测试
没问题进行上线再测试
上线成功 ，上线失败，版本回退，继续用之前的版本
回退的版本要重新让开发修改，测试 ，上线

上线前会准备线上测试数据，上线后我们在线上测试下新版本；
如果线上没问题，上线完成，
如果有bug，首先分析bug对项目的影响，影响大，退回版本；影响小，开发和测试分析并上报，建议下一个版本修改。

======================================================================
案例1
工作流程是：拿到需求后，我们会对需求进行评审，通过评审确定需求文档，之后测试经理会根据需求文档来编写测试计划，安排各自的任务去写测试用例，在所有人测试用例写完之后进行用例评审，评审通过后将用例导入用例管理工具，
然后搭建环境，等待开发提测把写好的代码包发过来部署到测试环境。再进行冒烟测试，冒烟不通过则版本打回，冒烟通过则进行sit测试，过程中发现BUG提交给开发，开发修改完bug则进行sit2回归测试，先冒烟再测试。一直这样反复测试直到0BUG且测试用例全部执行完毕。然后输出测试报告，通知产品进行验收，验收通过后封装版本上传到预发环境中，在预发环境中再进行测试，没问题后进行上线，上线之后再测试，没问题后则测试完成

案例2：
我们拿到需求文档，我们的产品经理开始召开需求评审会议，对需求进行澄清，评审完之后会形成一个机械化文档（需求规格说明书），开发就会根据需求规格说明书去编写概要设计和详细设计说明书，我们测试人员还在深入了解需求规格说明书，并且评审开发写的概要和详细设计说明书，直到我们测试经理输出测试计划以及测试方案，我再根据测试经理安排的需求去编写测试用例并且写完之后会进行一个组内的评审，评审完用例之后会把定好的用例输入到我们的禅道中去，等开发那边写好代码之后，开发就会把代码包给到我，之后我会进行环境的部署，部署完成之后就会进行冒烟测试，若冒烟不通过，则版本打回；如果通过，则进入到sit1系统集成测试（全量测试），这个时候我就会把功能和接口全部测试完，有bug就提bug，开发把所有的bug修复完之后分配到我这边，我再进行回归测试，可能会有sit2,sit3，回归直到用例全部执行完毕并且没有bug，然后我就会uat任务给到产品经理，uat验收没问题，则发布的前一天会进行一个预发环境的上线，我们会在预发环境进行进一步的验收，无问题后则发布生产环境，最后输出测试报告。。。。。

案例3：
在拿到客户需求之后，我们产品经理会召集我们开一个SRS澄清会议，对需求进行分析，会议完成之后开发那边会编写概要设计和详要设计，我们测试经理会根据需求生成一个测试计划，我会根据测试计划编写好测试用例，同时对测试用例进行评审，再把评审好的测试用例导入到禅道里面去，然后会搭建好测试环境，开发提交代码包后，会对环境进行一个部署，首先会进行冒烟测试，不通过则版本打回，通过之后会进行第一轮的SIT测试，有bug会提bug，开发修改好bug之后，同时进行第二轮SIT测试也叫回归测试，，直到通过所有测试用例，并且没有bug为止，然后会进行uat验收测试，同时运维会上预发环境，通过之后正式上线，并且产出测试报告。