深入探討 Chrome iOS 版測試及釋出流程

在近期於紐約舉辦的一場Google技術講座上，Google資深軟體測試工程師Lindsay Pasricha介紹了Chrome iOS版的測試及釋出流程，探討了其產品開發策略、自動化測試框架以及手工測試流程等。本文對其中重要內容做個總結。

開發環境

Xcode是Google iOS版產品的主要開發工具，與其它一些內部方案和工具結合使用。Pasricha說，其中有些工具也並非Google內部專用，如用於管理依賴的gyp和用於版本控制的git。“我們還使用了許多自動構建的解決方案讓開發過程儘可能更快，” 比如後面還會提到的Pulse和Waterfall。

iOS開發的挑戰

Chrome iOS版開發面臨的最大挑戰之一來自於Google本身是個Android導向的公司。比如他們很難在Google內部找到使用iPhone的工程師參與iOS版產品的內部測試。而且，想要與其它非iOS平臺的開發團隊之間達成共識也很不容易，因為他們並不瞭解iOS開發的侷限性，例如你不可能在App Store上釋出Beta版產品。

除此之外，另一大挑戰是App Store稽核流程強制規定了一個應用所允許提供的API和服務。這是所有iOS開發者面臨的一個普遍問題，但對Chrome來說尤為嚴苛，因為蘋果將所有瀏覽類應用限制在它們自己的UIWebView類裡，它就是個黑盒子，Pasrica說，而且Bug很多。

還有一個例子是在所有Google應用之間實現的單點登入機制。為了簡化使用者體驗、增強桌面Chrome應用和手機版之間的同步機制，Chrome iOS版於近期剛剛引入了單點登入。“這對蘋果來說是件大事，因為他們認為這樣存在潛在的安全威脅。最後，他們終於接受了我們的觀點——為使用者維護keychain其實正是強化了安全防護，最終Chrome拿到了許可。”

另外，App Store不允許釋出Beta版應用也增加了開發的難度。這一原則與Google的Chrome開發慣用策略相反——即通過分發金絲雀版本讓數百萬使用者使用。這樣一來，在iOS上的開發就不得不將之前的“開發-金絲雀版-beta版”流程放在公司內部完成，使得其測試使用者數縮減到幾百個——應用一旦釋出，這些測試使用者對應用的成熟度有很大影響。

釋出流程

在Google的計劃裡，Chrome遵循一個6到9周的釋出流程——從為當前開發階段的新特性取得開發許可開始。所有平臺都遵循這一流程。在這幾周裡，主要任務是在該階段的程式碼分支中開發新特性並修復Bug，在準備評審流程的同時，大部分測試也完成了。在這個過程中，既有自動化測試，又有手工測試，重點在迴歸測試和對新特性的測試。

一旦測試完成，應用就被提交上去做評審，“這可以說是‘一個有意思的過程’，” Pasricha說。蘋果公司沒有給Google什麼特權，但是從Pasricha的解說來看，他們與評審小組有專線聯絡，並且他們通常不會收到以文字形式描述的關於某次評審不通過的理由和細節，而是被邀請過去“談談”，有時甚至邀請Google的VP。Pasricha說評審過程從未少於2個星期，但導致被拒的原因總會被快速解決，“從沒有哪個里程碑是被徹底拒絕的，往往只是誤解而已。”

只要應用得到上線許可，它的使用範圍就從“一小部分Google內部使用者變為數百萬普通使用者”，有時也會產生新問題，這時Chrome團隊就要做一次新構建。隨之而來的Bug修復版本的評審時間往往短得多，因為他們可以在提交應用時附上說明，註明這個構建並沒有引入新功能，只是修復了哪些Bug。

自動化測試

Google的測試理念中很重要的一點是使用Bots——一種使用物理裝置來執行app的軟體架構。Pasricha說，雖然在iPhone6和6+問世之前，iOS開發領域沒有裝置的分裂問題，這個測試理念仍然十分重要，並且日後可能會變得越來越重要。

這些自動化解決方案無疑是能幫助我們儘早拿到關於程式碼質量反饋的最佳方式。

前文提到過，Google從3個渠道開展測試：開發，金絲雀版，beta版。這三個渠道的定義如下：

• 開發渠道：用於在新特性提交到里程碑之前的功能驗證。
• 金絲雀渠道：包含了待合併到程式碼分支的所有更改集；在金絲雀版本構建上會執行自動化測試、單元測試和端到端測試。
• Beta渠道：這是最接近App Store釋出版本的構建，其中包括了額外的端到端測試。

以下描述了需要完成的幾種最主要的測試型別：

• 單元測試：傳統的“用於檢驗在各種狀態下的變數值是否與期望值相符的低階別測試”，在開發過程中進行。
• 端到端測試：由KIF框架管理，它藉助iOS的易訪問性功能來實現iOS上的測試自動化。Pasricha說，與蘋果公司的自動化測試框架UIA相比，KIF“更為可靠一些”。
• 效能測試：通過Chrome訪問一系列URL，之後可以比較每次執行的效能表現。這些測試只能用來比較同一個里程碑內的軟體執行效能，而不能跨里程碑比較，因此執行這類測試的目的在於確保在每個釋出週期內軟體的執行時間沒有變長。
• 截圖測試：這類測試也是用Chrome傳送一系列URL，在訪問的同時截圖。如果渲染的影像之間的差異低於預先設定的閾值則測試通過，否則需要人工檢查。Pasricha說，這種測試的概念很好，但不幸的是，每次執行後許多頁面之間的差異幾乎達到80%，這是因為頁面本身的改變和廣告切換導致的，因此這類測試的誤報率往往很高。

手工測試

在Pasricha看來，儘管採用了自動化測試，手工測試仍然是必需且無可避免的。通常來說，總有一部分測試用例只能通過手工方式來測試，例如有些使用者網速很慢，那麼測試時執行速度就不能太快；還有需要在請求時加入限制條件的一類特殊的企業賬戶等等。而且有些功能的測試用例還沒有實現自動化，此時也要執行手工測試，這種情況往往發生在那些很晚才被新增到開發流程裡的新功能上。事實上，有時候有些功能直到最後都沒能實現自動化測試。最後，還有些功能本來就沒有必要實現自動化，比如Chrome的標籤頁切換功能。

Pasricha很希望看到Chrome iOS版團隊在這個領域做出一些改變，尤其需要“軟體工程師們承擔起軟體質量的責任”，這樣的話某個功能只有在開發人員也親自為它寫了測試程式碼之後才能被髮布上線，否則就不予釋出。必須承認，這是一個很難在Stakeholder之間達成一致的問題，包括決策層和產品經理——這些人一點也不喜歡看到某些功能無法上線是由於缺少自動化測試這樣的理由。

上文提到的開發渠道的測試中並不包括手工測試，而在金絲雀版本渠道內會進行兩種形式的手工測試：對比測試和delta測試。它們的關注點都在功能的變更上，因為眾所周知的，一幅熱點圖或者風險矩陣就能夠標示出所有發生變更的元件。Pasricha補充道，在進行這類測試時，詳細的釋出文件十分重要，因為它們提供了變更的位置以及哪些功能可能會因此受到影響等資訊。同樣的，開發人員並不太樂意提供那麼詳盡的釋出文件，那麼在這種情況下還需要做一些額外的工作以達成一致。

其它測試

需要進行的其它型別測試還有：

• 升級測試：app釋出之後，首先要做的測試就是“升級”測試，也就是從App Store更新已安裝的app。在這個階段，所有新功能也會被快速地過一遍。
• 可訪問性測試及國際化測試：這兩種測試不會在每個里程碑階段都全量進行，其完整測試每年執行兩次。
• 安全測試：每個功能都必須經過整個安全小組的安全評審，除非是很小的功能才會只指派一位安全工程師來做評審。
• 地理位置測試：這類測試也很重要，因為曾經發現過一些只在某些國家的網站上才會出現的Bug。

持續整合

Pasricha解釋道，Chrome iOS版團隊搭建了一套在Google內部使用的持續整合系統，叫做Pulse。在此之前，Pasricha使用的是Jenkins，但最後他們改用了Pulse。Pulse被用來建立構建併為其簽名，以使得iOS Instrumentation能夠在這些構建上執行，而Pulse本身並不是用來執行測試的。用在Pulse之後的是Waterfall，它被用於所有的Chrome平臺，並不僅僅是iOS，它負責執行測試並收集測試結果，這些測試結果用一個由紅綠格子組成的矩陣表示。

所有測試既要在模擬器中的OS X環境執行，也要在真實的裝置上執行。Pasricha警告說，使用模擬器有一個問題：它的記憶體比真實的裝置多，因此不能用於定位與記憶體相關的問題。

對老版本iOS的支援

關於是否支援某個iOS版本的問題，Pasricha的建議是，設定一個最小使用者數閾值，基於這個值來決定一旦發現了Bug是否要為此將當前開發階段重新開始。這個值可以是5%，3%或1%，也就是成千上萬的使用者。有時候你也可以選擇支援一小部分使用者的需求，儘管他們的群體在短期看來是很小的。這種情況就發生在iOS越獄社群，Pasricha說，他們對Chrome iOS版尤為重要，因為只有他們才可能選擇Chrome作為預設瀏覽器。但是一般來說，如果一個老平臺上只有很少量的使用者，比如iOS 5或iOS 6，那麼還是有必要仔細考慮你願意為支援這些使用者投入多少成本。如果要支援，後續還會有裝置和配置項增多的問題，從而導致測試矩陣變大。同時也增加了未來的開發成本，因為到時候可能還需要解決在這些平臺上功能缺失的問題。另一個需要考慮的方面在於開發人員為一箇舊iOS平臺解決Bug的意願：如果他們不願意，那麼就沒必要支援那些平臺了。