標籤: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.