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

一、項目背景
所有對項目的介紹一定是從客戶開始。
客戶：我們的客戶是一家全球領(lǐng)先的時尚內(nèi)容提供商，通過遍布全球的員工，客戶每天獲取大量關(guān)于時裝發(fā)布、產(chǎn)品設(shè)計、街邊流行、城市熱點等信息，這些信息的絕大部分以圖片的形式上傳到公司服務(wù)器，然后由專職編輯對這些圖片進行整理和歸類（打標(biāo)簽），最后再由設(shè)計人員根據(jù)這些信息書寫分析報表。
關(guān)鍵內(nèi)容：分類細致的海量高清圖片和具有前瞻性的分析報表。
商業(yè)模式：網(wǎng)站，行業(yè)內(nèi)用戶訂閱-付費。
客戶面臨的問題：同質(zhì)化競爭、客戶流失。
新系統(tǒng)的關(guān)鍵詞：CMS、更精確的內(nèi)容分類、更好的全文檢索、更好的用戶體驗（更有表現(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)容存儲框架。
系統(tǒng)的特點：
URI唯一標(biāo)識資源
通過URI能夠直接映射到JCR節(jié)點，例如http://localhost:80/content/section/news.html能夠映射到JCR里的/content/section/news節(jié)點

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

資源的多重表述
同一資源可以存在多種表述形式，例如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。
因為JCR提供了一套節(jié)點模型，所以Domain Model是在節(jié)點模型上的行為增強，例如所有對圖片節(jié)點的操作我們封裝在Asset領(lǐng)域模型里。


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

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

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

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

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


手工測試
手工測試內(nèi)容主要是功能測試。
自動化測試價值低的部分我們采用手工測試，這部分內(nèi)容包括報表模板，相對獨立，內(nèi)容不多，一次測試處處通過；
自動化測試成本高的部分我們采用手工測試，這部分內(nèi)容包括報表展現(xiàn)組件的編輯功能，因為采用了Ext JS，所以自動化測試困難；
無法自動化的測試：報表在線生成PDF，報表樣式，WEBDEV批量上傳圖片等;

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

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

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

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

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