關於測試組合應為金字塔形或蜂巢形，有許多爭論。我對此爭論的第二大問題是，由於人們對於單元測試和整合測試之間的差異看法不明確，因此這個爭論變得不透明。

廣泛堆疊測試是一種測試，會執行大型應用程式的大部分元件。它通常稱為端對端測試或全堆疊測試。它與元件測試相反，元件測試只會執行系統中定義良好的部分。

商業面向測試是一種測試，旨在用於協助與開發團隊中非程式設計人員（例如客戶、使用者、商業分析師等）溝通。當自動化時，它們會以領域導向的術語描述系統，並忽略系統本身的元件架構。商業面向測試通常用作驗收標準，通過這些測試表示系統提供了客戶預期的功能。

元件測試是一種測試，它將受測軟體的範圍限制在受測系統的一部分。它與廣泛堆疊測試相反，廣泛堆疊測試旨在執行系統中合理的部分。

使用 TestDouble 最常見的情況之一是當您與外部服務進行通訊時。通常此類服務由不同的團隊維護，它們可能會受到網路速度慢且不可靠的影響，而且本身可能也不可靠。這就是測試替身很方便的原因，它可以防止您自己的測試變得緩慢且不可靠。但針對替身進行測試時，總會產生一個問題，即替身是否確實準確代表外部服務，以及如果外部服務變更其合約會發生什麼事？

整合測試會判斷獨立開發的軟體單元在彼此連接時是否能正確運作。這個術語已變得模糊，即使以軟體產業的模糊標準來看也是如此，因此我在寫作時一直很小心避免使用它。特別是，許多人假設整合測試的範圍一定很廣，但其實範圍較窄時反而能更有效地執行。

故事測試是 BusinessFacingTests，用於描述和驗證作為 UserStory 一部分提供的軟體。當故事經過詳細說明後，團隊會建立多個故事測試，作為故事的驗收準則。故事測試可以結合到軟體的回歸套件中，並提供從需求（使用者故事）到測試，以及（透過執行）到系統行為的可追溯性。故事測試通常是 BroadStackTests。

我使用皮下測試來表示在應用程式使用者介面下方運作的測試。在執行應用程式的功能測試時，這特別有價值：當您想要測試端對端行為，但很難透過使用者介面本身進行測試時。

閾值測試是插入到 DeploymentPipeline 中的測試，它會透過將目前建置中的值與閾值進行比較，來監控某些可測量的現象。如果目前建置中的值通過閾值，測試就會失敗，導致建置失敗。

在軟體開發中，單元測試經常被提及，而且在我撰寫程式碼的這段時間裡，這是一個我熟悉的術語。然而，就像大多數軟體開發術語一樣，它定義得很差，而且我看到人們常常會在認為它的定義比實際上更嚴謹時感到困惑。

使用者歷程測試是一種 BusinessFacingTest，旨在模擬典型使用者在系統中的「歷程」。此類測試通常會涵蓋使用者與系統的完整互動，以達成某個目標。它們作為使用案例中的其中一條路徑。