軟體測試方法

來源:互聯網
上載者:User

標籤:java   使用   資料   cti   for   io   

軟體測試方法種類繁多,記憶起來混亂, 如果把軟體測試方法進行分類, 就會清晰很多。 我參考一些書籍和網上的資料, 把常用的軟體測試方法列出來, 讓大家對軟體測試行業有個總體的看法。

 

從測試設計方法分類

 

測試名稱

測試內容

Black box黑箱測試

把軟體系統當作一個“黑箱”,無法瞭解或使用系統的內部結構及知識。從軟體的行為,而不是內部結構出發來設計測試.

White box白盒測試

設計者可以看到軟體系統的內部結構,並且使用軟體的內部知識來指導測試資料及方法的選擇。

Gray box.  灰盒測試

介於黑盒和白盒之間

 

總結:   實際工作中,對系統的瞭解越多越好。目前大多數的測試人員都是做黑箱測試,很少有做白盒測試的。 因為白盒測試對軟體測試人員的要求非常高,需要有很多編程經驗。做.NET程式的白盒測試你要能看得懂.NET代碼。做JAVA程式的測試,需要你能看懂JAVA的代碼。 如果你都能看懂了,你還會做測試麼

 

從測試是手動還是自動上分類

 

測試名稱

測試內容

Manual Test 手動測試

測試人員用滑鼠去手動測試 (測試GUI)

Automation 自動化測試

用程式測試程式 (測試API)

 

對於項目來說, 手動測試和自動化測試同等重要,都是保障軟體品質的方法。 目前大部分的項目組都是手動測試和自動化測試相結合。因為很多測試無法做成自動化,很多複雜的商務邏輯也很難自動化, 所以自動化測試無法取代手動測試。

對於軟體測試人員個人發展來說, 做自動化測試是個挑戰,也是測試人員發展的一個方向,  需要測試人員學習大量的開發知識(開發的知識真是學無止境啊)。 從長遠角度來看,自動化測試肯定是越來越吃香的。

而手動測試比較適合剛工作不久的人,手動測試最大的缺點就是技術含量低,單調乏味,容易廢人。

 

總的來說,手工測試勝在測試商務邏輯,而自動化測試勝在測試底層架構。

 

如果被測試的程式可測試性比較好, 很有必要做成自動化測試。 能做自動化的盡量做成自動化, 下面這些情形是可以做自動化的

1.   測試預存程序。  例如用C#去測試預存程序

2.   測試Web servies. 例如: 用SoupUI工具,或者C#,Java 去測試Web servies。

3.   介面和商務邏輯分離的系統,比如,MVC,MVP架構, 或者WPF 程式。 可以用測試指令碼去測試這些程式的API。

 

從測試的目的分類

功能測試

測試的範圍從小到大,從內到外, 從程式開發人員(單元測試)到測試人員,到一般使用者Alpha/Beta測試

測試名稱

測試內容

Unit Test 單元測試

在最低的功能/參數上驗證程式的準確性,比如測試一個函數的正確性(開發人員做的)

Functional Test 功能測試

驗證模組的功能  (測試人員做的)

Integration Test 整合測試

驗證幾個互相有依賴關係的模組的功能 (測試人員做的)

Scenario Test  情境測試

驗證幾個模組是否能完成一個使用者情境 (測試人員做的)

System Test  系統測試

對於整個系統功能的測試 (測試人員做的)

Alpha 測試

軟體測試人員在真實使用者環境中對軟體進行全面的測試 (測試人員做的)

Beta 測試

真實的使用者在真實的使用者環境中進行的測試, 也叫公測   (終端使用者做的)

 

 

 

非功能測試

一個軟體除了準系統之外,還有很多功能之外的特性,這些叫“Quality of Service requirement”服務品質需求。沒有軟體的功能,這些特性都無從表現出來,因此,我們要在軟體開發的適當階段-準系統完成後做這些測試。

 

測試名稱

測試內容

Stress test 壓力測試

驗證軟體在超過負載設計的情況下仍能返回正確的結果,沒有崩潰

Load test 負載測試

測試軟體在負載情況下能否正常工作

Performance test效能測試

測試軟體的效能,是否提供滿意的服務品質

Accessibility test

軟體協助工具功能測試-測試軟體是否向殘疾使用者提供足夠的協助工具功能

Localization/Globalization

本地化/全球化測試

Compatibility Test

相容性測試

Configuration Test

配置測試-測試軟體在各種配置下能否正常工作

Usability Test

可用性測試 –測試軟體是否好用

Security Test

軟體安全性測試

 

效能測試

效能測試要求測試人員熟練效能測試工具,比如QTP, LoadRunner, Jmeter。  Visual Studio也提供了很多效能測試的工具. 要求測試人員對低層協議非常理解和編寫指令碼

效能測試非常有技術含量, 很有發展前途, 是軟體測試人員的一個職業發展方向。

 

安全性測試

安全性測試的內容很廣, 非常有難度啊。 我只接觸過XSS(跨站指令碼攻擊)和SQL注入攻擊。

安全性測試非常有技術含量, 我認為也是軟體測試人員的一個職業發展方向

 

 

按測試的時機和作用分類

 

在開發軟體的過程中,不少測試起著“烽火台”的作用,它們告訴我們軟體開發的流程是否暢通。

 

測試名稱

測試內容

Smoke Test

“冒煙”–如果測試不通過,則不能進行下一步工作

Build Verification Test(BVT)

驗證構建是否通過基本測試。

Acceptance Test

驗收測試,為了全面考核某功能/特性而做的測試

 

BVT測試是一種Smoke Test, 指Build產生好之後,自動啟動並執行自動化測試指令碼來檢查這個Build的準系統。 如果BVT測試失敗了,需要開發人員馬上修改,重建Build

 

 

 

按測試測策略分類。

 

測試名稱

測試內容

Regression Test 迴歸測試

對一個新的版本,重新運行以往的測試案例,看看新版本和已知的版本相比是否有退化 (regression)

Ad hoc Test 探索性測試

隨機進行的,探索性的測試。

Santiy Test

粗略的測試, 只需要執行部分的測試案例

 

Regression Test 迴歸測試:  

對軟體測試人員來說就是重複測試,所以迴歸測試最好是自動化的, 否則測試人員就要一遍又一遍地重複測試, 

1. 開發人員做些小改動,就需要測試人員做迴歸測試。確保現有的功能沒有被破壞

2. Bug Fix 也需要迴歸測試,確保新的代碼修複了Fix, 也確保現有的功能沒有被破壞

3. 項目後期,需要做一個完整迴歸測試, 確保所有的功能都是好的

 

Ad hoc Test 探索性測試: 

平常我最喜歡做隨機測試了, 拋開test case.  自己按照自己的思路,隨便點點。 如果測試GUI,Ad hoc能發現大量的bug. 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.