测试全流程
2023-05-22 14:16:12 1 举报AI智能生成
devops测试全流程脑图
作者其他创作
大纲/内容
现场协助参考设计缺陷
需求设计与逻辑是否可以实现
设计UE设计图
确定产品归属人
技术实现
确定开发归属人
预估研发测试所需完成时间
筛选排期
简单需求流程分析
新需求影响范围点
确定测试负责人
需求评审
立项会议
项目规划阶段
覆盖主流程
交与开发自测
测试根据需求编写测试点级测试用例
测试计划是工作量预估，也是工作考核绩效的重要依据，预估时间超额需要注重沟通是什么原因。测试计划的内容包括：测试范围、哪些阶段、什么时间点完成什么、测试资源的成本（人/天）等等。需求的诞生过程，免不了出现各种各样的特殊情况，人员生病拉肚子，请假，因其他原因导致测试时间不够，实际可能会跟测试计划有所出入。所以最后的测试报告中需要写明与测试计划产生偏差的原因，分析偏差的风险。最终的测试过程和测试结果还是以 测试报告 为准。
功能测试
兼容测试
接口测试
数据输入测试
性能测试
影响范围测试点
分析需求是否核心，排期安排
自动化测试
暴力点击测试等
分析需要针对的使用测试手段
测试根据需求编写测试计划
整体逻辑分析
按照用户角度对设计图分析
需求文字覆盖
非需求异向操作覆盖
覆盖全面
用户故事标准见其他文档要求
编写逻辑覆盖用例初稿
需求点覆盖全面
逻辑覆盖全面
异向流程操作覆盖全面
无硬伤未覆盖逻辑
达到评审标准
未来交叉测试时可看懂即可
达到标准要求
不啰嗦无需过多与其他人解释语句描述
达到简单直接
编写测试用例终稿
测试根据需求编写用户故事级别用例
尽量讲解时按照原型图或蓝图设计图讲解
从客户使用角度讲解操作逻辑与习惯
产研两方与测试其他人员进行协助遗漏
从直白有效的方式讲说用例
进行测试用例评审
研发过程中
冒烟通过，需求主要流程通过
达到需求描述核心设计
项目核心流程如有影响不可提测，等待更改后方可通过
冒烟测试教给测试
开发进行自测
发送提测邮件至相关负责人
一轮结束后BUG积累会将测试环境允许开发介入，用来复现相关问题，并查找问题原因。
上方可活用，一般更加推荐随测随改但是发版不可改了非流程问题就发版的情况
测试期间测试环境不允许开发人员访问，直到一轮测试结束
1、逐句分析交付需求成果是否达标
2、UI设计与设计图对比成果物是否符合标准
3、执行测试用例
4、未写在用例中的交互测试
5、响应测试
每日BUG数量
每日已解决数量
每日以外状态分析
设计缺陷与设计建议
6、每日测试过程中提交BUG解决率与标注状态跟踪
进行测试记录统计
所有更改后的BUG不仅仅需要改正测试，是否拆东墙补西墙也要考虑，所以改正后的范围测试很重要
7、BUG数量逐渐减少至不在发现
同时按照用户习惯进行兼容测试
围绕曾经事故产生位置与坑，再次勘察
8、影响范围测试并小范围回归测试
9、简单的测试报告，遗留风险与其他关键点
（偷偷的解释：该处因为之前用例按照执行再次执行意义不大，无业务测试下更增加发现奇葩BUG概率）
交叉测试注重刨除用例，进行盲测
10、内部通过业务相连人员进行交叉测试
如不再发现问题，可以参照测试完成阶段设计其他方案测试
11、整体回归测试
阶段性测试要求
测试进行执行测试
不可出现测试过程中私自偷偷摸摸发版导致测试误以为问题
发版之前无论开发测试必须提前群里告知更新代码
正常迭代更替新需求测试
一定有非常完整的发版计划，有充足的的时间，有充足的资源进行协调，即使因为一些特殊的原因未能按时完成发版计划，也可以进行延期。所以产品测试都会尽量的去进行完成的全级别测试。
产品测试
主流程保证时间紧测试
一般时间都非常紧，资源有限，发生意外的情况很多，任务时间都是被极度压缩到目前为止我经历过大大小小几十个项目，没有一个是能按计划时间充足的上线。所以项目测试一般会大量的精简测试过程，甚至为了按时上线做出一些牺牲，牺牲掉一些不重要的功能，来优先保证 重点功能、常用功能。
项目测试
测试的过程并不是固定的，要灵活的变化
多轮测试规划
研发完成阶段
建议测试环境之上至少增加准生产或灰度环境，避免配置问题产生事故
验收测试的目标包括：建立对整个系统质量的信心（产品自己心里有底）确认需求 是否完整 且需求将按预期方向走验证需求的功能和非功能行为 符合规范思维不同，可能发现新的问题
产品分析是否达到需求设计标准，研发结果是否达到预期
交于产品进行验收测试
测试回归测试完成
此时可以按照测试用例进行UI自动化设计
接口自动化设计
在设计测试计划中可能存在该需求适合并属于核心业务需求
（偷偷的环节：测试报告是否只进行记录分析，如与客户上报测试报告，是有对应销售客服部还是直接对接客户）
整理该迭代整体测试情况，做出测试报告
跑UI自动化进行回归
如已经有UI自动化脚本，根据脚本编写数量可以减少人员回归测试范围
测试完成阶段
对核心流程进行回归测试与UI自动化执行
配置问题
其他可能存在问题
查看新需求是否存在问题
上线阶段
历史事故记录
容易发生问题的不稳定位置
印象复盘，不是分析后就不利用
每次事故发生内部复盘
上几个阶段之外的事故记录点
踩坑阶段记录
保证数据无异常情况下，登录账号尽量准备不同账号以备测试
测试数据
项目实施阶段
所有BUG要在能看得懂的情况下，尽量描述准确简洁
【前端】
【后端】
开头进行前后端问题归属标注
XXX模块的XXX功能下的XXX位置
在进行问题位置路径描述
简洁写出什么问题即可
位置描述后进行问题描述
代码错误
设计缺陷
建议
等
其他选项选择好问题形式
web
APP
H5
小程序
归属于那个端
等级1：流程与需求不符问题
等级2：逻辑问题与功能问题
等级3：交互以及不重要但需要更改的问题
等级4：优化样式与建议
BUG的严重等级
表明测试时使用环境与URL地址
表明测试时使用可复现问题账号
表明出现问题时的数据信息
数据
可进行图片展示操作步骤
可进行录GIF动图形式展示操作步骤
可进行文字操作步骤描述如何复现
步骤
出现问题结果可以进行接口响应状态码截图展现
出现问题结果可以进行文字描述当前问题情况
出现问题结果可以通过查看日志报错截图展示
结果
可以根据需求描述贴出需要改动的预期结果
文字描述正常情况应该如何
期望
正文下
统一提交格式
如果还是不行，面对面的方式更加推荐去沟通
尽可能描述清楚的方式展现，哪怕使用视频讲解方式
如果开发说是需求改了或者说是产品经理说的，那么抱歉，请修改需求文档！不改需求文档未按照实现就是BUG测试时只认文档不认人。
如开发处理不同状态问题时也要进行相应描述
一切在需求描述中未描述出来或者需要产品确认的问题，一定不要进行口头确认，以聊天截图方式或产品标注形式在该BUG下进行描述，问题多的时候已免日后忘记
标题描述要求
我是图1
我是图2
web端 严重程度：4 设计缺陷【前端-CDP】自助分析---时间分析：点击菜单栏成功进入页面后，菜单栏未显示被选中菜单项高亮URL地址：httpXXXXXXXXXXXXXX....环境：rel(dev?)账号：12345678密码：111111[步骤]1.登录系统2.进入自助分析--时间分析页面3.查看菜单栏[结果]【我是图1】[建议]【我是图2】
bug的粗略描述格式合体模板：
子主题 4
提交BUG相关
大概就这个意思，提的对不对好不好不要在意细节格式至少是这个标准
测试角度流程规范初稿
0 条评论
回复 删除
下一页
