Workspace軟件測試工作流程

1. 確定需求與設計方案
        需求與設計方案的確定將直接影響軟件開發。如果軟件不能滿足顧客的需求，風格再好的程序也毫無價值。為避免這種情況，測試工程師應該參與到需求與設計文檔的審核工作中。這些文檔包括：

項目經理編寫的需求說明，包括市場部門與客戶支持部門的相關信息。 以需求說明為參考的功能設計要求，同樣由項目經理編寫。 由開發人員編寫的以功能設計方案為參考的設計方案實現說明。

        作為測試工程師，其主要任務就是檢查這些文檔的完整性、嚴格性和功能可測試性。這個過程也有助于測試工程師更早地參與項目開發。

 2. 準備測試計劃和測試用例
        測試計劃和測試用例是基于功能設計方案進行編寫的?！皽y試計劃”定義了測試的范圍、方法、資源和流程。這份計劃概括了測試項目、測試質量、測試任務、任務原則和風險。大多數情況下測試計劃還包括系統測試。因為單元測試和集合測試是開發人員的責任，開發計劃中也可以包括這些項目。對各階段測試工作量的評估時，可以假設每個階段所需的時間都是前一階段的1.1或1.5倍。比如，系統測試時間一般是編程階段（包括單元測試與集合測試）的1.1到1.5倍。
        測試計劃中最重要的一個方面便是變量控制。這些變量主要來于項目計劃、需求、測試軟件版本和測試資源。有效地處理變量可以減少風險。 
         測試用例也提供了對測試任務、測試模式、方法、技術和策略的描述。內容涉及測試目標、測試環境、數據輸入、測試步驟、預期結果和測試腳本。作為軟件測試的關鍵，測試用例將引導集合測試、系統測試和回歸測試的實行。此外，測試用例還可以用來度量測試結果，分析軟件缺陷并提高軟件質量。為完善測試用例設計，必須拋棄一些關于測試用例的錯誤觀點。測試用例并不是為了檢測“異?！比毕?。作為測試的基礎，測試用例必須完全覆蓋測試需求，也不能以個例為參考。測試用例的詳細程度應該考慮到測試人員對軟件的熟悉程度，既不能太簡單也不能過于詳細。測試人員必須明白測試用例是“活的”，它們必須在整個測試過程中及時更新。如果沒有根據需求和設計方案同步更新，測試用例將失效。 
         因此，任何測試用例都應該添加明顯的驗證方法。這對測試人員判斷輸出與預期結果的一致性是必要的。 
         同樣，項目經理和開發人員也需要對測試計劃和測試用例進行審核。這樣整個團隊才能對項目有個統一的了解。

 3. 測試實現
        主要測試流程是根據測試計劃執行測試用例程序。這包括編寫自動化測試腳本并反復執行這些腳本，也包括執行手工測試用例程序。測試順序是本著從簡單到復雜、從簡單功能測試到整體功能測試、從表面bug到深層bug的原則進行的。隨著項目開發和測試流程的發展，產品的功能和質量也將提高。因此必須反復執行測試用例以避免質量回歸，特別是自動化測試每次進行？連編時。測試人員的另一個任務是維護測試用例。如果根據最初說明文檔設計的測試方案中存在問題，或者當前的測試用例沒有覆蓋顧客反映的一些bug，就應該添加新的測試用例。

自動化測試

        為完善Workspace環境下的測試，我們使用IBM RFT（IBM的功能測試工具，Rational Functional Tester）實現自動化測試。

      

  如圖3所示，自動化測試過程可以分為兩個階段：

1. 準備腳本

開始錄制：打開RFT并精確地錄制測試用例的相關操作。 增強腳本功能：插入驗證點、測試參數和If/Else或Loop控制語句提高回歸測試自動化性能。 調試腳本：調試并驗證腳本。

 2. 回歸測試

執行腳本：通過自動化測試工具，執行腳本并驗證軟件。 結果分析：檢查日志文件的執行結果，分析軟件的問題并報告。

        自動化工具的使用提高了測試的效率，并可使測試人員將更多的注意力放在開發新測試模型和提高測試用例覆蓋率上。此外，自動化測試還提供了測試資源的數字化管理方式，這些測試資源還可以在功能測試與回歸測試中實現重用。

 

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