提醒：本文最後更新於 1242 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

經常關注我部落格的同學可能會發現，我的部落格文章從來沒有涉及到我所負責的專案、內部工作流程或配套工具。因為專案中遇到的很多問題和對應的解決方案都是基於一定條件所產生，並不具有普適性。內部的工作流程和配套工具也是一樣，對於非開源的內部工具或系統來說，無論我把它寫得多麼天花亂墜，對於我的讀者來說價值都是零。

所以我的部落格有很多純粹的技術知識，例如 HTTP/2、HTTP 協議；也有一些普適的技術經驗，例如對 Web 服務效能和安全性的優化；還有一些我對開源工具、系統的試用心得，例如 Sublime Text、Alfred，對程式碼 Review 系統的思考，以及今天要寫的移動應用測試平臺 —— Bugtags。

首先用一句話定義這個平臺：一款著力於提升移動應用測試效率的產品。

這麼說大家肯定不明白，先來描述一下大部分中小移動開發團隊進行應用功能測試的流程：開發工程師完成功能開發後，團隊裡面的每個人都要投入到測試中。測試過程中如果發現了問題，需要截圖、手機連電腦並匯入截圖、記錄裝置資訊、儘可能詳細地描述 bug，最終提交到例如 JIRA、Redmine、Bugfree 這類管理系統中。之後的流程就跟傳統 web 專案測試無異了。

可以看到，對於應用的功能測試，如何全面、方便地收集 bug 是一個痛點。

先拿 bug 資訊的全面性來說：網路是 2G 還是 3G、GPS 是開啟還是禁用、記憶體是否夠用、與服務端的資料互動是怎樣的（request 和 response）、產生 bug 的操作步驟，這些都不可或缺。對於開發同學來說，越全面的資料意味著 bug 越容易被複現和定位，也就可以為專案測試階段節省更多的時間，這一點我想不用多解釋了。

再來看看便利性。有些同學會說現在的手機已經做得都挺好用了。是的，單個手機看來都挺好，十幾個測試機放你面前就知道安卓機的奇葩之處了。有些手機返回鍵在左、選單鍵在右，有些手機恰好相反。還有，我到現在也沒完全搞明白我那些測試機都是如何截圖的，每個手機的截圖方式都不一樣，甚至裝不同 rom 之後都不一樣，有些手機要截圖還需要 root。所以我一般在報 bug 時，如果一定要截圖就拿另外手機拍下來。

我這樣喜歡折騰的技術人員都覺得給移動應用報一個高質量的 bug 是一件難事，團隊裡那些 leader、產品經理、設計師就更痛苦了。

當然，對於大公司來說，這些其實都不算是問題，大公司有專門的測試人力和相對充裕的測試時間，也會開發內部工具和平臺解決這些問題。但是這些工具都是基於自己業務開發的，目前還沒看到哪家公司開放出來給第三方使用。

而 Bugtags 就是一款試圖解決以上痛點，並且開放給第三方開發者使用的平臺。經過一段時間的內測，發現相比傳統的應用測試流程，它有以下優點：

1）SDK 整合簡單

Bugtags 做到了一行程式碼快速整合，不影響原有程式的結構，也不增加額外開發工作量（地球人都知道，如果整合成本高，再好的東西也沒人用）。整合後，會在應用介面出現一個可以拖動的懸浮小球，原有功能沒有任何影響。

2）所見即所得提交問題

團隊成員在測試應用功能的時候，如果發現了 bug，可以在當前介面點選懸浮小球，實現一鍵截圖（是的，忘記那些安卓機奇葩的截圖方式吧）、編輯標籤、描述問題。

3）自動收集裝置與應用執行狀態

提交問題的同時，會附帶自動收集到的裝置資訊、應用執行時資料等額外內容（再也不用手機連 PC，藉助 Fiddler、Wireshark 來抓包定位問題了），同步傳到雲平臺，幫助開發人員更好了解問題發生時裝置和應用的狀態，有利於問題定位和解決。

4）自動收集分析閃退資訊

對於閃退這種對使用者傷害很大的嚴重 bug，Bugtags 可以自動收集和分析，自動提交到雲平臺（附贈的全自動功能，不用白不用）。

5）簡單高效的 Bug 生命週期管理

Bugtags 雲平臺抽取傳統缺陷管理系統的最核心功能，能有效管理和跟蹤問題（Bugtags 自帶 bug 管理系統，不需要再搭建 JIRA、Bugfree 等同類軟體了，系統越多管理成本越高，能省就省）。

如果你有過類似的移動應用測試經歷，看到這裡一定也想要試用一下這個平臺，Bugtags 目前處於邀請內測階段，第一批大約有 20 個團隊的使用者。如果你也想嘗試一下，請給我留言。

Update @ 22/08，Bugtags 官網已經上線了，請訪問官網瞭解更多資訊：https://bugtags.com。

--EOF--

發表於 2015-08-17 18:42:02 ，並被新增「 軟體開發 」標籤 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 1242 天前，文中所描述的資訊可能已發生改變，請謹慎使用。