Android客户端线上BUG收集、反馈及定位

1.  线上BUG来源

用户反馈

用户反馈由运营或者客服或PD童鞋进行收集，对集中反应比较多的问题反馈到项目组及相关童鞋，对体验不好的地方进行产品改进。

回归测试

每周服务端预发和上线以后，在客户端进行回归测试工作，现在是由专门的童鞋进行回归，以后的方向是自动化回归。

适配测试

对于厂商反馈的适配BUG，由相关测试童鞋进行验证，不管是通性BUG还是适配BUG都属线上BUG,测试童鞋应及时反馈给开发童鞋，优先级最高。

当然线上BUG来源有很多，项目组童鞋在日常使用的过程当中，或是自动化回归的测试当中也会发现一些问题，都及时反馈给相关童鞋就好了，避免用户反馈的时候才去跟进，这样有利于减少线上BUG的在线时间。

2.  线上BUG反馈给

线上BUG应该反馈给PM、QA、TL以及项目级成员。

PM作为Ower，排出优先级，可指定QA进行定位，督导开发解决，直至问题完全fixed。由于线上BUG分为两类：客户端的BUG和服务端的BUG，如果是服务端的BUG，客户端PM应该能够举证并且通过严重级别督促服务端开发尽快解决问题。

3.  线上BUG定位

测试童鞋通过以下方法快速定位：

1、 为了节省定位时间，进行有针对性的验证，尽可能多的了解BUG产生的环境（比如：使用的网络、机型）

及操作步骤

提醒：开发童鞋应该对软件发生错误的提示进一步优化，做到更加明确，这样用户反馈以后我们就可以快速定位了。

2、 根据反馈的功能点进行针对性的回归接口测试用例

3、 用Debug包进行测试，查看抓取的log，观察请求的API是否正确（有一次付款时支付宝插件调用不成功就是通过log分析出来的，原因是请求的IP地址不正确）

4、 使用不同的网络（WIFI/移动/联通/电信）及接入点（cmwap/cmnet）进行定位

5、 使用不同的机型（MOTO/索爱/夏普/华为/联想/阿里云等）及不同的系统版本（1.6/2.1/2.2/2.3等）进行定位

不是所有的用户反馈都是BUG，但是用户也不会随便反馈问题，如果有用户反馈遇到了问题，要么就是产品体验做的不够好，要么就是用户操作有出入，再要么就是线上BUG。我们谁都不想出现线上BUG，但有测试时因为这样那样的原因，又不免有遗漏，所以但凡遇到用户反馈，我们QA或者相关项目组的童鞋都有义务想办法帮助用户解决问题。

作者: 毕小朋    e-mail: [email protected]   微博：http://weibo.com/00tester    转载请注明出处：http://blog.csdn.net/alexbxp