軟件測試中如何做好系統測試

軟件測試中如何做好系統測試

我一直感覺系統測試總像馬拉松總是測試不完，什么時候上線，什么時候算終點。雖然提交客戶了，可是對于質量仍然心里沒底，對于測試的效果沒有評價的依據。后來經過高人指點，終于領悟到至關重要的精髓：明確測試目標！

    如果要將系統進行全面測試，那么就要有一套完整的測試階段，每個階段都以測試目標為標準，科學、有序地進行測試，那么測試效率也就會自然而然跟著提高。

測試階段分為：測試前準備、需求分析、測試計劃、測試設計、測試執行、測試結果。

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

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

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

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

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

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

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

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

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

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

2）、測試異常場景

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

3）、特殊數據的處理

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

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

四、   提交BUG報告

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

五、   回歸測試

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

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

    也許“確定測試目標”還不能徹底解決復雜測試工作中出現的問題，但是我覺得這最起碼可以讓你的測試工作變得有條理；跟領導匯報工作的時候業績和工作效率有憑可據；面對需求變更的時候有理可依！

文章來源于領測軟件測試網 http://www.k11sc111.com/

TAG: 軟件測試 系統