| 超全的測試類型詳解，再也不怕面試答不出來了！ | 當前位置： 首頁> 學習中心> 小白入門> 詳情 |
在軟件測試工作過程中或者在面試過程中經常會被問到一些看起來簡單但是總是有些回答不上的問題，比如你說說“黑盒測試和白盒測試的區別？”，“你們公司做灰度測試么？", ”α測試和β測試有什么不一樣？“，“說說 AB test 的目的什么？”...
諸如此類的一些問題，總有些同學回答不上來，今天給大家總結一下所有的測試類型以及其使用場景。
測試類型詳解
黑盒測試
軟件對于測試員來說就是一個黑色的盒子，測試不知道里面的代碼實現，只能看到對軟件的輸入和以及軟件的輸出結果。
比如你陪女朋友去逛街，你在外面等著，看著女朋友拿著你的銀行卡進去，然后看著她拎著滿滿的商品出來，你對商場里的具體情況以及錢具體如何花掉的并不知情。商場對于你來說就是一個黑色的盒子，你不需要知道里面具體情況，只需要知道你女朋友進去然后出來的結果是你的工資卡空了。
白盒測試
沿用我們上面的例子，白盒測試就相當于你陪著女朋友走進去商場里，路線和商品你看得一清二楚，其中逛得過程可能遇到的各種突發問題你也可以知道來龍去脈，雖然結果也是你的這個月工資沒了，但是心里敞亮，知道具體怎么沒的。
所以，白盒測試就是軟件對于你來說是個白色透明的盒子，里面的結構可以一清二楚的展示出來，而你也需要對里面的實現邏輯有一定了解才能進行白盒測試。
灰盒測試
基于黑白之間，不需要具體看每一行代碼，但是又需要知道具體實現的邏輯和實現。一般我們的接口測試采用的就是這種測試方法。
功能測試
就是對軟件的基本的業務流程和功能的測試，保證軟件可以實現用戶的基本需求。這是一個最基礎要保證的測試。
界面測試
也叫 UI 測試，其實就是看產品的外形好不好看？設計是否合理？排版是否清晰美觀？
那關于界面美觀的測試標準是什么呢？先問一個問題，這個界面設計是誰定的？沒錯，是產品設計出來的原型圖和 UI 設計師設計出來的 UI 切圖。所以，我們測試需要確保軟件界面跟最終的效果圖一致；其次，也可以站在用戶角度上，體驗這種界面風格，如果覺得不合適，也可以提 bug。
兼容性測試
一般分為軟件和軟件之間兼容，軟件和系統軟件之間的兼容，以及軟件不同版本之間的兼容。
比如 B/S 架構的應用，就需要考慮瀏覽器的兼容，包括瀏覽器的類型（Chrome，Firefox，IE，360，QQ 等），瀏覽器的版本之間的兼容；
比如 APP 應用需要考慮手機型號的兼容，手機系統版本的兼容，還有不同屏幕大小的兼容等；
比如 PC 端應用，需要考慮操作系統版本（win7,win10,32bit,64bit 等）；
易用性測試
主要測試軟件測試是否符合用戶使用習慣，以及是否讓用戶體驗便捷和簡單。
比如我們一般 windows 的軟件關閉按鈕都在右上方，如設計出來的軟件在左上方就是不符合用戶的使用習慣的。當然這個的易用性測試主觀性比較強，所以我們需要站在大部分用戶的角度去思考，而且也可以多收集不同用戶的反饋去做調整和修改。
性能測試
大家在生活中應該有類似的體驗，比如雙十一或者雙十二的集中某個時間付尾款的時候，就經常會出現頁面很卡或者打不開的情況，這其實就是一種性能測試的范疇里的現象。
我們在進行功能測試的時候，使用的數據和流量就是普通的流量，所以我們需要確保在極限條件下，數量多、時間長，依然正常。這就是性能測試。這個初級測試人員做的比較少，而且需要借助一些工具或者代碼來做。
安全測試
對應用軟件的安全性進行測試，比如登錄賬號的防護，連接的安全性，掃描系統存在的一些漏洞和安全隱患，這個就需要測試人員對產品有充分的了解，也需要具備豐富的基礎知識體系和各種工具、代碼的使用能力。所以，一般也是建議從事了測試行業 3 年左右之后再做安全測試。
回歸測試
回歸測試一般就是指 Bug 被修正之后，或軟件功能、環境發生變化后，以及代碼被修改或者設計重構之后，需要帶原來測試過的功能進行重新測試，確保修改部分不會影響其他的模塊。注意這個不是 bug 驗證或者修改的功能本身的測試，而且測試其余沒有被修改的功能模塊會不會受影響。
冒煙測試
這個測試概念來自于硬件測試，電路板的測試人員為了驗證一個電路板是否好用，就先給電路板通電，如果一通電就電路板就冒煙了，說明電路板被燒壞了，那么后續詳細的測試就不需要就不需要再做了，直接打回給開發重新做一個新的就好了。
這個概念引用到軟件測試里，就是針對每一個新的軟件版本，會先進行基本主要功能的覆蓋測試，確定這個軟件版本是可測的，再進行后續的詳細測試；如果版本的基本功能都不能用， 那么就直接打回開發重做就好了，不用繼續后面的正式的測試。
探索性測試/自由測試
探索性測試是沒有詳細的需求，也沒有具體的方法，更沒有測試用例作為依據，全靠測試人員的經驗和知識儲備去發散測試。
所以，這種測試對測試人員有很高的要求，需要豐富的經驗積累和自我知識沉淀，所以在公司里基本不會作為一種單獨的測試方法進行覆蓋，可以作為一種補充。
單元測試
一般是在開發階段，開發自己做完了一個小模塊，自己做的單元測試。所以單元測試需要開發人員對代碼進行測試，很多公司都是由開發人員自己進行，也是軟件測試第一個階段要做的一種的測試。
集成測試
如果說剛剛第一階段做的單元測試是針對單個單元進行的測試，那么集成測試就是進行了簡單的拼接之后的測試。測試單元之間的交互和傳輸。我們常說的接口測試就是一種集成測試。
系統測試
系統測試就是整個軟件已經完整可見了，所有的單元都組合在一起，成為一個完整的軟件了，可以看到界面并可以操作。這種測試測試測試人員首要保證的一種測試，因為這是最貼近用戶場景的一種測試。
系統測試的結束也就意味著測試人員的工作結束了。
驗收測試
驗收測試就是最后來驗證軟件是否達到最開始的需求的一種測試，所以這個測試一般不是測試做的。具體由誰來做可以分情況說：
項目如果是由甲方爸爸（客戶）驅動的，那會有客戶那邊做驗收測試，看是否滿足了他們的需求
如果不是客戶驅動的，由公司內部產品和老板自主研發的，那么驗收測試就是由產品或者老板自己做的。
不管驗收由誰來做，如果驗收沒有通過，會打回到測試部門，重新進行系統測試。
α測試
這個測試不是所有的公司有，一般是大型的公司大型項目才會有，而且是在系統測試之后，產品基本沒有什么 bug 之后做的。α測試不是測試人員自己做的，是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試。它還是在公司里內部進行，盡量模擬用戶使用的場景進行的測試。
一般開發者和測試人員可以在測試現場，可以隨時記錄下錯誤和使用中出現的問題及時修復，但是測試不由測試人員進行。
β測試
β測試也一般是較為大型項目才會有的，跟α測試的區別就是不在測試環境下測試了，而是到真實用戶使用環境下進行，或者在客戶現場做的測試。一般開發者通常不在測試現場，Beta 測試不能由程序員或測試員完成。
在軟件臨近發布的最后階段，公司會找一些合作方，把產品部署進去 beta 幾個月之后，再正式上線，避免嚴重問題。或者直接發布一個 bata 版本召集用戶進行公測，讓用戶幫忙發現問題。
灰度測試
系統測試通過后，將測試版本發布到線上環境，替換部分的線上服務器進行預測試。在灰度測試結束后，如果沒有問題，線上版本實現會統一。所以灰度測試，本質上是上線前的測試，收集用戶的反饋。
AB 測試
AB 測試跟灰度測試差不多，也是指的是系統測試通過并發布后，同一個軟件功能針對不同的用戶進行分組：A 組用戶和 B 組用戶，不同組的用戶會看到不同的實現方式，目的也是收集每個用戶對新版本的反饋。如果沒有問題，再實現統一。
動態測試
測試對象在運行的測試，比如微信在使用，就是一種動態測試。我們做的大部分的軟件測試都是動態測試。
靜態測試
程序沒有在運行，比如代碼走查，或者軟件文檔測試，就都是靜態測試。
手工測試
就是測試人員手動的點點點測試。
自動化測試
使用工具或者代碼的方式替換手工測試，釋放人力的一種測試方法。
更多軟件測試相關推薦：
作者：羅斯托夫 文章來源：51testing測試圈 版權歸原作者所有
上文內容不用于商業目的，如涉及知識產權問題，請權利人聯系博為峰小編(021-64471599-8103)，我們將立即處理
滬公網安備 31010102002527號
