请选择 进入手机版 | 继续访问电脑版
 找回密码
 立即注册
  • 便民服务
  • 关注我们
  • 社区新手
H 模型 ==》【重点】==》项目的流程或者测试的流程(接到一个项目你怎么开展)
   
1、项目和版本的区别:
微信项目11年,期间更新了很多版本一个项目包含多个版本
2、项目和产品的区别:先有项目后有产品
==》软件生命周期可以了解到:
客户问题引入=》可行性分析=》招标=》立项=》需求分析=》开发测试=》维护
3、一个版本6个月==》交付周期
自然日:周一到周日
工作日:周一到周五
4、大致梳理流程
①、需求澄清(评审)     产品经理 测试 开发 运维等
②、概要设计HLD          测试了解需求
③、详细设计LLD          测试继续了解需求,基于项目周期输出测试计划
④、开发编写代码         测试人员根据需求编写测试用例和评审用例
⑤、开发把编写好的代码打成一个代码包     运维搭建测试环境,并将代码包部署到
测试环境
⑥、测试人员冒烟测试,根据用例执行sit测试,有bug提bug,交给开发修复,进行回归测试
⑦、所有的bug都已修复,回归测试都验证并且ok
⑧、输出一个测试总结报告,交给领导,领导会根据这个报告作上线准备
5、进行细化
① ==》
产品经理根据客户需求提炼出项目需求(研发团队看得懂的)==》给到研发团队(测试,开发等)
==》阅读 分析,有问题记录下来==》这个时候,产品经理会通知开会==》产品经理主讲==》测试开发
听,然后提出疑问,问题==》讨论这个是否合理==》产品需要调整需求==》
最后会形成需求规格说明书(SRS)
通知方式:邮件  项目组群  领导转达
通知的内容:开会时间   地点   内容
② ==》
开发同时基于需求文档编写概要设计说明书==》HLD
测试了解需求,review==》评审,测试也可以参加开发文档的评审
③ ==》
开发基于概要设计编写详细设计说明书LLD
测试继续深入了解需求,深入了解的目的,为了挖掘需求当中隐形 显示 关联的 特殊的需求点
会基于项目的周期,TPM 输出测试计划(测试范围 人员安排 时间 资源等等)
你们公司测试计划谁写?==》测试经理  测试组长 测试骨干  你(根据公司而定)
④ ==》
开发人员编写代码(coding)
测试人员:根据需求文档编写测试用例,编写完后进行用例评审(谁写的谁来讲),评审后可能需要修改
增删改,修改完后进行保存(1、发给领导 2、上传用例管理工具testlink 3、自己保存)
TE: 测试工程师 test engineer
TC:测试用例   test case
testlink:用例管理工具
你们公司有哪几种用例评审?
组内评审:项目组内部成员 领导 测试  开发  运维 ui ==》一般最多的是这种
交叉评审:我写的用例你来讲
会议评审:有可能客户会来参加
⑤ ==》
打包部署:运维搭建测试环境,开发人员把代码打成一个代码包,交给运维人员,运维人员
将代码包部署到测试环境(基于linux上,.war .jar .zip)包根据服务器来定,运维部署好了之后
通知测试人员可以进入测试阶段,给到ip地址  账号 密码,假如百度是我们的测试环境
你们公司有几种环境?
测试环境:测试人员用的  ==》内部环境
开发环境:开发人员联调自测  ==》内部环境
线上环境:生产环境 真实环境
区分环境:测试环境下一单不会真实发货,在线上环境下单会发货
⑥ ==》
测试人员开始测试,测试人员编写了1000条测试用例
测试人员首先要进行冒烟测试,假如冒烟测试不通过,把版本打回给开发 之前发布的版本v1.0,
开发修复好了后v1.1 打包部署,继续冒烟测试,冒烟测试通过,执行sit测试
什么叫冒烟测试?(冒烟测试一般执行多少条用例50条以内)==》最先起源于硬件行业 电路板
软件上定义:对主体功能的测试
什么是主体功能?
例子==》登录主体功能是什么?登录成功
例子==》qq注册功能的主体功能?qq注册成功
例子==》微信支付功能的主体功能?支付成功
sit1系统集成测试:又叫做全量测试,就是把1000用例全部执行一次,发现bug提交
到bug管理工具(禅道),有可能发现自己用例漏写了,需要新增用例
输出测试小结报告(记录这一轮执行了多少用例,发现了多少bug)
⑦==》
sit2:回归测试(增量测试,用例数量的增加)
回归测试测试哪些内容?
1)新增用例需要测试
2)修复的bug需要测试
3)冒烟测试
4)发现bug相关联模块需要测试
抽取全部用例的500用例测试,发现bug继续提bug,有可能发现自己用例漏写了,需要新增用例
输出小结报告(记录这一轮执行了多少用例,发现了多少bug)
sit3:回归测试(增量测试,用例数量的增加)
回归测试测试哪些内容?
1)新增用例需要测试
2)修复的bug需要测试
3)冒烟测试
4)发现bug相关联模块需要测试
抽取全部用例的200用例测试,发现bug继续提bug,有可能发现自己用例漏写了,需要新增用例
输出小结报告(记录这一轮执行了多少用例,发现了多少bug)
sit4:回归测试(增量测试,用例数量的增加)
回归测试测试哪些内容?
1)新增用例需要测试
2)修复的bug需要测试
3)冒烟测试
4)发现bug相关联模块需要测试
抽取全部用例的50用例测试,发现bug继续提bug,有可能发现自己用例漏写了,需要新增用例
输出小结报告(记录这一轮执行了多少用例,发现了多少bug)
....sit5 sit6 根据项目的需要
直到最后一轮所有回归测试没有问题,所有的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的全部修复,输出测试总结报告
发给领导

分享至 : QQ空间
收藏

0 个回复

您需要登录后才可以回帖 登录 | 立即注册