擁抱高效、擁抱 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，造福咱們這些工程師，有更多時間享受生活，你們晚安！