客服團隊如何在多台真實 Android 手機上重現問題

一個實用的支援工作流程，可以將特定於裝置的Android投訴轉化為可重複的案例、證據包和有用的工程交接。

為什麼支援團隊保留多臺安卓手機？

客戶可以準確描述故障，但支援團隊仍然無法重現故障。應用程式版本可能是正確的，但問題只出現在一個製造商版本、Android版本、顯示器尺寸、許可權狀態、語言、網路或電池策略上。單一參考手機無法代表該範圍。這就是為什麼移動支援團隊即使工程已經使用模擬器和自動化測試，也經常保留一小組真正的Android手機。

目標不是擁有每個模型。而是保持足夠的覆蓋範圍，以快速回答三個問題：團隊是否可以重現報告，什麼條件觸發了報告，以及哪些證據可以讓工程人員繼續工作而不重複整個支援對話？AWS Device Farm同樣將客戶支援代表與開發人員和QA團隊一起識別，並將真實裝置互動描述為除錯和重現客戶問題的一種方式。

• 身份驗證、付款、通知、許可權、相機、藍芽和後臺處理失敗。
• 在特定螢幕密度、字型比例、語言或導航模式下崩潰的佈局。
• 與Android版本或製造商韌體相關的升級或安裝問題。
• 僅在網路更改、應用程式後臺執行、電池限制或中斷後才出現的問題。
• 客戶報告需要截圖、簡短錄音、裝置詳細資訊和確切的複製步驟才能升級。

在選擇手機之前，請收集最低限度的手機殼資料。

不要先點選隨機的電話來開始。首先，將支援對話轉換為一個可測試的案例。缺少的輸入資料浪費的時間比物理裝置設定還要多，因為團隊無法區分特定裝置的缺陷與帳戶、構建、網路或過時的資料問題。

如果客戶無法提供所有資訊，請記錄未知的資訊，而不是默默填補空白。支援人員仍然可以測試已知的途徑，但工程人員應該能夠看到哪些假設被做出了。切勿要求客戶傳送密碼、付款詳細資訊、身份證件、私人訊息或與個人檔案無關的個人檔案。

從客戶證據中構建一個小型裝置矩陣

一個有用的支援臺是基於客戶實際使用的裝置，而不是一架充滿吸引力的旗艦手機。從分析、崩潰報告、票據數量和收入關鍵細分市場開始。選擇一臺低端裝置、一款常見的中端機型、一款最近的旗艦機型，以及任何在未解決案例中反覆出現的製造商或安卓版本。

1. 從可靠的產品資料中匯出頂級裝置型號和Android版本。
2. 按製造商韌體、效能等級、螢幕特性和作業系統版本將類似裝置分組。
3. 選擇覆蓋最大重要案例份額的最小物理集。
4. 只有當票據或產品風險證明其維護成本是合理的時，才新增模型。
5. 每季度審查矩陣，並淘汰不再代表有意義流量或風險的裝置。

三到六臺電話臺通常比一個大型、未維護的收藏更有用。更廣泛的相容性仍然可以透過雲服務進行運行。本地臺的存在是為了快速互動式複製、支援演示和重複使用相同裝置的情況。有關物理設定，請參閱低成本安卓裝置實驗室指南。

整理多電話支援臺

每部手機都需要一個穩定的身份。給它一個短程式，在實體上標記它，並記錄其型號、安卓版本、上次重置日期、電池狀況、連線方法、安裝測試版本和分配的測試帳戶。當多部手機共享一臺電腦時，請使用可靠的電纜和帶電源的USB集線器；不穩定的電源和損壞的電纜可能會導致看起來像應用程式缺陷的故障。

控制多臺安卓手機當團隊需要比較螢幕、在裝置之間移動或重複授權的設定步驟時，從一個共同的工作空間。 入萊彩投屏，裝置可以從一個Windows或macOS工作站中檢視，因此操作員花費的時間在接聽電話上減少，花費的時間在比較案例狀態上增加。分組對於分離乾淨的基線、活躍的支援案例、低端裝置和等待重置的手機很有用。

• 保留一個已知良好的基線裝置進行比較。
• 儘可能使用帶有合成資料的專用測試帳戶。
• 在以前的狀態可能會改變結果的情況下，重置案例之間的應用程式資料。
• 在每張螢幕截圖或案例備註中都保持電話程式清晰可見。
• 記錄充電、USB、Wi-Fi和熱量條件，當它們影響測試時。

執行一個受控的複製過程

通往有用的結果的最快途徑通常是受控的比較，而不是大量同時的操作。從最接近匹配的裝置開始，重現客戶的初始狀態。一次執行報告的步驟，不要更改任何內容。如果出現問題，請重複執行以確認頻率。如果沒有出現問題，請一次更改一個變數：網路、許可權、語言、應用程式資料、Android版本、製造商、字型比例或電池策略。

1. 建立包含電話程式、應用程式構建、帳戶型別、網路、地區/語言和起始螢幕的案例卡。
2. 在最近的匹配電話上重現客戶的確切步驟。
3. 在已知良好的基線手機上重複相同的步驟。
4. 只更改一個疑似狀況，然後再次執行該路徑。
5. 當觸發器被孤立或達到商定的嘗試限制時，停止。
6. 記下成功和失敗的嘗試；負面證據可以縮小下一次調查範圍。

當裝置已經分開時，請勿使用同步輸入。許可權對話方塊、載入速度緩慢、鍵盤或更新提示可能會將相同的單擊傳送到不同的控制元件。共享操作只有在每個選定的手機都顯然處於相同的安全狀態時才有用。否則，請單獨操作裝置，並保留您正在嘗試理解的差異。

建立一個證據包，工程師可以重播

一個有用的交接要足夠小，可以快速審查，足夠完整，可以重播。一張票應該連線環境、步驟、觀察到的結果、預期結果和支援證據。螢幕截圖證明了靜態狀態；簡短的螢幕錄製證明了時間和順序；日誌解釋了介面無法顯示的內容。這些都不取代其他內容。

將檔案命名為票據ID、電話程式、版本和時間戳。交接應該讓工程師在幾分鐘內理解故障，而不需要開啟多個聊天執行緒。有關更廣泛的QA工作流程，請參閱用於移動應用程式測試的Android螢幕映象。

選擇本地電話、模擬器或雲裝置服務

這些工具解決了不同的覆蓋問題。本地電話臺不能取代雲裝置農場，雲實驗室也不能消除支援團隊旁邊熟悉的電話的價值。選擇能忠實地重現情況的最便宜的環境。

一個實用的順序是先使用模擬器進行快速的無誤性檢查，用本地手機檢查可能的真實裝置原因，如果型號缺失或需要更廣泛的確認，則使用雲裝置。在PC或Mac上進行Android螢幕映象當支援需要直接對本地電話進行視覺控制，而不是對分散式企業車隊進行策略管理時，它是最有用的。

在複製過程中保護客戶資料

如果流程不小心，真實裝置故障排除可能會洩露個人資訊。預設情況下，使用合成帳戶和測試資料。如果真的需要生產資料，請獲得正確的授權，限制訪問許可權，僅捕獲案件所需的內容，並遵循公司的保留政策。AWS也警告其裝置服務的使用者，不要輸入帳戶憑據、個人資訊或其他安全敏感詳細資訊，因為會話可能會產生日誌和影片。

• 切勿將客戶的密碼、付款資訊、身份驗證令牌、私人照片或身份證件複製到實驗室手機上。
• 在附上證據之前，請模糊或裁剪無關的姓名、訊息、電子郵件地址和帳戶號碼。
• 根據公司政策，將測試帳戶分開，並根據環境輪換憑據。
• 在保留期結束時，刪除螢幕截圖、錄音、日誌、下載的檔案和應用程式資料。
• 記錄誰訪問了敏感案例，以及為什麼，當政策要求進行審計跟蹤時。

使用三部手機操作工作流程

不要先購買一牆電話。選擇一個定期的支援案例類別和三臺代表性裝置：已知良好的基線、最常見的客戶電話和與之形成對比的低端或特定製造商的電話。執行工作流程兩週，然後決定是否另一個裝置或雲服務可以解決試點人員無法覆蓋的案例。

1. 選擇十張最近因裝置不確定性而延誤的票。
2. 定義所需的輸入欄位和一個單一的證據包模板。
3. 標記並準備三部帶有乾淨測試帳戶的電話。
4. 追蹤到第一次有意義的複製、澄清迴圈、升級接受和未解決的裝置差距的時間。
5. 檢視哪款手機或環境條件實際上改變了結果。
6. 只有當證據表明有重複的覆蓋差距時才擴充套件。

要驗證的結果很簡單：支援工程師應該能夠接收一個案例，選擇一個合適的電話，重播路徑，並在不搜尋幾個無關的系統的情況下提供一個自給自足的接管。如果共享的本地工作區有助於該試點，萊彩投屏可以從一臺Windows或macOS計算機上保持所選的Android手機可見且可控制。

常見問題

支援團隊需要多少部安卓手機？

從實際票據和使用資料中選擇三到六部手機開始。只有當重複且重要的案例無法由當前的矩陣或偶爾的雲會話覆蓋時，才新增裝置。

是否應該支援複製每個客戶報告？

不。優先考慮嚴重程度、受影響的使用者、業務影響、安全風險、復發情況以及複製是否會改變下一步行動。裝置實驗室是一個決策工具，而不是每次都重複每一個模糊的投訴的必要條件。

同步控制能否同時在每部手機上複製一個錯誤？

只有當裝置明顯處於相同狀態且操作安全時。一旦時間、對話方塊、許可權、鍵盤或佈局不同，請單獨操作手機。差異是證據，而不是盲目點選的東西。

LaiCai是否取代了移動裝置管理平臺？

沒有。萊彩投屏是一種本地視覺控制和工作流程工具。需要零接觸註冊、策略執行、應用程式分發、庫存或遠端擦除的分散企業車隊應使用適當的MDM或EMM系統。

來源

• AWS Device Farm常見問題解答
• AWS Device Farm開發者指南
• OpenText移動和網路功能測試實驗室
• 三星遠端測試實驗室
• 谷歌Android企業支援指南