持續質量和云平臺:如何進行移動應用測試
作為與客戶互動的新策略,“移動先行”正在被越來越多的組織所采納。與此同時,而隨著移動應用市場的復雜度日益增加,移動應用開發/測試團隊需要滿足更快 的版本發布速度,移動正在推動敏捷。最新的現狀是移動應用需要一個完全不同的開發流程。為了能夠趕上市場的步伐,在移動應用的整個生命周期中,開發人員需 要應對不斷增長的變化集合——從來自于新的移動平臺和設備的終端用戶到終端用戶參與的數字體驗的增長。舉例來說,物聯網(IoT)帶來了更多新的具有傳感 功能的上下文感知設備,隨之而來的就是與桌面電腦、手機、可穿戴設備、平板電腦以及非移動設備的集成需求。伴隨著這些變化,我們必須接受移動的顛覆性將會 是持續不斷的;與此同時圍繞移動設備的功能和性能,也將不斷引入新的挑戰。當移動應用推動創新、需求及功能發展的同時,測試這些應用的相關復雜性也與日俱 增。如何確保開啟車庫門的應用不僅可以工作,而且可以持續保持良好的運轉?此外又如何能夠做到在不犧牲質量的前提下,達成更快的應用開發速度?能夠支撐移 動應用開發人員提升開發速度和質量的追求的唯一答案就是在移動軟件開發生命周期(SDLC)的早期就引入測試,并將測試貫穿整個生命周期直至投產。這就是 持續質量 方法論。
持續質量
持續質量是一種將質量活動嵌入到SDLC過程的每一步中的方法論——從設計到構建再到投產——所有這些都基于過程、工具和用于支持組織特定需求的 定制化測試實驗室基礎設施的支持。成功的持續質量過程可以優化上市時間,推動更加快速、頻率更高的版本發布并且通過盡早地以自動化的手段管控風險,將逃逸 到生產環境的缺陷減到最少。持續質量興起背后的主要驅動力源于持續高頻地發布高質量(原生的、混合的等)移動應用的需求。對于移動來說,必須要有敏捷的流 程,但是在敏捷方法之上,在應用的功能、性能、可用性和安全方面,開發團隊需要來自于真實設備的快速可操作的反饋。將與質量相關的所有內容嵌入到每一次的 構建中,并持續為開發團隊提供反饋,以便開發團隊能夠盡早洞察缺陷——這是持續質量的核心價值。目前,對于企業移動應用來說,平均需要執行數千次的測試。 這些測試流程需要在各種安卓和iOS設備、智能手機和平板電腦以及兩到三種最新版本的操作系統上執行。理想的持續質量過程依賴于可以針對測試設備矩陣執行 自動化測試腳本的持續集成服務器,測試設備矩陣中包括安卓、iOS設備,平板電腦,電話以及不同的操作系統版本。開發團隊從持續集成服務器上獲取報告,這 類自動化測試執行的周期長度大概為幾個小時(或一個晚上)。如果無法正常執行自動化過程,就幾乎不可能將質量過程轉化成一個可重復的循環,這一過程就會變 的冗長低效。
成功——不可能完成的任務:未采用持續質量的后果
使用老舊、傳統的開發方法的組織不可能在移動領域取得成功。未能實踐持續質量工作流程的團隊由于所用的工具與開發人員所用的完全不同,最終會以一 種支離破碎的方式終結運轉。如果一個團隊仍然依賴于某個開發人員或質量保證人員桌上有限的幾個移動設備完成測試,而沒有將這些設備置于云端環境之中,在應 用開發周期中他們將會面臨更多的挑戰,這其中就包括管理和安全的缺失。團隊仍將嚴重依賴于手工測試和嘗試性的基本的自動化測試——這與一夜之間就可以在多 臺設備上運行成千上萬條測試的持續集成機器相比相差甚遠。該團隊還缺乏創建并測試真實的終端用戶情景的能力。有許多工具可以模擬各種不同的網絡情景、運營 商網絡、GPS定位測試、載荷測試等,而且開發人員可以基于這些場景進行測試。這種“老舊”環境將導致對應用的質量和性能的可見性有限,這通常會導致缺陷 在項目晚期才會被實施工程師或用戶發現。
持續質量的實施
持續質量過程和其他過程的關鍵區別在于:在持續質量過程中,開發人員、測試人員和性能測試工程師之間沒有嚴格的界限。其重點是憑借一組環境資產、工具和 質量實驗室 在非常早期就引入質量保證工作,作為持續集成(CI)工作流的一部分,為開發人員提供一個自然的環境,并行完成開發、構建和測試移動應用的工作。為了實現 目前為止可能比Web應用更加碎片化,更加復雜并且更加難以預測的移動應用的持續質量過程,移動應用開發人員或移動敏捷團隊需要許多獨特的工具能力,以保 證強有力的持續質量過程。開發團隊應該考慮可用于測試的真實設備的移動應用質量實驗室;在許多技術方面,模擬器都無法滿足要求,并且無法提供完整的設備能 力,如傳感器、網絡條件、特殊的硬件限制等等。最理想的設置是在基于云的實驗室中將設備連接到真實的移動網絡中,該實驗室可以提供用于控制移動設備的相關 能力:
- 完整的移動設備系統控制
- 設備輪換
- 設備日志及關鍵信息,如CPU監控
- 真實的網絡條件,開發人員可以進行應用測試的各種網絡配置,如2G,3G,不同的丟包率以及其他,并且可以在各種載荷條件下檢查應用。
- 基于位置的測試能力(例如:利用谷歌地圖API模擬設備位置)作為早期測試并貫穿持續集成工作流程的一部分
- 簡單的USB設備接入能力,接入未被入侵,未被越獄的設備
- 模擬網絡環境
- 環境轉換能力,讓在預生產環境和生產環境中同時進行同一應用的測試更加容易
借力混編云
面對如此多變的需求和持續變革的移動設備市場,團隊可以從“混編云”環境獲益良多。混編云是指由多種不同部署選項組成的云環境——組織機構可以在 可用設備,共享設備和用于測試的遠程托管移動設備的組合上開展工作,這可以補充對相關覆蓋度的需求,并且可以支持全球團隊間的相互合作。隨著移動應用項目 的擴張或轉型,混編云的靈活性可以幫助團隊隨時增長或調整。混編云在滿足本地開發案例方面也是相當有價值的,如測試需要通過Wi-Fi或藍牙配對的可穿戴 設備,或測試基于NFC的應用,如支付應用。混編云還可以滿足全球化設備覆蓋度的需求,例如當某個分布式團隊需要與某個在特殊的網絡中擁有獨特設備的遠程 團隊合作時。利用混編云環境,這些設備成為了聯合云的一部分,所有團隊都可以共享設備并使用這些設備開發或測試,無論所處位置如何。
端到端的軟件開發生命周期支持
為了實現相當有挑戰的發布周期目標,開發人員和測試人員相處融洽是相當重要的。測試自動化工作在持續質量過程中起到了至關重要的作用。這一自動化 工作可以讓開發和測試團隊在他們所使用的任意框架和語言下編寫高效的測試代碼,并且可以在多個真實設備上無縫執行這些代碼,作為整體持續集成和構建驗收過 程的一部分。這一自動化解決方案可以與任何持續集成過程、測試框架(Selenium,Appium,Calabash等)以及集成開發環境 (Eclipse,Visual Studio,Xcode或其他IDE)集成,成為持續質量過程的基礎支柱。除了手工測試和功能測試以外,作為早期開發階段和持續集成的一部分,測試環境 還應該提供非功能性的性能和監控能力。意識到應用經常會與數個其他應用并行運行在各種不同的網絡條件下,爭奪有限的內存,CPU,電池延時和網絡帶寬是相 當重要的。因此沒有真實的載荷,復雜的場景和輸入的事件以及其他影響,只在“干凈的”機房環境中對應用進行測試的想法,的確有些天真。不重視上述情景,將 其作為持續質量過程的一部分,會讓你的應用暴露在后期的缺陷當中,而這類缺陷通常更加難以分析、修復和重新部署,特別是我們不得不通過應用商店冗長的重新 部署流程。
持續質量過程中開發人員的角色
持續質量過程可以讓開發人員獲得授權并且將注意力轉向高質量應用的構建。曾經習慣于非常基礎的單元測試,并將二進制程序(IPA、APK等)交給 QA團隊的開發人員現在擁有了可以讓整個持續質量周期更加高效并具有更高測試覆蓋度的能力和工具。開發人員可以在按需生成的應用構建(每日、每小時等)中 注入大量的驗證程序,并且可以在幾個小時內得到一個全面的報告;這將完全改變原有的游戲規則。作為應用構建的一部分,開發人員可以在其中包含健壯、持久的 測試自動化腳本,這些腳本可以是開發人員自己編寫的或自動化工程師用同樣的環境和語言編寫的并且為開發人員所熟悉的腳本。開發團隊應該用清晰的標準定義最 重要的測試用例(發現缺陷最多的測試用例、關鍵功能測試用例、客戶要求的缺陷修復等)并且應該將這些用例包含在每一次的持續集成回歸周期中。一旦這些測試 通過,就可以啟動剩余的測試用例以保證更高的覆蓋率、進一步降低風險。在基于真實設備和真實網絡環境的功能性自動化測試完成的基礎之上,開發人員可以包含 更加重要、目的明確的“環境測試”能力以提升校驗覆蓋率并獲得最大化的洞察力,以增加他們對這款即將上市的應用的信心。
不斷變換的市場:下一代可穿戴設備
隨著可穿戴設備對這個早已碎片化的市場的改變和加速,如今將持續質量過程作為SDLC一部分的需求比以往任何時候都更加強烈。可穿戴設備應用和移 動應用將會持續地進行交互,并且相互依賴。在一個設備上實時發生的來自于用戶的動作會觸發另一臺設備上的其他動作和事件。當用戶使用FitBit完成一次 跑步后,他/她就可以立刻在移動設備上查看最新的統計數據以及與前一天運動情況的對比。為了應對這一問題,開發人員需要能夠擁有對設備(智能手機/平板電 腦)系統以及可穿戴設備的完全控制權限。有了健壯的持續質量過程后,開發人員就擁有了對他們的移動環境以及用于開發和測試應用的工具的完全控制權限,以及 對這些外附平臺的支持。
實現向持續質量過程的飛躍:一個金融機構的旅程
我們應該如何做出改變,實現從冗長低效的移動應用開發過程向一流的持續質量過程的轉化?一個頂尖的金融機構正面臨這樣的問題,每一個版本的QA周 期都需要冗長的8周時間。這一周期不僅成本高昂,而且規模受限,這就導致相關風險隨著每次構建不斷增加。非常低的設備覆蓋率和每次構建十分有限的洞察讓開 發人員的行動和對市場終端用戶的反應遲緩。當時,該金融機構并未將反饋整合到過程當中,這就導致從用戶現場報告的缺陷需要花費數天時間才能夠被重現和調 研。如今的最終用戶不會有這樣的時間、耐心或渴望來等待問題的修復,他們會直接轉向競爭對手。該金融機構意識到基于應用商店中的公開用戶的反饋對移動應用 質量作出反應并非一個好的選擇,他們需要與市場保持緊密聯系才能留住客戶。該機構設置了清晰的目標以保證可以有更頻繁地版本發布,這就意味著需要在功能測 試和性能測試階段包含更高比例的測試自動化用例。為了實現向持續質量開發過程的轉變,提升應用發布的速度,該組織在思維方式上做出了關鍵的調整。他們提出 了一些尖銳的問題——從現在起,六個月以后他們希望他們的應用處于什么位置,一年以后以及更長時間以后呢?從質量的角度來說,他們的發布周期看起來應該是 什么樣子的?他們準備如何提升效率?最重要的是,如果沒有這些變化,終端用戶的體驗該如何繼續忍受?
- 經過調研和分析,最終確定如下目標:
- 提升應用質量,將應用商店中的評分提升至4-5星
- 用更細粒度的范圍降低版本發布周期的長度——根據受影響的代碼范圍執行自動化測試。
- 提高效率,設置80%的自動化目標,從而縮短上市時間,加快缺陷的解決平均時間(MTTR)。
- 提高設備覆蓋率,涵蓋目標市場上市場占有率最高的設備。
結果
該金融機構意識到,要評估移動應用,確保其可以在桌面瀏覽器、移動設備及其他設備上正常運轉,開發人員需要將測試貫穿整個移動應用開發的生命周期。這會提 升應用的質量并加快開發的速度。從移動應用開發的初始階段,他們就需要一個一直可用的測試實驗室。這個實驗室就可以根據需要提供對設備的訪問,這些設備電 量充裕、與真實的運營商網絡保持無間斷連接、擁有對設備系統的完全控制而且還提供日志。在這樣的環境中進行測試,在開發周期中他們可以及早發現問題——顯 然,這對提升開發速度、提高移動應用質量非常關鍵。此外,擁有混編云測試環境后,團隊就不再需要不斷追趕設備或改變測試語言。他們可以將精力完全集中在版 本質量和設備覆蓋率之上。通過實現完成了測試自動化和基于云的實驗室的持續質量過程,該金融機構可以將80%的手工測試自動化,并且可以將測試集成到持續 集成工作流當中,并在 多達20個真實的設備 上執行,基于此,他們可以在安卓和iOS應用上增加 真實網絡條件 下的性能測試——這些都要仰仗上文所提及的 混編云 模型。綜上所述,下圖是關于如何做出改變并轉向持續質量過程的“ 詳細計劃書 ”:
Jenkins這類自動化版本管理工具的普遍采用,與自動化的功能性回歸測試的結合是移動應用速度和質量的關鍵,這一點已經十分明確,然而,特別 是在移動環境中——性能測試也必須成為這一自動化版本管理過程的一部分。開發過程中很可能會無意中引入可能會導致性能下降的代碼變更。實現自動化的性能評 估作為自動構建的一部分可以消除這一風險,并且能夠為開發人員和性能工程師提供早期的洞察。
總結
隨著移動新時代的到來和對新平臺的期望,移動應用開發者需要擁抱新的過程和方法論,以便他們在組織中可以處于更強勢的位置,能夠對市場變化更快地 作出反應。對于組織來說,持續質量過程是能夠快速處理市場變化并輸出高質量、可預測成果的最有效的解決方案。開發人員應該持續不斷地“聆聽”市場發出的聲 音,以及這一聲音會如何影響他們的開發——或者是會影響他們的設備矩陣的新平臺發布、新的設備進入市場,或者是可能會影響移動應用質量的應用商店評審以及 主要市場活動。持續質量為開發人員和測試人員所提供的橋梁讓移動應用SDLC周期中的日常工作更加高效,因為整個團隊都可以從每一個持續集成構建中及時獲 得來自于真實網絡條件下的真實設備以及大規模的設備和操作系統中的詳細信息,而且所有這些都會直接進入開發者的自然環境,這是在當今移動領域至關重要。
關于作者
Eran Kinsbruner 是基于云的移動應用測試和自動化公司Perfecto Mobile的產品市場總監。在此之前曾經擔任Texas Instruments的移動測試CTO和Matrix的項目經理,Eran從1999年開始就從事測試相關的工作,還有在Qulicke & Soffa,Sun Microsystems,General Electric和Neustar的團隊管理經驗。作為在Sun Microsystems公司的移動J2ME測試的測試排除自動化機制的聯合發明者,Eran在移動測試領域擁有豐富的經驗。可以在ek121268@ 推ter ,LinkedIn以及他的專業移動測試博客 ek121268.wordpress.com 找到他。Eran還是 Perfecto Mobile博客 的定期撰稿人。
查看英文原文: Continuous Quality and the Cloud: How You Should Be Testing Mobile Apps