【测试流程】线上用户反馈

背景

之前写了不少的需求总结和测试平台技术相关的东西，这次说下测试流程上的东西，毕竟还是拥抱业务，挣钱才是核心，工具只是手段。

一、用户反馈目的

用户反馈作为用户对产品体验最直接的表达，是改善及衡量用户体验的重要输入，我们可从中挖掘到不同维度的有效信息，进行体验的优化迭代。

1.快速的解决线上的问题（一个问题有一个用户反馈， 那么线上一定是有上百个用户发生了，只不过只有一个用户来反馈，所以本着对用户负责的心态，和对线上质量负责的意识，我们需要快速的解决）。

2.了解我们的产品在用户那边是否易用，好用，交互是否友好，用户是否可以理解。来检验产品以下三个方面做的是否足够好，并且可以在产品层面进行优化：

• 引导和提示
• 限制操作
• 反馈和帮助

3.根据线上用户反馈，数据量化线上质量，然后可以在我们后续工作中进行改进

• 将相关的场景在需求规划阶段进行考虑
• QA逃逸的原因，然后做出相关的改进措施
• 机型适配的覆盖
• 线上自动化监控的补充

4. 最后：防范在前可以尽可能的在发布之前将质量提升暴露出更多的问题，在配合上完善的监控和报警，故障降级。降低线上的事故和问题的影响时长和影响范围，快速的恢复业务。

二、用户反馈OKR

1. 24h响应率：100%
2. 24h解决率：>=85%（24h解决或者给出解决方案）
3. NVIP24h解决率：100%
4. 逃逸率：用户反馈复盘原因属于【测试用例未覆盖，回归测试未覆盖】
   1. DAU>=5K的产品，逃逸率<=10‰
   2. DAU<5K的产品，不出现P0/P1功能的问题

三、用户反馈统计报表

1.线上用户反馈每周报告tapd列表归纳反馈问题。

2.重点度量指标：

1. 24h响应率（新->接收/处理）：度量QA的响应处理时效。
2. 24h解决率（接收/处理->已解决）：度量研发&QA的问题解决时效。
3. 24h答复率（已解决->已关闭）：度量反馈同学问题答复给用户的时效。
4. 解决方案=【已转需求】：QA侧推动解决的反馈转化成需求的数量
5. 所属部门=【QA】：QA解决排查用户反馈的占比，无需流转到研发侧进行二次排查。
6. 逃逸率：复盘原因属于【测试用例未覆盖，回归测试未覆盖】

 四、反馈处理流程

注意点：

1. QA作为每个用户反馈的负责人，负责跟进到底。填写的测试人员，为对应的反馈负责人。
2. NVIP的用户反馈优先处理，必须24h解决或者给出解决方案。
3. 为了确保非工作日可以正常的接收和处理用户反馈，请微信关注Tapd公众号，方便非工作日可以及时处理用户反馈信息，变流转Tapd流程。
4. 已处理：在tapd中填写相关的排查解决结果，和问题导致的原因，修改方案，以及计划修复的版本和日期。
5. 确保用户反馈相关填写信息的准确性。
6. 相关的修改调整和调整需要通知到运营和反馈组。

五、用户反馈录入

可以加入飞书【综合反馈大群】，反馈有问题会第一时间在飞书群里@对应同学，如果是需要技术侧排查跟进的需要让对应的反馈同学按照反馈模板录入相关的tapd。

登记在Tpad->用户反馈->缺陷。

六、问题排查流程

1. QA自查
   1. 根据用户反馈的信息进行复现，是否可以复现出来。注意关注：机型，系统版本，客户端版本
   2. 查看客户端日志
   3. 查看服务端请求和返回值，查看服务端下发的IM系统消息，mysql数据库，XX平台信息查询，
   4. 客户端/H5埋点信息
2. 转研发跟进：
   1. 根据经验初步判断问题是出现在客户端还是服务端，然后tapd&飞书通知相关的研发进一步排查跟进
   2. 将QA排查的结果录入在tapd评论中，方便研发进行问题排查
   3. 注意QA需要全程跟进该问题，不是流转完状态以后就没事了
3. 根据反馈的问题反思和总结，我们后续可以如何避免和改进，并运用到日后的工作中。

七、用户反馈排查分析案例

总结

用户反馈这个活其实很脏&&非常费时间，但是从业务角度来讲其实很重要，从激励角度来说应该给跟进用户反馈QA更多正反馈，不然我们瞎子摸象，天天自嗨觉得自己先进，其实线上一塌糊涂。