 |
Felix Krüger在德國布倫瑞克的BREDEX股份有限公司擔任一名軟件工程師。他在科特布斯的勃蘭登堡科技大學研究計算機科學。他參與了各種移動和桌面客戶端對企業軟件系統的開發。在過去的八年，他在自動化軟件開發的不同領域工作過。他對應付（基于Java和Eclipse的）客戶端服務器系統，以及測試自動化系統和嵌入式軟件很有經驗。 |
“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測試。因為我們從獨立后端供應商那接收的產品中的質量問題（很差的接口規范），所以集成測試的數量只低不高。
