肯定會有人疑問，如果一個系統很龐大的話，怎么能在一兩天內完成測試呢？是的，如果系統比較大的話，確實沒法在一兩天內完成所有測試點的全面測試，有可能需要一周或更長的時間，但是這樣的話，就出現了測試、開發互相等待的情況了。所以，在我們制定的測試階段計劃時，需要指明本次測試的測試重點，測試范圍。我可以這一輪測試進行AMILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">、B模塊基本功能測試，第二輪測試進行C、D模塊基本功能測試，第三輪測試，進行主要業務流程測試，第四輪測試，關注負面測試。在我之前的實踐中，發現這種方法還是比較有效的�？赡艽蠹乙沧⒁獾搅�，這個例子是另一個項目的。沒錯，在今天提到的移動的這個項目中我們沒有按照這種策略進行測試，弄得當時我們測試小組工作很累，很被動，經常是開發說測試我們就要馬上開始測試，而缺乏計劃。實施這種方法后，測試的計劃性就比較強，測試不用總是被打擾。
2.1.2 測試設計
測試設計，主要是根據需求、設計文檔進行的測試用例設計工作。如何從需求導出測試用例并設計測試用例，是整個測試過程中很重要的一部分工作，關系到測試執行效果。但是在剛開始時，系統沒有界面，所以我們只能根據系統用例搭建測試用例的初步框架，能寫多少寫多少。隨著對系統的理解深入，加上后面也開發了系統原型，我們就可以不斷完善測試用例。即使是在測試階段，我們仍不斷修改測試用例。測試用例我們分為兩種，一種是內部測試用例，項目組內部使用；一種是驗收測試用例，偏重于業務，供客戶使用。項目組內部用的測試用例例子如圖六所示：
圖六測試用例例子（項目內用）
從圖中大家也可以感覺到項目組內部使用的測試用例在維護上比較不方便。因為我們的需求并沒有做到很細，加上需求本身就是變化的，所以我們的測試需求經常修改，一旦測試需求新增、修改、刪除時，測試用例要相應進行調整。這就造成了1)定位測試用例比較不方便，2)測試用例編號修改不方便，3)閱讀、執行測試用例不方便。所以，我在2004年底開始準備在團隊內自主開發一個測試用例管理系統。
2.1.3 測試執行
在測試執行階段，主要進行測試的執行工作。如果項目有需要編寫或錄制測試腳本的話，那么也在這個階段進行。測試執行結果是在原有測試用例的副本上編寫實際執行結果而形成。在東南融通，它是把這個活動單獨為“測試實施”環節。
2.1.4 測試分析
在測試執行結束后，我們開始對測試執行結果進行測試分析并編寫測試報告。測試報告的編寫上，主要的內容在于對投入的資源、測試結果、缺陷進行分析，并對整體測試情況進行總結分析。對于資源的分析，包括各個測試任務投入的人力情況、實際工作量與計劃工作量的對比，并進行分析。測試結果分析，可以通過對測試需求的覆蓋情況、測試用例的覆蓋情況及測試用例執行結果情況進行統計，并進行分析。缺陷分析，可以通過對嚴重性、優先級、模塊缺陷數、缺陷修復情況等方面進行統計，并分析。例如，對系統缺陷進行統計后，發現存在比較多的可用性問題，如修改操作員所屬的組后，無法登錄系統等。整體情況的總結可以從測試充分性、軟件質量情況、測試活動情況、經驗教訓等方面進行總結。
測試分析中有個很重要的活動是對測試活動和測試過程進行經驗教訓的總結。因為測試經驗教訓是很重要的，所以我們團隊有專人負責對每個項目測試報告中的經驗教訓進行匯總，目的是讓后面項目測試工作可以吸取前面項目測試的經驗，避免犯前面項目測試工作同樣的錯誤。
注：本測試過程對于每個階段的測試活動、每一輪測試活動、測試團隊承接的各種測試類型均適用。
也就是說，每一輪測試之前，測試組組長都需要準備測試計劃，確定測試執行重點、目標、測試內容等，選取測試用例，并按照預先選取的測試用例執行測試，測試執行結束，需要進行測試匯報。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
