拥抱高效、拥抱 Bugtags 之来自用户的声音（三）

小编按：这是一篇 Bugtags 用户来稿，主要是介绍了使用 Bugtags 前后对测试及解决 Bug 所带来的变化，感谢山西农业大学 - 高正炎同学对 Bugtags 的信赖和支持。小编在这里诚邀各位热心用户向我们投稿，说出你使用 Bugtags 的故事。

0x01 前言

写在 Bugtags 上线 Crash 发生趋势之际，以及英语四级前夜。仅感触，无其他。

0x02 起缘

在 9 月份的时候，开学之际，随着 Codekk 微信号推送了一条名为 “移动应用Bug快速反馈利器” 的消息，工欲善其事，必先利其器。
看完介绍了以后，不禁感觉眼前一亮，和以前接触的 Crash 收集工具有点不一样，并且也听说过一些摇一摇进行反馈的功能。
这个主要是一个类似于外包的项目，应用内容是大学内 App 社交、社区等形式，其中整体 App 需要一个良好的架构，
以及完善的测试（然而并没有测试），只好在边开发边测试。
最初我们在应用开发上，采用的 git 版本控制，主要两个人进行开发，并没有测试妹纸。（ 最初找了一个“设计师”同学 ），在经理提出项目需求和改进时，
往往通过经理去告诉给另外一个人，然后另一个人进行评估，直接在代码里进行修改，并且没有记录，整个过程并不透明。
后来经理会找张纸记录一些问题，解决了打个对勾，但是这还是不好管理，并且对于机型的不确定性，以及 Bug 的难复现，降低了一些效率。

此处应该有图片：

在公众号信息里，展示了提交 Bug 的流程，然后试着集成了一下 SDK，整体集成的过程并不麻烦，很快感受到了效果，并推荐给了另一位开发。

在接入以后，熟悉了提交 Bug 的方式，感觉相见恨晚，很适合经理在提哪有问题，哪需要改进。

0x03 成长

在接入应用以后，效率上感觉到了一些方便，但是就发现了一些问题，比如那会会一直邮件收到提醒，并提了工单，
在 QQ 群里也进行了咨询，并且收到了这个问题正在解决中，会在下周上线。
并且 Bugtags 提交 Bug 时，整体流程并不麻烦。

令人感到欣慰的是，Bugtags 团队的迭代，使得 Bugtags 不断的完善，随着使用中，逐渐上线了以下几个特性：

增加几种标签状态和类型。

区别了开发人员和提交 Bug 人员

可以批量修改状态和删除标签

Crash 可以抓到截图

支持了导出功能

增加匿名提交

添加了批量邀请成员等功能

……

在团队的不断迭代开发应用的过程中，收到了很多经理的提的标签，经常一天提十几条，如果按照往常的列出清单，然后一个一个去解决，会浪费很多时间和效率。
应用也在 fir.im 内测，不断的去完善，提高着自己的开发技能，奔溃影响机型数从最初的少量的几台手机在逐渐增加。

此处应该有图片：

0x04 伴随

在使用的过程中，提交的问题越来越多，收到的标签也越来越多，毕竟是一个 App 应用，从 0.1 到 0.9 的过程（0.1指接入时已经开发了一个简单原型）。
一张现在的统计，标签已经不少了，此处继续应该有图片：

问题界面：

随着不断的使用，发觉提高了不少效率，在这将近三个月的相处之中，感受到了 Bugtags 团队的不懈努力，感受到了对开发与测试的关注。
并且现在也提供了一些可视化的数据，来表达测试的效果，以及应用的完善程度。
在上线以后，我们也重点关注了一些 Crash，并且 Crash 相对于以前来说，更加好复现，并且对其进行了改进，优化应用的性能，提升了一些用户体验。
因为机型和系统不同，作为一个 Android 开发者，不可避免地会遇到很多 Crash，当用户遇到了以后，作为开发也很无奈，毕竟比较难复现，
有了 Bugtags 了以后，可以及时地统计机型，系统版本，以及用户所执行的步骤，
现在最近又上线了 Crash 的发生趋势，可以让开发专注于近期发生频率高的 Crash 进行改进。

此处应该有图片：

在今年的华北五省计算机应用大赛的答辩现场，也给评委们简单介绍了一下这个 Bug 管理平台，提高了一些开发效率。

0x05 后记

你们的测试妹子、霸道产品、老板肯定需要它很久了，爱他恨他就转给他。

在 Bugtags 之前，并不知道有相关的 Bug 管理平台，作为一名开发者，Bugtags 是值得推荐的。

最后提几点意见（其中有些不知道中肯与否）：

开发 Android studio 插件，实现可以收到紧急标签会提醒。

开发 Android 客户端，实现可以移动管理标签状态。

开放一些 API，实现自定义配置

希望可以提供一些移动应用测试，例如 Monkey 之类的实践。

如果是非 Wi-Fi 环境下，提供一些流量方面的统计。

​