软件产品测试方法论：四步排查法

AvBoss · 发表于昨天 17:00

当产品抛出一个典型、描述很笼统的需求：“这个页面用户反馈不好，经常卡顿、闪退，投诉量很高，麻烦好测一遍，把所有bug都找出来。”

思考三个直击要害的问题：

1、所谓体验不好，具体是什么现象？是页面加载耗时久、用户耐心不足？还是按钮点击无响应？或是展示的数据偶尔异常？这几类问题分别有多少反馈、覆盖了多少用户？

2、提到的崩溃，是App直接闪退退出，还是页面空白无法渲染，或是接口超时返回报错？能不能分清不同严重等级bug的优先级？

3、这个功能上线之后，你心里最大的隐患是什么？用户最容易在哪一步遇到故障？能不能一句话提炼出核心风险？

软件测试质量排查思路：

一：先筛掉伪缺陷（回归源头，理性甄别）

拿到用户“卡顿”“报错”“数据不对”这类笼统反馈，先做甄别：用户说卡，是本身性能短板，还是用户网络环境差、手机机型老旧导致？用户觉得数据错了，是程序计算逻辑出错，还是用户不熟悉业务规则产生误解？用户反馈崩了，是程序真正闪退，还是长时间加载，让用户误以为崩溃？

剔除环境、理解偏差这类外部因素，剩下的，才是我们需要重点跟进的真实缺陷。

二：把问题量化，告别主观感受

不再用“时不时出问题”这种模糊描述，换成崩溃率0.1%或是5%这样明确指标，不说“加载很慢”，而是给出P90耗时是2s还是12s，不说“很多用户受影响”，而是明确受影响用户占比1%还是80%。

三：按需设计测试方案

判断逻辑是这样：

1、核心链路（登录、下单、支付）→ 全场景覆盖，配套自动化回归保障

2、次要模块（消息页、个人主页）→ 重点场景核验，手工测试为主

3、极端边界场景（特殊输入、高并发操作）→ 抽样测试，有风险再追加

四层：上线前风险彩排，备好兜底方案

版本发布前，一定要敲定三件事：
1、准入标准：核心用例全部通过，P0、P1级高危缺陷清零

2、预警信号：反复多轮修改依旧持续冒出新bug，大概率是需求本身定义模糊

3、兜底预案：一旦线上崩溃率异常走高，能不能快速回滚至上一个稳定版本

总结：

bug多并不可怕，真正棘手的是虚的需求——全部都是主观感受，缺少客观数据支撑。

		自动登录	找回密码
密码			立即注册

软件产品测试方法论：四步排查法

相关帖子