Duolingo 的內部測試是如何運作的

Duolingo 的內部測試是如何運作的？在 Duolingo，我們鼓勵 Duolingo 員工下載該應用程式的最新內部版本，無論是 Android、iOS 還是 Web 客戶端（或三者兼而有之！）並定期使用。這個內部應用程式執行最新的應用程式版本，透過它我們可以在新功能和應用程式改進到達使用者之前對其進行測試。

在 Duolingo，每個人都被鼓勵進行測試，而不僅僅是那些構建面向使用者的功能的人。目前，公司超過 70% 的員工都是測試者，包括我們的執行長，他每天在多種裝置型別上的多個課程中測試我們的應用程式。

除了在各個級別營造一種測試文化外，Duolingo 還舉辦了一年兩次的語言挑戰賽，為員工在 6 個月期間持續參加測試語言課程提供經濟激勵。我們的同事在完成課程時提供了很多深思熟慮的反饋！

測試資料

一旦新的應用程式版本可用，Duolingo 員工就會被鼓勵下載並開始測試，這將開始從新版本收集遙測資料：應用程式無響應 (ANR) 事件、應用程式崩潰和記憶體不足等效能指標（ OOM）事件和幀速率。我們還利用 Google Firebase Crashlytics 跨客戶端和應用程式版本細分應用程式崩潰資料。

事實上，我們僅從測試構建中就獲得了大量資料，因此我們構建了工具來從遙測中收集早期見解並擴充套件我們的工程運營。對於應用程式效能指標，我們建立了一個釋出儀表板，該儀表板在新版本進入測試後立即顯示遙測資料 - 我們通常能夠在幾個小時內獲得每個版本的可靠訊號。

釋出儀表板，其中包含 iOS 測試構建的效能指標

這使得工程團隊能夠監控即將釋出的版本的效能，如果指標有所提高，則可以調查並進一步瞭解可能在何處引入了迴歸。

我們還構建了一個名為 Jeeves 的內部工具，它從內部測試錯誤報告和外部反饋中收集使用者反饋，其中包括我們的測試版程式、Reddit、Twitter、Google Play 和 App Store 以及 Zendesk 等輸入。Jeeves 使用人工智慧將這些資料聚合成 “峰值”，即趨勢單詞和短語。

Jeeves 監控

我們的質量保證和工程團隊可以過濾報告中生成的峰值，從而使團隊能夠在學習者發現可能影響使用者體驗的問題之前識別、分類和修復這些問題。

儘早並經常消滅 bug

內部團隊從測試過程中發現的錯誤中獲得了巨大的價值。為了更輕鬆地歸檔和調查錯誤，我們建立了一個名為 Shake-to-Report 的內部工具，它允許員工快速報告錯誤，以便工程團隊可以在錯誤到達使用者之前開始解決它們。

搖動報告的工作方式與它聽起來的差不多：如果員工在使用該應用程式時遇到錯誤，他們可以搖動裝置（或在 Web 客戶端上單擊按鈕），從而彈出內部錯誤報告表。

搖動報告選單

為了幫助診斷錯誤，報告會自動包含螢幕截圖和大量後設資料，包括當前處理使用者的實驗、使用者的裝置和應用程式版本以及使用者的特定課程和課程資料。我們在每個錯誤報告中都包含一個獨特的 Fullstory 記錄，顯示使用者在遇到錯誤之前在應用程式中執行的操作。Shake-to-Report bug 還包含一個日誌檔案，該檔案特別有用，因為工程團隊經常在不同點新增日誌語句以幫助除錯問題。

例如，在我們在 iOS 應用程式中推出數學和音樂課程之前，Duolingo 員工對這些新課程的內部構建進行了幾個月的測試！在正式釋出前幾周，音樂課程背後的團隊注意到有關音樂課程崩潰的持續測試錯誤報告，與 Crashlytics 崩潰率的上升同時發生。

音樂課程崩潰 了

為了診斷崩潰，該團隊新增了額外的語句來記錄使用者的音樂課程資訊、歌曲資料和課程互動。隨著狗食錯誤報告不斷出現，團隊分析了更詳細的日誌並確定了根本情況：以特定模式暫停歌曲導致的邊緣情況。距離 iOS 上的數學和音樂課程推出僅剩幾周時間，他們透過在測試錯誤日誌中記錄額外資料，實現了修復！

釋出儀表板、Jeeves 和 Shake-to-Report 由 Duolingo 的測試和釋出基礎架構團隊維護，他們與客戶工程師和 QA 密切合作，以確保無縫的應用程式釋出流程。週一早上，在推出最新的公共應用程式版本之前，我們的內部 QA 團隊會檢查週末測試中報告的錯誤。除非沒有任何錯誤阻礙或顯著影響使用者體驗，否則我們不會開始應用程式部署。（非阻塞錯誤由 QA 團隊進行分類。）

透過在全公司範圍內建立內部測試文化，我們能夠保持持續的資料流，幫助我們保持應用程式質量並不斷改善我們的應用程式體驗。（原文連結：https://blog.duolingo.com/dogfooding-app/）