测试流程规范
2022-04-18 17:36:43 0 举报AI智能生成
测试流程,测试标准,测试规范
作者其他创作
大纲/内容
1. 项目准入规范标准
一、准入的目的
1. 保证项目最核心的功能正常，不阻塞其他方面的验证，保障项目按期高质量交付
2. 把时间与精力投入到更有价值的验证工作上，而非简单功能的double check
二、准入规范
1. 准入case全部通过才能继续进行下一步测试
2. 若准入case不通过，QA打回提测单，暂停测试
3. RD/FE修复bug重新提测后，qa再次进行冒烟准入
三、准入执行流程
提测前
QA
A/B/C级项目：提前最晚前一天case评审功能case及准入case，准入case最终敲定
自测阶段
RD/FE
A/B/C级项目：使用QA提供的准入case进行自测，提测的前提是全部准入case测试通过
提测
RD/FE
提测邮件需反馈准入情况（通过/不通过）
注意：准入通过的标准是准入case全部通过，如果没有全部通过，请先修改，避免提测后被打回。
注意：准入通过的标准是准入case全部通过，如果没有全部通过，请先修改，避免提测后被打回。
准入测试
QA
提测后，优先测试准入case，若准入case全部通过，继续进行下一步测试，若不通过进行打回操作
注意：如果准入case未通过被打回，研发同学修改完bug后需重新提交提测邮件
注意：如果准入case未通过被打回，研发同学修改完bug后需重新提交提测邮件
四、Q&A
哪些项目加入准入流程？
A/B/C级全部项目加入准入流程（研发同学可自己评估，如果不需要经过QA测试可走绿色通道自测通过后直接上线，如经过QA测试，按照QA的标准进行准入验证）
如何挑选准入case？
项目提测的基本功能、涉及核心服务的功能作为准入case。
基本功能的定义
属于本次项目正常功能点
除非本次项目涉及到诸如特殊用户类型(封禁、屏蔽)、特殊状态(屏蔽)等，否则，此类case不作为正常功能范畴
除去以上范畴的case都属于基本功能范畴内
五、误区拉齐
rd/fe "过了准入，我都自测完了，还要qa干什么呢？"
准入的case仅占对应项目基本功能的20%~30%，部分重点项目比例会加大；也即过了准入其实也只能保证一定比例的基本功能无问题
除了基本功能外，qa需要关注测试设计(功能、体验、安全、性能等)、用最小的成本，覆盖边界、异常功能点以及未覆盖的其他基本功能
有上线时间点的项目，准入不通过打回提测，影响上线时间怎么办？
准入严格按照标准执行。反复提测不会提升效率，反而会影响上线质量和效果，提测打回，提测时间按照最后准入case通过的时间计算，测试周期顺延。
2. 测试case输出规范
一、case编写时间
评审结束后可以先准备case，技术评审结束后准备全量case
二、case评审时间
研发联调前进行case评审
三、case输出内容要求
1、case编写严禁只按照prd照搬
2、case编写必须能看到测试场景，测试验证逻辑，覆盖场景全面
3、对需求的疑问case评审的时候尽量全量提出，避免出现测试过程中case执行跟产品确认需求的情况。
4、case评审先进行全量case评审，最后评审准入case（冒烟case为需求主功能case，研发产品如果有异议，需要他们提供原因，合理才进行修改，不合理按照准入case来）
5、准入case单独按照场景单列出来(可单独在wiki体现）
四、执行case标准
1、按照评审的case严格执行，执行完成进行标记
2、项目提测后，优先执行准入case，通过率要求100%，不通过进行邮件打回操作
3. 提测打回邮件流程及规范
一、打回依据标准
case评审与peer方拉齐敲定冒烟case，提测后优先验证冒烟case通过率，冒烟case通过率100%，可认定冒烟case通过，否则进行打回处理
二、打回节点
提测后，冒烟case测试过程节点
三、提测打回邮件规范
收件人
邮件发送相关研发，测试，产品，抄送 技术负责人、测试负责人、产品负责人
邮件标题
xx项目提测不通过打回预警
邮件正文
HI,all，
XX项目于XX月XX日提测，验证此项目准入case，通过率不足100%，提测不予准入，已打回，辛苦研发同学尽快修复bug，冒烟case通过后再进行提测。另外提测打回后，以新的提测时间为最终提测时间，测试周期顺延，辛苦@相关项目负责人@相关PM 关注。
未通过冒烟case详情如下
附：冒烟case地址：****
4. Bug提交规范及标准
一、要求
所有跟进项目需求，测试过程中发现的问题都需要通过bug进行记录
二、bug提交
Bug有效性
1、交付过程中qa需按照设定好的模块，对Bug进行归类提交；
2、Bug的类型默认为UI问题、功能问题、崩溃问题，提交Bug时不能弄错；
3、需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、Bug是否唯一性；
4、避免提交设计如此、操作错误、重复的、已知的Bug；
5、尽量少花时间在边界值、页面显示问题上，多提业务逻辑功能、交互测试方面的问题；
Bug标题
Bug标题要求简明扼要的阐述问题本质，使查看人员能快速了解Bug内容。需要写明在哪个页面执行什么操作出现什么现象。
特别提醒：
1.标题中标点符号不能超过1个
2.标题中不能含有测试流程步骤和模块信息
1.标题中标点符号不能超过1个
2.标题中不能含有测试流程步骤和模块信息
测试设备
提交Bug要表明测试使用的设备、设备操作系统版本、测试环境、网络类型等等。
前提条件
明确指出所提交的Bug是在怎么样的情况下出现的，当所发现Bug前提条件为空时，需要填【无】。
测试步骤
要简明清晰分步骤描述如何复现Bug问题，步骤用序号编排。
要按照自己的操作的实际步骤写清楚每一步是怎么操作的，最后操作到哪个页面或者点击哪个按键。
如在特定情况下发生的问题，还需明确提供以下信息
1.准确写出连续点击次数，点击时长与上下滑动屏幕时长。
2.对于特定数据产生的问题，提供具体数据。
3.精准描述bug产生的路径后，再描述现象。
特别提醒：测试步骤中的点击要用->符号连接
期望结果
按照测试步骤应当得到的正确结果，按照产品需求的期望清晰准确的填写预期结果。而且结果必须是肯定无疑义，可判定性的结果。
特别提醒：期望结果不要包含测试步骤，要是简单的一个结果
实际结果
按照测试步骤实际出现的错误结果，避免使用“不正常”，“有误”等模糊词汇，需要直接描述实际现象。
特别提醒：期望结果和实际结果要相互对应
复现步骤描述及概率
描述复现步骤中的页面切换为避免出现描述不清或有歧义，需用">"符号链接
关于复现概率一定要在多次测试的基础之上填写，若必定复现则填写100%，若偶现，请执行多次后统计概率填写。
截图和附件
UI类型
Bug需要上传截图，并且增加相应的红框标识；
功能类型
问题必须上传视频文件，上传格式MP4为主；
崩溃类型
bug则需要上传视频和log并且log不得超过10分钟。
特别提醒
1.附件命名需与标题相呼应（提交Bug后，附件名称将自动与Bug标题保持一致）
2.log日志抓取不能超过10分钟
3.文件名称不能出现怪异冗长
5. 测试日报规范
一、日报节点
项目提测后，测试介入之后每日下班前
若涉及多项目，可分开发出、多人负责统一项目，一个人发出即可
二、收件人
发送给: 相关研发、测试、产品、运营
抄送给: 研发lead \ 测试leader
三、邮件标题
XX项目XX年XX月XX日 -- 测试日报
四、邮件内容
项目名称
***接口测试
测试进度
后台整体进度 100 %
C端进度 80%
C端进度 80%
项目bug情况
总数
P0 bug数
P1 bug数
日清率
80%
Repoen个数
0
回归率
100%
五、示例
子主题
6. 遗留问题确认bug邮件规范
一、发出节点&人员
需求上线前，遗留bug未解决，相关研发，测试，产品，运营同学
二、邮件主题
XX项目遗留问题确认
三、邮件内容
xx项目原定xx时间上线，当前测试遗留未修复问题x个，当前问题XXXX，复现概率较高，问题一经出现，影响用户使用，建议修复后再上线，如必须上线，辛苦 @项目相关pm
遗留bug列表
bug详情
是否阻塞主流程
bug优先级
是否必现
复现概率
复现路径
示例
子主题
7. 测试报告规范
一、测试报告发出节点
测试环境验证完成，pm验收完成，上线前需发出项目测试报告
二、测试报告规范及标准
发送邮件需发送相关研发，测试，产品，运营
抄送技术leader、项目leader、产品leader
三、测试报告内容
示例
子主题
0 条评论
下一页
