系統測試全過程

系統測試全過程


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

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

1.測試前準備階段
主要是相關業務的學習。業務知識是測試的根本依據，只有業務過關了，以后才能有效的進行測試工作。
了解業務步驟：
a、了解業務名詞；
b、對現有系統的學習：功能點、業務場景等；
c、分析現有系統數據庫，了解數據的走向。

2.需求分析階段
需求是項目開發的基礎，也是測試的依據。所以需求分析一定要做。但是很多公司是沒有詳細的需求文檔的，那如何進行需求分析呢？
此時分析數據庫就是一個非常好的方法：
a、每張表的索引和約束條件；
b、數據的來源、走向；
c、數據的存儲、變化；
d、數據間的關聯；
e、表與表間的關系；

這些分析都可以為了解業務場景和之后的測試用例設計打好基礎。

3.測試計劃階段
    我們總是覺得被測試進度緊逼、計劃失控、測試不完全等等狀態，其實解決這些情況的最好方法就是：制定測試目標。
    在計劃初期先明確測試目標，制定不同層次目標的執行標準，指導后期設計不同級別的測試用例，跟蹤不同級別的缺陷修改。在測試時間較緊情況下，至少可以先把保證所有功能正常操作的最低目標版本先提交給客戶，不會再有手忙腳亂，心里沒底的狀況。
測試目標分為：
             最低目標
             基本目標
             較高目標
             最高目標   等級別

可以使用表格形式來規范目標準側，例如：

測試目標準則表

目標
 測試范圍
 需求覆蓋率
 
最低目標：

正常的輸入+正常的處理過程，有一個正確的輸出

 
 （明確的功能點全部列出來）
 1.        功能：

正常功能

異常功能

單功能    

業務場景

非功能：16種測試類型

2.        輸入覆蓋率：

有效無效

處理過程：基本流

          備選流

狀態變化：正常、異常

輸出
 
SRS00001
 
SRS00002
 
SRS00003
 
基本目標：

對異常的輸入有錯誤的捕獲，并進行相應提示或屏蔽

 
 
 
 
較高目標：

對隱式需求進行測試

 
根據公司規模不同，確定測試目標級別也可不同。一般小公司有最低標、基本目標即可，大公司可以提高目標標準，直接從基本目標開始，直至最高目標。

4.具體的ST用例的編寫以及執行
測試用例設計的粒度一直是個討論對象，很多時候總會強調時間很緊啊，如果時間再多點，我的用例肯定會設計的再細一些??！
是不是設計的越細就一定越好呢，不一定，測試是無窮盡的，使用窮舉方法來進行測試是不科學的。
因為制定了測試目標，那么就應該根據測試目標，在設計測試用例時也要制定設計用例目標。

比如：按照最低目標選擇測試用例
輸入—>有效
處理—>有效
輸出—>有效
按照最低目標的宗旨，只要是設計出來的測試用例足以覆蓋和驗證系統基本功能可以正常使用，那么這些測試用例的粒度就足夠細了！從而提高了設計用例效率，同時也提高了測試效率。

5.測試之后的評估
實現一級測試目標之后都要進行評審工作，根據評審結果進行系統版本發布。例如：

1.保證所有需求都有測試用例
2.保證所有功能的正常操作和正常操作有對應的測試用例           V1.0版本
3.保證所有功能的異常校驗有對應的測試用例                     V2.0版本
4.各功能組合形成的業務流有對應的測試用例                     V3.0版本
5.各功能或整體軟件所需滿足的非功能性需求有對應的測試用例     V4.0版本

這樣做既可以對代碼版本進行控制，也可以應對需求變更的問題。

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

原文轉自：http://www.anti-gravitydesign.com