測試用例復用在電子采購交易平臺中的應用

楊 軍 盧彩霞 黃 辰 王 婷

（北京中電普華信息技術有限公司 北京 100085）

1 引言

本文主要介紹在用戶軟件需求說明和系統設計說明書的基礎上對測試需求的提取，以及由此引申出測試用例的生成，并且描述了測試需求和測試用例在電子采購交易平臺系統中的分析過程。闡述了測試用例復用的設計原則及過程，并且將其應用在電子采購交易平臺的過程，最終達到改善軟件測試環境，提高軟件測試效率的目的。

2 軟件測試中的測試用例

2.1 測試需求

在介紹測試用例定義之前，我們先介紹一下軟件測試需求的概念，軟件測試需求是對軟件產品測試范圍的定義，表明測試軟件產品是要測什么。軟件測試需求必須是可觀測、可測評的行為。目的是希望通過從原始需求（原始需求可以是用戶需求說明書或是系統設計說明書）提煉出測試的要點，再針對每一個測試要點編寫對應的測試用例。

軟件測試需求定義就是編寫一組需求分類、歸檔依據、需求描述、測試要點、重要性、測試需求狀態的組合，實現從原始需求到測試要點的提煉過程。

我們可以把測試需求表示為一個八元組合

Test Requirements=｛Tq_ID，Qd，Qc，Ab，Oq，Tp，Imp，Qs｝

分別表示：｛需求標識，需求名稱，需求分類，歸檔依據，原始需求，測試要點、重要性、需求狀態｝；

1）需求標識Tq_ID：作為測試需求的唯一ID；

2）需求名稱Qd：簡要表述需求的某項特性；

3）需求分類Qc：分為流程類、功能類和其他；

4）歸檔依據Ab：與項目區域的類別相關，即所屬模塊；

5）原始需求Oq：對原始需求的描述；

6）測試要點Tp：根據原始需求提煉出的測試點；

7）重要性Imp：分為核心、重要、一般和可選四種，表示測試需求對最終用戶的相對重要程度。通過與業務/系統分析人員/開發團隊成員相互交換意見，最終確定測試需求的重要性；

8）需求狀態Qs：新增、變更、刪除；新增代表本次版本新增的測試需求，變更代表本次版本原始需求發生變更導致測試需求發生變更的，刪除代表本次版本原始需求發生變更不在本次測試范圍內的，只是設置一個標志位，實際未刪除；

軟件測試需求來源于用戶業務需求說明書、功能需求說明書和系統設計說明書，我們可以直接將一個原始用戶需求對應到一個測試需求或是多個測試需求，一個測試需求可以對應一個測試用例，或是拆分成多個測試用例。用公式可以表示如下：

Oq=＞Tq（一對一），或者 Oq1=＞（Tq11、Tq12、Tq13……Tq1N）（一對多）

Tq=＞Tc（一對一），或者Tq11=＞（Tc111、Tc112、Tc113……Tc11N）（一對多）；

從而推導出三者之間的關系：

Oq=＞Tq=＞Tc（一對一）；

OqM=＞（Tq11、Tq12、Tq13……Tq1N，Tp21、Tp22、Tp23……Tp2N，……，TpM1、TpM2、TpM3……TpMN）=＞（Tc111、Tc112、Tc113……Tc11X，Tc121、Tc122、Tc123……Tc12X，……，TcMN1、Tc-MN2、TcMN3……TcMNX）（一對多）；（Oq表示原始需求，Tq代表測試需求，Tc表示測試用例，M代表第幾個原始需求，N代表一個原始需求對應的測試需求個數，X代表一個測試需求對應的測試用例個數）。

由此可知原始需求、測試需求和測試用例之間的對應關系，下面我們將緊接著對軟件測試用例進行介紹。

2.2 測試用例

軟件測試用例定義就是編寫一組用例分類，測試要點，前提條件，輸入，執行步驟，預期結果的集合，實現對某個特定目標或是需求的測試。

我們可以把測試用例表示為一個十元組合：

Test Case=｛TC_ID，Td，Tc，TQ_ID，Pre，In，Es，Er，Cs，Fr｝

分別表示：｛用例標識、用例名稱、用例分類、需求標識、前提條件、輸入數據、執行步驟、預期結果、用例狀態及正反向｝

1）用例標識TC_ID：作為測試用例的唯一ID；2）用例名稱Td：簡述測試用例測試的目的；3）用例分類Tc：分為流程類、功能類和其他；4）需求標識TQ_ID：當前測試用例對應的測試需求，通過此標識關聯對應的測試要點；

5）前提條件Pre：說明執行測試用例必須的前提條件，例如測試開始之前必須完成的一些操作步驟或者數據準備；

6）輸入數據In：明確測試用例的數據輸入或者測試數據的生成辦法。輸入數據可以在操作描述中說明，或者寫在單獨的案例數據表中，根據功能驗證的要求的不同，可以輸入正向數據、反向數據、邊界數據等；

7）執行步驟Es：說明如何操作該測試步驟且步驟要求清晰無歧義。例如說明點擊操作的時候，需要說明點擊的對象是菜單、按鈕，還是鏈接；

8）預期結果Er：說明從測試輸入到執行該步驟應該產生的對應的輸出，比如狀態的遷移、計算結果、提示信息、頁面的切換等

9）用例狀態Cs：新增、變更、刪除；新增代表本次版本新增的測試用例，變更代表本次版本原始需求發生變更導致測試用例發生變更的，刪除代表本次版本原始需求發生變更不在本次測試范圍內的，只是設置一個標志位，實際未刪除；

10）正反向Fr：正向、反向；正向測試主要關注于系統能夠正常工作，反向指系統不支持的輸入或狀態，這類用例是為了檢查系統的容錯能力和可靠性。

以上介紹了測試需求和測試用例的定義及相關要素，測試需求是測試用例編寫的前提，而測試用例又是測試執行的前提，所以測試需求和測試用例在測試過程中至關重要，下面我們將以某一應用為例，介紹測試需求和測試用例的分析過程。

2.3 測試需求和測試用例分析過程

本章以電子采購交易平臺系統中的一種采購方式為例，說明測試需求和測試用例的分析過程。測試需求來源于原始需求，對于簡單的原始需求此處不做說明，本次只針對復雜的原始需求，流程存在多個分支或者子流程的，采用如下的分析過程：

1）根據原始需求描述對業務進行分析，對于復雜的業務流程可以借助思維導圖或是流程圖；

2）確定主流程、子流程或是分支流程；

3）根據原始需求制定出主流程、子流程或是分支流程的測試需求，在每個測試需求中提取測試要點；需要注意的是，有時候需求和設計的變更并沒有完全體現在相關需求分析和設計文檔中，所以在分析測試需求時，還應參照系統的用戶操作界面，輔助資料、補遺文檔中缺失或修改的系統功能；

4）編寫測試需求時，按照以上定義的測試需求進行規范及標準化編寫，保證應有的元素不能缺失，并且每個要素要求描述充分。

5）針對分解出的測試需求編寫測試用例，依照本系統的特征，測試用例按類型分為流程類測試用例和功能類型測試用例；

6）編寫測試用例時，按照以上定義的測試需求進行規范及標準化編寫，遵循統一的規范格式并且包括全部應有的要素，保證測試用例可執行且有效，能夠發現軟件的缺陷。

7）在測試用例中，輸入項中定義了案例數據表，案例數據表作為單獨的一項，是考慮到在操作步驟不變的情況下，根據測試需求的不同變換不同的輸入數據項，為自動化測試做準備。

以上是針對電子采購交易平臺中的一種采購方式進行的分析過程。但是在軟件測試過程中，測試用例會隨著環境、產品、功能、業務的變化而失效，測試用例的設計不能僅局限于一個系統，而應具備通用性、獨立性、標準性等特性，因此如何設計出可復用的測試用例是測試的關鍵技術。

3 軟件測試用例的復用

3.1 軟件測試復用

軟件復用是指利用原有的軟件相關知識、成果、經驗進行軟件開發的技術。軟件復用的對象是指軟件產品生產過程中的一切勞動成果，包括項目計劃書、可行性報告、系統的需求分析、軟件設計、測試，以及形成的相關文檔等［1］。

軟件復用有三個基本問題：一是必須要有可以復用的對象；二是所復用的對象必須是有用的，三是復用者需要知道如何去使用被復用的對象。通過軟件復用，消除了包括分析、設計、編碼、測試等在內的許多重復勞動，從而提高了軟件開發的效率，同時，通過復用高質量的已有開發成果，避免了重新開發可能引入的錯誤，從而提高了軟件質量［2］。了解了軟件復用基本概念以后，下面主要針對軟件測試領域的復用進行討論，軟件測試的復用包括測試過程的復用、測試方法的復用和測試用例的復用。基于我們所測試的電子采購交易平臺系統的特點，我們主要針對測試用例的復用進行敘述，所謂測試用例復用是指對一個軟件已執行的測試用例，將其不同程度地應用于該軟件新階段的測試中或其他軟件的測試中。可復用的測試用例具有通用性、獨立性、有效性、完整性和標準化的特點［3］。

Adhikari針對自動化測試腳本的可復用性，提出了編寫自動化復用測試用例的四個原則［3，6］：

1）設計相互獨立的測試用例

2）設計自包含的測試用例

3）設計基于出發點的測試用例

4）設計可全覆蓋和無重復的測試用例。

在我們測試的電子采購交易平臺系統中，最為關注的是手工測試用例，根據自動化復用測試用例的原則和特點，設計手工測試的可復用測試用例同樣可以遵循以上的原則進行分析。

3.2 測試用例復用的設計

隨著電子商務的快速增長，招標投標市場也呈現出快速發展的態勢，各類電子采購交易平臺由政府、企業、協會等不同主體大量建設，其中我們也承擔了許多大型電子采購交易平臺系統項目的建設，比如中廣核、中國移動、大唐集團、三峽集團、新奧能源集團、國機集團等大型集團公司電子采購交易平臺項目的建設，基于這些系統之間的共性，如平臺、實現、功能、業務等相似性，總結出一套適合電子采購交易平臺系統可以復用的測試用例。

在進行測試用例復用設計的時候，我們主要考慮以下幾個要素：

首先考慮系統所屬行業、軟件實現的功能、業務場景，運行的平臺及采用的編程語言，以此來判斷此類軟件相似程度是多少；

其次根據軟件相似度、業務場景及功能實現的不同判斷測試用例庫中是否存在與之匹配的測試用例，針對被測系統，做一些輸入、輸出的改動，進而對測試用例進行不同程度的復用；

最后執行測試用例，通過執行復用的測試用例，檢查被測軟件是否通過測試。

3.3 測試用例復用的分析過程

軟件測試用例的復用有三個基本的條件一是必須有可以復用的軟件測試用例，二是復用的軟件測試用例對將來軟件測試是非常有用的，三是復用者應該知道如何去使用被復用的測試用例。正確地刻畫、描述和管理可復用的測試用例是實現測試用例復用的關鍵技術［5］。

下面以電子采購交易平臺系統為例進行分析，說明測試用例復用的分析過程。

1）對軟件框架進行分析。本系統框架是基于SoGrid企業級構造云平臺，包括了平臺構造、框架構造和業務構造三部分，以SoGrid作為電子交易采購平臺的應用支撐。SoGrid的框架構造提供了致力于敏捷軟件開發、快速應用開發、平臺無關的基礎框架，可以進行JAVAEE企業級軟件研發。在充分考慮了集成環境的復雜性的情況下，本系統的框架即能運行在國網統一的SG-UAP上，也能運行在公司自主產品SoTower上，軟件在不同平臺之間的可移植性為可復用測試用例的編寫提供了一些可參考的依據。

2）對軟件業務進行分析。通過對電子采購交易平臺系統業務分析，整體業務流程梳理，從業務中抽取共性功能作為公共業務組件，同時，抽取的公共業務組件與電子采購交易平臺業務沒有強制的依賴關系，耦合度低，公共業務組件是否存在不影響整體業務流程。公共業務組可以跨越多個邏輯層和子系統，公共業務組件有明確的業務功能邊界，功能獨立，卸載后不會造成其他功能無法使用，從業務角度為電子采購交易平臺提供了運行時和開發時的伸縮性。公共業務組件是獨立的實體，影響測試用例是否具有獨立性，而測試用例的獨立性決定了測試用例的復用性的強弱。

3）對軟件功能進行分析。電子采購交易平臺系統核心采購模式包括公開招標、邀請招標、競價采購、詢價采購、競爭性談判、單一來源和比選采購等，采購過程分為招投開評定五大環節，這在所有的電子采購項目中是共有的屬性；在招標環節，招標方根據項目計劃發布公告或是邀請函，在投標環節，供應商需參與標書購買，澄清交互，投標文件編制以及開標文件確認等業務；在開標環節，招標方負責對供應商的投標文件進行開啟；在評標/評審環節，專家參與采購項目的初評、詳評，評標報告/談判報告的編制。在定標環節，根據評標結果產生中標候選人；在整個采購過程，紀檢監察人員對采購的關鍵環節進行事中監察或事后監察。采購結束后，以中標結果作為簽訂合同的依據進行合同的簽訂，合同的履約，合同的變更等業務。紀檢監察人員對合同的全過程也會進行事中監察或事后監察，系統實現企業供應鏈全過程管理，實現了上下協同、內外協同的物資采購管理模式。系統功能的全部實現，以及多個系統之間存在的共性，決定了是否能設計出全覆蓋且可復用的測試用例。

4）對組織機構及用戶權限進行分析。首先從業務需求判斷采購方式是集中采購還是自行采購，采購方式的不同將決定該軟件組織機構采用何種部署方式。其次對用戶權限進行分析，首先用戶的權限由系統賦予的角色所決定，而角色要由綁定的資源決定，而資源決定了此用戶的操作和數據。比如招標項目經理具有招標、開標和定標的權限，供應商具有投標的權限、專家具有評標的權限等，而這些用戶在相似的系統中應該具有相類似的權限控制。

5）對軟件業務實現的依據進行分析。國家制定了《電子招投標系統技術規范》、《招投標法》、《招標投標法實施條例》等辦法，目的就是為了規范招標投標活動，所有的招投標系統都要遵從這些辦法及規范進行設計開發，所以這些標準化、規范化的辦法及條例是設計開發的依據，也是設計可復用測試用例的依據和參考。

6）對軟件輸入進行分析。所有的電子采購交易平臺都有五個部分組成，分別是招標、投標、開標、評標和定標，從這五個部分中整理出共性的屬性作為輸入項的父集，然后再針對每個不同行業的電子采購交易平臺的個性特點，整理出輸入域的子集。父集可以在所有的電子采購平臺進行通用，子集根據不同的行業要求進行不同的應用。

最后根據以上分析和測試用例的定義要求，編寫通用的、有效的、獨立的、標準的、完整的可復用測試用例。考慮到可復用的目的，測試用例的設計要滿足測試用例復用的特性。可復用測試用例設計完成以后組織專家進行評審，以確保測試用例是有效且正確的，對評審通過后的測試用例執行，經測試執行確認的可復用測試用例納入到測試用例庫中，供測試人員在以后的待測軟件中查詢使用。

本文雖然重點關注測試用例復用在電子采購交易平臺中的復用，但是這種測試用例復用的方法在其他軟件平臺中同樣適用。

3.4 測試用例復用的應用

本文的研究內容在采購領域進行了應用，電子采購交易平臺系統在不同的行業的應用過程中（比如參與建設的能源行業、通信行業，機械裝備、核電行業等），雖然行業有所不同，但是不同的行業對該類軟件有共性需求。

首先對待測軟件的運行環境、測試需求、業務功能等進行分析之后，發現待測軟件與已測軟件兩者之間存在共性的需求。然后在原有測試用例庫V1.0中檢索與待測軟件相同或是相似的測試用例，若與待測軟件不匹配，對其進行修正使之更符合該軟件的測試用例，若原有的測試用例庫中未檢索到與待測軟件相同或是相似的測試用例，則按照可復用測試用例的設計原則進行設計，生成新的測試用例，對其進行評審，對評審通過后的測試用例執行，最后經驗證確認的可復用測試用例入庫到測試用例庫V1.0之后，生成新版本的測試用例庫V1.1以便后續繼續復用，保證軟件測試用例的收集和積累。在實際參與的幾個系統中，同樣應用了可復用測試用例，大大縮短了測試時間，提高了測試效率。

本文提出了基于復用的軟件測試模型，主要表現在測試用例設計及測試用例的復用上，如圖1所示。

圖1 軟件測試用例復用模型

下面以參與測試過的兩個電子采購交易平臺為例說明測試用例的復用。

首先針對已測試過的電子采購交易平臺中的招標采購進行測試用例的設計，測試用例分析的過程根據以上3.3中提到的方法執行。招標采購是為用戶提供招標采購的基本信息服務，包括了招標管理、投標管理、開標管理、評標管理和定標管理，這五部分是每一個電子采購平臺共有的環節，但是每個系統由于業務的差異又有所不同，先從這五個主要部分中整理出共性的屬性作為測試用例的父集，然后再針對電子采購平臺特有的部分整理出個性的子集。經過評審的測試用例入庫到用例庫中，測試用例庫分為兩部分一部分是系統通用和共性的用例即為父集庫，一部分是系統專用和特性用例庫即為子集庫。

然后再針對待測電子采購交易平臺中的招標采購進行軟件分析。因為每個電子采購交易平臺通用的部分都是招投開評定五個部分，在測試用例庫中這部分的用例有上千條，可以直接從原有的用例庫中提取父集中的共有用例，在編寫測試用例上節約很多的時間和資源。但是有所不同的是待測電子采購交易平臺在招標管理前的準備階段，是通過與其他系統的集成來獲取采購計劃，已測電子采購交易平臺在招標管理前的準備階段是通過在本系統直接新增采購計劃，因此根據兩個系統不同特征建立對應的子集加入到用例庫中生成新的測試用例庫。如果其他電子采購交易平臺采用的是集成的方式，測試用例可以直接從前者的測試用例子集中提取，如果是采用新增的方式直接從后者的測試用例子集中提取執行。在不同的系統不斷的應用過程中，子集中出現越來越多共性的屬性的時候，子集可以升級為父集，作為通用用例來執行。

4 結語

本文研究的主要內容是測試需求和測試用例在實際應用中的分析過程，軟件測試用例設計是軟件測試的重要環節，設計出高效可復用的測試用例是更關鍵的技術，將設計出可復用測試用例的思路和方法應用到不同的電子采購交易平臺中，從而達到改進測試方法，提高測試效率的目的。