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

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

二、系統架構與模塊劃分
1、REST的架構風格
系統采用了Sling作為WEB框架，JCR作為了底層內容存儲框架。
系統的特點：
URI唯一標識資源
通過URI能夠直接映射到JCR節點，例如http://localhost:80/content/section/news.html能夠映射到JCR里的/content/section/news節點

GET/POST/DELETE標準方法對資源進行操作
支持標準方法對資源的直接操作

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

http://localhost:80/content/section/news.json展現資源信息的JSON描述，
http://localhost:80/content/section/news.pdf展現網頁的PDF。

服務器端的無狀態
通過JS獲取當前用戶信息并緩存在客戶端。

2、系統分層
系統分為四層：JS、Servlet、Domain Model和JCR。
因為JCR提供了一套節點模型，所以Domain Model是在節點模型上的行為增強，例如所有對圖片節點的操作我們封裝在Asset領域模型里。


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

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

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

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

我們最后的自動化測試結構：


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

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

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

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

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

3、測試的重點是測試用例的設計，它反映出對需求的理解
那么結論就很明顯，我們如果連需求就沒有理解，如何進行實現，所以測試驅動是很自然的。