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、 使用不同