軟體測試這些你知道嗎？

我們常常聽說的一些測試專業術語，比如白盒、黑盒、單元測試，筆者在前幾年對測試也僅僅停留在這個兩個詞彙上，更多的就不得而知了。後來在一家做跨境電商的公司學到了一些新術語，也見到了測試崗位的一些日常，比如冒煙測試、測試用例(TC)、迴歸測試、介面測試以及偶爾和我吵架等等。

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

黑盒測試是行為測試，即從軟體的行為而不是內部結構觸發來設計測試，也就是在軟體上到處點點等。白盒指的是在設計測試的過程中，設計者可以“看到”軟體系統的內部結構，並使用軟體的內部結構和知識來選擇測試資料及具體的測試方法。

功能測試和非功能測試

---

按測試的目，分為功能測試和非功能測試，單元測試是功能測試裡的一種，每種測試的名稱和內容如下：

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

其他分類下的測試

---

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

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

單元測試

---

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

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

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

單元測試過後，機器狀態保持不變。如果單元測試建立了臨時的檔案或目錄，應該在Teardown(拆卸)階段刪掉。如果單元測試在資料庫中建立或修改了記錄，那麼也許要刪除或恢復這些記錄，或者每一個單元測試使用一個新的資料庫，這樣可以保證單元測試不受以前單元測試例項的干擾。

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

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

獨立性—單元測試的執行/透過/失敗不依賴於別的測試，可以人為構造資料，以保持單元測試的獨立性。

單元測試應該覆蓋所有程式碼路徑。

單元測試應該整合到自動化測試的框架中。

單元測試必須和產品程式碼一起儲存和維護。

然並卵！都說國內很多程式設計師是不寫單元測試的，甚至從來都不寫，筆者當年做Java的時候也沒寫過幾次（捂臉）。

迴歸測試

---

在單元測試的基礎上，我們就能夠建立關於這一模組的迴歸測試（Regression Test）。Regress：return to a worse or less developed state，是倒退、退化、退步的意思。在軟體專案中，如果一個模組或功能以前是正常工作的，但是在一個新的構建中出了問題，那麼這個模組就出現了一個“退步”（Regression），從正常工作的狀態退化到不正常工作的狀態。在一個模組的功能逐步完成的同時，與此功能有關的測試用例也同樣在完善中。一旦有關的測試用例透過，我們就得到了此模組的功能基準線（Baseline），一個模組的所有單元測試就是這個模組最初的Baseline。

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

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

同時要驗證新的程式碼有沒有破壞模組的現有功能，有沒有Regression

對於“迴歸測試”中的“迴歸”，我們可以將其理解為“迴歸到以前不正常的狀態”。迴歸測試最好要自動化，因為這樣就可以對於每一個構建快速執行所有迴歸測試，以保證儘早發現問題。單元測試是迴歸測試的基礎。在專注於模組基本功能的單元測試之外，還有功能測試——從使用者的角度檢查功能完成得怎麼樣。

探索性測試

---

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

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

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

場景/整合/系統測試

---

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

應該什麼時候做整合測試呢？是不是越早越好？原則上是當一個模組穩定的時候，就可以把它整合到系統中，和整個系統一起進行測試。在模組本身穩定之前就提早做整合測試，可能會報告出很多Bug，但是這些由於提早測試而發現的Bug，有點像汽車司機在等待綠燈時不耐煩而拼命地按喇叭——也就是說，有點像噪音。我們還是要等到適當的時機再開始進行整合測試。

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

制定測試計劃

設計與編寫測試用例

實施測試

BUG跟蹤

測試報告與總結

其他測試工程活動

很多測試工作並不是說，有了測試工程師，把測試相關的全部事情扔給他們就完事了，需要開發和測試配合，共同完成某些測試任務，軟體測試也不僅僅是為了發現bug然後提給開發，測試=質量保障，提升質量相關的都是測試工程師需要關注和負責的，軟體測試的目標是幫助專案打造使用者喜歡的產品。

總結

如何一起學習，有沒有免費資料？

   為了讓學習變得輕鬆、高效，今天給大家免費分享一套資深測試大牛雲層傳授的一套教學資源。幫助大家在升職加薪的道路上披荊斬棘。這套影片詳細講解了（測試基礎，介面測試進階，自動化測試，效能測試）等這些測試必備的內容！ 

前300名進群可以免費領取測試整合學習影片一份

測試分享交流群： 903217991

測試基礎，網路爬蟲，自動化測試，介面測試，效能測試，TestOps等這些測試必備的內容已全部錄製好。