基于工作流的場景測試建模方法研究

張冬玲

（中山大學新華學院，廣州廣東，510663）

0 引言

軟件測試是軟件質量的重要保障，是軟件工程項目中的重要活動。現在軟件開發的主流技術是面向對象和移動互聯，大多數的軟件系統采用MVC設計架構，用事件觸發來控制程序流程已成為軟件系統的主要操作方式。基于場景的測試已經成為一種普遍使用技術。

在軟件運行中，其功能都由事件觸發控制。不同的事件觸發，同一事件的不同觸發順序，便形成不同場景[1]。根據不同的場景來設計測試用例，有利于測試用例容易被理解和執行，提高測試的有效性[2]。

1 場景測試方法

場景（Scene）是事件流的一個實例，由基本流或基本流加備選流的步驟組成。對于交互式程序，場景定義為可以獨立運行的操作活動，表明用戶執行系統的操作序列。原本，使用場景分析法是用來進行軟件需求設計的，Rational公司將場景的思想引入到軟件測試中，可以非常有效地實現對軟件的測試。

1.1 場景流的組成

基本流（Basic Flow），是經過用例的最簡單的路徑,指每個步驟都“正常”運作時所發生的事情。在一個業務中只有一個基本流。

備選流（Alternative Flow），描述可選的或備選的情況，或異常事件流程。在一個業務中可以有多個。

每個備選流都源自基本流程，或另一個備選流，且備選流程是在某個特定條件下觸發執行的。場景可以遍歷所有從用例開始到結束的包含基本流和備選流的路徑，如圖1所示。其中，用○表示測試起始結點，用●表示測試路徑的終止結點，BF為基本流，AF1、AF2、AF3、AF4分別為備選流1至備選流4。根據此圖可以構建如下8個基本的場景：

場景1：BF；

場景2：BF-AF1；

場景3：BF-AF1-AF2；

場景4：BF-AF3；

場景5：BF-AF3-AF1；

場景6：BF-AF3-AF1-AF2；場景7：BF-AF4；

場景8：BF-AF3-AF4。

圖1 場景流圖

在上面的場景4、5、6、8中，備選流3（AF3）都只考慮經過一次。從測試覆蓋的原則來看，這8個場景即可滿足測試的完備性和無冗余性要求[3]。

選取典型基本場景的原則如下：

1） 最少場景數等于基本流與備選流的總數；

2） 有且僅有一個場景僅包含基本流；

3） 對應某個備選流，至少應有一個場景覆蓋備選流，且在該場景中應盡量避免覆蓋其他的備選流。

1.2 場景測試模型

場景建模是場景測試最基本的過程，通過模擬被測軟件中所有可能存在的業務來創建場景的過程[4]。場景測試模型包含兩部分：一是測試路徑，二是測試數據[5]。

1） 測試路徑

在測試場景流圖的基礎上，從業務流的入口出發，到出口結束，遍歷所有的基礎流和備選流，生成的互相獨立的測試路徑，稱為測試路徑。

2） 測試數據

每一個測試場景包含多個測試用例，場景在測試中的重要程度確定其測試強度。測試強度越高，測試用例的數量就越多。這些測試用例構成測試數據。

基于場景的測試用例（Scene Test Case）可描述為：

STC={ScenelD，CaselD，Input，Output，NextSceneID，WaitTime，Method，ChangeEnv}

其中STC是場景測試用例，每個場景測試用例包括：ScenelD為場景編號；CaselD為測試用例編號；Input為測試場景的輸入數據或操作；Output為測試場景在輸入了Input之后的輸出結果或期望完成的功能；NextSceneID為正確執行完測試用例后下一個要執行的測試場景編號；WaitTime為測試場景在本測試用例下所能容忍的最大等待時間，單位是毫秒；Method為該測試用例所執行的方法；ChangeEnv用于說明執行該測試用例是否會改變當前的測試環境。

場景測試法不僅從功能層面，而且從業務工作流層面對系統進行動態的、全局性的測試，保證了對系統中多個功能交叉點、復雜約束邏輯以及測試覆蓋性的充分性和有效性。但是，以什么樣的粒度分析出基本流和備選流，怎樣構建出典型的場景集，以及如何運用場景來設計測試用例仍然是場景測試的難點。下面就提取基本流和備選流，構建有效測試場景進行研究。

2 場景測試建模分析

場景測試遵從W測試模型，軟件的開發與測試同步進行。即在軟件系統的需求分析之后，即可進行測試需求分析，提取場景測試的基本流和備選流。在軟件的概要設計之后，即可進行場景的構件。

2.1 測試需求（粒度）分析

對于一個復雜而龐大的系統，如果不加區分地對待每一個模塊是無法清晰地測試系統的。我們可參照軟件的設計理念，采用分而治之的辦法，首先將系統按照一定的原則分解成若干個模塊，降低其功能和結構的復雜程度，然后以模塊為單位，對其進行進一步分解。

對系統的測試模塊分解可以直接參考開發設計文檔，分解后的模塊可以單獨地被理解、測試、查錯。模塊分解的細化程度取決于其在項目中的重要性、開發的成熟度、邏輯復雜度、風險程度等因素。如果模塊的重要程度越高、成熟度越低、復雜度及風險越高，其分解就越細。

以網上在線購物系統的在線支付模塊為例。用戶進入該購物網站選定需購物品后，進行在線支付，主要的流程是：支付卡帳號登錄-支付交易-生成訂購單-完成購物。

在這個業務流中，支付卡帳號登錄是一個成熟度較高的設計部分，但考慮到其重要性和風險性都較高，因此需要細分解到登錄這一級別；支付交易涉及較多的邏輯判斷，和較高的風險性，所以也需要細分。

2.2 基本流與備選流的提取

對于每個模塊，根據其業務畫出其操作流圖。在本文中，對各類操作給出如下定義。

定義1 一個操作由一個二元組OP＜OPi[]，OPo[]＞組成，其中OP表示操作名，OPi[]是輸入變量數組，OPo[]是輸出變量數組。可以用圖2表示：

圖2 一個操作的兩種輸入輸出情形圖示表示

一個操作的圖示表示不止上述兩種表示法。還可以是一個輸入變量，多個輸出變量；多個輸入變量，一個輸出變量；多個輸入變量，多個輸出變量等情形。

定義2 如果一個操作有多個輸出變量，則這個操作存在邏輯判斷條件，是一個判斷點。

定義3 基本流是保證業務能正常執行的操作流。即只有一個輸出變量，或者多個輸出變量中使得業務正常執行下去的輸出變量，構成基本流。

定義4 備選流是業務執行過程中的一些異常執行操作流。即當操作存在多個輸出變量時，一些非正常執行的輸出變量，構成備選流。

對于上述在線支付流程中的支付卡登錄模塊，可以用圖3描述：

圖3 帳號登錄的操作流圖

在圖3的帳號輸入操作和密碼輸入操作之后都存在一個判斷點，判斷輸入的有效性和正解性。每一個判斷點都可以作為備選流的分支結點。由此可以提取出基本流與備選流，見表1中描述。

表1 帳號登錄的基本流與備選流

2.3 構建測試場景

根據本文2.1中描述的場景流的組成方法，在獲得模塊的基本流和備選流之后，可以方便地得到場景流圖。但是，本文2.2中得到的基本流和備選流只是單一考慮功能層面提取的，由此構建的測試場景不一定能完全符合用戶的需求，軟件仍存在潛在缺陷。

1）完備性補充

基于工作流的場景測試，不僅要考慮功能測試的需求，還要考慮非功能測試的需求[6]。

功能測試：對軟件需求說明書中規劃的模塊，及該模塊與其它模塊之間的約束關系進行測試。主要的測試目的是測試其功能能否正常執行。

非功能測試：根據工作流的業務標準，對其他非功能特性進行測試，檢測相關性能是否達到要求。非功能特性包括性能、可靠性、安全性、一致性和容錯等[6]。

備選流的完備性補充：將非功能測試中測試項作為備選流，添加到已有的備選流中。

在支付卡登錄模塊中，如果其需求說明書中提出對登錄響應時間、安全性檢驗及容錯性能（字母的大小寫區分）等業務標準提出要求，則改進后的帳號登錄基本流與備選流見表2所描述。

由表2的基本流和備選流分析，可以畫出場景流圖，如圖4所示。根據場景測試的一般方法，對所有備選流進行路徑遍歷，可得到46不同場景，數據相當龐大，且存在較大冗余。

2）冗余性控制

模塊的備選流間存在著一定的關系，有些是因果關系，有些是前后序關系，有些則是相互獨立關系。為減少冗余場景，需要對場景的備選流路徑進行精簡。下面以兩個備選流為例給出精簡原則：

表2 完備后的基本流與備選流

●如果備選流A和備選流B是因果關系，則場景中含有B時一定含有A；

●如果備選流A和備選流B是前后順關系時，則只須單獨包括其中的之一。即包含A，則不包含B，反之亦然；

●如果備選流A和備選流B是相互獨立關系時，則基本場景須遍歷A、B備選流。

當備選流是兩個以上者，參照上述原則執行。

圖4 帳號登錄的場景流

運用精簡原則分析支付卡登錄模塊的基本場景，備選流1，備選流2、3與備選流4、5、6之間存在前后順序關系，則基本場景流的路徑分上、中、下三部分；備選流2和備選流3的是因果關系，所以必存在場景路徑：BF-AF2-AF3；備選流4、5、6是三個獨立的備選流，則需要列出這三個備選流的任意個數的組合。精簡后的基本場景為：

場景1：BF；

場景2：BF-AF1；

場景3：BF-AF2；

場景4：BF-AF2-AF3；

場景5：BF-AF4；

場景6：BF-AF4-AF5；

場景7：BF-AF4-AF5-AF6；

場景8：BF-AF4 -AF6；

場景9：BF-AF5；

場景10：BF-AF5-AF6；

場景11：BF-AF6；

構建出基本的場景集后，就可以對每一場景設計測試用例了。

3 結語

本文在描述了場景測試的一般方法之后，提出一套關于場景建模的方法，包括基于需求說明書的模塊細分原則，基于業務工作流的基本流和備選流提取，完備的，少冗余的場景集的構建。并以網上在線購物系統的支付卡登錄模塊為案例，說明場景的建模過程。場景測試無論是用于人工測試還是自動化測試、本地測試還是云測試，都是以場景的構建為基礎。本文的研究為場景測試的實施提供了一種可行建模方案，具有較重要的理論意義和應用價值。

本文側重于場景測試的建模過程分析，對場景測試方法的實踐研究存在不足，如缺乏實例驗證數據，在生成測試用例部分也涉及不多，有待于今后進一步的深入研究，促進場景測試方法的理論和實踐的發展。

[1]潘建勇，陳邦興.基于場景的測試用例設計方法研究[J].通信技術，2011,12(44):77-80.

[2]殷永峰，劉斌，姜同敏.基于場景技術的嵌入式軟件測試用例生成方法[J].計算機工程與設計，2008,29(16):4111-4114.

[3]佟偉光，郭菲菲.軟件測試（第2版）[M].北京：人民郵電出版社，2015:61-62.

[4]Whittaker JA.What is Software Testing? And Why is it So Hard?[J].IEEE Software, 2000,17(1):70-79.

[5]馬春燕，朱怡安，陸偉.Web服務自動化測試技術[J].計算機科學，2012,39(2):162-169.

[6]吳彩華，朱小冬，劉俊濤等.基于可靠性增長模型的軟件可靠性增長測試充分性準則[J].計算機科學，2008,35(11):281-283.