測試名稱 |
測試內(nèi)容 |
Black box黑盒測試 |
把軟件系統(tǒng)當(dāng)作一個“黑箱”,無法了解或使用系統(tǒng)的內(nèi)部結(jié)構(gòu)及知識。從軟件的行為,而不是內(nèi)部結(jié)構(gòu)出發(fā)來設(shè)計測試. |
White box白盒測試 |
設(shè)計者可以看到軟件系統(tǒng)的內(nèi)部結(jié)構(gòu),并且使用軟件的內(nèi)部知識來指導(dǎo)測試數(shù)據(jù)及方法的選擇。 |
Gray box. 灰盒測試 |
介于黑盒和白盒之間 |
總結(jié): 實際工作中,對系統(tǒng)的了解越多越好。目前大多數(shù)的測試人員都是做黑盒測試,很少有做白盒測試的。 因為白盒測試對軟件測試人員的要求非常高,需要有很多編程經(jīng)驗。做.NET程序的白盒測試你要能看得懂.NET代碼。做JAVA程序的測試,需要你能看懂JAVA的代碼。 如果你都能看懂了,你還會做測試么
從測試是手動還是自動上分類
測試名稱 |
測試內(nèi)容 |
Manual Test 手動測試 |
測試人員用鼠標(biāo)去手動測試 (測試GUI) |
Automation 自動化測試 |
用程序測試程序 (測試API) |
對于項目來說, 手動測試和自動化測試同等重要,都是保障軟件質(zhì)量的方法。 目前大部分的項目組都是手動測試和自動化測試相結(jié)合。因為很多測試無法做成自動化,很多復(fù)雜的業(yè)務(wù)邏輯也很難自動化, 所以自動化測試無法取代手動測試。
對于軟件測試人員個人發(fā)展來說, 做自動化測試是個挑戰(zhàn),也是測試人員發(fā)展的一個方向, 需要測試人員學(xué)習(xí)大量的開發(fā)知識(開發(fā)的知識真是學(xué)無止境?。?。 從長遠(yuǎn)角度來看,自動化測試肯定是越來越吃香的。
而手動測試比較適合剛工作不久的人,手動測試最大的缺點就是技術(shù)含量低,單調(diào)乏味,容易廢人。
總的來說,手工測試勝在測試業(yè)務(wù)邏輯,而自動化測試勝在測試底層架構(gòu)。
如果被測試的程序可測試性比較好, 很有必要做成自動化測試。 能做自動化的盡量做成自動化, 下面這些情形是可以做自動化的
1. 測試存儲過程。 例如用C#去測試存儲過程
2. 測試Web servies. 例如: 用SoupUI工具,或者C#,Java 去測試Web servies。
3. 界面和業(yè)務(wù)邏輯分離的系統(tǒng),比如,MVC,MVP架構(gòu), 或者WPF 程序。 可以用測試腳本去測試這些程序的API。
從測試的目的分類
功能測試
測試的范圍從小到大,從內(nèi)到外, 從程序開發(fā)人員(單元測試)到測試人員,到一般用戶Alpha/Beta測試
測試名稱 |
測試內(nèi)容 |
Unit Test 單元測試 |
在最低的功能/參數(shù)上驗證程序的準(zhǔn)確性,比如測試一個函數(shù)的正確性(開發(fā)人員做的) |
Functional Test 功能測試 |
驗證模塊的功能 (測試人員做的) |
Integration Test 集成測試 |
驗證幾個互相有依賴關(guān)系的模塊的功能 (測試人員做的) |
Scenario Test 場景測試 |
驗證幾個模塊是否能完成一個用戶場景 (測試人員做的) |
System Test 系統(tǒng)測試 |
對于整個系統(tǒng)功能的測試 (測試人員做的) |
Alpha 測試 |
軟件測試人員在真實用戶環(huán)境中對軟件進(jìn)行全面的測試 (測試人員做的) |
Beta 測試 |
真實的用戶在真實的用戶環(huán)境中進(jìn)行的測試, 也叫公測 (最終用戶做的) |
非功能測試
一個軟件除了基本功能之外,還有很多功能之外的特性,這些叫“Quality of Service requirement”服務(wù)質(zhì)量需求。沒有軟件的功能,這些特性都無從表現(xiàn)出來,因此,我們要在軟件開發(fā)的適當(dāng)階段-基本功能完成后做這些測試。
測試名稱 |
測試內(nèi)容 |
Stress test 壓力測試 |
驗證軟件在超過負(fù)載設(shè)計的情況下仍能返回正確的結(jié)果,沒有崩潰 |
Load test 負(fù)載測試 |
測試軟件在負(fù)載情況下能否正常工作 |
Performance test性能測試 |
測試軟件的效能,是否提供滿意的服務(wù)質(zhì)量 |
Accessibility test |
軟件輔助功能測試-測試軟件是否向殘疾用戶提供足夠的輔助功能 |
Localization/Globalization |
本地化/全球化測試 |
Compatibility Test |
兼容性測試 |
Configuration Test |
配置測試-測試軟件在各種配置下能否正常工作 |
Usability Test |
可用性測試 –測試軟件是否好用 |
Security Test |
軟件安全性測試 |
性能測試
性能測試要求測試人員熟練性能測試工具,比如QTP, LoadRunner, Jmeter。 Visual Studio也提供了很多性能測試的工具. 要求測試人員對低層協(xié)議非常理解和編寫腳本
性能測試非常有技術(shù)含量, 很有發(fā)展前途, 是軟件測試人員的一個職業(yè)發(fā)展方向。
安全性測試
安全性測試的內(nèi)容很廣, 非常有難度啊。 我只接觸過XSS(跨站腳本攻擊)和SQL注入攻擊。
安全性測試非常有技術(shù)含量, 我認(rèn)為也是軟件測試人員的一個職業(yè)發(fā)展方向
按測試的時機(jī)和作用分類
在開發(fā)軟件的過程中,不少測試起著“烽火臺”的作用,它們告訴我們軟件開發(fā)的流程是否暢通。
測試名稱 |
測試內(nèi)容 |
Smoke Test |
“冒煙”–如果測試不通過,則不能進(jìn)行下一步工作 |
Build Verification Test(BVT) |
驗證構(gòu)建是否通過基本測試。 |
Acceptance Test |
驗收測試,為了全面考核某功能/特性而做的測試 |
BVT測試是一種Smoke Test, 指Build生成好之后,自動運(yùn)行的自動化測試腳本來檢查這個Build的基本功能。 如果BVT測試失敗了,需要開發(fā)人員馬上修改,重新生成Build
按測試測策略分類。
測試名稱 |
測試內(nèi)容 |
Regression Test 回歸測試 |
對一個新的版本,重新運(yùn)行以往的測試用例,看看新版本和已知的版本相比是否有退化 (regression) |
Ad hoc Test 探索性測試 |
隨機(jī)進(jìn)行的,探索性的測試。 |
Sanity Test |
粗略的測試, 只需要執(zhí)行部分的測試用例 |
Regression Test 回歸測試:
對軟件測試人員來說就是重復(fù)測試,所以回歸測試最好是自動化的, 否則測試人員就要一遍又一遍地重復(fù)測試,
1. 開發(fā)人員做些小改動,就需要測試人員做回歸測試。確保現(xiàn)有的功能沒有被破壞
2. Bug Fix 也需要回歸測試,確保新的代碼修復(fù)了Fix, 也確?,F(xiàn)有的功能沒有被破壞
3. 項目后期,需要做一個完整回歸測試, 確保所有的功能都是好的
Ad hoc Test 探索性測試:
平常我最喜歡做隨機(jī)測試了, 拋開test case. 自己按照自己的思路,隨便點點。 如果測試GUI,Ad hoc能發(fā)現(xiàn)大量的bug.
以上就是對軟件測試的幾種方法整理,后續(xù)繼續(xù)整理相關(guān)資料,謝謝大家對本站的支持!
標(biāo)簽:泰安 濟(jì)寧 臺州 武威 汕頭 濟(jì)源 廣東 安徽
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《軟件測試方法大匯總》,本文關(guān)鍵詞 軟件測試,方法,大,匯總,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。