擁抱高效、擁抱 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 環境下，提供一些流量方面的統計。