從事軟件測試工作已經有兩年多的時間了，在這期間內，我曾和大家一起參與過PS、GS多個版本的產品發(fā)版測試，也曾單獨或與客戶一起參與了多個項目的測試。通過這些經歷，我個人對ERP軟件測試有了一個更高的認識，只有真正以客戶為關注焦點，ERP軟件測試才能有質的提高。我想從今年我所經歷的兩個項目，分別是上海交行年金項目和新汶考核管理，來詳細的說明一下，在這兩個項目的測試過程中，是如何盡量做到以客戶為關注焦點的。

　　上海交行年金項目

　　這次年金項目測試，是由交行的工作人員帶領進行的一次上線前的測試。整個測試過程在交行內部進行，歷經兩個月，截止年金系統(tǒng)上線試運行后一個月結束。

　　測試流程

　　第一輪：功能測試。

　　第二輪：第一輪UAT分組測試。

　　第三輪：第二輪UAT分組測試。

　　第四輪：真實業(yè)務測試。

　　渠道測試，性能測試。

　　功能測試

　　本次功能測試是在集成環(huán)境針對各功能點的測試，主要目的是為了確保各功能點無嚴重影響流程的問題，暫沒有更深一步的測試。

　　雖然交行年金系統(tǒng)功能點巨多，但由于測試人員也比較多，每個人分別負責不同的功能模塊，大約一周時間幾乎將所有功能點覆蓋了一遍。這個過程沒有測試用例，所有測試人員均是手動自行輸入數據，亦沒有進行數據記錄，每天下午5點和晚上9點進行兩次程序更新。

　　雖然功能測試進行的并不深入，時間也比較短，但是效果非常明顯，為后面的UAT測試和真實業(yè)務測試做出了很好的鋪墊。

　　UAT測試

　　UAT（User Acceptance Test），用戶接受度測試。其實本階段測試我感覺是系統(tǒng)上線前的真實業(yè)務測試。

　　由于本次UAT測試之前，進行了一次功能測試，所以測試人員的系統(tǒng)結構和業(yè)務流程都有了一定的了解，更為重要的是交行工作人員提供了三份非常完備的測試案例，這些案例都是根據交行的客戶的真實數據組織而來，客戶資料，業(yè)務流程、客戶職責、輸入數據、輸出數據，甚至連登記日期時間都非常詳細，完全避免了由于測試人員對新系統(tǒng)陌生而感覺測試無從下手的尷尬局面。

　　測試執(zhí)行過程中，將所有測試人員按照三份交行客戶的測試案例分成了三個測試小組，每個組內又按照不同的職責進行了分工，而不是再按照功能模塊進行分工了，所以每個測試人員幾乎都要按照業(yè)務流程測到所有的模塊。譬如海爾測試用例分別設置了海爾集團，海爾總部公司，海爾分公司，虛擬公司四個職責，在一起初始完基礎數據和客戶資料后，各測試人員會按照職責的分工，并分別按照著測試案例里的流程和數據進行測試。由于各職責之間不管是業(yè)務還是數據都存在著一定的關系，譬如，上級公司可引用下級公司的數據，上級公司下達的指標下級公司是否準確收到并報告完成情況，所以在測試時大家既獨立又關聯(lián)，需要所有測試人員功能盡力協(xié)作才能順利的完成本階段測試。

　　UAT測試分了兩輪，第二輪測試新建了帳套，各測試人員對職責進行了互換，流程和數據沒有變化。

　　在UAT測試的同時，也進行著一項非常重要的測試，也是本次測試所需攻占的難點，是日終測試。日終，應該是銀行系統(tǒng)所特有的一項功能，這個測試主要有兩個目的：一是確保各功能模塊的日終過程均無問題；二是確保日終后的數據正確。這個測試在獨立于UAT測試的另一套帳套里進行，每天分別進行一個功能模塊的日終測試，測試人員還是按照功能測試的分工進行。測試數據手動輸入，并且要對輸入的數據進行記錄，順利完成日終后，按照公式手動計算來驗證日終后的數據是否正確。

　　真實業(yè)務測試

　　本階段測試是在年金系統(tǒng)3月5日上線后的試運行階段進行的，在正式服務器上建立了一套與正式帳套并行的測試帳套，測試分工和測試數據仍沿用UAT測試階段的方案，不同的是本次測試嚴格按照銀行的工作安排進行，譬如，系統(tǒng)每天都是早上9點開門，晚上9點日終，每天發(fā)生的業(yè)務和需要錄入的數據都要嚴格按照案例在當天進行。不管是流程還是數據，這個階段的測試都是接近客戶實際業(yè)務的測試。

　渠道測試，性能測試

　　渠道測試，與前面所說的第二輪UAT測試同步開始，由交行各渠道的年金工作人員進行測試，測試出的問題也在第一時間反饋項目組。

　　性能測試，交行請了Mercury的工作人員使用loadrunner進行了性能測試，同時也讓他們對一些相對簡單的功能給錄制了QTP腳本，用來對這些功能進行更新后的驗證。