首页  思维导图  详情



 



测试全流程

2023-05-22 14:16:12   1  举报





AI智能生成

devops测试全流程脑图

测试流程

测试流程规范

测试流程图

测试用例

模板推荐

作者其他创作

大纲/内容

项目规划阶段

立项会议

需求评审

需求设计与逻辑是否可以实现

现场协助参考设计缺陷

确定产品归属人

设计UE设计图

确定开发归属人

技术实现

筛选排期

预估研发测试所需完成时间

确定测试负责人

简单需求流程分析

新需求影响范围点

项目实施阶段

研发过程中

测试根据需求编写测试点级测试用例

覆盖主流程

交与开发自测

测试根据需求编写测试计划

测试计划是工作量预估，也是工作考核绩效的重要依据，预估时间超额需要注重沟通是什么原因。测试计划的内容包括：测试范围、哪些阶段、什么时间点完成什么、测试资源的成本（人/天）等等。需求的诞生过程，免不了出现各种各样的特殊情况，人员生病拉肚子，请假，因其他原因导致测试时间不够，实际可能会跟测试计划有所出入。所以最后的测试报告中需要写明与测试计划产生偏差的原因，分析偏差的风险。最终的测试过程和测试结果还是以测试报告为准。

分析需要针对的使用测试手段

功能测试

兼容测试

接口测试

数据输入测试

性能测试

影响范围测试点

自动化测试

分析需求是否核心，排期安排

暴力点击测试等

测试根据需求编写用户故事级别用例

按照用户角度对设计图分析

整体逻辑分析

编写逻辑覆盖用例初稿

覆盖全面

需求文字覆盖

非需求异向操作覆盖

用户故事标准见其他文档要求

编写测试用例终稿

达到评审标准

需求点覆盖全面

逻辑覆盖全面

异向流程操作覆盖全面

无硬伤未覆盖逻辑

达到标准要求

未来交叉测试时可看懂即可

达到简单直接

不啰嗦无需过多与其他人解释语句描述

进行测试用例评审

尽量讲解时按照原型图或蓝图设计图讲解

从客户使用角度讲解操作逻辑与习惯

从直白有效的方式讲说用例

产研两方与测试其他人员进行协助遗漏

研发完成阶段

开发进行自测

冒烟测试教给测试

冒烟通过，需求主要流程通过

达到需求描述核心设计

项目核心流程如有影响不可提测，等待更改后方可通过

测试进行执行测试

阶段性测试要求

测试期间测试环境不允许开发人员访问，直到一轮测试结束

一轮结束后BUG积累会将测试环境允许开发介入，用来复现相关问题，并查找问题原因。

上方可活用，一般更加推荐随测随改但是发版不可改了非流程问题就发版的情况

1、逐句分析交付需求成果是否达标

2、UI设计与设计图对比成果物是否符合标准

3、执行测试用例

4、未写在用例中的交互测试

5、响应测试

6、每日测试过程中提交BUG解决率与标注状态跟踪

每日BUG数量

每日已解决数量

每日以外状态分析

设计缺陷与设计建议

7、BUG数量逐渐减少至不在发现

进行测试记录统计

所有更改后的BUG不仅仅需要改正测试，是否拆东墙补西墙也要考虑，所以改正后的范围测试很重要

8、影响范围测试并小范围回归测试

同时按照用户习惯进行兼容测试

围绕曾经事故产生位置与坑，再次勘察

9、简单的测试报告，遗留风险与其他关键点

10、内部通过业务相连人员进行交叉测试

交叉测试注重刨除用例，进行盲测

（偷偷的解释：该处因为之前用例按照执行再次执行意义不大，无业务测试下更增加发现奇葩BUG概率）

11、整体回归测试

如不再发现问题，可以参照测试完成阶段设计其他方案测试

多轮测试规划

发版之前无论开发测试必须提前群里告知更新代码

不可出现测试过程中私自偷偷摸摸发版导致测试误以为问题

测试的过程并不是固定的，要灵活的变化

产品测试

一定有非常完整的发版计划，有充足的的时间，有充足的资源进行协调，即使因为一些特殊的原因未能按时完成发版计划，也可以进行延期。所以产品测试都会尽量的去进行完成的全级别测试。

正常迭代更替新需求测试

项目测试

一般时间都非常紧，资源有限，发生意外的情况很多，任务时间都是被极度压缩到目前为止我经历过大大小小几十个项目，没有一个是能按计划时间充足的上线。所以项目测试一般会大量的精简测试过程，甚至为了按时上线做出一些牺牲，牺牲掉一些不重要的功能，来优先保证重点功能、常用功能。

主流程保证时间紧测试

测试完成阶段

建议测试环境之上至少增加准生产或灰度环境，避免配置问题产生事故

测试回归测试完成

交于产品进行验收测试

产品分析是否达到需求设计标准，研发结果是否达到预期

验收测试的目标包括：建立对整个系统质量的信心（产品自己心里有底）确认需求是否完整且需求将按预期方向走验证需求的功能和非功能行为符合规范思维不同，可能发现新的问题

在设计测试计划中可能存在该需求适合并属于核心业务需求

此时可以按照测试用例进行UI自动化设计

接口自动化设计

整理该迭代整体测试情况，做出测试报告

（偷偷的环节：测试报告是否只进行记录分析，如与客户上报测试报告，是有对应销售客服部还是直接对接客户）

如已经有UI自动化脚本，根据脚本编写数量可以减少人员回归测试范围

跑UI自动化进行回归

上线阶段

对核心流程进行回归测试与UI自动化执行

查看新需求是否存在问题

配置问题

其他可能存在问题

踩坑阶段记录

上几个阶段之外的事故记录点

历史事故记录

容易发生问题的不稳定位置

每次事故发生内部复盘

印象复盘，不是分析后就不利用

测试数据

保证数据无异常情况下，登录账号尽量准备不同账号以备测试

提交BUG相关

所有BUG要在能看得懂的情况下，尽量描述准确简洁

标题描述要求

统一提交格式

开头进行前后端问题归属标注

【前端】

【后端】

在进行问题位置路径描述

XXX模块的XXX功能下的XXX位置

位置描述后进行问题描述

简洁写出什么问题即可

其他选项选择好问题形式

代码错误

设计缺陷

建议

等

归属于那个端

web

APP

小程序

BUG的严重等级

等级1：流程与需求不符问题

等级2：逻辑问题与功能问题

等级3：交互以及不重要但需要更改的问题

等级4：优化样式与建议

正文下

数据

表明测试时使用环境与URL地址

表明测试时使用可复现问题账号

表明出现问题时的数据信息

步骤

可进行图片展示操作步骤

可进行录GIF动图形式展示操作步骤

可进行文字操作步骤描述如何复现

结果

出现问题结果可以进行接口响应状态码截图展现

出现问题结果可以进行文字描述当前问题情况

出现问题结果可以通过查看日志报错截图展示

期望

可以根据需求描述贴出需要改动的预期结果

文字描述正常情况应该如何

一切在需求描述中未描述出来或者需要产品确认的问题，一定不要进行口头确认，以聊天截图方式或产品标注形式在该BUG下进行描述，问题多的时候已免日后忘记

如开发处理不同状态问题时也要进行相应描述

如果开发说是需求改了或者说是产品经理说的，那么抱歉，请修改需求文档！不改需求文档未按照实现就是BUG 测试时只认文档不认人。

bug的粗略描述格式合体模板：

web端严重程度：4 设计缺陷【前端-CDP】自助分析---时间分析：点击菜单栏成功进入页面后，菜单栏未显示被选中菜单项高亮 URL地址：httpXXXXXXXXXXXXXX.... 环境：rel(dev?) 账号：12345678 密码：111111 [步骤] 1.登录系统 2.进入自助分析--时间分析页面 3.查看菜单栏 [结果] 【我是图1】 [建议] 【我是图2】

我是图1

我是图2

子主题 4