④根據業務流程關系場景的輸入集合確定測試用例輸入集合。

　　⑤根據業務流程關系場景的輸出集合確定測試用例輸出集合。

　　業務流程一般包含多個場景，場景之間轉移關系也較復雜，這些復雜性不利于測試用例生成。因此，在生成測試用例前，需要根據簡化原則簡化業務流程的描述與場景轉移關系。業務流程簡化原則包括：原則1：子圖分解原則。將一個業務流程分解為若干個子流程，分解前后的流程是等價的。原則2：循環活動簡化原則。對于可多次重復的活動，規定活動重復的大次數，以避免發生死循環。原則3：并發活動簡化原則。如果兩個并發活動之間相互獨立，可任選一個執行順序，以串行方式執行活動；如果并發活動在條件滿足時，必須同時執行，則將活動合并。原則4：場景簡化原則。對較大系統進行分析時，會造成一個測試場景過于龐大，因此，可劃分出系統的子場景。

　　這些簡化原則，將復雜的業務流程轉化為只包含順序關系場景的業務流程，提高了測試用例的質量。

　　1.4 測試用例執行順序的確定

　　當測試資源有，不僅要考慮測試用例是否覆蓋所有被測功能，更要制定合理測試用例執行順序，降低“測試逃逸”風險。

　　測試用例執行順序可以通過業務模型的場景優先級確定。場景優先級的獲得有靜態分析與動態調整兩種方法。靜態分析是在建立業務模型時，通過軟件失效模式和影響分析(SFMEA，softwarefailuremodeandeffectsanalysis)為場景靜態分配優先級；動態調整是在軟件測試過程中，根據軟件質量特征再次進行SFMEA分析，動態調整場景優先級。測試用例可以通過與業務流程之間的聯系，以及SMF獲得場景優先級，為確定測試用例執行順序提供有力依據。

　　2、實例應用

　　某信息采集系統在試用過程中，用戶反饋由于信息錄入員提交的信息有誤，系統中經常存在一些無效信息。為避免該問題，用戶提出增加“提交審核”業務，即信息錄入員提交的信息經管理員審核通過后，才可進入信息采集系統。該項目開發采用敏捷方法，業務模型在項目需求獲取階段已建立。為盡快響應用戶需求，軟件開發設計與測試設計同時開始，測試人員使用業務模型驅動測試活動，并貫穿整個測試過程。

　　2.1 測試計劃階段

　　2.1.1 業務規則

　　該階段主要修改內容是向信息錄入業務規則添加子規則信息審核。

　　2.1.2 場景

　　增加信息審核場景。

　　2.2 測試設計與開發階段

　　略

　　2.3 測試實施階段

　　根據場景優先級可以計算出測試用例的優先級TOP值(在關系場景中，單個場景優先級高值)與AVG值(所有關系場景的平均值)等值。

　　2.4 測試評估階段

　　在測試評審階段，根據業務模型判斷軟件測試風險，評估軟件質量。后，根據測試結果，對業務模型的場景優先級進行動態調整。例如：由于測試用例TC?F1?1通過測試，則可調低該測試用例關系場景的優先級

　　3、結束語

　　本文在對相關基本概念進行說明的基礎上，提出了基于業務模型的測試過程，并重點闡述了測試用例生成及其執行順序的確定方法。后，將研究成果應用于實際軟件系統的測試實踐，證明了本方法的有效性和正確性。在下一步研究中，將業務模型與自動化測試結合，設計一個基于業務模型的測試管理系統。隨著軟件工程的發展，軟件行業對測試越來越重視，只有不斷的探索、實踐新的軟件測試理論與方法，才能高效率完成測試任務，保證測試工作的有效性與可信性。