如何避免移動測試自動化失敗

Nadya Denisenko 說，移動開發中的測試自動化應該由 Scrum 團隊完成；不要建立單獨的測試自動化團隊。她建議遵守移動測試的測試金字塔，并從一開始就讓測試人員參與進來。測試人員是面向質量的開發人員，他們可以指導和幫助其他開發人員交付高質量的軟件；手工測試將在未來消失。

移動開發是廠商鎖定的。Denisenko 說，市場上有兩大廠商決定操作系統、應用程序、開發和測試的走向。此外，大多數公司都在尋找能夠在兩個平臺上開發自動化測試的測試自動化獨角獸。Denisenko 說，這意味著手機領域的自動化工程師至少應該了解 Kotlin、Swift、Java 和 Objective-C，以及 iOS 和 Android 的工作原理，他們預期自動化工程師有能力手動測試這款應用，但事實并非如此。

Denisenko 表示，移動應用程序以開發速度快著稱，在大多數情況下，QA 都是在產品上市很長一段時間后才開始參與。她說，在一個習慣了長時間沒有測試人員的團隊中建立測試流程會帶來大量的挑戰。她建議慢慢來：首先，與開發人員一起構建一個測試自動化框架，將引入 sprint 的特性自動化，并實現一個回歸場景。

Denisenko 說，與 web 或后端項目相比，移動項目非常??；對于 Scrum 團隊能夠或者應該處理的任務來說，單獨的自動化測試團隊是沒有意義的。

Denisenko 提到測試人員的角色是指導和幫助開發人員交付高質量的軟件。她說：“我堅信測試人員是面向質量的開發人員，手工測試在未來將消失或改變。”

Denisenko 說，越來越多的公司希望開發人員可以負責開發可測試的代碼和測試。她從一個人工測試人員成長為測試自動化工程師，相信測試人員的角色正在轉變為軟件開發測試或代碼質量評估教練。

InfoQ 正在報道 2019 年的歐洲測試大會 ，有幸采訪了 Nadya Denisenko ，與她談論了在移動測試自動化中失敗的方法以及如何避免失敗。

InfoQ：你在演講中說過，單獨的自動化團隊是在浪費錢。你能詳細解釋一下原因嗎?

Nadya Denisenko：一個主要原因是測試的設計。在決定測試覆蓋率時，我們中的大多數人使用 70% 的單元測試、20% 的集成測試和 10% 的 E2E 自動化測試的測試金字塔。在移動世界中，違反測試金字塔的做法很常見，結果要么是測試沙漏型，要么是測試冰淇淋甜筒型。在大多數情況下，擁有一個獨立的自動化團隊意味著這樣一個團隊的主要關注點是自動化 E2E 測試，因此根據測試設計來分配資源更有意義。

InfoQ：測試金字塔比沙漏型或者冰淇淋型更合適?

Denisenko：是的。測試金字塔可以更好地控制應用程序中發生的事情，并節省調試問題的時間。

InfoQ：為什么移動測試人員會違反測試金字塔?

Denisenko：根據具體情況，有以下幾個原因：

銀彈。管理人員和一些開發人員 (特別是后端開發人員) 認為，通過使用 E2E UI 測試，可以在所有真實環境中運行。此外，他們認為這些測試將涵蓋 API 測試、后端和客戶端集成測試的缺失，這是錯誤的。由于平臺的限制，有太多東西無法在移動設備上測試。舉一個簡單的例子，比如深度鏈接外部應用程序推送通知。人們也容易忘記，在后端和應用程序 UI 之間有太多的層，所有這些層都可能出錯，而且據我所知，沒有哪個框架能夠提供關于問題確切位置的詳細信息：第三方、后端、網絡、應用程序的網絡實現、UI，所有你能說得出的都做不到。結果，項目最終只留下些不可維護的測試和令人失望的測試自動化。

時機。新的移動項目總是以 MVP 的身份開始，然后發展壯大。它總是在不考慮應用程序的可測試性的情況下開始，這意味著該應用程序在設計時沒有考慮過單元和 E2E UI 測試之外的測試。當開發人員發現需要進行深入測試時，得進行成本高昂的變更，于是團隊只能選擇忽略。

專業知識。有時這只是一個專業知識的問題。集成測試是移動測試中的一個新浪潮，并不是每個開發人員都有足夠的知識理解什么是集成測試，以及如何進行集成測試。有些人甚至沒有學習的欲望。

InfoQ：在自動化移動測試方面，你學到了什么?

Denisenko：我學到了：

在加入一個沒有自動化的項目時，千萬不要試圖玩趕進度的游戲。

在開發測試自動化框架時，盡可能使用供應商的測試框架。開源解決方案往往會在 OS 新版本發布六個月后才發布對最新 OS 版本的支持 (這意味著在此之前任何自動化測試都不能在最新的 OS 上工作)，而且它們往往還會停止更新。

不要試圖調整為其他項目開發的測試。最終陷于不斷的測試集成，在整個 Sprint 中修復測試，而不是專注于開發和維護我自己的測試。

使用自己擅長的語言。開發人員很懶，他們永遠不會僅僅為了測試目的而學習 Ruby 或 Python。

質量是一個共同的責任，每個團隊成員都應該為它做出貢獻。

InfoQ：蘋果和谷歌提供了哪些測試指南，我們應該如何使用它們?

Denisenko：測試指南是：

谷歌建議進行不同層次的測試：單元測試、集成 (組件間的集成)、UI 測試、功能 UI 測試、E2E 測試。谷歌試圖培養一代知道如何在不同級別上測試代碼的開發人員，最好是使用測試自動化。他們已經編寫了很多關于這方面的教程，Google 的測試社區非?；钴S。

然而，蘋果鼓勵開發者開發單元測試和 E2E 測試。他們建議開發人員在實際用戶使用應用程序時實現自動化，并在 E2E 測試中實現自動化。

在我看來，供應商不應該影響開發人員和測試人員，讓他們決定哪種策略更好。通過增加規則和設置限制，它們實際上減少了創造出新的、更好的和創新的東西的可能性。

查看英文原文： How to Avoid Failing at Mobile Test Automation

原文轉自：https://www.infoq.cn/article/yWPX34NfBckFFPmy*Fxi