項(xiàng)目上線，有時(shí)間總結(jié)一下當(dāng)前的項(xiàng)目，對(duì)自己而言，一直是一個(gè)學(xué)習(xí)的過程。本篇總結(jié)我們的測試實(shí)踐。本文分5部分，分別是：項(xiàng)目背景、系統(tǒng)架構(gòu)與模塊劃分、我們的測試實(shí)踐、自動(dòng)化測試在項(xiàng)目中的價(jià)值與對(duì)自動(dòng)化測試的進(jìn)一步思考。

一、項(xiàng)目背景
所有對(duì)項(xiàng)目的介紹一定是從客戶開始。
客戶：我們的客戶是一家全球領(lǐng)先的時(shí)尚內(nèi)容提供商，通過遍布全球的員工，客戶每天獲取大量關(guān)于時(shí)裝發(fā)布、產(chǎn)品設(shè)計(jì)、街邊流行、城市熱點(diǎn)等信息，這些信息的絕大部分以圖片的形式上傳到公司服務(wù)器，然后由專職編輯對(duì)這些圖片進(jìn)行整理和歸類（打標(biāo)簽），最后再由設(shè)計(jì)人員根據(jù)這些信息書寫分析報(bào)表。
關(guān)鍵內(nèi)容：分類細(xì)致的海量高清圖片和具有前瞻性的分析報(bào)表。
商業(yè)模式：網(wǎng)站，行業(yè)內(nèi)用戶訂閱-付費(fèi)。
客戶面臨的問題：同質(zhì)化競爭、客戶流失。
新系統(tǒng)的關(guān)鍵詞：CMS、更精確的內(nèi)容分類、更好的全文檢索、更好的用戶體驗(yàn)（更有表現(xiàn)力的內(nèi)容展現(xiàn)）、更快的內(nèi)容發(fā)布。

二、系統(tǒng)架構(gòu)與模塊劃分
1、REST的架構(gòu)風(fēng)格
系統(tǒng)采用了Sling作為WEB框架，JCR作為了底層內(nèi)容存儲(chǔ)框架。
系統(tǒng)的特點(diǎn)：
URI唯一標(biāo)識(shí)資源
通過URI能夠直接映射到JCR節(jié)點(diǎn)，例如http://localhost:80/content/section/news.html能夠映射到JCR里的/content/section/news節(jié)點(diǎn)

GET/POST/DELETE標(biāo)準(zhǔn)方法對(duì)資源進(jìn)行操作
支持標(biāo)準(zhǔn)方法對(duì)資源的直接操作

資源的多重表述
同一資源可以存在多種表述形式，例如http://localhost:80/content/section/news.html展現(xiàn)網(wǎng)頁，

http://localhost:80/content/section/news.json展現(xiàn)資源信息的JSON描述，
http://localhost:80/content/section/news.pdf展現(xiàn)網(wǎng)頁的PDF。

服務(wù)器端的無狀態(tài)
通過JS獲取當(dāng)前用戶信息并緩存在客戶端。

2、系統(tǒng)分層
系統(tǒng)分為四層：JS、Servlet、Domain Model和JCR。
因?yàn)镴CR提供了一套節(jié)點(diǎn)模型，所以Domain Model是在節(jié)點(diǎn)模型上的行為增強(qiáng)，例如所有對(duì)圖片節(jié)點(diǎn)的操作我們封裝在Asset領(lǐng)域模型里。


3、程序劃分
程序分為兩個(gè)大的模塊：Migration和Bundles。為什么叫Bundles？因?yàn)镾ling使用了OSGI框架Felix。
Migration負(fù)責(zé)導(dǎo)入客戶的遺留數(shù)據(jù)到新系統(tǒng)。之前客戶的CMS運(yùn)行已有10多年的時(shí)間，積累有大量數(shù)據(jù)。主要是各種類型的報(bào)表和圖片。
Bundles實(shí)現(xiàn)系統(tǒng)功能。主要包括了定義報(bào)表模板、定義報(bào)表各種所見即所得的展現(xiàn)組件、實(shí)現(xiàn)對(duì)圖片的管理、搜索（包括基于圖片的可視化搜索）和其他七七八八。

三、測試實(shí)踐
1、Migration的測試
  自動(dòng)化測試
對(duì)Migration，我們采用了TDD的方式。
輸入是客戶實(shí)際提供的xml文件，輸出是JCR里的節(jié)點(diǎn)。測試環(huán)境的搭建主要是在本地建立起Jackrabbit實(shí)例。我們的工作方式是這樣：每天早上領(lǐng)到一張migration故事卡，然后先寫一個(gè)xml到j(luò)cr節(jié)點(diǎn)的集成測試描述出該類型報(bào)表的功能需求，接下來就是讓這個(gè)測試通過。經(jīng)過開始階段的熟悉過程，我們的速度保持在一對(duì)Pair一天一種報(bào)表類型的導(dǎo)入。

   手工測試
將xml文件內(nèi)容正常解析并導(dǎo)入JCR只是第一步，第二步我們需要在Bundles里為該類型的報(bào)表編寫模板使之正常展現(xiàn)。由于涉及到報(bào)表樣式，這個(gè)測試我們采用手工測試，這個(gè)工作也是QA工作的重要一部分。
在最開始的開發(fā)中，我們沒有導(dǎo)入所有報(bào)表數(shù)據(jù)進(jìn)行測試。這帶來了問題，由于客戶遺留數(shù)據(jù)跨越10多年，各種數(shù)據(jù)形式都可能存在（特別是04年以前數(shù)據(jù)，給UI帶來了很大挑戰(zhàn)），而最開始的開發(fā)中，我們只是使用了部分?jǐn)?shù)據(jù)（09、10年數(shù)據(jù)）進(jìn)行測試，這個(gè)導(dǎo)致了建立UAT環(huán)境時(shí)程序的很多返工以及QA的測試壓力。

2、Bundles的測試
自動(dòng)化測試
對(duì)領(lǐng)域模型，我們采用了TDD的方式進(jìn)行單元測試；在本地Jackrabbit實(shí)例里建立數(shù)據(jù)，領(lǐng)域模型封裝數(shù)據(jù)測試行為。
對(duì)servlet，我們采用了TDD的方式進(jìn)行集成測試（同時(shí)測試了servlet和領(lǐng)域模型），在測試中對(duì)request和response進(jìn)行mock；
對(duì)JS，我們使用數(shù)據(jù)驅(qū)動(dòng)的selenium功能測試進(jìn)行覆蓋。

我們最后的自動(dòng)化測試結(jié)構(gòu)：


手工測試
手工測試內(nèi)容主要是功能測試。
自動(dòng)化測試價(jià)值低的部分我們采用手工測試，這部分內(nèi)容包括報(bào)表模板，相對(duì)獨(dú)立，內(nèi)容不多，一次測試處處通過；
自動(dòng)化測試成本高的部分我們采用手工測試，這部分內(nèi)容包括報(bào)表展現(xiàn)組件的編輯功能，因?yàn)椴捎昧薊xt JS，所以自動(dòng)化測試?yán)щy；
無法自動(dòng)化的測試：報(bào)表在線生成PDF，報(bào)表樣式，WEBDEV批量上傳圖片等;

我們與QA的約定：
每完成一個(gè)用戶故事，我們會(huì)與QA、BA一起mini showcase；
QA驗(yàn)收完成后編寫功能測試用例；
我們對(duì)QA編寫的功能測試用例進(jìn)行自動(dòng)化，共同維護(hù)一個(gè)功能測試列表；
對(duì)于不能自動(dòng)化或自動(dòng)化價(jià)值不高的測試用例QA繼續(xù)使用手工測試。

四、我們感受到的自動(dòng)化測試價(jià)值
1、通過自動(dòng)化功能測試，我們使得需求對(duì)客戶可視化；
2、QA的回歸測試成本降低，盡管目前頻繁的向客戶實(shí)際使用環(huán)境部署，但QA每次部署只需要做一些簡單的冒煙測試；
3、測試即需求，這點(diǎn)在TDD的開發(fā)過程中感覺非常明顯，今天開發(fā)的目的就是使這個(gè)測試通過，避免了頻繁部署到應(yīng)用中進(jìn)行測試，最快的電梯不是速度最快的電梯，而是中間停的樓層最少的電梯；
4、與持續(xù)集成一起，及時(shí)反饋。這點(diǎn)在進(jìn)行JS代碼編寫時(shí)，心理上都非常依賴于selenium測試，對(duì)于沒有測試覆蓋的地方，沒有安全感；
5、足夠的單元、集成測試保證了頻繁重構(gòu)，沒有人愿意引入BUG，沒有足夠的測試，沒人愿意重構(gòu)；
6、測試即文檔，良好的測試和命名，使得新加入的成員非常容易理解當(dāng)前代碼的功能。

五、思考和討論
1、自動(dòng)化功能測試做到多少才合適？
當(dāng)然是越多越合適，問題在于自動(dòng)化功能測試成本要大大高于單元測試和集成測試，這些成本反映在測試環(huán)境的搭建、數(shù)據(jù)的準(zhǔn)備，需要準(zhǔn)備其他很多關(guān)聯(lián)數(shù)據(jù)例如用戶信息和權(quán)限信息、自動(dòng)化功能測試的運(yùn)行時(shí)間長、穩(wěn)定性（隨機(jī)成功/失敗）、編寫等等，需要權(quán)衡成本與收益。
個(gè)人認(rèn)為，自動(dòng)化功能測試需要考慮的著重點(diǎn)包括：頁面是否包含大量功能交互性JS（與展現(xiàn)性JS相對(duì)）？當(dāng)前功能是否與其他功能共享一些代碼？即獨(dú)立性，獨(dú)立性越低越需要著重覆蓋（這里又涉及到另外一個(gè)問題，即從各個(gè)模塊里重構(gòu)出共用代碼是否總是合適？）。QA每次冒煙測試時(shí)是否需要重復(fù)回歸（重復(fù)回歸次數(shù)越多，自動(dòng)化越有價(jià)值）？經(jīng)常失敗的測試一定比不失敗的測試價(jià)值更高？或者從未失敗過的測試就沒有價(jià)值？

2、單元測試？功能單元測試？
TDD的測試粒度多大才合適？從我個(gè)人而言，幾乎天然的反對(duì)mock，為了滿足測試覆蓋率的追求，強(qiáng)制將兩個(gè)聯(lián)系很緊密的類分開，做出各式各樣mock，這真讓人氣餒；stub也不是什么好東西，在一個(gè)曾經(jīng)的spring項(xiàng)目里，在測試目錄里，一堆一堆的測試xml配置文件讓人有種嘔吐的感覺。那就做集成測試吧，兩個(gè)類關(guān)系很好，那么就整體測試它們的輸入和輸出，看起來很不錯(cuò)，功能實(shí)現(xiàn)了，測試也沒多寫，也不用準(zhǔn)備太多其他東西，但是打開實(shí)現(xiàn)代碼，你就發(fā)現(xiàn)那個(gè)丑陋，到處是復(fù)制和粘貼，是啊，不管黑貓白貓抓住老鼠就是好貓，只關(guān)注了當(dāng)前結(jié)果，完全失去了TDD驅(qū)動(dòng)簡單設(shè)計(jì)的好處。

3、測試的重點(diǎn)是測試用例的設(shè)計(jì)，它反映出對(duì)需求的理解
那么結(jié)論就很明顯，我們?nèi)绻B需求就沒有理解，如何進(jìn)行實(shí)現(xiàn)，所以測試驅(qū)動(dòng)是很自然的。