小編按：這是一篇 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 環境下，提供一些流量方面的統計。