軟件測(cè)試方法種類繁多，記憶起來(lái)混亂， 如果把軟件測(cè)試方法進(jìn)行分類, 就會(huì)清晰很多。 我參考一些書籍和網(wǎng)上的資料， 把常用的軟件測(cè)試方法列出來(lái)， 讓大家對(duì)軟件測(cè)試行業(yè)有個(gè)總體的看法。

從測(cè)試設(shè)計(jì)方法分類

總結(jié)：   實(shí)際工作中，對(duì)系統(tǒng)的了解越多越好。目前大多數(shù)的測(cè)試人員都是做黑盒測(cè)試，很少有做白盒測(cè)試的。 因?yàn)榘缀袦y(cè)試對(duì)軟件測(cè)試人員的要求非常高，需要有很多編程經(jīng)驗(yàn)。做.NET程序的白盒測(cè)試你要能看得懂.NET代碼。做JAVA程序的測(cè)試，需要你能看懂 JAVA的代碼。 如果你都能看懂了，你還會(huì)做測(cè)試么

從測(cè)試是手動(dòng)還是自動(dòng)上分類

對(duì)于項(xiàng)目來(lái)說(shuō)， 手動(dòng)測(cè)試和自動(dòng)化測(cè)試同等重要，都是保障軟件質(zhì)量的方法。 目前大部分的項(xiàng)目組都是手動(dòng)測(cè)試和自動(dòng)化測(cè)試相結(jié)合。因?yàn)楹芏鄿y(cè)試無(wú)法做成自動(dòng)化，很多復(fù)雜的業(yè)務(wù)邏輯也很難自動(dòng)化， 所以自動(dòng)化測(cè)試無(wú)法取代手動(dòng)測(cè)試。

對(duì)于軟件測(cè)試人員個(gè)人發(fā)展來(lái)說(shuō)， 做自動(dòng)化測(cè)試是個(gè)挑戰(zhàn)，也是測(cè)試人員發(fā)展的一個(gè)方向，  需要測(cè)試人員學(xué)習(xí)大量的開(kāi)發(fā)知識(shí)（開(kāi)發(fā)的知識(shí)真是學(xué)無(wú)止境啊）。 從長(zhǎng)遠(yuǎn)角度來(lái)看，自動(dòng)化測(cè)試肯定是越來(lái)越吃香的。

而手動(dòng)測(cè)試比較適合剛工作不久的人，手動(dòng)測(cè)試最大的缺點(diǎn)就是技術(shù)含量低，單調(diào)乏味，容易廢人。

總的來(lái)說(shuō)，手工測(cè)試勝在測(cè)試業(yè)務(wù)邏輯，而自動(dòng)化測(cè)試勝在測(cè)試底層架構(gòu)。

如果被測(cè)試的程序可測(cè)試性比較好， 很有必要做成自動(dòng)化測(cè)試。 能做自動(dòng)化的盡量做成自動(dòng)化， 下面這些情形是可以做自動(dòng)化的

1.   測(cè)試存儲(chǔ)過(guò)程。  例如用C#去測(cè)試存儲(chǔ)過(guò)程

2.   測(cè)試Web servies. 例如： 用SoupUI工具，或者C#,Java 去測(cè)試Web servies。

3.   界面和業(yè)務(wù)邏輯分離的系統(tǒng)，比如，MVC，MVP架構(gòu)， 或者WPF 程序。 可以用測(cè)試腳本去測(cè)試這些程序的API。

從測(cè)試的目的分類

功能測(cè)試

測(cè)試的范圍從小到大，從內(nèi)到外， 從程序開(kāi)發(fā)人員（單元測(cè)試）到測(cè)試人員，到一般用戶Alpha/Beta測(cè)試

非功能測(cè)試

一個(gè)軟件除了基本功能之外，還有很多功能之外的特性，這些叫“Quality of Service requirement”服務(wù)質(zhì)量需求。沒(méi)有軟件的功能，這些特性都無(wú)從表現(xiàn)出來(lái)，因此，我們要在軟件開(kāi)發(fā)的適當(dāng)階段-基本功能完成后做這些測(cè)試。

性能測(cè)試

性能測(cè)試要求測(cè)試人員熟練性能測(cè)試工具，比如QTP, LoadRunner, Jmeter。  Visual Studio也提供了很多性能測(cè)試的工具. 要求測(cè)試人員對(duì)低層協(xié)議非常理解和編寫腳本

性能測(cè)試非常有技術(shù)含量， 很有發(fā)展前途， 是軟件測(cè)試人員的一個(gè)職業(yè)發(fā)展方向。

安全性測(cè)試

安全性測(cè)試的內(nèi)容很廣， 非常有難度啊。 我只接觸過(guò)XSS（跨站腳本攻擊）和SQL注入攻擊。

安全性測(cè)試非常有技術(shù)含量， 我認(rèn)為也是軟件測(cè)試人員的一個(gè)職業(yè)發(fā)展方向

按測(cè)試的時(shí)機(jī)和作用分類

在開(kāi)發(fā)軟件的過(guò)程中，不少測(cè)試起著“烽火臺(tái)”的作用，它們告訴我們軟件開(kāi)發(fā)的流程是否暢通。

BVT測(cè)試是一種Smoke Test, 指Build生成好之后，自動(dòng)運(yùn)行的自動(dòng)化測(cè)試腳本來(lái)檢查這個(gè)Build的基本功能。 如果BVT測(cè)試失敗了，需要開(kāi)發(fā)人員馬上修改，重新生成Build

按測(cè)試測(cè)策略分類。

Regression Test 回歸測(cè)試：　　

對(duì)軟件測(cè)試人員來(lái)說(shuō)就是重復(fù)測(cè)試，所以回歸測(cè)試最好是自動(dòng)化的，　否則測(cè)試人員就要一遍又一遍地重復(fù)測(cè)試，　

1. 開(kāi)發(fā)人員做些小改動(dòng)，就需要測(cè)試人員做回歸測(cè)試。確?，F(xiàn)有的功能沒(méi)有被破壞

2. Bug Fix 也需要回歸測(cè)試，確保新的代碼修復(fù)了Fix, 也確保現(xiàn)有的功能沒(méi)有被破壞

3. 項(xiàng)目后期，需要做一個(gè)完整回歸測(cè)試， 確保所有的功能都是好的

Ad hoc Test 探索性測(cè)試： 

平常我最喜歡做隨機(jī)測(cè)試了， 拋開(kāi)test case.  自己按照自己的思路，隨便點(diǎn)點(diǎn)。 如果測(cè)試GUI，Ad hoc能發(fā)現(xiàn)大量的bug.