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

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

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

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

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

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

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

1.測試前準備階段

主要是相關業務的學習。業務知識是測試的根本依據，只有業務過關了，以后才能有效的進行測試工作。

了解業務步驟：

a、了解業務名詞；

b、對現有系統的學習：功能點、業務場景等；

c、分析現有系統數據庫，了解數據的走向。

2.需求分析階段

需求是項目開發的基礎，也是測試的依據。所以需求分析一定要做。但是很多公司是沒有詳細的需求文檔的，那如何進行需求分析呢？

此時分析數據庫就是一個非常好的方法：

a、每張表的索引和約束條件；

b、數據的來源、走向；

c、數據的存儲、變化；

d、數據間的關聯；

e、表與表間的關系；

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

3.測試計劃階段

    我們總是覺得被測試進度緊逼、計劃失控、測試不完全等等狀態，其實解決這些情況的最好方法就是：制定測試目標。

    在計劃初期先明確測試目標，制定不同層次目標的執行標準，指導后期設計不同級別的測試用例，跟蹤不同級別的缺陷修改。在測試時間較緊情況下，至少可以先把保證所有功能正常操作的最低目標版本先提交給客戶，不會再有手忙腳亂，心里沒底的狀況。

測試目標分為：

             最低目標

             基本目標

             較高目標

             最高目標   等級別

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

測試目標準則表

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

4.具體的ST用例的編寫以及執行

測試用例設計的粒度一直是個討論對象，很多時候總會強調時間很緊啊，如果時間再多點，我的用例肯定會設計的再細一些??！

是不是設計的越細就一定越好呢，不一定，測試是無窮盡的，使用窮舉方法來進行測試是不科學的。

因為制定了測試目標，那么就應該根據測試目標，在設計測試用例時也要制定設計用例目標。

比如：按照最低目標選擇測試用例

輸入—>有效

處理—>有效

輸出—>有效

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

5.測試之后的評估

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

1.保證所有需求都有測試用例

2.保證所有功能的正常操作和正常操作有對應的測試用例           V1.0版本

3.保證所有功能的異常校驗有對應的測試用例                     V2.0版本

4.各功能組合形成的業務流有對應的測試用例                     V3.0版本

5.各功能或整體軟件所需滿足的非功能性需求有對應的測試用例     V4.0版本

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

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

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