軟件自動化測試應該

軟件自動化測試應該  自動化測試工具

軟件自動化測試應該

事情(通常所說的建設性或積極的測試)的任何事情(通常所說的破壞性或消極的 測試)

  ·測試應用程序是健壯的(例如，能夠處理假的數據而不崩潰)；如果可能，特殊的積極測試結果和消極測試結果應該被確認為特殊測試腳 本的預期輸出。

    Fuchs是一個寧愿寫自動化測試用例而不愿記錄它們的人，他提供了一種創建自動化測試用例的三步方法，下面給出了具體的實施方案[2]。

    第一步：設計測試用例。Fuc}ls說每一個測試用例都應該包含l～10個密切相關的場景。具有10個以上場景的測試用例應該分成多個測試用例。每個場景都應該與一個惟一的預期結果相關聯。

    第二步：手工運行測試。Fudu指出在回歸測試中自動化測試是發現錯誤的最好方法，而在第一回合中用手工測試比較好。第一組測試用例在發現新錯誤方面應該是最有成效的，而回歸測試應該發現較多的與軟件的改進有關的錯誤。但是回歸測試確實發現了原來沒發現的錯誤。我們曾親眼看到回歸測試識別出了從一開始就存在于軟件系統中的錯誤(舉例來說，有一個錯誤在系統中存在了20多年，直到回歸測試發現了它)。

    第三步：自動化測試用例。在每個測試場景中，測試腳本應該包含以下幾個部分：

  ·進行設置

  ·進行測試

  ·驗證結果

  ·記錄結果

  ·處理意外情況

  ·決定停止還是繼續測試用倒

  ·進行請理工作

  測試腳本必須運行的設置工作包括定義測試所用的共同變量、常數以及過程；也包括啟動Aur和創建所需要的日錄和數據文件。

    測試工作需要模擬用戶是如何使用AWr的。這里比較重要的一點是測試場景必須按照它們被編寫的順序執行，因為這個順序代表著用戶怎么樣來進行工作。在識別典型的用作業務目的的場景時應該從功能需求文檔開始。比較好的方法是看一個人怎樣實際使用這個系統，然而在大多數情況下這是不可能的，因為系統沒經過測試。

    驗證結果涉及到檢查每個用戶操作中的控制參數的初始狀態和終止狀態。同時也意味著為那些預期的和非預期的變化檢查數據庫。驗證業務規則以及業務規則相互作用有關的應用程序功能性的惟一方法是確認那些變化是針對相關的數據值出現的。

    記錄結果就是指為每個測試用例的通過或失敗的狀態做一個記錄。這樣．在測試完成后，你可以回顧測試結果，可以把不同測試執行情況的測試記錄相比較。

    處理意外情況包括跟蹤意外事件并對它們進行恢復?？赡馨l生的意外事件包括意外按鍵、意外窗口、本來應該出現卻沒有出現的窗口和系統級的中斷。

    在每個測試場景結束時需要決定是停止還是繼續。作出怎樣的決定取決于剛剛執行的測試場景是處于通過狀態還是失敗狀態。在一些情況下，即使前面的測試場景失敗了，后面的仍然能夠執行，但在另外一些情況下，如果前面的測試場景失敗了，那么后面就會輸出無效的測試結果。

    進行清理工作包括關閉AuT、刪除任何不再需要的目錄和數據文件以及運行其他所有附屬的清理工作。這通常是指將測試用例返回到出發點。

    測試腳本應該置人測試套件中，并且測試套件從Shdl腳本中執行[2]。微軟v如u出1bt在線文檔顯示了如何設計功能區域測試套件、回歸測試套件、基準測試套件、壓力測試套件以及驗收測試套件。我們則添加了三類測試——單元測試套件、集成／冒煙測試套件和系統測試套件。

原文轉自：http://www.kjueaiud.com