“app”一詞表示我們在處理“小的應用程式”。儘管在一些情況下這或許是真的，但本文中它是指用於遠端監控一個機器不同部分（比如：燈，氣流和位置）狀態的相當大的應用程式。機器使用一個可用後端伺服器訪問的（我們的app通過因特網訪問的）行動通訊網路。總之，其複雜程度和一個桌面app相同。app的一個重要方面體現在不同的管理上。不同的客戶群接受不同的功能裝置，而不同的機器型別需要特定的資料陳述。這就形成了一個充滿變數的app——構建和執行期間其元件都是如此，這取決於我們想用哪一種機器。因此，這絕對不是一個“小”專案。它不是一個伴隨現有業務應用程式的移動app，它是這個業務流程唯一的解決方案。會有一個更長的維護階段來支援產品改進，新功能及更多的版本。App是機器的一個內在組成部分，且必須要有同樣好的質量，實用性和使用者體驗。本文提供了一份該專案的概述，以及我們關於QA和

專案設定：一個概念，兩個app，兩個團隊　　專案使用SCRUM敏捷軟體開發框架。一次sprint要花上兩週，包括一天的sprint綜述，回顧和規劃。sprint綜述是由整個開發團隊，一兩個客戶代表，有時還有來自QA或基礎設施部門的利益相關者執行。綜述後客戶會將規範細化。在sprint規劃的第一部分——使用者故事選擇中，一名客戶代表也要參加。這樣開發人員可以就規範細節提問，有時提出規範變化以允許app更多的“本地”行為。　　最重要的開發階段計劃要花上九個月。期間，團隊規模會在8-13人之間變化，包括產品負責人和Scrum專家。波動一部分是跟了這個專案一段時間的學生，部分是因特殊原因暫時加入團隊的專家。我們的目標裝置是iPhones 和

圖1. 從移動裝置到機器的通訊設定

自動化測試　　我們測試QA的挑戰是：對每個app進行多個級別（單元，整合，驗收，UI測試）的測試。因為我們想盡可能地自動化，所以我們有一個QA顧問，他是團隊一員，推動我們的測試自動化。他負責測試規範和測試執行的審查。自動化測試的實際執行是由開發者完成，由一個為每個使用者故事預設生成的測試任務觸發。根據執行功能，，還有驗收測試（自動化UI測試），單元測試和整合測試。測試總是特定平臺執行的。在UI測試中，他們同步使用一樣的驗收標準。對於一個（UI相關的）使用者故事中定義的每一個驗收標準，都至少有一個UI測試。為了實現所有這些不同的自動化測試，我們使用特定平臺框架。我們低水平的測試是分別使用SenTest或JUnit實現的。關於ios，額外的函式庫像nocilla和JRSwizzle則被用於模擬。對於UI，我們iOS用KIF，Android用Robotium。Robotium Recorder（商用產品）已被證明可以幫助獲得更穩定的Android測試並消除“假陰性”結果。儘管很重視app功能相同，但iOS和Android的導航和使用者體驗間的區別表明：取得並使用每個功能所需的步驟是不同的。不像在桌面領域，只是理論上有可能使用一個UI測試來覆蓋超出簡單概念的跨平臺app。這有不利之處，會增加技術和精力；但是也有好處，能夠使用特定工具解決特定問題。關於比例，人們常說UI測試應該是測試中最小的一塊。這部分是因為執行時間，也因為它們仍被視作最難寫和最難維護的。我們的經驗是：最好要重新評估特定測試等級在每個專案中的比例。隨著對客戶驗收越來越重視（敏捷專案和移動領域中都是），UI測試工具的穩定性越來越強，UI測試和GUI邏輯測試不該被忽視；確實，測試中單元測試的比重要高於UI測試。對於這個專案，我們有10%的單元測試，40%的整合測試以及50%的UI測試。因為我們從獨立後端供應商那接收的產品中的質量問題（很差的介面規範），所以整合測試的數量只低不高。

持續整合　　我們使用帶有一個基本的分支模型的Git作為我們的版本控制系統。它明確了一個主分支，釋出分支，以及每個功能和bug修改的分支。使用者故事完成後，開發者將一個功能作為一個整體合併到主分支中。為了保證不把不完整的功能整合到住分支中去，每個使用者故事都生成預設任務。有驗收（由產品經理和QA顧問審查）和程式碼質量（程式碼審查，靜態程式碼分析，還有自動化測試）的預設任務。持續整合的基礎是主分支，因為它應該始終包含一個“隨時準備釋出”的專案。每次提交（整合功能）都觸發一個完整的開發週期，包含以下工作：▪▪更新/建立依存關係▪▪建立app（現在有三個不同的構建版本）▪▪靜態分析▪▪單元測試▪▪UI測試▪▪通過內聯網進行app分配

圖2. 測試級別比例（最好的，典型的移動開發專案）

iOS和Android我們使用Jenkins，因為它是公司預設值，且由IT部門支援。尤其是在IOS開發中，我們遇上了(如果我們能選擇Xcode伺服器，就可以避免的)Jenkins的初期問題。但是，Jenkins中的額外外掛最終使得將我們的IOS系統整合到CI中成為可能，比如，Clang Analyzer和管理環境變數或共享工作間工作空間的外掛。

最後的思考：自動化在哪兒不起作用　　和描述的一樣，我們的流程包含各種幫助我們實現我們客戶的高質量期待的因素。整個團隊都參與質量流程，每次sprint中的專案都能保證高質量。這多虧了自動化測試的幫忙。但是有的地方必須手動保證質量。團隊進行桌面開發時不一定能立即想到這些，它們都列在下面了：▪▪實用性和使用者體驗：　　這是人們廣泛接受的必要的手動測試，但是移動app的客戶很重視質量。隨著指令的難度增加和方向的變化，我們發現我們必須更加重視質量——測試由團隊及客戶代表手動執行。此設定中，是由客戶來確保不同裝置作為其手動驗收測試被檢測的。我們自動化測試被限制為一個平臺一個版本。▪▪國際化：　　多語言桌面app中的正常流程是：讓講本地語言的人檢測字串，在app文字之外。由於顯示屏尺寸變小，我們計劃的超過15種語言的國際化比桌面app的更耗時間。我們的轉換是由外部員工執行的，每次轉換都必須手動測試以確保其在顯示屏上使用恰當的空間。我們使用我們的UI測試通過建立可以被轉換團隊審查的自動截圖來支援這個。

質量最重要——即使（尤其）是對於app　　本文表明：app開發要求至少要有與桌面商用app同級別的測試策略及質量保證工作。在某些方面，因為為兩個平臺開發一個app的挑戰，對於高質量工作的要求更高了。從許多方面來說，我們可以看到移動開發不會改變要求的質量工作。不過能改變的是特定工作的相關性或重要性。對我來說，這在我們單元，整合和驗收測試的分配以及在（一個非移動專案中並不重要或並不花費時間的）手動測試中很明顯。我們的結論？質量最重要——知道你要測試什麼，為什麼測試以及如何測試很重要。即使是對於移動app來說。