客户反馈的bug大家是怎么处理的？

wonder

看到很多人讨论缺陷工具的使用问题， 但很少有讨论缺陷流程的问题。
想问一下大家，各自公司中针对客户反馈的bug是怎么样的一个流程？
客户反馈的问题是否和 测试人员发现的bug记录在一个系统中，
客户反馈bug 和测试人员发现bug的比率是否会作为一个测试人员考核的依据？
想和大家讨论一下。

wonder

我是觉得客户反馈的bug是有必要和测试人员发现的bug 统计到一个BUG 管理库中的， 这样的好处是可以维护一个项目缺陷的完整性， 客观的反映了该项目的一个质量情况， 另外可以针对客户反馈的bug做一个数据统计和分析，看哪些是由于测试人员测试遗漏的， 哪些是由于客户操作不当造成的， 哪些是由于版本更新错误造成的， 等等。
    但是为了统计数据方便， 必然需要制定客户反馈bug的一些关键字来和其他的bug做一个区别， 比如增加bug 来源为 customer feedback or  from Test。
    大家公司里面关于这方面是怎么做的呢？

alex62345

我们是把客户的BUG也记录进TD的，summry是 “XXX客户的问题反馈”

wonder

Alex62345 ：
       也就是说客户反馈的问题和测试人员发现的问题是管理在一起的吗？
那么你们公司是否有针对客户反馈bug的数据做过相关的分析呢？

我是觉得可以定期出一些不同类型的报表，好处如下：
1， 可以分析一下客户关注的bug主要是些什么问题？ 比如客户比较关注我们容易忽略掉的UI问题， 没有想到的性能问题 等等。
2， 可以分析一下客户的操作熟练程度。客户是否经常反馈一些由于操作不当或者理解有误引起的bug， 这样我们可以考虑改进用户使用培训方面的问题
3， 可以分析一下是否经常发现一些在本地环境无法重现的问题， 这样可以考虑是否内部测试环境和客户实际环境有何差异，或者使用习惯经常不一样。
4， 客户反馈的bug有些时候可能是新的需求（即他们认为是bug，在我们看来可能是需求不明确或者遗漏造成的），这样我们可以在需求分析方便做一些改进。
5， 客户反馈的bug是否由于版本更新出错引起的， 后期可以考虑改进我们的更新方法，或者出货流程， 避免这方面的错误。
6， 测试遗漏的bug占测试人员发现bug的百分比， 对于测试人员有一定的监督作用（关于这点具体怎么操作， 还没有想好。）
。。。。。
暂时想到这些， 大家还有什么想法呢， 很想和大家讨论一下。。。

lj1981727

我也觉得针对客户的bug应该每隔一段时间就进行分析，这样便于分析我们的测试工作，
以前出现的bug是哪种类型的bug，是异常数据出现的问题，用户操作方面的问题，性能方面的问题
还是其他的问题，找到问题的的原因后，想办法提升我们的测试质量，针对薄弱环节投入更多的精力
和人力，来避免以前出现的问题再次发生，同时，通过客户反馈bug的记录，也能对测试人员有一定的
压力，当测试人员看到记录的这些bug时，自然会有一种责任感，在后面的测试工作中会更加细心和努力
也能间接的提高测试的质量

pierre0505

对于客户提出的bug，我们都会作为测试人员提交的bug一样记录到TD中，其缺陷跟踪的流程跟测试人员提交的bug一样，只是在描述中，增加一个“客户反馈”的字样，没有特殊 标识。
对于Wonder想到的6点中，我觉得想法很好，真不错。

wonder

谢谢大家的反馈，因为客户反馈的bug情况比较复杂，所以目前我们考虑了专门新增一个Online bug Project，用来记录和保存所有客户反馈bug，但里面所有的bug只有三种状态： open（表示未处理，cancel（非bug），close（已经处理完毕的bug），开发人员不参与这个bug流程，由各项目测试组长进行录入和确认状态，由字段Project 区分。另外增加一个validation 下拉选择字段，用来标明该bug的产生原因， 比如 用户操作错误，新需求，版本升级错误，环境不同，脏数据，维护性项目遗留bug， 测试人员遗漏。。。等。 这个bug project , 比较方便进行各项目组的横向对比。
       针对确实是bug的问题，还需要再录入一次到测试人员提交的bug project中去， 由字段customer feedback标明，对于这样的bug同样需要经历bug生命周期。  
      目前准备这样去试运行，希望可以给大家一个借鉴，当然也希望大家多多提出宝贵的意见！

yfzang1001

三楼的第六条嘛,在我们公司是这样的,可在测试记录中加上一条上轮测试者是谁,是pass,fail还是NT,fail和nt的都写上理由,然后在每天的日报中加上上轮测试有无次问题.

小小丫

wonder对于你说的Online bug Project,录入客户的BUG,由项目的测试组长录入和确认状态,如果一个测试组长对具体的BUG状态不是很清楚,那怎么操作呢?我们也是把客户的BUG和测试人员的BUG一样都录入到一个BUG库中,只是一个发现人是客户,但现在执行这个客户BUG的跟踪有点混乱,测试人员不对客户的BUG进行跟踪,又客户跟踪的,但客户跟踪BUG又不及时,到了版本后期还会存在客户OPEN的BUG

wonder

小小丫 :
     目前我们对于客户反馈的缺陷都是由测试人员进行跟踪的，只是在进行跟踪之前首先要对客户反馈的bug 进行一下过滤，
这个是由测试负责人和项目经理来做的，1， 分析是否为bug， 2 ，如果是bug，是否需要修改，
所以其实bug 的定位是项目经理和测试组长一起定位，只是由测试组长维护进bug 管理系统而已，
而对于确实需要改正的bug 是需要录入本项目的正式bug 库的， 其流程等同于其他由测试人员发现的bug。所以不会存在遗漏的情况， 这样做唯一的缺点就是测试组长对于一些bug 需要维护两次， 不过在客户反馈bug 并不是很多的情况下，还可以忍受。

April.H.X

我们有专门的支持系统,用户可以在支持系统中反应系统的Bug,也可以电话的方式反应.Bug的收集工作以及和客户的反馈是由技术支持人员做的,支持人员会把Bug交给项目经理,由项目经理决定是漏测还是别的原因,如果是测试的疏漏,测试负责人组织进行分析,后续的流程和普通Bug基本一样了.

ccmjxh

我们公司目前的做法是：
针对客户的BUG，首先进行过滤，看哪些是测试人员忽略的BUG，哪些是新需求，哪些是客户操作不当引起的，然后再考虑哪些是要改的，哪些不必改。
需要修改的录入的CQ库中，以字段区分，如：BUG的来源等。
最后是，每隔一段时间对客户的BUG进行一次分析，一来衡量测试人员的测试水平，直接跟个人的绩效考核挂勾，二来总结一下客户提出的是哪种类型的BUG，提高测试质量，以免以后出现同样的问题。