客户反馈的bug大家是怎么处理的？
看到很多人讨论缺陷工具的使用问题， 但很少有讨论缺陷流程的问题。想问一下大家，各自公司中针对客户反馈的bug是怎么样的一个流程？
客户反馈的问题是否和 测试人员发现的bug记录在一个系统中，
客户反馈bug 和测试人员发现bug的比率是否会作为一个测试人员考核的依据？
想和大家讨论一下。 我是觉得客户反馈的bug是有必要和测试人员发现的bug 统计到一个BUG 管理库中的， 这样的好处是可以维护一个项目缺陷的完整性， 客观的反映了该项目的一个质量情况， 另外可以针对客户反馈的bug做一个数据统计和分析，看哪些是由于测试人员测试遗漏的， 哪些是由于客户操作不当造成的， 哪些是由于版本更新错误造成的， 等等。
但是为了统计数据方便， 必然需要制定客户反馈bug的一些关键字来和其他的bug做一个区别， 比如增加bug 来源为 customer feedback orfrom Test。
大家公司里面关于这方面是怎么做的呢？ 我们是把客户的BUG也记录进TD的，summry是 “XXX客户的问题反馈” Alex62345 ：
也就是说客户反馈的问题和测试人员发现的问题是管理在一起的吗？
那么你们公司是否有针对客户反馈bug的数据做过相关的分析呢？
我是觉得可以定期出一些不同类型的报表，好处如下：
1， 可以分析一下客户关注的bug主要是些什么问题？ 比如客户比较关注我们容易忽略掉的UI问题， 没有想到的性能问题 等等。
2， 可以分析一下客户的操作熟练程度。客户是否经常反馈一些由于操作不当或者理解有误引起的bug， 这样我们可以考虑改进用户使用培训方面的问题
3， 可以分析一下是否经常发现一些在本地环境无法重现的问题， 这样可以考虑是否内部测试环境和客户实际环境有何差异，或者使用习惯经常不一样。
4， 客户反馈的bug有些时候可能是新的需求（即他们认为是bug，在我们看来可能是需求不明确或者遗漏造成的），这样我们可以在需求分析方便做一些改进。
5， 客户反馈的bug是否由于版本更新出错引起的， 后期可以考虑改进我们的更新方法，或者出货流程， 避免这方面的错误。
6， 测试遗漏的bug占测试人员发现bug的百分比， 对于测试人员有一定的监督作用（关于这点具体怎么操作， 还没有想好。）
。。。。。
暂时想到这些， 大家还有什么想法呢， 很想和大家讨论一下。。。 我也觉得针对客户的bug应该每隔一段时间就进行分析，这样便于分析我们的测试工作，
以前出现的bug是哪种类型的bug，是异常数据出现的问题，用户操作方面的问题，性能方面的问题
还是其他的问题，找到问题的的原因后，想办法提升我们的测试质量，针对薄弱环节投入更多的精力
和人力，来避免以前出现的问题再次发生，同时，通过客户反馈bug的记录，也能对测试人员有一定的
压力，当测试人员看到记录的这些bug时，自然会有一种责任感，在后面的测试工作中会更加细心和努力
也能间接的提高测试的质量 对于客户提出的bug，我们都会作为测试人员提交的bug一样记录到TD中，其缺陷跟踪的流程跟测试人员提交的bug一样，只是在描述中，增加一个“客户反馈”的字样，没有特殊 标识。
对于Wonder想到的6点中，我觉得想法很好，真不错。 谢谢大家的反馈，因为客户反馈的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生命周期。
目前准备这样去试运行，希望可以给大家一个借鉴，当然也希望大家多多提出宝贵的意见！ 三楼的第六条嘛,在我们公司是这样的,可在测试记录中加上一条上轮测试者是谁,是pass,fail还是NT,fail和nt的都写上理由,然后在每天的日报中加上上轮测试有无次问题. wonder对于你说的Online bug Project,录入客户的BUG,由项目的测试组长录入和确认状态,如果一个测试组长对具体的BUG状态不是很清楚,那怎么操作呢?我们也是把客户的BUG和测试人员的BUG一样都录入到一个BUG库中,只是一个发现人是客户,但现在执行这个客户BUG的跟踪有点混乱,测试人员不对客户的BUG进行跟踪,又客户跟踪的,但客户跟踪BUG又不及时,到了版本后期还会存在客户OPEN的BUG
回复 #9 小小丫 的帖子
小小丫 :目前我们对于客户反馈的缺陷都是由测试人员进行跟踪的，只是在进行跟踪之前首先要对客户反馈的bug 进行一下过滤，
这个是由测试负责人和项目经理来做的，1， 分析是否为bug， 2 ，如果是bug，是否需要修改，
所以其实bug 的定位是项目经理和测试组长一起定位，只是由测试组长维护进bug 管理系统而已，
而对于确实需要改正的bug 是需要录入本项目的正式bug 库的， 其流程等同于其他由测试人员发现的bug。所以不会存在遗漏的情况， 这样做唯一的缺点就是测试组长对于一些bug 需要维护两次， 不过在客户反馈bug 并不是很多的情况下，还可以忍受。 我们有专门的支持系统,用户可以在支持系统中反应系统的Bug,也可以电话的方式反应.Bug的收集工作以及和客户的反馈是由技术支持人员做的,支持人员会把Bug交给项目经理,由项目经理决定是漏测还是别的原因,如果是测试的疏漏,测试负责人组织进行分析,后续的流程和普通Bug基本一样了. 我们公司目前的做法是：
针对客户的BUG，首先进行过滤，看哪些是测试人员忽略的BUG，哪些是新需求，哪些是客户操作不当引起的，然后再考虑哪些是要改的，哪些不必改。
需要修改的录入的CQ库中，以字段区分，如：BUG的来源等。
最后是，每隔一段时间对客户的BUG进行一次分析，一来衡量测试人员的测试水平，直接跟个人的绩效考核挂勾，二来总结一下客户提出的是哪种类型的BUG，提高测试质量，以免以后出现同样的问题。
页:
[1]
