根據您的外觀，您會得到略有不同的答案。我已經讀了很多關于這個主題的內容，這是我的精華; 再次，這些是略微愚蠢的，其他人可能不同意。

單元測試

測試最小的功能單元，通常是方法/函數（例如，給定具有特定狀態(tài)的類，在類上調用x方法應該導致y發(fā)生）。單元測試應該集中在一個特定的功能上（例如，當堆棧為空時調用pop方法應該拋出InvalidOperationException）。它觸及的一切都應該在記憶中完成; 這意味著測試代碼和被測代碼不應該：

• 呼喚（非平凡）合作者

• 訪問網絡

• 點擊數據庫

• 使用文件系統(tǒng)

• 旋轉一個線程

• 等等

任何緩慢/難以理解/初始化/操作的依賴都應該使用適當的技術進行存根/模擬/處理，這樣您就可以專注于代碼單元正在做什么，而不是它的依賴關系。

簡而言之，單元測試盡可能簡單，易于調試，可靠（由于外部因素減少），執(zhí)行速度快，有助于證明程序中最小的構建塊在組合之前按預期運行。需要注意的是，雖然你可以證明它們完全孤立地工作，但代碼單元在組合時可能會爆炸，這使我們...

集成測試

集成測試建立在單元測試的基礎上，通過組合代碼單元并測試生成的組合正確運行。這可以是一個系統(tǒng)的內部結構，也可以將多個系統(tǒng)組合在一起以做一些有用的事情。此外，將集成測試與單元測試區(qū)分開來的另一個因素是環(huán)境。集成測試可以并將使用線程，訪問數據庫或執(zhí)行所需的任何操作，以確保所有代碼和不同的環(huán)境更改都能正常工作。

如果您已經構建了一些序列化代碼并且單元測試了它的內部而沒有觸及磁盤，那么當您加載并保存到磁盤時，您怎么知道它可以工作？也許你忘了刷新和處理文件流。也許你的文件權限不正確，你已經在內存流中測試了內部。唯一可以確定的方法是使用最接近生產的環(huán)境來測試它“真實”。

主要的優(yōu)點是，他們會發(fā)現(xiàn)單元測試無法發(fā)現(xiàn)的錯誤，例如布線錯誤（例如A類的實例意外收到B的空實例）和環(huán)境錯誤（它在我的單CPU機器上運行正常，但是我的同事的4核心機無法通過測試）。主要缺點是集成測試會觸及更多代碼，可靠性降低，故障難以診斷且測試難以維護。

此外，集成測試不一定證明完整的功能有效。用戶可能不關心我的程序的內部細節(jié)，但我這樣做！

功能測試

功能測試通過將給定輸入的結果與規(guī)范進行比較來檢查特定功能的正確性。功能測試不涉及中間結果或副作用，只是結果（他們不關心在執(zhí)行x之后，對象y具有狀態(tài)z）。它們被編寫為測試規(guī)范的一部分，例如“調用函數Square（x），參數為2，返回4”。

驗收測試

驗收測試似乎分為兩種類型：

標準驗收測試涉及在整個系統(tǒng)上執(zhí)行測試（例如，通過Web瀏覽器使用您的網頁），以查看應用程序的功能是否滿足規(guī)范。例如，“單擊縮放圖標應將文檔視圖放大25％?！?nbsp;沒有真正的連續(xù)結果，只有通過或失敗的結果。

優(yōu)點是測試用簡單的英語描述，并確保整個軟件功能完整。缺點是你已經在測試金字塔上移動了另一個級別。驗收測試觸及大量代碼，因此追蹤故障可能會非常棘手。

此外，在敏捷軟件開發(fā)中，用戶驗收測試涉及創(chuàng)建測試以鏡像在開發(fā)期間由軟件客戶創(chuàng)建的用戶故事。如果測試通過，則意味著軟件應滿足客戶的要求，并且可以認為故事是完整的。驗收測試套件基本上是以域特定語言編寫的可執(zhí)行規(guī)范，該語言描述了系統(tǒng)用戶使用的語言中的測試。

結論

他們都是互補的。有時，關注一種類型或完全避開它們是有利的。對我來說，主要的區(qū)別在于，一些測試從程序員的角度來看待事物，而其他測試則以客戶/最終用戶為中心。