資料結構
網路
關係資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法律研究整合測試（型別、自頂向下和自底向上）
什麼是整合測試？
整合測試是一種軟體測試，其中軟體模組在概念上連線在一起並作為一個單元進行測試。一個典型的軟體專案由多個軟體模組組成，這些模組由多個程式設計師編寫。此級別測試的目標是查詢各種軟體元件在組合在一起時互動方式中的缺陷。
整合測試關注確保資料在各個單元之間進行通訊。因此，它也被稱為“I&T”（整合和測試），“字串測試”和“執行緒測試”。
什麼是整合測試以及它是如何工作的？
整合測試的目的是什麼？
整合測試用例示例
整合測試方法、策略和方法
大爆炸方法
逐步方法
存根和驅動程式有什麼區別？
自底向上整合
自頂向下整合
三明治/混合整合
什麼是整合測試以及它是如何工作的？
整合測試計劃：快速概述
整合測試入口和出口標準
整合測試最佳實踐/指南
整合測試的目的
儘管每個軟體模組都進行了單元測試，但由於各種原因，故障仍然會發生，例如 -
通常，模組由單個軟體開發人員建立，其程式設計邏輯和理解可能與其他程式設計師不同。需要進行整合測試以確保軟體部分能夠協同工作。
客戶的需求很有可能在模組開發過程中發生變化。這些額外需求可能不會進行單元測試，因此需要進行系統整合測試。
軟體模組與資料庫的介面可能不正確。
如果存在，外部硬體介面可能不正確。
不合格的異常處理可能會導致問題。
整合測試用例示例
整合測試用例與其他測試用例的不同之處在於，它主要關注元件之間的介面和資料/資訊流。應優先考慮整合連結而不是已經過測試的單元功能。
對於以下情況，以下是一些整合測試用例示例：應用程式包含三個模組：“登入頁面”、“郵箱”和“刪除郵件”，每個模組在邏輯上都已整合。
登入頁面測試已在單元測試下完成，因此此處無需花費太多時間。但是，請檢視它如何連線到郵箱頁面。
同樣，檢查郵箱與刪除郵件模組的連線。
| 測試用例 ID | 測試用例目標 | 測試用例描述 | 預期結果 |
|---|---|---|---|
| 1 | 驗證登入和郵箱模組之間是否存在介面關係。 | 輸入登入憑據後，單擊登入按鈕。 | 將被定向到郵箱。 |
| 2 | 驗證郵箱和刪除郵件模組之間的介面關係是否完好無損。 | 從郵箱中選擇電子郵件並將其刪除。 | 已刪除/垃圾資料夾應包含選定的電子郵件。 |
整合測試方法和方法
軟體工程提供了多種執行整合測試的策略，包括 -
大爆炸方法
增量方法
三明治方法 - 自頂向下和自底向上的組合
下面列出了各種策略、如何實施以及它們的侷限性和優勢。
大爆炸實驗
大爆炸測試是一種整合測試技術，其中所有元件或模組都同時組合在一起，然後作為單個實體進行測試。在測試過程中，此整合元件集合被視為單個物件。除非單元中的所有元件都已完成，否則整合過程將不會執行。
優點
它非常適合小型系統。
缺點
很難查明故障的確切位置。
鑑於此方法中必須檢查的大量介面，可能會忽略某些必須評估的介面。
由於整合測試只能在“所有”模組都定義後才能開始，因此測試團隊在測試階段執行測試的時間會減少。
由於所有模組都是同時評估的，因此不會分離和首先檢查高風險關鍵模組。處理使用者介面的外圍模組不會被分離或優先考慮進行測試。
增量測試
增量評估技術包括合併兩個或多個在邏輯上相互關聯的模組，然後測試應用程式的功能是否正確。然後逐步整合其他連線的模組，並重復此過程，直到所有邏輯上連線的模組都已成功整合和測試。
增量方法使用兩種替代方法實施 -
自底向上
自頂向下
驅動程式和存根
存根和驅動程式是整合測試中使用的虛擬程式，用於簡化軟體測試過程。這些程式充當測試中缺少的模型的替身。它們沒有實現軟體模組的所有程式設計邏輯，但它們確實在測試期間模擬與呼叫模組的資料傳輸。
存根 - 此方法由被測模組呼叫。
驅動程式 - 這是呼叫將要測試的模組的程式。
自底向上完整性檢查
自底向上整合測試的策略是首先測試最低級別的元件。然後使用經過測試的模組來幫助測試更高級別的模組。重複此過程，直到所有頂級模組都已測試。當較低級別的模組經過測試和合並後，將生成下一級別的模組。
優點
更容易找到故障。
與大爆炸策略不同，不會浪費時間等待所有模組構建。
缺點
影響程式流程的關鍵模組（在軟體架構的頂層）最後進行測試，並且更有可能存在錯誤。
無法建立早期原型。
自頂向下整合測試
自頂向下整合測試是一種從軟體系統控制流的頂部到底部進行整合測試的方法。為了確保軟體功能，首先測試更高級別的模組，然後測試和整合更低級別的模組。如果某些模組未準備好，則使用存根對其進行測試。
優點
更容易找到故障。
可以儘早獲得原型。
關鍵模組首先進行測試；可以首先發現和糾正嚴重的設計缺陷。
缺點
需要許多存根。
較低級別的模組沒有經過徹底測試。
三明治測試
三明治測試是一種方法，其中頂級模組與較低階模組一起進行測試，而較低階元件與頂級模組一起組合並作為系統進行評估。混合整合測試是一種混合技術，結合了自頂向下和自底向上的方法。此專案中使用了存根和驅動程式。
整合測試方法
無論軟體測試方法（如上所述）如何，整合測試方法如下 -
制定整合測試計劃。
建立測試場景、用例和指令碼。
在執行測試用例後，報告缺陷。
缺陷跟蹤和重新測試
步驟 3 和 4 會重複執行，直到整合成功完成。
整合測試計劃：快速概述
它具有以下特徵 -
測試方法/方法（如上所述）。
範圍和排除整合測試專案
職責和角色
整合測試有幾個先決條件。
測試環境。
風險和緩解計劃。
整合測試入口和出口標準
在任何軟體開發方法中，整合測試階段都存在入口和出口標準。
入口標準
已進行單元測試的元件/模組
所有高優先順序錯誤都已解決並關閉。
所有模組都必須編碼並正確整合。
整合計劃、測試用例和方案的測試都必須獲得批准並記錄在案。
整合測試需要建立測試環境。
出口標準
已成功測試整合應用程式。
已完成的測試用例已記錄在案。
在提交技術文件和發行說明之前，必須修復並關閉所有高優先順序缺陷。
整合測試最佳實踐/指南
首先確定可以使用哪種整合測試策略，然後建立相應的測試用例和資料。
檢查應用程式的架構並確定關鍵模組。必須儘快對其進行測試。
獲取架構團隊的介面設計並編寫測試用例以徹底檢查所有介面。必須徹底測試資料庫介面以及任何外部硬體或軟體應用程式。
在測試用例之後，測試資料是最重要的因素。
在執行之前，始終準備好模擬資料。在執行測試用例期間，請勿選擇測試資料。
整合測試挑戰
我們已經廣泛介紹了整合測試的工作原理及其帶來的好處。好處，一如既往，也伴隨著一些缺點。由於一些問題，整合測試可能比您想象的更困難。以下是一些類似場景的示例 -
當太多人參與程式碼開發過程，每個人都有自己的風格時，很難理解單元的邏輯。
各種元素（資料庫、平臺、環境等）可能會使測試變得複雜。
整合兩個遺留系統，以及將新系統整合到現有系統中，很少一帆風順。
如果多個團隊構建不同的系統進行整合，它們可能不相容。
由於多種方法和測試組合，選擇最有效的模型可能具有挑戰性。
結論
整合測試是測試層次結構的第二層。在單元測試之後，它為 QA 團隊創造了一個更具挑戰性的職責：確定不同的單元如何協同工作以及它們是否能夠工作。
整合測試可以儘早發現缺陷，降低錯誤成本並加快產品交付速度。如果您忽略此步驟，則可能會忽略一個嚴重的問題，這將降低使用者體驗或迫使您推遲釋出日期。
2K+ 閱讀量
