持續(xù)集成
　　我們使用帶有一個基本的分支模型的Git作為我們的版本控制系統(tǒng)。它明確了一個主分支，發(fā)布分支，以及每個功能和bug修改的分支。用戶故事完成后，開發(fā)者將一個功能作為一個整體合并到主分支中。為了保證不把不完整的功能整合到住分支中去，每個用戶故事都生成默認(rèn)任務(wù)。有驗收（由產(chǎn)品經(jīng)理和QA顧問審查）和代碼質(zhì)量（代碼審查，靜態(tài)代碼分析，還有自動化測試）的默認(rèn)任務(wù)。持續(xù)集成的基礎(chǔ)是主分支，因為它應(yīng)該始終包含一個“隨時準(zhǔn)備發(fā)布”的項目。每次提交（整合功能）都觸發(fā)一個完整的開發(fā)周期，包含以下工作：
　　▪▪更新/建立依存關(guān)系
　　▪▪建立app（現(xiàn)在有三個不同的構(gòu)建版本）
　　▪▪靜態(tài)分析
　　▪▪單元測試
　　▪▪UI測試
　　▪▪通過內(nèi)聯(lián)網(wǎng)進行app分配

圖2. 測試級別比例（好的，典型的移動開發(fā)項目）

　　iOS和Android我們使用Jenkins，因為它是公司默認(rèn)值，且由IT部門支持。尤其是在IOS開發(fā)中，我們遇上了(如果我們能選擇Xcode服務(wù)器，可以避免的)Jenkins的初期問題。但是，Jenkins中的額外插件終使得將我們的IOS系統(tǒng)集成到CI中成為可能，比如，Clang Analyzer和管理環(huán)境變量或共享工作間工作空間的插件。

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

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

版權(quán)聲明：本文出自 SPASVO澤眾軟件測試網(wǎng)：http://www.misscakediy.com/news/html/20141224140712.html

原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明，否則將追究法律責(zé)任。