技術與測試 核心 B · 官方指南或詞彙 平台: 通用

Integration Test

整合測試

整合測試會檢查系統中的兩個以上部分,能不能透過真實介面一起正常運作。

看看怎麼運作
也有人這樣說 Integration Test整合測試

看看怎麼運作

原創情境範例整合測試

另一個例子

後端測試把 API 請求送到已有範例訂單的真實測試資料庫。API 端點必須存下一筆訂單,並回傳約定欄位;如果只用假的儲存庫測一個資料轉換函式,那是單元測試。

主要部分

  1. 01參與元件
  2. 02真實介面
  3. 03跨邊界 assertion

什麼時候用

程式是否正確,取決於自家元件或基礎設施之間的真實介面時,可以使用這個詞。

什麼時候不要用

如果較小的測試已能可靠證明結果,就不要把每個特殊情況都做成較慢、成本較高的整合測試。

程式裡的名稱

component A ↔ real boundary B

上線前要檢查

檢查環境與預先準備的測試資料。定義看得到的預期結果、失敗與邊界案例。也要定義隔離方式、固定輸入、查錯資訊與清理流程。設定執行時間預算、負責人與不穩定測試的處理規則。

可以直接複製的需求

預期成果:用 整合測試 (Integration Test) 收集可重複驗證這項行為或品質風險的證據。 使用者情境:後端測試把 API 請求送到已有範例訂單的真實測試資料庫。API 端點必須存下一筆訂單,並回傳約定欄位;如果只用假的儲存庫測一個資料轉換函式,那是單元測試。 驗證方式:整合測試 (Integration Test)。 適用理由:程式是否正確,取決於自家元件或基礎設施之間的真實介面時,可以使用這個詞。 不應使用的情況:如果較小的測試已能可靠證明結果,就不要把每個特殊情況都做成較慢、成本較高的整合測試。 測試要求:說明要測的系統與環境。定義預先準備的測試資料(Fixture)、其他輸入,以及看得到的預期結果。加入預期失敗、邊界案例、容許值、隔離方式與清理流程。 測試維護:讓失敗原因容易查找,並控制隨機或會改變的輸入。指定負責人。測試速度與維護成本要符合發布前檢查的需要。 驗收條件:已知缺陷存在時測試會失敗,修正後通過。測試能在目標環境重複執行,提供可採取行動的證據,且不洩漏或改動無關資料。 證據與限制(證據邊界):它只代表該來源的官方說法。其他平台或團隊可能有不同用法。 待確認:發布前必過的檢查、環境、測試資料、容許值、執行時間預算、負責人,以及不穩定測試的處理規則。

檢查這份需求

請 AI 程式助手檢查目前如何使用 整合測試 (Integration Test)。 定義:整合測試會檢查系統中的兩個以上部分,能不能透過真實介面一起正常運作。 正式環境檢查:檢查環境與預先準備的測試資料。定義看得到的預期結果、失敗與邊界案例。也要定義隔離方式、固定輸入、查錯資訊與清理流程。設定執行時間預算、負責人與不穩定測試的處理規則。 修改程式前,先列出看到的證據、缺口、嚴重程度,以及最小且安全的修正。

B
這個術語有多正式?

官方指南或詞彙

列出的平台、框架、專案或專業組織,有發布這個術語的官方指南。

它只代表該來源的官方說法。其他平台或團隊可能有不同用法。

適用範圍
只包含來源有說明的內容:正式名稱、定義、使用指南、避免事項
文件狀態
穩定
查證日期
2026-07-30

證據來源與適用範圍

正式來源 + 術語參考資料 · International Software Testing Qualifications Board · 穩定 ISTQB Glossary 適用範圍: 正式名稱、定義、使用指南、避免事項 本頁用途: 直接術語參考 來源涵蓋內容: 正式名稱, 定義, 使用指南, 避免事項

自行複製

瀏覽器無法自動複製。請選取下方文字,再自行複製。