送給初級程序員的測試認知文

作為開發(fā)同學，一些基本的測試崗位相關(guān)知識還是很有必要了解一下，免的某些同學在工作中和測試同學斗嘴、打架、群毆等以及被測試鄙視....。

我們常常聽說的一些測試專業(yè)術(shù)語，比如白盒、黑盒、單元測試，相信搞作為程序員的你脫口而出的就是這三個詞匯吧，筆者在前幾年對測試也僅僅停留在這個兩個詞匯上，更多的就不得而知了。后來在一家做跨境電商的公司學到了一些新術(shù)語，也見到了測試崗位的一些日常，比如冒煙測試、測試用例(TC)、回歸測試、接口測試以及偶爾和我吵架等等。

白盒黑盒測試是按測試設(shè)計方法分類的，是指軟件測試設(shè)計的方法，而不是軟件測試的方法，注意這個區(qū)別。

黑盒測試是行為測試，即從軟件的行為而不是內(nèi)部結(jié)構(gòu)觸發(fā)來設(shè)計測試，也就是在軟件上到處點點等。白盒指的是在設(shè)計測試的過程中，設(shè)計者可以“看到”軟件系統(tǒng)的內(nèi)部結(jié)構(gòu)，并使用軟件的內(nèi)部結(jié)構(gòu)和知識來選擇測試數(shù)據(jù)及具體的測試方法。

功能測試和非功能測試

按測試的目，分為功能測試和非功能測試，單元測試是功能測試里的一種，每種測試的名稱和內(nèi)容如下：

一個軟件除了基本功能之外，還有很多功能之外的特性，這些叫非功能需求，或者服務(wù)質(zhì)量需求。然而，若沒有軟件的基本功能，這些特性都將無從表現(xiàn)出來，因此，我們要在軟件開發(fā)的適當階段——基本功能完成后再來做這些非功能測試，非功能測試有如下這些

其他分類下的測試

在開發(fā)軟件的過程中，不少測試起著“烽火臺”的作用，它們告訴我們軟件開發(fā)的流程是否順暢，比如冒煙測試是指測試不通過不能進行下一步工作，是一種基本驗證測試，據(jù)說是從硬件設(shè)計行業(yè)流傳過來的說法。當年設(shè)計電路板的時候，很多情況下，新的電路板一插上電源就冒起白煙，燒壞了。如果插上電源后沒有冒煙，那就是通過了“冒煙測試”，可以進一步測試電路板的功能了。還有驗證構(gòu)建是否通過基本測試以及全面考核某方面的功能的驗收測試。

另一些測試名稱則是說明不同的測試方法

單元測試

對于開發(fā)來講，最最常用和熟悉的還是單元測試，怎樣才算一個好的單元測試？單元測試應(yīng)該準確、快速地保證程序基本模塊的正確性。下面是驗證單元測試好壞的一系列標準：

• 單元測試應(yīng)該在最基本的功能/參數(shù)上驗證程序的正確性。

• 單元測試必須由最熟悉代碼的人（程序的作者）來寫。

• 單元測試過后，機器狀態(tài)保持不變。如果單元測試創(chuàng)建了臨時的文件或目錄，應(yīng)該在Teardown(拆卸)階段刪掉。如果單元測試在數(shù)據(jù)庫中創(chuàng)建或修改了記錄，那么也許要刪除或恢復這些記錄，或者每一個單元測試使用一個新的數(shù)據(jù)庫，這樣可以保證單元測試不受以前單元測試實例的干擾。

• 單元測試要快（一個測試的運行時間是幾秒鐘，而不是幾分鐘）。

• 單元測試應(yīng)該產(chǎn)生可重復、一致的結(jié)果。

• 獨立性—單元測試的運行/通過/失敗不依賴于別的測試，可以人為構(gòu)造數(shù)據(jù)，以保持單元測試的獨立性。

• 單元測試應(yīng)該覆蓋所有代碼路徑。

• 單元測試應(yīng)該集成到自動化測試的框架中。

• 單元測試必須和產(chǎn)品代碼一起保存和維護。

然并卵！都說國內(nèi)很多程序員是不寫單元測試的，甚至從來都不寫，筆者當年做Java的時候也沒寫過幾次（捂臉）。

回歸測試

在單元測試的基礎(chǔ)上，我們就能夠建立關(guān)于這一模塊的回歸測試（Regression Test）。Regress：return to a worse or less developed state，是倒退、退化、退步的意思。在軟件項目中，如果一個模塊或功能以前是正常工作的，但是在一個新的構(gòu)建中出了問題，那么這個模塊就出現(xiàn)了一個“退步”（Regression），從正常工作的狀態(tài)退化到不正常工作的狀態(tài)。在一個模塊的功能逐步完成的同時，與此功能有關(guān)的測試用例也同樣在完善中。一旦有關(guān)的測試用例通過，我們就得到了此模塊的功能基準線（Baseline），一個模塊的所有單元測試就是這個模塊最初的Baseline。

針對一個Bug Fix，我們也要做Regression(海退) Test。目的是：

驗證新的代碼的卻改正了缺陷。

同時要驗證新的代碼有沒有破壞模塊的現(xiàn)有功能，有沒有Regression

對于“回歸測試”中的“回歸”，我們可以將其理解為“回歸到以前不正常的狀態(tài)”。回歸測試最好要自動化，因為這樣就可以對于每一個構(gòu)建快速運行所有回歸測試，以保證盡早發(fā)現(xiàn)問題。單元測試是回歸測試的基礎(chǔ)。在專注于模塊基本功能的單元測試之外，還有功能測試——從用戶的角度檢查功能完成得怎么樣。

探索性測試

探索性測試是為了某一個特定目的而進行的測試，且就這一次，以后一般也不會重復測試。在軟件工程的實踐中，“Ad hoc”大多是指隨機進行的、探索性的測試。

探索式測試的測試流程是不可重復的，因為它的測試都是“特定”測試，沒法重復。這一原因，使得探索式測試不能自動化，就這一點而言，還達不到CMMI二級——可重復級。

作為管理人員來說，如果太多的小強是在探索式測試中找出來的，那我們就要看看測試計劃是否基于實際的場景，開發(fā)人員的代碼邏輯是否完善，等等。

場景/集成/系統(tǒng)測試

在軟件開發(fā)的一定階段，我們要對一個軟件進行全面和系統(tǒng)的測試，以保證軟件的各個模塊都能共同工作，各方面均能滿足用戶的要求。這類測試叫系統(tǒng)/集成測試。這一方法的核心思想是：當用戶使用一個軟件時，他/她并不會獨立使用各個模塊，而是把軟件作為一個整體來使用。我們在做場景測試的時候，就需要考慮在現(xiàn)實環(huán)境中用戶使用軟件的流程是怎樣的，然后模擬這個流程，看看軟件能不能滿足用戶的需求。這樣，才能使軟件符合用戶的實際需求。

應(yīng)該什么時候做集成測試呢？是不是越早越好？原則上是當一個模塊穩(wěn)定的時候，就可以把它集成到系統(tǒng)中，和整個系統(tǒng)一起進行測試。在模塊本身穩(wěn)定之前就提早做集成測試，可能會報告出很多Bug，但是這些由于提早測試而發(fā)現(xiàn)的Bug，有點像汽車司機在等待綠燈時不耐煩而拼命地按喇叭——也就是說，有點像噪音。我們還是要等到適當?shù)臅r機再開始進行集成測試。

了解完這些概念后，我們來看看究竟一個測試工程師的職責是怎么樣的呢，下面列舉一些：

• 制定測試計劃

• 設(shè)計與編寫測試用例

• 實施測試

• BUG跟蹤

• 測試報告與總結(jié)

• 其他測試工程活動

很多測試工作并不是說，有了測試工程師，把測試相關(guān)的全部事情扔給他們就完事了，需要開發(fā)和測試配合，共同完成某些測試任務(wù)，軟件測試也不僅僅是為了發(fā)現(xiàn)bug然后提給開發(fā)，測試=質(zhì)量保障，提升質(zhì)量相關(guān)的都是測試工程師需要關(guān)注和負責的，軟件測試的目標是幫助項目打造用戶喜歡的產(chǎn)品。

文章首發(fā)于我的微信公眾號，關(guān)注可獲得每次最新推送

---

《構(gòu)建之法》讀書筆記之二

總結(jié)

以上是生活随笔為你收集整理的程序员，软件测试知多少？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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