封亮　吳振宇

軟件系統(tǒng)測試是保障軟件質(zhì)量、降低維護(hù)成本、改善研發(fā)過程的重要工作環(huán)節(jié)。然而面對結(jié)構(gòu)體系龐大、邏輯功能繁復(fù)的應(yīng)用軟件系統(tǒng)，其輸入空間、執(zhí)行順序、運(yùn)行依賴因素間的邏輯組合幾乎趨于無限，工程技術(shù)人員如何保證測試工作的充分性與有效性？國家工程軟件產(chǎn)品質(zhì)量監(jiān)督檢驗(yàn)中心通過總結(jié)大型任務(wù)電子系統(tǒng)軟件測試實(shí)施經(jīng)驗(yàn)，提出了“利用UML順序圖構(gòu)建業(yè)務(wù)流程運(yùn)行場景及基于場景建模進(jìn)行軟件系統(tǒng)測試”，其實(shí)現(xiàn)途徑或?qū)閺V大工程技術(shù)人員所借鑒。

軟件系統(tǒng)測試現(xiàn)狀

作為現(xiàn)代信息系統(tǒng)的核心，軟件的作用日益突出。為了令軟件產(chǎn)品功能更完善、架構(gòu)更健壯、性能更可靠，系統(tǒng)測試工作貫穿于軟件生命周期的每個階段。軟件研發(fā)過程中，工程人員需要開展各種不同類型的測試，包括單元測試、部件測試、配置項(xiàng)測試、系統(tǒng)聯(lián)試和系統(tǒng)測試等。

系統(tǒng)聯(lián)試是由軟件研制單位組織的系統(tǒng)連通性驗(yàn)證試驗(yàn)，重點(diǎn)關(guān)注系統(tǒng)主要功能的正確性，而受軟件研制人員自身思維定勢所限，測試粒度、完備性都不夠理想。

配置項(xiàng)測試是對組成系統(tǒng)的各個軟件配置項(xiàng)進(jìn)行測試，重點(diǎn)考查軟件功能實(shí)現(xiàn)的正確性和完備性，能夠較好地發(fā)現(xiàn)軟件中存在的問題，但受制于配置項(xiàng)測試的環(huán)境因素，往往不能如實(shí)反應(yīng)外部相關(guān)軟件的實(shí)際影響，難以驗(yàn)證系統(tǒng)主要業(yè)務(wù)流程的正確性和協(xié)調(diào)性。

面對上述問題，進(jìn)行軟件系統(tǒng)測試就顯得尤為重要。系統(tǒng)測試是軟件測試工作的重要環(huán)節(jié)，目的是在實(shí)裝環(huán)境（包含真實(shí)的人、機(jī)、數(shù)據(jù)環(huán)境）或接近實(shí)裝的環(huán)境中，考查系統(tǒng)各業(yè)務(wù)流程執(zhí)行的正確性和協(xié)調(diào)性，從而驗(yàn)證系統(tǒng)軟件是否達(dá)到研制總要求，以及系統(tǒng)和子系統(tǒng)段設(shè)計(jì)文檔中所列出的全部功能和指標(biāo)需求。

目前，復(fù)雜任務(wù)電子信息系統(tǒng)多為龐大的系統(tǒng)工程，硬件結(jié)構(gòu)繁復(fù)，軟件架構(gòu)龐大，且由眾多不同領(lǐng)域的企業(yè)協(xié)同開發(fā)……這為系統(tǒng)的軟件測試工作帶來了諸多困難：多單位協(xié)同開發(fā)，測評環(huán)境往往分布于多地，且側(cè)重點(diǎn)不同；系統(tǒng)規(guī)模龐大，系統(tǒng)內(nèi)外部接口復(fù)雜，測試人員需要理解整個被測系統(tǒng)，作為測試依據(jù)的被測系統(tǒng)設(shè)計(jì)/輸入類文檔的質(zhì)量及詳細(xì)程度影響著整個系統(tǒng)測試質(zhì)量。面對上述情況，探尋有效的系統(tǒng)級測試實(shí)施策略與技術(shù)方法顯得尤為重要。

軟件系統(tǒng)測試技術(shù)研究

若干實(shí)踐經(jīng)驗(yàn)表明，有效的軟件系統(tǒng)測試必須包括選取確定的測試范圍、系統(tǒng)場景建模、測試內(nèi)容策劃等關(guān)鍵環(huán)節(jié)。

大型任務(wù)電子系統(tǒng)的內(nèi)外部接口關(guān)系復(fù)雜，由不同專業(yè)的分系統(tǒng)構(gòu)成，按照嚴(yán)格的科研管理流程，通常由研制企業(yè)內(nèi)部進(jìn)行軟件單元/部件測試，配置項(xiàng)測試以及出廠（所）測試，由經(jīng)國家授權(quán)的軟件測評機(jī)構(gòu)執(zhí)行第三方配置型測試、分系統(tǒng)測試以及系統(tǒng)測試。其中分系統(tǒng)軟件測試工作將重點(diǎn)關(guān)注構(gòu)成分系統(tǒng)的軟件配置項(xiàng)的功能、內(nèi)外部接口、性能等要求的實(shí)現(xiàn)情況，并能給出分系統(tǒng)的測試結(jié)果。考慮到系統(tǒng)的規(guī)模、復(fù)雜度以及分系統(tǒng)測試工作的實(shí)際情況，在啟動系統(tǒng)測試時，需對系統(tǒng)功能進(jìn)行篩選，選取出需要進(jìn)行系統(tǒng)級測試的系統(tǒng)功能。因此必須確立相應(yīng)的篩選原則，以保證系統(tǒng)測試的有效性與邏輯覆蓋的完備性，在工作中總結(jié)出以下原則：涉及分系統(tǒng)之間交互的功能點(diǎn)需被選取，而在分系統(tǒng)內(nèi)部閉環(huán)的功能點(diǎn)不被選?。辉跍y評環(huán)境滿足的前提下，選取覆蓋最大閉環(huán)路徑長度的業(yè)務(wù)流程進(jìn)行系統(tǒng)功能驗(yàn)證。

隨著UML在軟件開發(fā)過程中的廣泛運(yùn)用，基于UML 的測試技術(shù)逐漸受到人們的關(guān)注。UML順序圖是一種常用的UML動態(tài)建模模型，可以建模系統(tǒng)的使用邏輯（或稱為應(yīng)用場景），具有直觀、半形式化等特點(diǎn)，包含豐富的、體現(xiàn)設(shè)計(jì)架構(gòu)的系統(tǒng)信息。適用于描述對象之間的動態(tài)交互關(guān)系，顯示一個協(xié)作涉及對象的消息傳遞關(guān)系，它著重體現(xiàn)對象間消息傳遞的時間順序。

UML的順序圖有兩個維度：縱向是時間線，定義對象在交互活動中的生命周期；橫向是不同的對象。順序圖中用一個帶有垂直虛線的矩形框表示對象，矩形框內(nèi)標(biāo)有類名、對象名或角色名。垂直虛線稱為生命線，代表在對象之間的交互作用中該對象的生命周期。對象間的通信消息通過對象生命線之間的箭頭表示，箭頭上方標(biāo)注消息名和一些控制信息。接收對象收到消息時被激活，在對象生命線上顯示一個細(xì)長矩形框來表示，激活描述在一定時間段內(nèi)對象執(zhí)行操作的持續(xù)時間。

在場景建模階段，通過分析系統(tǒng)研制總要求、系統(tǒng)/子系統(tǒng)段設(shè)計(jì)文檔等測試依據(jù)類技術(shù)文檔，以及與軟件研發(fā)人員和系統(tǒng)使用人員進(jìn)行交流溝通，獲取被測任務(wù)電子系統(tǒng)的主要業(yè)務(wù)流程。根據(jù)提取的業(yè)務(wù)流程，利用UML順序圖進(jìn)行場景建模，不僅能夠清晰地展現(xiàn)系統(tǒng)業(yè)務(wù)流程中的動態(tài)交互關(guān)系，還有助于測試項(xiàng)的確定以及潛在業(yè)務(wù)流程的發(fā)掘。

根據(jù)系統(tǒng)典型應(yīng)用場景對各系統(tǒng)的綜合應(yīng)用工作流程進(jìn)行測試。各應(yīng)用場景用例主要用來驗(yàn)證各分系統(tǒng)間的協(xié)調(diào)性和正確性。系統(tǒng)級應(yīng)用場景是指至少涉及兩個分系統(tǒng)之間的集成工作流程。任務(wù)電子系統(tǒng)測試時基于分系統(tǒng)間的交互關(guān)系進(jìn)行系統(tǒng)應(yīng)用場景分析，首先建立獲取頂層的系統(tǒng)應(yīng)用場景，再逐層細(xì)化分析出各分系統(tǒng)之間的集成工作流程，如任務(wù)執(zhí)行場景等。

清晰完整、合理可行的測試項(xiàng)集合是測試項(xiàng)目順利開展的必要條件，進(jìn)行場景建模的目的正是為了提取系統(tǒng)測試的測試項(xiàng)。業(yè)務(wù)流程場景圖的建立能夠清晰地展示業(yè)務(wù)流程相關(guān)的測試項(xiàng)，方便了測試項(xiàng)的確定。

然而測試項(xiàng)的劃定必須考慮測評環(huán)境的制約——環(huán)境因素可能會影響業(yè)務(wù)流程執(zhí)行的暢通性，還必須對環(huán)境帶來的差異進(jìn)行有效地分析確認(rèn)，使其能夠充分支持業(yè)務(wù)流程的驗(yàn)證。

在確定測試范圍的基礎(chǔ)上，依托場景圖和實(shí)際環(huán)境因素，給出測試項(xiàng)相關(guān)的測試類型并明確各種測試類型的測試方法、測試輸入/輸出數(shù)據(jù)以及測試通過判斷準(zhǔn)則等信息，從而完成在特定場景下對相應(yīng)系統(tǒng)功能的測試內(nèi)容策劃，并填寫相關(guān)信息。

測試項(xiàng)的建立過程中需要積極和軟件研制人員與系統(tǒng)分析使用人員溝通交流，確保測試項(xiàng)內(nèi)容的正確性、完整性。測試項(xiàng)的完整性體現(xiàn)了對頂層需求（包括隱含需求）覆蓋的完整程度，同時能夠反映測試的充分性。為了及時掌握測試項(xiàng)完整性情況，可建立需求追溯矩陣來反映當(dāng)前測試項(xiàng)對頂層需求的覆蓋情況。

軟件系統(tǒng)測試用例開發(fā)設(shè)計(jì)輔助環(huán)境

根據(jù)UML順序圖應(yīng)用場景建模執(zhí)行軟件系統(tǒng)測試，可以實(shí)現(xiàn)軟件系統(tǒng)測試用例開發(fā)設(shè)計(jì)環(huán)境，其中內(nèi)嵌了符合UML 2.0規(guī)范的建模組件，能夠針對軟件系統(tǒng)應(yīng)用場景進(jìn)行建模，然后基于模型，結(jié)合軟件配置項(xiàng)測試、子系統(tǒng)測試階段設(shè)計(jì)的測試用例，生成軟件系統(tǒng)測試應(yīng)用場景的測試用例集，滿足軟件系統(tǒng)、分系統(tǒng)、子系統(tǒng)的測試需求。

軟件系統(tǒng)測試用例開發(fā)設(shè)計(jì)環(huán)境使用UML描述應(yīng)用場景模型，并基于該場景模型生成對應(yīng)的測試用例集合。系統(tǒng)測試人員可根據(jù)自動生成的測試用例集合進(jìn)行修改或優(yōu)化，得到最終測試用例集。

軟件系統(tǒng)測試用例開發(fā)設(shè)計(jì)環(huán)境由場景順序圖建模、測試用例生成兩個子系統(tǒng)，由圖形用戶界面、模型生成、模型解析、場景樹生成、用例生成等模塊共同組成。

進(jìn)行系統(tǒng)測試場景模型建模時，使用符合UML 2.0規(guī)范的順序圖描述系統(tǒng)級的事件交互及事件的順序，對系統(tǒng)的參與者（用戶、子系統(tǒng)或配置項(xiàng)）、參與者之間傳遞的數(shù)據(jù)或調(diào)用命令等系統(tǒng)組成要素進(jìn)行建模。在順序圖中，須測試的應(yīng)用場景被定義為在相互交互過程中的各對象間傳遞的一個消息序列，每個消息序列代表一個可能的事件流，在一個順序圖中通過分支和循環(huán)結(jié)構(gòu)可實(shí)現(xiàn)多個場景的定義。

對于每一個測試場景，建立各對象（用戶輸入、子系統(tǒng)或配置項(xiàng)）的測試用例，其輸入和輸出參數(shù)化，定義各對象測試用例的執(zhí)行流程順序；按照執(zhí)行流程順序，關(guān)聯(lián)各測試用例的輸入.輸出參數(shù)；測試場景的測試用例實(shí)例化按照覆蓋正常值和邊界值的原則，對測試場景的測試用例進(jìn)行實(shí)例化腳本生成。

基于UML2.0的被測系統(tǒng)應(yīng)用場景建模主要基于順序圖完成給定的典型應(yīng)用場景的建模，其建模過程可按照系統(tǒng)、子系統(tǒng)分層建立，建模后形成基于元數(shù)據(jù)交換格式XMI（XML Metadata Interchange Format）模型文件。

解析由XML表示的UML順序圖，提取相關(guān)信息建立場景測試樹；對于要進(jìn)行測試的具體場景，記錄該場景的條件約束、各對象狀態(tài)等模型中的語義信息?；陧樞驁D的用例生成技術(shù)使用這些信息生成測試用例所需數(shù)據(jù)，并與場景結(jié)合生成實(shí)際的測試用例，場景實(shí)例化主要基于XML解釋程序解析由XMI表示的UML順序圖或狀態(tài)圖，主要對IF、While等進(jìn)行處理，生成無分子轉(zhuǎn)移的順序流程，形成場景測試樹，其葉節(jié)點(diǎn)可為子系統(tǒng)或配置項(xiàng)。

系統(tǒng)測試用例生成過程讀入UML 2.0實(shí)例化場景模型文件解析后的信息、對于每一個被測應(yīng)用系統(tǒng)測試場景，按照分層原則，完成測試用例的開發(fā)、設(shè)計(jì)，必要時，建立相應(yīng)的測試控制腳本。包括輸入和輸出參數(shù)化，定義各配置項(xiàng)測試用例的執(zhí)行流程順序；按照執(zhí)行流程順序，關(guān)聯(lián)各測試用例的輸入輸出參數(shù)；測試場景的測試用例實(shí)例化按照覆蓋正常值和邊界值的原則。

軟件系統(tǒng)測試用例開發(fā)設(shè)計(jì)環(huán)境的運(yùn)行過程分為“場景建?！迸c“測試用例生成與優(yōu)化”兩個主要階段。

軟件系統(tǒng)測試用例開發(fā)設(shè)計(jì)環(huán)境場景建模工具提供圖形用戶界面，包括符合UML2.0規(guī)范的建模界面和模型元素，對任務(wù)電子信息系統(tǒng)、分布式應(yīng)用系統(tǒng)的典型應(yīng)用場景進(jìn)行UML順序圖建模，根據(jù)典型應(yīng)用場景建模生成的順序圖保存為可解析的模型文件（XML格式）。

測試用例生成包含模型解析、場景樹生成與用例生成三個主要過程?！澳Ｐ徒馕觥碧崛鼍绊樞驁D的模型文件，將其轉(zhuǎn)換為XML格式的中間文件，獲取該場景的參與者、消息及相關(guān)約束等信息；“場景樹生成”，根據(jù)模型解析生成的XML文件生成測試場景樹數(shù)據(jù)文件；“用例生成”根據(jù)生成的測試場景樹文件生成測試用例集，并進(jìn)行優(yōu)化，最終產(chǎn)生該場景的最小測試用例集，以XML格式存儲到本地文件系統(tǒng)。

算法實(shí)現(xiàn)的基本過程包括：查找順序圖中的基本流，基本流即無警戒條件的消息。將找出的基本流序號按次序放入容器m_BaseFlow中，另外對于那些有警戒條件的消息，根據(jù)他們的值，將這些消息分組，有相同警戒條件值的消息劃分在同一組，有些警戒條件是由若干個其他警戒條件用連接符AND，OR和NOT組合而成，那么還要記錄這些警戒條件是由哪些其他警戒條件共同組成。

找出順序圖中所有的場景結(jié)束點(diǎn)，將所有的結(jié)束點(diǎn)的序號按次序存放在m_EndPoint容器中，所謂順序圖的場景結(jié)束點(diǎn)就是被標(biāo)注了<>的消息。

根據(jù)警戒條件進(jìn)行排列組合運(yùn)算，得到相應(yīng)的場景序列。查找生成的場景序列中是否有多個結(jié)束點(diǎn)，如果有多個結(jié)束點(diǎn)，這個場景就不正確，將在場景容器m_SceneVec中刪除。最后，去除重復(fù)的場景序列以及含有子場景的場景序列。

綜上所述，針對復(fù)雜電子信息系統(tǒng)軟件系統(tǒng)測試的實(shí)施過程，基于場景建模的系統(tǒng)測試技術(shù)方法給出了基本實(shí)現(xiàn)方法和軟件實(shí)現(xiàn)實(shí)例，目前已在多個大型系統(tǒng)測試項(xiàng)目開展過程中運(yùn)用，在保證系統(tǒng)測試完備性、提高工作效率方面，可以取得很好的效果。