2022年5月22日

v模型
客户提出需求==》需求分析==》概要设计阶段==》详细设计阶段==》编码和实现阶段==》单元测试（白盒测试）==》集成测试（灰盒测试 接口测试）==》系统测试（功能测试）==》验收测试阶段
验收测试阶段：UAT（验收环境  测试环境）==》产品经理对内

1）α（阿尔法）==》内部测试：产品经理和测试 开发，坐在一起模拟用户场景测试，这是发现问题，立马交给开发修复，测试人眼需要跟进

2)β（贝塔）==》外部测试：软件已经交给客户，客户或者时客户这边的测试进行验收，此时发现问题，研发团队这边让客户统一收集，以邮件的方式抄送给相关的人，测试人员需要对这些问题进行验证分等级，协助开发尽快修复
1、提问：你上一家公司的项目有哪些阶段，每隔阶段的输入输出？
阶段                             输入                             输出
需求分析阶段              测试开发产品开会讨论               需求规格说明书SRS
概要设计阶段              需求规格说明书                     概要设计说明书HLD
详细设计阶段              概要设计说明书                     详细设计说明书LLD
编码阶段                  开发编写代码                       整个代码包（.war .jar .zip）
单元测试阶段              对各自开发的模块进行代码测试       单元测试报告
系统集成测试阶段          编写测试用例和执行测试用例         系统集成测试报告
验收测试阶段              产品和测试开发或者客户验收测试     验收测试报告

2、软件上线后，客户发现问题，你怎么办？
1）收集客户发现的问题
2）对这些问题在测试环境（线上环境也是）中操作一遍，看是否是客户操作有误
3）如果测试环境没有问题，可能代码漏传代码，立马上传代码，再去看下是否有问题
4）如果确实存在问题，对这些问题进行划分等级（哪些是严重的，哪些是一般的），通知上级领导
5）一时半会修复不了，这些问题有点严重，看是否需要回滚代码（撤回上线代码），
回滚代码需要注意数据备份
6）跟进这些问题，直到修复为止

H 模型
大致梳理流程
①、需求澄清（评审）     产品经理 测试 开发 运维等
（开发人员）                 （测试人员）
②、概要设计HLD          测试了解需求
③、详细设计LLD          测试继续了解需求，基于项目周期输出测试计划
④、开发编写代码         测试人员根据需求编写测试用例和评审用例
⑤、开发把编写好的代码打成一个代码包     运维搭建测试环境，并将代码包部署到
测试环境
⑥、测试人员冒烟测试，根据用例执行sit测试（系统集成测试 全量测试），有bug提bug，交给开发修复，进行回归测试
⑦、所有的bug都已修复，回归测试都验证并且ok
⑧、输出一个测试总结报告，交给领导，领导会根据这个报告作上线准备
TE: 测试工程师 test engineer
TC：测试用例   test case
testlink:用例管理工具

你们公司有哪几种用例评审？
组内评审：项目组内部成员 领导 测试  开发  运维 ui ==》一般最多的是这种
交叉评审：我的写用例你来讲
会议评审：有可能客户会来参加

你们公司有几种环境？
测试环境：测试人员用的  ==》内部环境
开发环境：开发人员联调自测  ==》内部环境
线上环境：生产环境 真实环境
区分环境：测试环境下一单不会真实发货，在线上环境下单会发货

什么叫冒烟测试？（冒烟测试一般执行多少条用例50条以内）==》最先起源于硬件行业 电路板
软件上定义：对主体功能的测试

什么是主体功能？
例子==》登录主体功能是什么？登录成功
例子==》qq注册功能的主体功能？qq注册成功
例子==》微信支付功能的主体功能？支付成功
回归测试（增量测试，用例数量的增加）
回归测试测试哪些内容？
1）新增用例需要测试
2）修复的bug需要测试
3）冒烟测试
4）发现bug相关联模块需要测试
抽取全部用例的500用例测试，发现bug继续提bug，有可能发现自己用例漏写了，需要新增用例输出小结报告（记录这一轮执行了多少用例，发现了多少bug）
。。。
直到最后一轮所有回归测试没有问题，所有的bug都已修复，bug数为0，输出测试总结报告
，发给上级领导，领导会根据这个报告来做上线准备
问题1：H模型中的1表示什么？
表示有一个易用性的bug，不影响使用，需要把这个情况告知领导，可以留到下一个版本解决

问题2：你们公司一定要bug数为0才能上线吗？
不一定，一般来说致命 严重  一般的bug需要为0，如果有易用性的bug可以留到下一个版本，
这个情况需要告知客户和领导，商定好修复时间

问题3：你们测试准出的标准是什么？
1）所有功能都已实现，且符合需求规定的功能
2）提交到bug管理工具的bug都已验证
3）所有回归测试都ok，且致命 严重 一般的bug都已通过，且关闭
4）输出测试总结报告以及其他文档（用例文档 bug文档等等）

问题4：你们公司测试准入的标准是什么？
1）所有相关文档都已输出（需求文档 开发文档 用例文档 测试计划等等）
2）开发编写好代码且通过了单元测试，研发的功能也符合需求文档
3）测试用例已评审通过
4）环境搭建好了，代码已部署到测试环境
5）冒烟测试通过
【H总结】项目的流程【重点】==》工作的流程、测试流程
产品接到一个需求，进行分析提炼得到项目需求，下发给项目组成员，我们拿到这个需求文档进行阅读，分析，记录
一些问题，这时产品经理组织开一个评审会议，产品经理主讲，提出我们记录的问题，进行讨论，产品经理进行调整
最终会形成一个基线化文档，测试人员编写测试计划，开发编写代码，测试根据测试计划编写测试用例，进行评审
等到运维把代码部署到测试环境中，首先进行冒烟测试，冒烟测试不通过，打回版本给开发，如果冒烟测试通过，进行sit系统集成测试，发现bug 提bug，等开发修复好了后进行回顾测试，直到所有bug的全部修复，输出测试总结报告发给领导
测试活动的生命周期
测试计划：之前已经了解需求文档，输出了需求规格说明书
测试分析与设计：之前测试计划已输出==》设计用例
测试实现与执行：测试用例已写好，且评审过了
测试资产归档：一般指app（配手机）