线上bug的分析与处理的个人意见

关于线上bug

1、线上bug汇总后，可以按照版本、类型、等级分类，以便分析 测试 过程中哪些方面、哪些模块更容易漏测。这个分析可以和目 前客户端这边的测试总结有点类似，可以做出一些饼图或者趋势图进行分析。

2、可以将线上bug统一汇总到bug管理系统中（这个是 我们组的组长提出的，觉得挺好的），如bugzilla，但是如果人力来做的话，如果时间紧的情况下可能比较耗时。个人建议QA平台可以在现有bug系统 基础上对bug增加固定格式的导入功能，且能够提供线上和非线上bug的区分，这样运维可以按照标准格式统计，经项目组人员具体协商哪些是bug后直接导 入QA的bug系统，不知是否可行。

3、关于线上bug的原因：时间紧张无法先编写用例而直接进入测试，这样边测试边考虑的过程肯 定比先编写用例、用例review再进行测试的过程欠缺一些方面的考虑，且当组内成员交换模块测试时，因为没有用例参考，或多或少会浪费时间同时遗漏测 试。

4、组内共享：各个产品线上bug都不一样，所以当各个产品线上bug产出分析报告后，应该能够互相分享交流且总结出一些通用 的经验和教训，这个和编写公共测试用例有点类似。

 

关于开发已知的bug

   对于一些研发上的策略 可能引起的风险，或者一些控件、接口等本身存在的缺陷而导致程序出现的一些问题，测试人员并不一定能够及时发现或者在测试报告中指出，故开发人员本身对自 己编写代码的风险考虑、程序漏洞也需要做一个分析，并同时提供给测试人员，这样即节省了测试时间，也能够让测试更全面的进行测试。对于有些开发本身已知的 bug，更需要及时通知测试人员报入bug系统。