談談集成測試（integration testing）

　　對於軟件開發來講，軟件測試是一個幾乎貫穿全部階段的活動，因此測試的重要性毋庸置疑。不一樣開發組織如何在不一樣的產品研發階段進行測試，也在很大程度上反映了其研發能力和質量控制能力。軟件測試有不少類型，包括單元測試，集成測試，壓力測試... 其中，集成測試的投入產出比相對最高，由於它覆蓋的基本上都是最經常使用的用例（用戶影響權重高）。根據維基百科的定義，集成測試(integration testing)是將若干的軟件模塊組合起來，測試某項特定功能。不一樣於單元測試只孤立的測試軟件模塊，集成測試更關注不一樣軟件模塊之間的交互。冒煙測試能夠被認爲是最小化的集成測試。因此從廣義角度來講，幾乎全部開發組織都會作不一樣規模的集成測試。

　　集成測試策略基本分爲4種：大爆炸測試（big-bang），自頂而下測試(Top-down)，自底而上測試(Bottom-up)，三明治測試。大爆炸測試就是把大部分軟件模塊在同一時間組合在一塊兒進行測試。很明顯，這種測試策略整體上來講是很是低效的，也違背迭代式開發的基本原則。問題會在同一時間大量爆發，而且由於每一個模塊均可能存在嚴重問題，問題定位也將很是艱難，從而使項目進度和質量都不可控制。所以，大爆炸測試是最糟糕的測試策略。自頂而下測試(Top-down）是先測試最低層模塊，而後向上逐級測試更高級的模塊。自底而上測試(Bottom-up)則與之相反。三明治測試是把自頂而下測試(Top-down)和自底而上測試(Bottom-up)結合在一塊兒的測試策略。在四種策略中，三明治測試應該最優先被採用，由於它兼具高效性和可控性，使得開發並行性成爲可能。

　　集成測試的測試用例（test case）必須基於用例(use case)進行開發。一個用例對應一個或多個集成測試用例。（用例屬於需求分析的範疇，不在本文討論之列，可參閱相關資料）。覆蓋用例的主要路徑（happy path）固然是測試用例的最基本要求。對用例的異常路徑（exceptions）的覆蓋程度，則是提升軟件質量的重要因子。所以，提升測試用例覆蓋度的首要前提，是提升用例的完備度。在現實中，一些開發組織不作正式的需求分析，有些即便作需求分析可是不對用例進行文檔化，形成的結果是集成測試甚至不能保證覆蓋全部的主要路徑。不一樣於單元測試可運行於宿主開發機或模擬器系統（針對嵌入式開發），集成測試必須運行於真實的目標系統，由於集成測試屬於功能測試。集成測試通常基於API級別，介於白盒測試和黑盒測試之間。除了基於用例的路徑覆蓋，也應採起等價類測試和邊界測試等功能測試方法，以提升測試覆蓋度。

　　系統集成測試（System integration testing）是集成測試一個特例，是將被測系統（包括全部的硬件和軟件）做爲一個總體來進行測試，所以屬於徹底的黑盒測試。測試用例代碼能夠不運行於待測系統中，而運行於另外的測試系統中。測試系統經過被測系統提供的接口（好比硬件引腳、通訊信道，軟件接口等），根據用戶需求或者被測系統規格書，對被測系統進行測試。同通常的集成測試相似，若是能根據用戶需求和系統規格書產生完整的用例文檔，將極大的方便建立系統集成測試的測試用例。

　　雖然某些系統集成測試也能夠手動進行，可是集成測試應儘量的自動化。測試用例須要週期性的運行，相比於手動測試，自動化測試可極大的縮短測試時間和減小人力成本。同時，測試用例代碼應同功能代碼一塊兒統一管理和維護。也就是說，測試用例代碼應達到或接近功能代碼的質量要求。不然若是測試用例代碼自己的問題反而會託慢開發進程，甚至應不被信任被拋棄。

　　綜上所述，集成測試對於任何軟件開發組織都是必選項，所以對於集成測試的任何改善都能極大的幫助質量控制水平。需求分析和用例文檔是集成測試的重要前提，應重視測試用例的代碼質量。開發組織可根據其特色，選擇合適自身的集成測試策略。