Posted on 2005-12-08 17:09
笨笨 閱讀(1793)
評論(0) 編輯 收藏 所屬分類:
軟件開發
業務驅動用例測試
笨笨所知的測試大致分類
單元測試/Unit test
基于代碼中類或函數一級的測試
用例測試/Use case test.
基于一個完整業務用例的測試，可以不包括用戶業務系統環境的完整操作流程。
如，銀行網銀系統的轉賬測試可以認為是一個完整業務用例測試，但是不必要要求測試用例先執行登錄過程，再進行轉賬業務代碼的測試。
集成測試/Integration test
由業務人員主導，業務系統作為一個完整黑盒，測試系統功能和性能。
用戶接受測試/User Accept test
集成測試通過后，用戶基于生產系統剝離的實際數據，再一次對業務系統執行測試；如果集成測試不充分，可以再一次有機會暴露系統的缺陷。
項目實施過程與測試
從項目的實施過程來說，單元測試是程序員自測，算在開發階段，集成測試和用戶接受測試所占用時間能夠達到項目代碼開發階段的一倍到兩倍，大型項目的測試階段可能還要長。
而用例級測試目前很少作為一個正式的階段在項目實施過程中存在，或由程序員自行自測，或合并到集成測試過程中。
對于大型業務系統，集成測試和用戶測試所花費的主要工作量如下，可能不全。
1 數據準備，測試人員調配準備。
2 測試過程中，測試人員要找到哪些測試數據還能用，再手工操作系統界面，執行測試過程。對于大型業務系統來說，可用測試數據是隨著測試進展不斷變化的，很有可能某個用戶數據剛剛狀態正常，現在就欠費了。要想找到合適的數據來測試系統，這是個費勁且混亂的過程。
3 集成回歸測試，業務系統如果有升級或改動，需要將所有交易重新測試一遍，以防止變更給原有代碼引入缺陷。
用例測試
用例測試關注業務。
用例測試集中在業務服務這一層，業務服務直接對應了業務用例。
用例測試注重業務服務運行環境的模擬和重現，從而支持業務服務層的自動測試。
用例測試的價值
1 減少集成測試的時間和成本，降低集成測試發現缺陷數，從而降低項目總缺陷修復代價。
用例測試缺陷修復代價遠低于集成測試的缺陷修復代價；用例測試發現大部分缺陷后，集成測試就相對輕松了。
2 可回歸的用例測試支持快速代碼重構。
3 ...
單元測試無法覆蓋用例測試
業務代碼運行需要底層資源如數據庫或其它業務系統配合，單元測試工具缺乏提供業務服務運行所需環境的模擬，從Junit系列單元測試工具來說，它還是主要從技術角度考慮，從業務角度的考慮如：
底層資源（數據庫，JMS）模擬
依賴服務模擬
服務訪問模擬
自動檢測、重放和比對服務運行時的輸入輸出參數、資源、依賴服務。
服務接口變動波及分析
代碼重構的成本
代碼重構需要付出代價。集成測試費時費力，但用戶不可能因為程序員說“我保證代碼重構不會改變系統功能”，就不對變動后代碼進行測試。
用例回歸測試支持可以以較小代價支持代碼重構，因為它可在業務服務級自動對功能進行驗證，集成測試工作能夠相應的減少。