拥抱高效、拥抱 Bugtags 之来自用户的声音 2

碰见 bugtags 以前那点事

那些年，咱们单车娱乐 App，自研发到上线，苦逼的在友盟，bugly，bughd 等各类 bug 反馈的工具来来回回踩坑，然而让 QA 和 PM 以及最身同感觉的咱们这些一线开发工程师表示各类吐槽...

1. 线上的bug收集时候，都不是实时的，很容易丢失现场环境数据，难以跟踪并重现问题，鉴于使用环境以及设备的多样性，一旦发布出去的 App，必然或多或少都有各类奇葩兼容崩溃问题。全世界手机这么多，能 fix 得过来么？
   
   （各类 npe，各类 ise，别介，我已经懒得吐槽了）

2. 大部分 bug 展现的信息只有基础设备信息和一些崩溃的日志，然而没什么用，由于崩溃或多或少都涉及到用户的使用环境才能重现并得知问题缘由从而进行修正处理。
   

3. 人肉测试占比例很大，尤为是在测试过程当中，一旦发生意外，处于一线开发的工程师就像消防员那样十万火急的救火，为的是意外的现场日志以及相关操做流程。（人肉测试的苦，谁作谁知道）

4. 曾经对 QA 来讲的一场噩梦：截图，状况描述，环境描述，操做描述等等相关bug的反馈，让 App 的质量保证愈加紧张和效率低下。

QA：这个bug修复了么？
App工程师（就是我）:没有，我还在研究这怎么出现的
（10分钟过去了。。。）
PM：刚才我测试崩了，大家看看神马状况
QA，一众工程师全围观上纷纷议论。。。。

鉴于以上四点吐槽，我相信各位看官感触良多，然而相似的故事也多不胜数，终究是为了对 App 开发有个更好的质量保证。当同事给我推荐了 Bugtags 的时候，我立马来了精神：这尼玛就是我要的 bug 神器啊，简直黑科技啊，拯救 QA，PM，以及一线开发工程师于水深火热之中啊！

和 bugtags 的一见倾心

别不说，通过在官网的注册浏览一些教程以后，我立马在本身正在开发的 App 集成bugtags，并当场发布内部版本给 QA 作一些简单指导：

1. 打开 App 就看到那个蓝色的 bugtags logo，没错，就是这货；
   

2. 点 bugtags 小球后会有操做项；
   

3. 第一次打标签有引导提示，告诉你怎么玩；
   

4. 在错误的位置上点击一下，添加一个标签，写完 bug 描述后，肯定；
   

5. 提交
   

对于 QA 和 PM 以及全公司一块儿参与 App 测试反馈，这简直是神器，太特么的神器了。。。

神马人人都是产品经理，在 bugtags 的时候，人人都是 QA 工程师了，均可觉得 App 出一分力以提升app研发质量。

然而到这里就完了？并没，在 bugtags 的系统，这只是小小的前戏，在bugtags web的系统上，你能够看到各类信息：

1. 首页就是总体应用的相关状况；
   
   （一个字，一目了然，啊，不对，是四个字）

2. 接下来才是咱们 bugtags 主场，大部分工程师都围绕这里工做，你能够看到 bug 的归纳信息，而且进行过滤，从而开始咱们修复工做；
   

3. 点击具体问题，就能够看到与之对应的问题信息，包括截图，设备环境以及设备信息，用户步骤，以及堆栈信息等等，很是全面；
   

固然，你也能够考虑看看最右边的详细数据以选择是否优先处理这个问题。 看到这里，bugtags 对于咱们这个 team 来讲，暂时就接触到这里了。

将来一段时间，会对 bugtags 加以深刻，好比：

1. 对一些崩溃，进行必要数据收集，更方便确认崩溃现场数据究竟是哪里出错。
2. 用户反馈信息的集成，这样更好的处理用户以及测试的优化方案。

对于 team 来讲，团队的成员会在相应的问题下面进行追踪历史记录。

就目前来讲，咱们单车娱乐 App，从九月中开始，已经用 bugtags 有些日子了，不单是用来作测试反馈修正，还在线上发版用来崩溃信息收集，兼有了可视化，可量化，可回归的开发模式。由于开发和维护的紧张繁复，拜托了 bugtags 的一臂之力，从而变得有序进行了。

指望 bugtags

说实话，一个好的工具，能成倍的提升效率，这点在 bugtags 已经彻底体现出来了。在这一个多月的相处来讲，bugtags 确实解决了一个痛点，绝大部分平台没留意到的痛点，恰好这痛点可让你对 bug 再也不以迷惘方式去处理了。

感谢 bugtags，造福咱们这些工程师，有更多时间享受生活，你们晚安！