如何利用好现场测试缺陷

　　一般现场缺陷，由现场测试人员或者是用户、销售等其他人员反馈，现场测试人员反馈的缺陷大多数由测试人员进行对接。接到问题后测试人员首先需要经过筛查或者复现，再反馈给现场人员或者交由开发人员进行修复。

　　那么，有人会问，遇到这种问题，真正能解决的人最终还是开发人员，那么测试人员在整个 过程中，除了协助解决和验证，还能做些什么呢？

　　首先，我们要对问题进行分类统计，后续才好根据不同类别的问题再深入分析。我个人认为，主要就两类问题：

一、缺陷

　　也就是 Bug，对这类问题需要做 WWW 分析，这个分析其实在接到现场问题时就会去分析，但在事后还是需要再分析一次，因为在处理问题时的分析也许相对个体化或特例化，在事后其实就可以集中一些同类别的 Bug 做更垂直深入和拓展性的分析。

What's the problem?

　　对问题做一个清晰且专业的描述，因为，往往现网反馈的问题，只是表象上的描述或者只是非专业的破碎化的叙述，我们需要对它们做一个“转译”，便于后面会说到的再利用。

What's the root cause?

　　找出会产生此类问题的根本原因，有这样几类（大家可以补充）：

1. 测试用例没有覆盖到；
2. 测试策略没有考虑到，比如压力测试没有做；
3. 测试执行的遗漏；
4. 现场环境的特殊性；
5. 系统没有做相应的操作保护，用户操作导致的异常数据（我认为这一条可以属于测试用例没有覆盖到）；

What's the solution?

• 针对 1 和 2，要从测试用例的设计方法和测试计划环节着手去提高和改进，同时做好用例补充；
• 针对 3，要从测试过程的监控和测试产物质量的验收环节着手去提高和改进；
• 针对 4，要从改善实验室测试环境，逐步向现场环境靠近去提高和改进；
• 针对 5，要从自身系统的易用性和健壮性考虑，去提高和改进；

 

二、操作问题

　　从这类问题中，我们一般会汇总产出两样东西：

1、用户操作问题 FAQ（这个我们很少能接触到，但是我感觉还是挺有用的，有必要了解一下）；

　　这个 FAQ 除了可用于产品帮助文档的补充，或客服的问题参考文件之外，还有一个比较重要的功能，就是我们通过整理这个 FAQ 的过程，可以分析出一些我们没有想到过的用户行为习惯，往往可以帮助我们找到一些潜在的系统问题。

2、产品交互设计的改进；

　　现场问题有时是一些对操作逻辑和界面显示的建议，有时是一些需求，这可以帮助我们的产品交互设计师持续提高产品的用户体验满意度。同时也是可以分析出一些我们没有想到的用户行为习惯，帮助我们更好的站在用户的角度进行测试。

 

　　在现场问题的处理过程中，还有一个重要的可持续更新的产物，那就是“现场问题清单”，这个 Checklist 主要包含问题的描述、问题出现的原因、问题的类型等，这样就对后续进行现场问题分析提供了依据。

　　只有做完上述这些事情，我们才能松一口气。一个观点，就是现场问题的处理过程一定要和产品研发过程（至少是产品质量检测环节）形成一个闭环，即从现场问题的处理流程中获取到的产物，一定要作用于产品研发或质量检测流程，改进也好，补充也好，杜绝也好，都不能落在空处，否则现网问题的处理就仅仅只是停留在解决问题的表层，而无法真正做到避免同类问题再次发生。

 

我们可以允许自己第一次犯错，但一定不能允许自己再次犯同一个错

 

转载于:https://www.cnblogs.com/enenwenmc/p/10058747.html