“app”一詞表示我們在處理“小的應用程序”。儘管在一些情況下這或許是真的，但本文中它是指用於遠程監控一個機器不同部分（比如：燈，氣流和位置）狀態的相當大的應用程序。機器使用一個可用後端服務器訪問的（我們的app通過因特網訪問的）移動通信網絡。總之，其複雜程度和一個桌面app相同。app的一個重要方面體現在不同的管理上。不同的客戶羣接受不同的功能設備，而不同的機器類型需要特定的數據陳述。這就形成了一個充滿變數的app——構建和運行期間其組件都是如此，這取決於我們想用哪一種機器。因此，這絕對不是一個“小”項目。它不是一個伴隨現有業務應用程序的移動app，它是這個業務流程唯一的解決方案。會有一個更長的維護階段來支持產品改進，新功能及更多的版本。App是機器的一個內在組成部分，且必須要有同樣好的質量，實用性和用戶體驗。本文提供了一份該項目的概述，以及我們關於QA和測試自動化，持續集成和項目管理的決定和經驗。
項目設置：一個概念，兩個app，兩個團隊
項目使用SCRUM敏捷軟件開發框架。一次sprint要花上兩週，包括一天的sprint綜述，回顧和規劃。sprint綜述是由整個開發團隊，一兩個客戶代表，有時還有來自QA或基礎設施部門的利益相關者執行。綜述後客戶會將規範細化。在sprint規劃的第一部分——用戶故事選擇中，一名客戶代表也要參加。這樣開發人員可以就規範細節提問，有時提出規範變化以允許app更多的“本地”行爲。
最重要的開發階段計劃要花上九個月。期間，團隊規模會在8-13人之間變化，包括產品負責人和Scrum專家。波動一部分是跟了這個項目一段時間的學生，部分是因特殊原因暫時加入團隊的專家。我們的目標設備是iPhones 和Android手機，尤其是iPhone 3GS及以上–(iOS 6+)，還有Android 4及以上。機器將被控制，服務器後端已存在，因此，我們唯一的任務就是開發app，包括用戶界面，後端通信，變量管理以及特定平臺服務（比如推送通知，地圖或社交網絡）的集成。爲了保證最佳用戶體驗，我們不會使用跨平臺工具包；反之，我們正在開發兩個獨立的本地app。
開發人員被分到子團隊中，子團隊中都有各自的專家和平臺。爲了促進溝通，兩隊在一個網站上進行合作。因爲這兩個團隊，產品積壓由多數用戶故事構成了兩次，一個版本用於一個支持的平臺。對於大多數用戶故事，兩個版本都是根據與iOS和Android不一樣的開發流程而在同一次sprint中計劃的。
實施了一個故事時，其結果就會被拿來與其他平臺的app相比。在sprint概述中，我們更願意爲iOS和Android平行呈現一個功能。通過這麼做，我們就可以確保我們爲兩個平臺都實現了功能相同的app和相似的用戶體驗。除了用戶體驗，Android and iOS app還有相類似的軟件結構，儘管是分開進行的。一個常見的軟件結構文件中詳細規定了數據模型，分層設計，屏幕流管理，變量管理以及特定域算法。因此，爲第二個平臺執行一個功能時，很容易理解模板，因爲它是在同樣的基礎上執行的。因爲不同部分和用戶集成概念，這對視圖實施卻行不通——在這兒，開發是有特定平臺的。
圖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來說。
本文轉自：http://www.spasvo.com/news/html/20141224140712.html
