一、想要零基礎(chǔ)學(xué)好軟件測(cè)試，當(dāng)然需要對(duì)測(cè)試有一個(gè)良好的認(rèn)知。你可以大致的瀏覽一下標(biāo)題，先看這些標(biāo)題從理解上看有沒(méi)有難度。然后在根據(jù)自己的情況來(lái)判斷軟件測(cè)試是否難學(xué)。

1、什么是軟件測(cè)試?

軟件測(cè)試(英語(yǔ)：Software Testing)，描述一種用來(lái)促進(jìn)鑒定軟件的正確性、完整性、安全性和質(zhì)量的過(guò)程。換句話說(shuō)，軟件測(cè)試是一種實(shí)際輸出與預(yù)期輸出之間的審核或者比較過(guò)程。軟件測(cè)試的經(jīng)典定義是：在規(guī)定的條件下對(duì)程序進(jìn)行操作，以發(fā)現(xiàn)程序錯(cuò)誤，衡量軟件質(zhì)量，并對(duì)其是否能滿足設(shè)計(jì)要求進(jìn)行評(píng)估的過(guò)程。

2、怎樣才算一個(gè)真正的軟件測(cè)試工程師?

真正的軟件測(cè)試工程師算是半個(gè)產(chǎn)品經(jīng)理，半個(gè)開(kāi)發(fā)工程師。有人覺(jué)得這個(gè)標(biāo)題有點(diǎn)諷刺，真正的測(cè)試?難道我們不是真正的測(cè)試，平常做的都不是測(cè)試的工作嗎?其實(shí)不肯定也不否定，但這是一個(gè)包含關(guān)系，如果只是評(píng)審+用例編寫(xiě)執(zhí)行，那么確實(shí)不是一個(gè)真正的測(cè)試。

正如標(biāo)題那樣，我認(rèn)為真正的測(cè)試 =“半個(gè)產(chǎn)品+半個(gè)開(kāi)發(fā)”。

半個(gè)產(chǎn)品，主要體現(xiàn)在理解這個(gè)需求為什么要做?其核心價(jià)值在哪里?吸引用戶的特點(diǎn)是什么?意味著在評(píng)審階段，你除了幫助完善功能需求外，更重要的是理解這個(gè)需求對(duì)于用戶有什么價(jià)值，你是用戶你會(huì)怎么想有什么感受,不能簡(jiǎn)單的走完流程就可以了，比如一個(gè)播放視頻類應(yīng)用， 多樣性 流暢度 簡(jiǎn)易性 快速性等 這是在評(píng)審之后可以總結(jié)出來(lái)的，那么抱著這個(gè)價(jià)值點(diǎn)，圍繞這我們的整個(gè)測(cè)試流程，往往能夠發(fā)現(xiàn)不一樣的地方。比如還是播放類應(yīng)用，在我了解個(gè)特性后，在測(cè)試過(guò)程中我會(huì)更加留意播放方面的性能，以及兼容性，在我設(shè)計(jì)測(cè)試方案的時(shí)候就會(huì)標(biāo)明這幾個(gè)測(cè)試重點(diǎn)，以便我自己或者組員能夠在測(cè)試過(guò)程中多加留意這部分的測(cè)試點(diǎn)，然后在設(shè)計(jì)測(cè)試用例的時(shí)候會(huì)提高優(yōu)先級(jí)和覆蓋率。可以發(fā)現(xiàn)，測(cè)試有了測(cè)重點(diǎn)。

半個(gè)開(kāi)發(fā)，其實(shí)個(gè)人認(rèn)為這是偏向于灰盒測(cè)試了，體現(xiàn)在一個(gè)需求，你除了要明確這個(gè)需求的業(yè)務(wù)邏輯，其代碼邏輯(數(shù)據(jù)流邏輯)也是需要知道的，從后臺(tái)獲取的json數(shù)據(jù)結(jié)構(gòu)到客戶端展示再到存儲(chǔ)至本地?cái)?shù)據(jù)，這一個(gè)流向，都是需要去了解并測(cè)試的(這部分參照之前寫(xiě)的測(cè)試分析文章)，所以測(cè)試驗(yàn)證的不僅僅是功能層面的東西，還是內(nèi)部的具體實(shí)現(xiàn)(當(dāng)然，具體到類方法的測(cè)試那是測(cè)試開(kāi)發(fā)的職能，不關(guān)咱測(cè)試的事)，我們要保證的，就是這一階段數(shù)據(jù)的正確性和容錯(cuò)性。這樣做的好處是，能從內(nèi)部發(fā)現(xiàn)缺陷，在出現(xiàn)問(wèn)題的時(shí)候可以大概定位到問(wèn)題出在哪，在出問(wèn)題面對(duì)boss的質(zhì)疑能夠把責(zé)任丟給開(kāi)發(fā)，哦不，是更好的解決問(wèn)題。

那么半個(gè)開(kāi)發(fā)還體現(xiàn)在對(duì)工具效率的提升上，能夠通過(guò)小腳本，小框架去提升測(cè)試效率，這要求對(duì)于基本的語(yǔ)言要求是必須的，大公司面試的某一輪考研的就是你的代碼能力，所以測(cè)試還是半個(gè)開(kāi)發(fā)這一點(diǎn)是毋庸置疑滴。

1、測(cè)試項(xiàng)目啟動(dòng)與規(guī)劃

一般地，項(xiàng)目啟動(dòng)過(guò)程組包括兩個(gè)過(guò)程：即制定項(xiàng)目章程和制定項(xiàng)目初步范圍說(shuō)明書(shū);而項(xiàng)目規(guī)劃過(guò)程組則會(huì)綜合項(xiàng)目的成本、范圍、時(shí)間、質(zhì)量、風(fēng)險(xiǎn)、人力、溝通、采購(gòu)等因素制定項(xiàng)目計(jì)劃，該項(xiàng)目計(jì)劃將用于指導(dǎo)項(xiàng)目的實(shí)際執(zhí)行。

對(duì)任一項(xiàng)目而言，有三個(gè)文件是非常重要的。即：項(xiàng)目章程、項(xiàng)目范圍說(shuō)明書(shū)，項(xiàng)目管理計(jì)劃。這三個(gè)文件均產(chǎn)生于項(xiàng)目啟動(dòng)階段和項(xiàng)目規(guī)劃階段。其中項(xiàng)目章程被認(rèn)為是三大文件之首(項(xiàng)目章程、項(xiàng)目范圍說(shuō)明書(shū)，項(xiàng)目管理計(jì)劃)。一個(gè)項(xiàng)目，不論大小，都應(yīng)該有項(xiàng)目章程。

一個(gè)典型的項(xiàng)目章程包括如下內(nèi)容：

1)項(xiàng)目名稱及背景描述;

2)項(xiàng)目經(jīng)理任命及職責(zé)范圍界定;

3)項(xiàng)目業(yè)務(wù)需求描述;

4)項(xiàng)目發(fā)起的原因;

5)主要項(xiàng)目干系人及其初步需求;

6)產(chǎn)品及預(yù)期交付成果描述;

7)項(xiàng)目假設(shè)和約束條件。

三、零基礎(chǔ)如何學(xué)好軟件測(cè)試，不懂測(cè)試方法怎能事半功倍?

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

Black box黑盒測(cè)試：把軟件系統(tǒng)當(dāng)作一個(gè)“黑箱”，無(wú)法了解或使用系統(tǒng)的內(nèi)部結(jié)構(gòu)及知識(shí)。從軟件的行為，而不是內(nèi)部結(jié)構(gòu)出發(fā)來(lái)設(shè)計(jì)測(cè)試.

White box白盒測(cè)試：設(shè)計(jì)者可以看到軟件系統(tǒng)的內(nèi)部結(jié)構(gòu)，并且使用軟件的內(nèi)部知識(shí)來(lái)指導(dǎo)測(cè)試數(shù)據(jù)及方法的選擇。

Gray box. 灰盒測(cè)試：介于黑盒和白盒之間

總結(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è)試么？

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

Manual Test 手動(dòng)測(cè)試：測(cè)試人員用鼠標(biāo)去手動(dòng)測(cè)試 (測(cè)試GUI)

Automation 自動(dòng)化測(cè)試：用程序測(cè)試程序 (測(cè)試API)

對(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。

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

功能測(cè)試

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

Unit Test 單元測(cè)試：在最低的功能/參數(shù)上驗(yàn)證程序的準(zhǔn)確性,比如測(cè)試一個(gè)函數(shù)的正確性(開(kāi)發(fā)人員做的)

Functional Test 功能測(cè)試：驗(yàn)證模塊的功能 (測(cè)試人員做的)

Integration Test 集成測(cè)試：驗(yàn)證幾個(gè)互相有依賴關(guān)系的模塊的功能 (測(cè)試人員做的)

Scenario Test 場(chǎng)景測(cè)試：驗(yàn)證幾個(gè)模塊是否能完成一個(gè)用戶場(chǎng)景 (測(cè)試人員做的)

System Test 系統(tǒng)測(cè)試：對(duì)于整個(gè)系統(tǒng)功能的測(cè)試 (測(cè)試人員做的)

Alpha 測(cè)試：軟件測(cè)試人員在真實(shí)用戶環(huán)境中對(duì)軟件進(jìn)行全面的測(cè)試 (測(cè)試人員做的)

Beta 測(cè)試：真實(shí)的用戶在真實(shí)的用戶環(huán)境中進(jìn)行的測(cè)試, 也叫公測(cè) (最終用戶做的)

非功能測(cè)試

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

Stress test 壓力測(cè)試：驗(yàn)證軟件在超過(guò)負(fù)載設(shè)計(jì)的情況下仍能返回正確的結(jié)果，沒(méi)有崩潰

Load test 負(fù)載測(cè)試：測(cè)試軟件在負(fù)載情況下能否正常工作

Performance test性能測(cè)試：測(cè)試軟件的效能，是否提供滿意的服務(wù)質(zhì)量

Accessibility test：軟件輔助功能測(cè)試-測(cè)試軟件是否向殘疾用戶提供足夠的輔助功能

Localization/Globalization：本地化/全球化測(cè)試

Compatibility Test：兼容性測(cè)試

Configuration Test：配置測(cè)試-測(cè)試軟件在各種配置下能否正常工作

Usability Test：可用性測(cè)試 –測(cè)試軟件是否好用

Security Test：軟件安全性測(cè)試

性能測(cè)試

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

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

安全性測(cè)試

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

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

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

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

Smoke Test：“冒煙”–如果測(cè)試不通過(guò)，則不能進(jìn)行下一步工作

Build Verification Test(BVT)：驗(yàn)證構(gòu)建是否通過(guò)基本測(cè)試。

Acceptance Test：驗(yàn)收測(cè)試，為了全面考核某功能/特性而做的測(cè)試

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

5、按測(cè)試測(cè)策略分類

Regression Test 回歸測(cè)試：對(duì)一個(gè)新的版本，重新運(yùn)行以往的測(cè)試用例，看看新版本和已知的版本相比是否有退化 (regression)

Ad hoc Test 探索性測(cè)試：隨機(jī)進(jìn)行的，探索性的測(cè)試。

Santiy Test：粗略的測(cè)試， 只需要執(zhí)行部分的測(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è)試。確保現(xiàn)有的功能沒(méi)有被破壞;

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

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

總的來(lái)說(shuō)，測(cè)試不難，關(guān)鍵是你有沒(méi)有心思去認(rèn)真學(xué)習(xí)！行動(dòng)是打敗焦慮的最好方式！

總結(jié)

以上是生活随笔為你收集整理的测试功能范围_软件测试难学吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。