敏捷軟件開發中用戶故事與驗收測試的現狀研究

馬秀穎

(北方工業大學,北京 100144)

0 引言

敏捷開發是一種非常流行的軟件開發和管理方法。它的特性之一是在項目分析階段使用用戶故事來表達需求。用戶故事的廣泛使用使得它們變得越來越重要,而判斷它們是否被實現和滿足尤其重要。驗收測試用于解決這個問題。本項研究工作從用戶故事和驗收準則兩方面討論了最新的研究工作方法,希望為相關研究者提供參考。

1 相關概念

1.1 用戶故事

在敏捷開發中,用戶故事(user story)是軟件系統最終用戶用來描述系統所做或需要做的工作的若干句描述。它是軟件需求的傳統方法——軟件需求說明書或用例等的一種輕量級,更靈活的替代品。實際上,可以說用戶故事是敏捷開發最重要的工件。Cohn 認為用戶故事包括三個部分:(1)簡短的書面描述;(2)關于故事的對話,以詳細說明故事;(3)用于驗收測試的驗收準則。用戶故事的書面描述遵循一個簡單的模板:As a ,I want so that 。其中,Role是與系統交互的真實用戶,Function是系統的行為或操作。Benefit是所取得的結果,它一般用來表述非功能性的或系統外部的作用。

1.2 用戶故事驗收測試

驗收測試是極限編程的核心實踐之一,對于驗收測試到底是什么有很多不同的解釋。R.Owen Rogers等人[1]對它做了簡單的定義:驗收測試是客戶定義的,用來驗證一個故事是否完整和正確的測試。為了強調客戶在定義這些測試中的中心作用,驗收測試也稱為用戶測試(Customer Tests)。因此,驗收測試是驗證系統功能是否符合客戶期望的關鍵機制。

2 用戶故事研究現狀

盡管用戶故事已經是一種半結構化的自然語言,但它仍不能完全擺脫自然語言的模糊性等特點,再加上用戶對需求表達的非專業性、需求采集的多樣性等,使得基于用戶故事的敏捷需求實踐充滿了挑戰。等人[2]在2015年的綜述中,基于用戶故事的敏捷需求實踐將用戶故事的關注點總結為用戶故事收集,角色建模,驗收測試,評估、發布計劃和迭代開發,追蹤和交互,并對用戶故事管理工具做了詳細分類和總結。我們在他們工作的基礎上進行了相關研究工作的補充。為了方便展示,我們制作了表1。表1描述了近幾年的主要研究工作。

表1 主要研究工作Tab.1 Main Research

3 戶故事驗收測試

用戶故事驗收測試是一個將驗收測試與領域用戶故事相結合的過程,簡單來說可以包括驗收測試的表達、測試用例的生成和驗收測試的執行。

3.1 驗收測試表示

用戶故事的驗收測試需要依據驗收標準進行展開。在驗收測試中有兩種常見的表示形式。第一種為文本場景表示法(Gherkin Language),他運用了Gherkin語法,使用該格式可以很好的與Cucumber這一BDD(Behavior-Driven Development)的自動化測試框架進行銜接。Duc-Man Nguyen等人[3]就在其工作中使用了這種表示。第二種為前面提到的checklist表示法,多用于書面筆記。此外,還有一種表格表示法(Fit tables),該表示依托于fit家族得到了廣泛使用。Ernani Cé sar dos Santos等人比較了表格表示法和文本場景表示法,結果表明沒有足夠的證據來確認一種技術更容易指定測試場景或者更好地溝通軟件需求。在此之前,Melnik 等人進行了一個實驗,表明非技術用戶與軟件工程師一起工作時,可以使用驗收測試場景作為溝通和驗證軟件業務需求的一種方式。實驗指出,非技術用戶可以使用Fit表清楚地指定軟件需求,但它指出用戶在學習如何使用這種符號指定測試場景時有困難。此外,這項研究表明,一些非技術用戶不允許使用Fit表作為指定需求的工件。

3.2 測試用例生成

傳統的用戶故事驗收測試是全手工的,而為功能需求手工編寫測試用例是一項耗時的任務。這樣的測試用例不僅難以編寫,而且維護起來也很有挑戰性。此外,手工測試用例生成效率低下,并且容易出錯,于是眾多學者圍繞自動化驗收測試展開研究。自動生成測試用例需要對用戶故事和驗收準則有較好的解析能力,然而用戶故事和驗收準則均為自然語言,因此要想較好的支持自動解析需要對他們進行較為細致的約束。

Mahawish Massod 等人定義了受限制的用戶故事模板,模板中的驗收準則由前置條件和滿足條件(Conditions of Satisfaction)組成。滿足條件由執行路徑和后置條件組成。執行路徑的表達受自然語言限制規則的約束,并使用規定的關鍵字。他們給出了常用的數據類型以及相關屬性的選擇,通過這些約束生成測試用例。他們的方法對用戶友好且對Selenium IDE有很好的支持。Duc-Man Nguyen等人也對用戶故事及驗收準則的表達進行了規范。驗收準則的書寫格式是采用了When I Xan dY,I will check for Z as a result.他們將其按照預定義的myDSL 模板進行二次書寫以將其轉換為Z3 SMT格式,然后使用求解器進行求解生成測試用例。該方法還支持添加啟發式規則,這一方面有利于檢查和優化測試用例輸出,另一方面也彌補了Z3 對字符串處理的缺陷。

為了適應通用的敏捷過程模型,Pallavi Pandit等人[4]提出了一個UAT過程模型,它旨在基于驗收標準,用自然語言生成詳盡的測試用例。模型分為三部分,分別是迭代前規劃、迭代中和迭代結果。在迭代前的規劃階段輸入用戶故事和驗收準則,對于驗收準則的表示,他們采用了Given [input |preconditions]When [actions | triggers]Then [output | consequences]格式。在迭代過程中,首先使用MoSCoW(Must,Should,Could and Would)對用戶故事進行優先級排序。其次提取用戶故事元素以便生成測試用例圖,測試用例圖就像是用戶驗收測試(UAT)的基礎。最后將驗收準則轉換為驗收測試(積極的、消極的和非功能性的)。在迭代結果階段可以查看報告、追溯性和缺陷日志。針對該過程模型,他們開發了AgileUAT、工具以百分比值表示是否滿足驗收標準,并通過使用DOM樹說明了史詩、用戶故事、驗收標準和驗收測試用例之間的可追溯性。

3.3 驗收測試執行

驗收測試執行的方法和工具有很多。Fit是用于指定和執行驗收測試的最成熟的技術框架。使用這個框架,驗收測試以表格的形式編寫,稱為Fit表。Fit表除了用于表示測試場景外,它們還用于報告測試的結果。由程序員制作的用于執行業務邏輯表的fixture將表內容映射到軟件系統中。測試結果以三種不同顏色顯示測試的不同狀態:綠色表示測試通過;黃色表示無法執行的測試,紅色表示測試失敗。表的第一列和第二列表示輸入,而第三列(名稱后面跟著括號)表示預期輸出。當測試失敗時,預期的和實際的輸出值將顯示給用戶。

Agile Planner with Fit對Fit-table做了改進。Agile Planner with Fit的實現依賴于兩個插件:Agile Planner和Fitclipse。Agile Planner是一種基于卡片的規劃工具。Fitclipse是一個擴展Fit和FitLibrary的Eclipse插件,允許用戶在Eclipse IDE環境中執行項目計劃,并將項目計劃保持在與代碼相同的位置。除了Fit和FitLibrary附帶的功能之外,Fitclipse還可以跟蹤測試結果的歷史,支持多模態測試執行,并添加驗收測試重構功能。FitLibrary是Fit中fixture的擴展集。除了Fit提供的測試樣式之外,它還支持測試網格和圖像。FitNesse是一個Wiki前端測試工具,支持創建和編輯驗收測試的團隊協作。FitNesse使用Fit框架通過web瀏覽器運行驗收測試。它還集成了用于編寫和運行驗收測試的FitLibrary。還有一些其他的Eclipse插件也使用Fit或FitNesse,包括FitRunner、conFIT和AutAT。FitRunner為Eclipse提供了一個Fit啟動配置,使人們能夠運行自動化驗收測試。ConFIT使用一個FitNesse服務器來執行驗收測試,該服務器可以本地運行,也可以遠程運行。AutAT 允許非技術用戶使用用戶友好的圖形化編輯器編寫和執行web應用程序的自動化驗收測試。Haugset等人對常用驗收測試工具做了總結,比較了Fit、FitNesse和Selenium。其中Fit及其衍生物通常直接與業務層集成,而Selenium則與用戶界面層集成。

4 結論與展望

本文描述了與用戶故事和驗收測試相關的實踐現狀并提出了可能的未來研究趨勢。隨著敏捷方法的廣泛使用,用戶故事和驗收測試的重要性也在增加,通過研究現狀我們發現了以下研究趨勢:

(1)借助自然語言處理技術提取用戶故事信息、進行聚類分組與降重、重用。

(2)借助自然語言處理,挖掘用戶故事間的關系,包括從屬關系、交互關系等。借助關系的挖掘,進行模型轉換、迭代管理。

(3)借助機器學習技術,研究模型自動生成與轉換,自動進行驗收測試與生成驗收測試用例。

(4)相信隨著機器學習和自然語言處理的發展,用戶故事的應用與管理將會取得長足進步。