一套軟件做完了，在給客戶上線之前，我們自己要進行完整的系統測試，這個工作聽起來好象沒什么，但其實是很不好做的，這要求測試人員要熟悉業務、熟悉系統的各個功能項、還要有一套完整的測試方法。我們軟件銷售部從開始做系統分析工作，現在又開始擔當系統測試的角色了，沒辦法，公司人手不夠，只能擔當多種角色了。不過對于我們來說也有一定好處，系統分析設計是我們做的，現在做好的系統由我們來測試，一是我們對業務比較熟悉，二是對我們來說也是一種自我的檢驗，檢驗一下自己設計的系統是否合理，為以后更好的系統分析打好基礎。

好了，言歸正傳，講一下我們在測試工作中的一點體會吧，寫出來一面為自己理一下思路，二也是為自己做工作的一個總結。

一、   測試之前要充分掌握業務流程

首先，在進行系統測試之前，要知道系統的業務流程，也就是說要清楚每項業務間發生的前后順序。只有知道了業務的先后順序，你的測試數據才能繼續在ERP系統功能間流轉，否則，無法進行各項業務的全面覆蓋測試。

其次，還要明白每一項業務中的詳細流程和各個環節涉及的角色，一項比較復雜的業務其詳細流程往往比較多，只有了徹底掌握了這項業務，才能對當前業務環節進行全方位的測試。比如：訂單管理中，銷售業務員創建了一個銷售訂單，還要經過主管審核，方可執行訂單，訂單執行完畢后關閉訂單。

二、   了解業務流程對應的ERP系統的功能

對整個業務有了總體的認識，再把業務分塊，在ERP中找出相應的模塊與業務對應起來。只有把業務和REP功能完全對應上了，才能說有可能對ERP系統進行全面的覆蓋測試。

三、   系統功能集中測試和測試方法

找到與具體業務對應的ERP子系統，根據當前業務的流程與角色，對ERP子系統進行集中測試。測試還要講求方法，盡量做到全覆蓋測試，其中注意幾點：

1）、按正常場景進行測試

根據業務流程，按著正常的順序，用正確的測試數據測試系統；檢查系統的結果是否與預期的結果相同，如果結果相符，表示當前系統模塊符合業務邏輯；否則，系統有問題，將錯誤信息記錄到BUG報告中，及時提交開發部門。

2）、測試異常場景

根據業務流程，輸入異常的測試數據測試系統，查看系統提示哪些異常信息，并查看是否有異常判斷，如果有，則表示系統做過異?？紤]處理，否則表示系統漏掉了當前異常情況，需要提示開發部門，添加當前異常情況的考慮處理。

3）、特殊數據的處理

根據業務流程，在輸入測試數據時，輸入邊緣數據、空值等特殊字符，查看系統是否做了數據錄入范圍和要求的判斷，如果沒有，表示系統遺漏數據范圍和錄入要求的考慮，需要提示開發部門，添加相應數據范圍和要求的處理。

以上三方面的考慮，是比較常見而且不可遺漏的測試部分，當然，可以用測試用例來規范。如：

四、   提交BUG報告

通過前邊的測試，把得出的錯誤信息，以BUG報告的形式展現出來，轉發給開發部門相應人員，以例開發部集中修改系統錯誤信息。下邊說一下BUG報告的內容：錯誤序號、發現日期、子系統名稱、二級模塊名稱、三級模塊名稱、發生頁面、錯誤描述、發現者、是否修改狀態、修改人意見、修改人、修改日期、確認人、確認日期。按著上邊這幾項內容，將錯誤信息以BUG報告的形式列表出來，轉發給相應的部門修改。

五、   回歸測試

BUG修改完畢后，更新ERP系統，更新完畢后，對已往的錯誤信息進行二次測試，以確保錯誤信息的正確修改。

通過以上五個步驟，把我們銷售部當前進行的測試工作，做了一個完整的總結，這就是我們目前采用的簡單的測試方法和步驟，經過我們的測試，系統性能得到了一定的提高，當然不否認系統還可能存在一些潛在的問題，這需要我們在后期維護中不斷的改進，今天寫到這里，希望有測試經驗的朋友能提出更好的測試建議，我們一同提高??！