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

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

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

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

　　自動化測試
　　我們測試QA的挑戰(zhàn)是：對每個(gè)app進(jìn)行多個(gè)級別（單元，集成，驗(yàn)收，UI測試）的測試。因?yàn)槲覀兿氡M可能地自動化，所以我們有一個(gè)QA顧問，他是團(tuán)隊(duì)一員，推動我們的測試自動化。他負(fù)責(zé)測試規(guī)范和測試執(zhí)行的審查。自動化測試的實(shí)際執(zhí)行是由開發(fā)者完成，由一個(gè)為每個(gè)用戶故事默認(rèn)生成的測試任務(wù)觸發(fā)。根據(jù)執(zhí)行功能，，還有驗(yàn)收測試（自動化UI測試），單元測試和集成測試。測試總是特定平臺執(zhí)行的。在UI測試中，他們同步使用一樣的驗(yàn)收標(biāo)準(zhǔn)。對于一個(gè)（UI相關(guān)的）用戶故事中定義的每一個(gè)驗(yàn)收標(biāo)準(zhǔn)，都至少有一個(gè)UI測試。為了實(shí)現(xiàn)所有這些不同的自動化測試，我們使用特定平臺框架。我們低水平的測試是分別使用SenTest或JUnit實(shí)現(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)航和用戶體驗(yàn)間的區(qū)別表明：取得并使用每個(gè)功能所需的步驟是不同的。不像在桌面領(lǐng)域，只是理論上有可能使用一個(gè)UI測試來覆蓋超出簡單概念的跨平臺app。這有不利之處，會增加技術(shù)和精力；但是也有好處，能夠使用特定工具解決特定問題。關(guān)于比例，人們常說UI測試應(yīng)該是測試中小的一塊。這部分是因?yàn)閳?zhí)行時(shí)間，也因?yàn)樗鼈內(nèi)员灰曌麟y寫和難維護(hù)的。我們的經(jīng)驗(yàn)是：好要重新評估特定測試等級在每個(gè)項(xiàng)目中的比例。隨著對客戶驗(yàn)收越來越重視（敏捷項(xiàng)目和移動領(lǐng)域中都是），UI測試工具的穩(wěn)定性越來越強(qiáng)，UI測試和GUI邏輯測試不該被忽視；確實(shí)，測試中單元測試的比重要高于UI測試。對于這個(gè)項(xiàng)目，我們有10%的單元測試，40%的集成測試以及50%的UI測試。因?yàn)槲覀儚莫?dú)立后端供應(yīng)商那接收的產(chǎn)品中的質(zhì)量問題（很差的接口規(guī)范），所以集成測試的數(shù)量只低不高。