Felix Krüger在德國布倫瑞克的BREDEX股份有限公司擔(dān)任一名軟件工程師。他在科特布斯的勃蘭登堡科技大學(xué)研究計算機科學(xué)。他參與了各種移動和桌面客戶端對企業(yè)軟件系統(tǒng)的開發(fā)。在過去的八年，他在自動化軟件開發(fā)的不同領(lǐng)域工作過。他對應(yīng)付（基于Java和Eclipse的）客戶端服務(wù)器系統(tǒng)，以及測試自動化系統(tǒng)和嵌入式軟件很有經(jīng)驗。

　　“app”一詞表示我們在處理“小的應(yīng)用程序”。盡管在一些情況下這或許是真的，但本文中它是指用于遠程監(jiān)控一個機器不同部分（比如：燈，氣流和位置）狀態(tài)的相當(dāng)大的應(yīng)用程序。機器使用一個可用后端服務(wù)器訪問的（我們的app通過因特網(wǎng)訪問的）移動通信網(wǎng)絡(luò)。總之，其復(fù)雜程度和一個桌面app相同。app的一個重要方面體現(xiàn)在不同的管理上。不同的客戶群接受不同的功能設(shè)備，而不同的機器類型需要特定的數(shù)據(jù)陳述。這形成了一個充滿變數(shù)的app——構(gòu)建和運行期間其組件都是如此，這取決于我們想用哪一種機器。因此，這不是一個“小”項目。它不是一個伴隨現(xiàn)有業(yè)務(wù)應(yīng)用程序的移動app，它是這個業(yè)務(wù)流程的解決方案。會有一個更長的維護階段來支持產(chǎn)品改進，新功能及更多的版本。App是機器的一個內(nèi)在組成部分，且必須要有同樣好的質(zhì)量，實用性和用戶體驗。本文提供了一份該項目的概述，以及我們關(guān)于QA和測試自動化，持續(xù)集成和項目管理的決定和經(jīng)驗。

　　項目設(shè)置：一個概念，兩個app，兩個團隊
　　項目使用SCRUM敏捷軟件開發(fā)框架。一次sprint要花上兩周，包括的sprint綜述，回顧和規(guī)劃。sprint綜述是由整個開發(fā)團隊，一兩個客戶代表，有時還有來自QA或基礎(chǔ)設(shè)施部門的利益相關(guān)者執(zhí)行。綜述后客戶會將規(guī)范細化。在sprint規(guī)劃的第一部分——用戶故事選擇中，一名客戶代表也要參加。這樣開發(fā)人員可以規(guī)范細節(jié)提問，有時提出規(guī)范變化以允許app更多的“本地”行為。
　　重要的開發(fā)階段計劃要花上九個月。期間，團隊規(guī)模會在8-13人之間變化，包括產(chǎn)品負責(zé)人和Scrum專家。波動一部分是跟了這個項目一段時間的學(xué)生，部分是因特殊原因暫時加入團隊的專家。我們的目標設(shè)備是iPhones 和Android手機，尤其是iPhone 3GS及以上–(iOS 6+)，還有Android 4及以上。機器將被控制，服務(wù)器后端已存在，因此，我們的任務(wù)是開發(fā)app，包括用戶界面，后端通信，變量管理以及特定平臺服務(wù)（比如推送通知，地圖或社交網(wǎng)絡(luò)）的集成。為了保證佳用戶體驗，我們不會使用跨平臺工具包；反之，我們正在開發(fā)兩個獨立的本地app。
　　開發(fā)人員被分到子團隊中，子團隊中都有各自的專家和平臺。為了促進溝通，兩隊在一個網(wǎng)站上進行合作。因為這兩個團隊，產(chǎn)品積壓由多數(shù)用戶故事構(gòu)成了兩次，一個版本用于一個支持的平臺。對于大多數(shù)用戶故事，兩個版本都是根據(jù)與iOS和Android不一樣的開發(fā)流程而在同一次sprint中計劃的。
　　實施了一個故事時，其結(jié)果會被拿來與其他平臺的app相比。在sprint概述中，我們更愿意為iOS和Android平行呈現(xiàn)一個功能。通過這么做，我們可以確保我們?yōu)閮蓚�平臺都實現(xiàn)了功能相同的app和相似的用戶體驗。除了用戶體驗，Android and iOS app還有相類似的軟件結(jié)構(gòu)，盡管是分開進行的。一個常見的軟件結(jié)構(gòu)文件中詳細規(guī)定了數(shù)據(jù)模型，分層設(shè)計，屏幕流管理，變量管理以及特定域算法。因此，為第二個平臺執(zhí)行一個功能時，很容易理解模板，因為它是在同樣的基礎(chǔ)上執(zhí)行的。因為不同部分和用戶集成概念，這對視圖實施卻行不通——在這兒，開發(fā)是有特定平臺的。

圖1. 從移動設(shè)備到機器的通信設(shè)置

　　自動化測試
　　我們測試QA的挑戰(zhàn)是：對每個app進行多個級別（單元，集成，驗收，UI測試）的測試。因為我們想盡可能地自動化，所以我們有一個QA顧問，他是團隊一員，推動我們的測試自動化。他負責(zé)測試規(guī)范和測試執(zhí)行的審查。自動化測試的實際執(zhí)行是由開發(fā)者完成，由一個為每個用戶故事默認生成的測試任務(wù)觸發(fā)。根據(jù)執(zhí)行功能，，還有驗收測試（自動化UI測試），單元測試和集成測試。測試總是特定平臺執(zhí)行的。在UI測試中，他們同步使用一樣的驗收標準。對于一個（UI相關(guān)的）用戶故事中定義的每一個驗收標準，都至少有一個UI測試。為了實現(xiàn)所有這些不同的自動化測試，我們使用特定平臺框架。我們低水平的測試是分別使用SenTest或JUnit實現(xiàn)的。關(guān)于ios，額外的函數(shù)庫像nocilla和JRSwizzle則被用于模擬。對于UI，我們iOS用KIF，Android用Robotium。Robotium Recorder（商用產(chǎn)品）已被證明可以幫助獲得更穩(wěn)定的Android測試并消除“假陰性”結(jié)果。盡管很重視app功能相同，但iOS和Android的導(dǎo)航和用戶體驗間的區(qū)別表明：取得并使用每個功能所需的步驟是不同的。不像在桌面領(lǐng)域，只是理論上有可能使用一個UI測試來覆蓋超出簡單概念的跨平臺app。這有不利之處，會增加技術(shù)和精力；但是也有好處，能夠使用特定工具解決特定問題。關(guān)于比例，人們常說UI測試應(yīng)該是測試中小的一塊。這部分是因為執(zhí)行時間，也因為它們?nèi)员灰曌麟y寫和難維護的。我們的經(jīng)驗是：好要重新評估特定測試等級在每個項目中的比例。隨著對客戶驗收越來越重視（敏捷項目和移動領(lǐng)域中都是），UI測試工具的穩(wěn)定性越來越強，UI測試和GUI邏輯測試不該被忽視；確實，測試中單元測試的比重要高于UI測試。對于這個項目，我們有10%的單元測試，40%的集成測試以及50%的UI測試。因為我們從獨立后端供應(yīng)商那接收的產(chǎn)品中的質(zhì)量問題（很差的接口規(guī)范），所以集成測試的數(shù)量只低不高。