手工測試
將xml文件內容正常解析并導入JCR只是第一步，第二步我們需要在Bundles里為該類(lèi)型的報表編寫(xiě)模板使之正常展現。由于涉及到報表樣式，這個(gè)測試我們采用手工測試，這個(gè)工作也是QA工作的重要一部分。
在最開(kāi)始的開(kāi)發(fā)中，我們沒(méi)有導入所有報表數據進(jìn)行測試。這帶來(lái)了問(wèn)題，由于客戶(hù)遺留數據跨越10多年，各種數據形式都可能存在（特別是04年以前數據，給UI帶來(lái)了很大挑戰），而最開(kāi)始的開(kāi)發(fā)中，我們只是使用了部分數據（09、10年數據）進(jìn)行測試，這個(gè)導致了建立UAT環(huán)境時(shí)程序的很多返工以及QA的測試壓力。
2、Bundles的測試
自動(dòng)化測試
對領(lǐng)域模型，我們采用了TDD的方式進(jìn)行單元測試；在本地Jackrabbit實(shí)例里建立數據，領(lǐng)域模型封裝數據測試行為。
對servlet，我們采用了TDD的方式進(jìn)行集成測試（同時(shí)測試了servlet和領(lǐng)域模型），在測試中對request和response進(jìn)行mock； 對JS，我們使用數據驅動(dòng)的selenium功能測試進(jìn)行覆蓋。
我們最后的自動(dòng)化測試結構：
手工測試
手工測試內容主要是功能測試。
自動(dòng)化測試價(jià)值低的部分我們采用手工測試，這部分內容包括報表模板，相對獨立，內容不多，一次測試處處通過(guò)；
自動(dòng)化測試成本高的部分我們采用手工測試，這部分內容包括報表展現組件的編輯功能，因為采用了Ext JS，所以自動(dòng)化測試困難；
無(wú)法自動(dòng)化的測試：報表在線(xiàn)生成PDF，報表樣式，WEBDEV批量上傳圖片等;
我們與QA的約定：
每完成一個(gè)用戶(hù)故事，我們會(huì )與QA、BA一起mini showcase；
QA驗收完成后編寫(xiě)功能測試用例；
我們對QA編寫(xiě)的功能測試用例進(jìn)行自動(dòng)化，共同維護一個(gè)功能測試列表；
對于不能自動(dòng)化或自動(dòng)化價(jià)值不高的測試用例QA繼續使用手工測試。
四、我們感受到的自動(dòng)化測試價(jià)值
1、通過(guò)自動(dòng)化功能測試，我們使得需求對客戶(hù)可視化；
2、QA的回歸測試成本降低，盡管目前頻繁的向客戶(hù)實(shí)際使用環(huán)境部署，但QA每次部署只需要做一些簡(jiǎn)單的冒煙測試；
3、測試即需求，這點(diǎn)在TDD的開(kāi)發(fā)過(guò)程中感覺(jué)非常明顯，今天開(kāi)發(fā)的目的就是使這個(gè)測試通過(guò)，避免了頻繁部署到應用中進(jìn)行測試，最快的電梯不是速度最快的電梯，而是中間停的樓層最少的電梯；
4、與持續集成一起，及時(shí)反饋。這點(diǎn)在進(jìn)行JS代碼編寫(xiě)時(shí)，心理上都非常依賴(lài)于selenium測試，對于沒(méi)有測試覆蓋的地方，沒(méi)有安全感；
5、足夠的單元、集成測試保證了頻繁重構，沒(méi)有人愿意引入BUG，沒(méi)有足夠的測試，沒(méi)人愿意重構；
6、測試即文檔，良好的測試和命名，使得新加入的成員非常容易理解當前代碼的功能。
五、思考和討論
1、自動(dòng)化功能測試做到多少才合適？
當然是越多越合適，問(wèn)題在于自動(dòng)化功能測試成本要大大高于單元測試和集成測試，這些成本反映在測試環(huán)境的搭建、數據的準備，需要準備其他很多關(guān)聯(lián)數據例如用戶(hù)信息和權限信息、自動(dòng)化功能測試的運行時(shí)間長(cháng)、穩定性（隨機成功/失�。�、編寫(xiě)等等，需要權衡成本與收益。
個(gè)人認為，自動(dòng)化功能測試需要考慮的著(zhù)重點(diǎn)包括：頁(yè)面是否包含大量功能交互性JS（與展現性JS相對）？當前功能是否與其他功能共享一些代碼？即獨立性，獨立性越低越需要著(zhù)重覆蓋（這里又涉及到另外一個(gè)問(wèn)題，即從各個(gè)模塊里重構出共用代碼是否總是合適？）。QA每次冒煙測試時(shí)是否需要重復回歸（重復回歸次數越多，自動(dòng)化越有價(jià)值）？經(jīng)常失敗的測試一定比不失敗的測試價(jià)值更高？或者從未失敗過(guò)的測試就沒(méi)有價(jià)值？
2、單元測試？功能單元測試？
TDD的測試粒度多大才合適？從我個(gè)人而言，幾乎天然的反對mock，為了滿(mǎn)足測試覆蓋率的追求，強制將兩個(gè)聯(lián)系很緊密的類(lèi)分開(kāi)，做出各式各樣mock，這真讓人氣餒；stub也不是什么好東西，在一個(gè)曾經(jīng)的spring項目里，在測試目錄里，一堆一堆的測試xml配置文件讓人有種嘔吐的感覺(jué)。那就做集成測試吧，兩個(gè)類(lèi)關(guān)系很好，那么就整體測試它們的輸入和輸出，看起來(lái)很不錯，功能實(shí)現了，測試也沒(méi)多寫(xiě)，也不用準備太多其他東西，但是打開(kāi)實(shí)現代碼，你就發(fā)現那個(gè)丑陋，到處是復制和粘貼，是啊，不管黑貓白貓抓住老鼠就是好貓，只關(guān)注了當前結果，完全失去了TDD驅動(dòng)簡(jiǎn)單設計的好處。
3、測試的重點(diǎn)是測試用例的設計，它反映出對需求的理解
那么結論就很明顯，我們如果連需求就沒(méi)有理解，如何進(jìn)行實(shí)現，所以測試驅動(dòng)是很自然的。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
