程序員，軟件測試知多少？

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

做爲開發同窗，一些基本的測試崗位相關知識仍是頗有必要了解一下，免的某些同窗在工做中和測試同窗鬥嘴、打架、羣毆等以及被測試鄙視....。

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

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

黑盒測試是行爲測試，即從軟件的行爲而不是內部結構觸發來設計測試，也就是在軟件上處處點點等。白盒指的是在設計測試的過程當中，設計者能夠「看到」軟件系統的內部結構，並使用軟件的內部結構和知識來選擇測試數據及具體的測試方法。

功能測試和非功能測試

按測試的目，分爲功能測試和非功能測試，單元測試是功能測試裏的一種，每種測試的名稱和內容以下：

一個軟件除了基本功能以外，還有不少功能以外的特性，這些叫非功能需求，或者服務質量需求。然而，若沒有軟件的基本功能，這些特性都將無從表現出來，所以，咱們要在軟件開發的適當階段——基本功能完成後再來作這些非功能測試，非功能測試有以下這些

其餘分類下的測試

在開發軟件的過程當中，很多測試起着「烽火臺」的做用，它們告訴咱們軟件開發的流程是否順暢，好比冒煙測試是指測試不經過不能進行下一步工做，是一種基本驗證測試，聽說是從硬件設計行業流傳過來的說法。當年設計電路板的時候，不少狀況下，新的電路板一插上電源就冒起白煙，燒壞了。若是插上電源後沒有冒煙，那就是經過了「冒煙測試」，能夠進一步測試電路板的功能了。還有驗證構建是否經過基本測試以及全面考覈某方面的功能的驗收測試。

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

單元測試

對於開發來說，最最經常使用和熟悉的仍是單元測試，怎樣纔算一個好的單元測試？單元測試應該準確、快速地保證程序基本模塊的正確性。下面是驗證單元測試好壞的一系列標準：

• 單元測試應該在最基本的功能/參數上驗證程序的正確性。

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

• 單元測試事後，機器狀態保持不變。若是單元測試建立了臨時的文件或目錄，應該在Teardown(拆卸)階段刪掉。若是單元測試在數據庫中建立或修改了記錄，那麼也許要刪除或恢復這些記錄，或者每個單元測試使用一個新的數據庫，這樣能夠保證單元測試不受之前單元測試實例的干擾。

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

• 單元測試應該產生可重複、一致的結果。

• 獨立性—單元測試的運行/經過/失敗不依賴於別的測試，能夠人爲構造數據，以保持單元測試的獨立性。

• 單元測試應該覆蓋全部代碼路徑。

• 單元測試應該集成到自動化測試的框架中。

• 單元測試必須和產品代碼一塊兒保存和維護。

然並卵！都說國內不少程序員是不寫單元測試的，甚至歷來都不寫，筆者當年作Java的時候也沒寫過幾回（捂臉）。

迴歸測試

在單元測試的基礎上，咱們就可以創建關於這一模塊的迴歸測試（Regression Test）。Regress：return to a worse or less developed state，是倒退、退化、退步的意思。在軟件項目中，若是一個模塊或功能之前是正常工做的，可是在一個新的構建中出了問題，那麼這個模塊就出現了一個「退步」（Regression），從正常工做的狀態退化到不正常工做的狀態。在一個模塊的功能逐步完成的同時，與此功能有關的測試用例也一樣在完善中。一旦有關的測試用例經過，咱們就獲得了此模塊的功能基準線（Baseline），一個模塊的全部單元測試就是這個模塊最初的Baseline。

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

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

2. 同時要驗證新的代碼有沒有破壞模塊的現有功能，有沒有Regression

對於「迴歸測試」中的「迴歸」，咱們能夠將其理解爲「迴歸到之前不正常的狀態」。迴歸測試最好要自動化，由於這樣就能夠對於每個構建快速運行全部迴歸測試，以保證儘早發現問題。單元測試是迴歸測試的基礎。在專一於模塊基本功能的單元測試以外，還有功能測試——從用戶的角度檢查功能完成得怎麼樣。

探索性測試

探索性測試是爲了某一個特定目的而進行的測試，且就這一次，之後通常也不會重複測試。在軟件工程的實踐中，「Ad hoc」大可能是指隨機進行的、探索性的測試。

探索式測試的測試流程是不可重複的，由於它的測試都是「特定」測試，無法重複。這一緣由，使得探索式測試不能自動化，就這一點而言，還達不到CMMI二級——可重複級。

做爲管理人員來講，若是太多的小強是在探索式測試中找出來的，那咱們就要看看測試計劃是否基於實際的場景，開發人員的代碼邏輯是否完善，等等。

場景/集成/系統測試

在軟件開發的必定階段，咱們要對一個軟件進行全面和系統的測試，以保證軟件的各個模塊都能共同工做，各方面均能知足用戶的要求。這類測試叫系統/集成測試。這一方法的核心思想是：當用戶使用一個軟件時，他/她並不會獨立使用各個模塊，而是把軟件做爲一個總體來使用。咱們在作場景測試的時候，就須要考慮在現實環境中用戶使用軟件的流程是怎樣的，而後模擬這個流程，看看軟件能不能知足用戶的需求。這樣，才能使軟件符合用戶的實際需求。

應該何時作集成測試呢？是否是越早越好？原則上是當一個模塊穩定的時候，就能夠把它集成到系統中，和整個系統一塊兒進行測試。在模塊自己穩定以前就提前作集成測試，可能會報告出不少Bug，可是這些因爲提前測試而發現的Bug，有點像汽車司機在等待綠燈時不耐煩而拼命地按喇叭——也就是說，有點像噪音。咱們仍是要等到適當的時機再開始進行集成測試。

瞭解完這些概念後，咱們來看看究竟一個測試工程師的職責是怎麼樣的呢，下面列舉一些：

• 制定測試計劃

• 設計與編寫測試用例

• 實施測試

• BUG跟蹤

• 測試報告與總結

• 其餘測試工程活動

不少測試工做並非說，有了測試工程師，把測試相關的所有事情扔給他們就完事了，須要開發和測試配合，共同完成某些測試任務，軟件測試也不只僅是爲了發現bug而後提給開發，測試=質量保障，提高質量相關的都是測試工程師須要關注和負責的，軟件測試的目標是幫助項目打造用戶喜歡的產品。

文章首發於個人微信公衆號，關注可得到每次最新推送

---

《構建之法》讀書筆記之二