軟體測試技術體系->專業術語
https://zhuanlan.zhihu.com/p/41490482
​
已認證的官方帳號

專案型軟體：

專案型軟體是指本軟體是針對專門的客戶進行定製開發，軟體需求由客戶（甲方）指定和確認，軟體版權和原始碼，文件等歸甲方所有，只針對甲方收費，軟體的研發和驗收只為甲方負責。比如蝸牛創想為成都樂圈科技，雅安無線電管理中心等企業客戶定製開發的軟體均稱為專案型軟體。專案型軟體有明確的研發週期，客戶驗收通過並付費後即表明本專案結束，所以專案的研發風險相對較低，當然，另外一方面其利潤空間也相對不高。

產品型軟體：

產品型軟體是指本軟體是針對大眾需求進行研發，軟體需求通常最開始由研發團隊或運營團隊根據市場可能的需求進行構思和設計，客戶群體也是由市場團隊或研發團隊進行市場定位後確定。產品在沒有正式上市運營之前無法收費，產品上市後繼續根據使用者的反饋進行產品改進和優化。產品可以選擇收費或免費策略。目前我們看到的手機APP，遊戲，QQ，微信，防毒軟體，辦公軟體，作業系統等等各類可下載的軟體產品均屬於產品型軟體。產品型軟體沒有明確的週期可言，只要市場有需求，可以無限制地一直改進下去。比如我們看到的Windows作業系統，QQ或微信，美圖秀秀之類的軟體產品，並沒有固定的週期，一直在更新和完善功能，以保持產品的使用者數和市場競爭力。

單元測試 (Unit-Testing)：

軟體測試的早期階段，主要專注於程式碼邏輯的實現，測試物件為單獨的API（方法），其測試目標為保證每一個程式碼單元被正確實現，測試用例設計的目標是覆蓋儘可能多的程式碼路徑，通常採用路徑覆蓋法來判斷測試程式碼的執行效果。

整合測試 (Integration-Testing)：

軟體測試的中期階段，主要專注於API與API之間（比如A呼叫B，B呼叫C），或者模組與模組之間(比如登入模組與操作模組，操作模組與許可權模組)，甚至子系統與子系統之間的介面（比如淘寶網與支付寶，淘寶網與物流跟蹤系統）。測試目的是確保程式碼單元進行整合後相互之間可以協同工作，典型的應用場景還包括Web前端頁面與伺服器後臺頁面之間的整合等。

系統測試 (System-Testing)：

軟體測試的晚期階段，主要專注於整個系統進行整合後的整體功能，從一個軟體系統層面進行整體測試分析，設計與執行。系統測試階段結束後並且對發現的BUG已經修復完成，則軟體產品基本可以準備交付或釋出。

驗收測試 (Acceptance-Testing)：

軟體測試的交付階段，當專案型軟體完成系統測試後，便可以交付給客戶進行軟體的驗收。通常驗收測試由客戶方完成，客戶根據明確的需求文件對軟體的功能，效能，安全，相容，可靠，可用待方面進行一一確認。有問題則繼續改進問題，再進行驗收，如果驗收通過，則本專案宣告結束。

Alpha測試：

Alpha測試也簡寫為α測試，也被稱之為“內測”，是專門針對產品型軟體的一種測試手段，通常研發團隊或邀請部分優質客戶來到研發現場對軟體進行測試，發現問題及時討論解決。所以它是一種可控的測試手段，而且有固定的測試方法和套路。

Beta測試：

Beta測試也簡寫為β測試，也被稱之為“公測”，是專門針對產品型軟體的一種測試手段，通常我們會將已經開發完成的軟體交付給使用者使用，使用者不必在研發現場，而是正常使用該軟體，發現問題後向研發團隊反饋，對產品進行改進。所以它是一種不可控的測試手段，我們無法明確知道使用者會怎麼使用軟體產品，所以有些軟體會跟蹤記錄使用者行為，用以改進產品。β測試的產品不能向用戶收費。

Gamma測試：

Gamma測試也叫γ測試，通常是產品型軟體正式上市釋出前的最後一輪測試，之所以叫γ測試，是取Release Candidate的R作為標記，即候選釋出版本。這個時候的測試通常由整個軟體產品研發團隊包括專案經理，需求分析師，測試人員，開發人員等所有人在內進行探索性測試，不依賴於測試用例和文件，也不太多關注需求，而是把全體成員扮演成使用者的角色來進行測試。

白盒測試：

白盒測試是一種測試方法，主要關注程式碼邏輯，直接對程式碼部分進行測試，可以測試程式碼塊，或某一個獨立的API，或者是某個模組均可。通常我們在單元測試階段會更多地使用白盒測試方法。

灰盒測試：

是一種測試方法，主要關注介面之間的呼叫，通常在整合測試階段會更多地使用灰盒測試方法。灰盒測試方法不關心程式碼的具體實現和程式碼邏輯，所以它不是純粹的白盒測試，同時它也不關注介面的實現，所以它也不是純粹的黑盒測試。它關注的是介面，我們利用程式碼來呼叫介面而不是利用介面操作來呼叫。從測試的角度來看可以這樣理解：灰盒測試是利用白盒測試的方法進行的黑盒測試，也可以說成是利用黑盒測試方法進行的白盒測試，可以偏白一些，也可以偏黑一些。我們只關注介面傳入的引數型別和返回值，所有黑盒測試的用例設計方法均適用。同時我們是繞開了介面的操作，而直接寫程式碼來呼叫介面。這就是灰盒測試。

黑盒測試：

理解了白盒測試和灰盒測試，黑盒測試的理解相對容易。不關注程式碼，也不關注介面，而是關注介面。像一個普通使用者一樣來使用和測試軟體。只關注功能的實現，關注使用者使用場景，關注需求，關注使用體驗。

基於協議的測試：

基於程式碼的測試通常稱之為白盒測試，基於介面的測試通常稱之為灰盒測試，基於介面的測試通常稱之為黑盒測試，而基於協議的測試其實也是一種偏黑的介面測試。對於網路應用系統來說，前端和後端之間的通訊一定需要通過協議完成，所以我們可以繞開前端的介面而直接向後端傳送協議資料包來完成相應的操作和介面呼叫，從而達到測試的目的。後續專案中我們將花費大量時間來完成基於協議的測試，比如功能性測試，安全性測試和效能測試等，都將基於協議來完成。

靜態測試：

不啟動被測物件的測試，比如程式碼走讀，程式碼評審，文件評審，需求評審等測試工作被稱為靜態測試。

動態測試：

啟動被測試物件的測試，比如白盒測試，灰盒測試，黑盒測試等，都需要將被測物件啟動和呼叫才能達到測試的目的。

手工測試（Manual-Testing）：

指不依賴於程式碼，而是完全依賴於人的操作來進行的測試。我們知道測試的重點和難點在於測試的分析和設計，而通常所說的手工測試是指測試的執行。通常用於黑盒測試方法或系統測試階段。

自動化測試（Automation-Testing）：

指利用測試指令碼來驅動被測物件完成的測試，我們的工作重點在於開發測試指令碼，需要具備較強的程式設計能力。

注：基於程式碼或基於介面的測試天然的就是自動化測試。而基於黑盒測試的方法可以手工完成，也可以自動化完成，後面的專案中使用Selenium來完成的基於介面的測試便是黑盒測試自動化。

冒煙測試（Smoke-Testing）：

冒煙測試的物件是每一個新編譯的需要正式測試的軟體版本，目的是確認軟體基本功能正常，可以進行後續的正式測試工作。

隨機測試（Ad-hoc-Testing）

隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。 隨機測試主要是對被測軟體的一些重要功能進行復測，也包括測試那些當前的測試用例(TestCase)沒有覆蓋到的部分。另外，對於軟體更新和新增加的功能要重點測試。

迴歸測試(Regression-Testing)

迴歸測試是指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。自動迴歸測試將大幅降低系統測試、維護升級等階段的成本。迴歸測試的策略有兩種，一種是完全迴歸，一種是部分迴歸。

注：希望學習更多技術，繼續在IT行業突破提升自己的各位朋友，歡迎加群594154674，不管你自我感覺牛不牛B

釋出於 2018-08-07