集成測試非常重要。[4] 對于傳統軟件的集成測試，可以根據設計階段形成的功能分解樹，采用自頂向下或自底向上逐步測試用經過測試的單元組裝成系統的過程中有無錯誤。[3]而面向對象軟件采用的是通過組合實現系統的功能，沒有一個功能分解樹可用，所以傳統的基于功能分解的集成測試策略不適合面向對象軟件。要檢驗最終實現中各種集成是否與設計的集成一致，則需要對每一個集成層次進行測試，而這里的集成分為結構集成和行為集成，所以面向對象軟件的集成測試包含結構集成測試和行為集成測試。結構集成測試主要測試類的繼承、類的容器、類的接口、組件的接口中有無錯誤；行為集成測試主要是類內方法交互、類間方法交互、組件間交互是否被錯誤地實現。測試工作的核心主要是生成測試用例，在面向對象軟件開發過程中系統的規約、設計、代碼是生成測試的信息來源，是軟件在其生命周期不同階段的變體，當然規約、設計、代碼在每一階段的測試中都起相應的作用，特別地，系統規約是生成系統測試的測試用例的基礎和系統測試的檢驗依據，軟件代碼是生成單元測試用例的基礎和單元測試的檢驗依據，系統設計是生成集成測試用例和集成測試的檢驗依據。系統的設計信息有助于理解系統功能和結構，設計模型包含規約和程序結構的信息，同時也描述了系統的相應功能片斷的行為，因此也被稱為灰盒�？梢越Y合白盒測試和黑盒測試方法，從設計信息生成集成測試用例，測試設計模型表示的軟件系統的灰盒行為。 UML是面向對象系統分析、設計的標準的建模語言，自從在1997年成為建模語言事實上的標準后，就得到學術界的推崇和工業界的支持，使得UML廣為使用，基于UML的方法和實用技術的研究成為將來的發展趨勢。UML對面向對象軟件開發全生命周期的支持也使得軟件開發人員優先用它來描述系統。[8]正像集許多優點的面向對象技術不能免除軟件測試一樣，使用UML進行面向對象軟件開發，在提高軟件質量的同時，仍然需要測試來確認軟件分析、設計、實現的一致性和正確性。同時基于UML開發的軟件系統，軟件開發的分析、設計階段工作成果多為各種模型圖，系統的可用信息都在這些模型圖中，給信息的提取帶來了新的問題，從而也給測試帶來新的課題。對測試而言，原先的基于規約或者是基于程序的方法都不能直接使用，對基于UML模型的測試，要將問題轉換到原來傳統測試方法可以處理的問題空間中加以解決，轉換工作主要解決信息提取問題，然后用常規測試方法生成測試。面向對象的軟件中，對象通過交互來實現行為，UML的交互圖[6,7]是描述一組對象間的結構關系和交互行為設計的最佳選擇，主要有順序圖和協作圖兩種，順序圖關注全局的時序，協作圖關注協作對象之間的關系，本文主要研究協作圖。UML協作圖描述了系統的一個協作中參與對象之間如何交互，集成測試正是要驗證這些對象是否正確交互，所以我們研究基于UML協作圖的集成測試用例生成方法。本文中我們使用UML協作圖作為系統功能片斷的高級描述，用來作為生成測試的基礎，使得在系統設計階段一開始就可以計劃集成測試階段的測試。在軟件開發早期準備軟件測試，在軟件的系統分析、設計階段,利用每一階段的人工制品(artifact)生成軟件測試各個階段所需的測試用例，在代碼階段結束后便可以開始測試工作，而且對分析設計模型進行分析的同時也能發現分析、設計本身的缺陷，以便及時排除，以防缺陷隨著軟件開發過程的進展而被放大。由于UML在工業界的使用越來越普遍，而相應支持在分析設計階段基于模型生成測試用例的實用方法和支持工具還不多見。我們希望能夠研究出僅從UML分析、設計模型圖自動生成測試用例的方法，而且不需要使用者的除UML外其他方面專業的知識，能夠實現自動化而不增加用戶額外的工作量，這樣的測試方法容易被已經使用UML的工業界采用。[8,10] 本文研究如何通過面向對象軟件設計階段的UML協作圖選擇合適的集成測試用例的方法，第2部分對協作圖的語法和語義作了詳細的介紹，并回顧了測試模型、協作集成測試模式、協作故障模型等知識；第3部分對基于協作圖生成測試用例的方法作了總體介紹，詳細描述了從協作圖生成測試用例的具體算法和支撐工具框架原型，第4部分是相關工作的介紹，最后是結束語和將來工作的構想。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
