基于知識提取的測試文檔自動生成

孫曉韓，李 寧，于 楊，楊子儀，張 林

(北京信息科技大學 網絡文化與數字傳播北京市重點實驗室，北京 100101)

0 引 言

產品測試文檔是一類特殊的文檔，它記錄產品測試活動留下的記錄，并作為交付物，供產品的相關方使用，是產品的重要組成部分。這類文檔的特點是與測試項目的數據有緊密聯系，種類繁多內容復雜。此外，這類文檔有嚴格的編制要求，存在大量的測試規范和文檔編制規范[1-2]。文獻[3]總結了軟件文檔編制的四方面要求：(1)準確性：產品文檔描述的內容要與實際情況保持一致，并反映產品的最新更新；(2)完整性：產品文檔中能夠系統、詳盡地描述產品所提供的全部功能；(3)及時性：產品文檔可隨時按需獲得；(4)可用性：文檔可以指導目標用戶高效地完成工作。這些要求對于其他種類的文檔編制也是必要的。

文檔的計算機輔助編制技術，特別是軟件產品的文檔編制技術研究已有很長的歷史[4-5]。以往的計算機輔助軟件文檔編寫手段主要有：(1)通過辦公軟件、Dita[6]等寫作工具或手工編寫或填充模板；(2)通過 MarkDown[7]、reStructedText[8]等工具輔助，在軟件開發過程中對代碼進行標記，自動化地或半自動化地生成文檔；(3)使用軟件工具自動記錄數據并生成文檔；(4)開發專用的文檔編寫軟件。這些文檔編制方法都存在各自的優缺點。

首先第一種方法編寫的文檔可讀性較好，但是主要依靠人工，費時費力，難以做到與系統同步更新；第二種方法能夠做到與系統同步更新，但是需要進行大量的標注，帶來額外的負擔，且生成的文檔類型有限，可讀性較差；第三種方法自動化程度較高，但需要完善的軟件工程環境的支持，一般工具形成的文檔難以做到規范和全面，且難以進行靈活定制；第四種方法需要為不同的項目開發文檔系統，而今天人們更希望以“低代碼”的方式適應產品的變化。此外，當前大部分文檔都是靜態的，難以按需展現數據內容或實現交互式的信息檢索。

當前隨著軟硬件開發技術的快速演進，以往的文檔編制過程也顯得低效而難以適應需要。以測試文檔為例，軟件測試是軟件工程的重要環節，其主要產物是測試文檔。測試文檔要反映測試過程的活動，包括測試計劃、測試需求、測試流程、缺陷跟蹤和記錄，等等。特別是大型軟件測試經常包含成千上萬個測試用例，記錄這些測試案例和測試結果，使得測試文檔的編寫工作量很大。另一方面，敏捷開發方法和DevOps[9]的應用，強調持續集成(Continuous Integration，CI)和持續交付(Continuous Delivery，CD)，使得傳統的測試文檔編制過程難以適應，一方面頻繁的迭代和更新導致文檔延遲交付，另一方面找不到掌握全面信息的文檔編制人員，文檔的開發成為了影響項目進展的瓶頸。

隨著近年人工智能和自然語言處理技術的發展，計算機輔助寫作技術逐漸成熟。廣義的計算機輔助寫作(Computer Aided Writing， CAW)以數據和知識為基礎，將知識管理與認知技術相結合，輔助人工完成文檔的編寫[10]。在CAW中，數據到文本的生成(Data to Text，D2T)技術與該文關系較大。目前該領域已經取得了較多的研究進展，業界已經研制出面向不同領域和應用的多個生成系統，如基于數值數據生成天氣預報文本[11]、體育新聞[12]、財經報道、醫療報告等[13]。數據到文本的生成技術一般包括以下階段：數據的分析和理解，文本的規劃以及遣詞造句[14]。

測試文檔的編寫也可以看作是從測試記錄和測試數據生成測試報告文本的過程。數據到文本的生成技術可以為之提供很好的借鑒。例如，可以基于測試規范構建測試過程的知識本體，通過對測試數據的分析，將其映射到知識本體，形成知識表達，然后借助測試文檔模板和內容生成規則，最終生成測試文檔。此外，可以借助CAW的動態模板技術和復合出版[15]的特點，在遵循測試文檔編寫規范的前提下，根據數據的形態個性化地展現報告內容。例如，對于重復的測試項，自動形成子章節內容，對于統計數據，根據需要展現成表格和圖表，或借助智能標記和插件對測試結果進行檢索。

綜上，針對文檔編制過程中的低效問題，該文按上述思路提出一種基于知識提取的測試文檔自動生成方法，其可以實現測試文檔的自動生成，有效提升了現實中軟件產品測試的智能性、可復用性以及自動化程度。

1 測試文檔生成方法及模型設計

該文的目標是為計算機產品的質量測試開發測試數據管理與測試文檔生成系統。希望能夠支持多類軟件的測試，能夠對測試結果進行語義檢索，能夠跨平臺運行，能夠保持測試文檔的實時更新。經過調研得知，在計算機產品的質量測試中，一個被測系統一般由多部分子系統構成，每個部分均按多個測試項、多個指標和多輪次測試開展測試，有一套預先設計的電子表格文檔用于記錄測試數據，不同類型的被測產品對應不同的電子表格記錄。一個中等規模的測試項目大約包含50張電子表格，500多項測試數據，一個復雜系統的數據量會數倍于它。可見數據的規模和復雜程度是很高的。一個典型的記錄測試數據的電子表格局部如圖1所示。

圖1 一個典型的記錄測試數據的電子表格(局部)

一般的測試文檔自動生成系統會簡單建立電子表格單元格到測試文檔模板中標識項的映射，通過模板填充生成測試文檔[16]。但是這樣處理會存在多個問題：(1)無法對測試數據進行有效的管理和后續利用，例如對測試結果進行動態查詢；(2)深度依賴被測的產品的種類，如果換一種產品則需要重新編程，無法達到“低代碼”的目標；(3)缺少靈活性，記錄測試數據的電子表格一旦結構發生變化，將需要重建映射。

筆者認為，要改進上述問題，需要一種有效的方式來管理測試數據。由于測試數據記錄與具體的被測產品相關，靈活多變，要將其體現在標準的測試文檔內容中，構建的流程如下：

第一步：對不同類型產品的測試數據進行分析和知識提取，得到測試結果的結構化語義表示；第二步：將提取后的測試結果結構化表示映射到通用的測試本體，形成穩定、通用的知識表示并加以存儲；第三步：構造知識本體到測試文檔的映射關系，將測試結果通過模板填充或格式轉換形成測試文檔。其中，第一步對應D2T的數據理解過程；第三步對應D2T的文本規劃和遣詞造句過程；其中第二步是該文特有的。在自然語言處理中，D2T生成的是自由的文本，不需要特定的結構和格式約束，而測試文檔需要符合相關的編制規范，對于不同的產品測試類型，測試文檔的撰寫方式是基本一致的，因此需要對測試結果進行規范化的表示并保存到測試知識庫中。

圖2 測試文檔生成過程(1)

圖3 軟件文檔生成過程(2)

2 測試數據理解與知識提取

大量的電子表格中的測試數據是以非關系型的方式記錄的，例如，圖1中有多個表格嵌套，不符合關系型范式。因此需要與之相適合的層次模型表示數據及其關系，XML數據顯然是最好的選擇。從自由設計的電子表格中提取出XML并非易事。例如，圖1的電子表格并沒有明確的與XML數據的對應關系。為此需要進行表格邏輯結構的識別，以獲得測試數據的知識表示。

設計了以下的表格邏輯結構識別算法。

從邏輯結構來看，表格模板是由單元格集合C和單元格間關聯關系集合R組成的一種數據存儲結構。其中單元格集合C為：

C={c|c∈T1∪T2}

(1)

式中，T1={Header},T2={Data,HeaderData}。Data表示數據型單元格，在表格模板中，Data不含內容。Header表示表頭型單元格，它是一種只含表頭信息而不含數據信息的單元格。HeaderData表示表頭數據型單元格，它既含表頭信息，又能被填入數據。

單元格間關聯關系分為兩種：層次關系(表示為Hie)和指示關系(表示為Ind)。層次關系集合H為：

(2)

(3)

R=H∪I

(4)

圖4 表格模板示例

(5)

如果所有單元格兩兩不重復組合形成的集合為P，則：

P=R∪N

(6)

由此可知，若要提取表格的邏輯結構，必須要確定表格的單元格集合C和單元格間關聯關系集合R。其中，C的確立依賴于表頭型單元格集合T1、其他單元格集合T2的確立，即表頭型單元格的識別。并且，關聯關系集合R是在已知T1、T2集合的基礎上建立的，故表頭識別是邏輯結構識別的首要任務。

該文構造了一種全連接神經網絡分類器來區分Header和HeaderData。神經網絡由輸入層、隱含層和輸出層組成，它依靠神經元內的激活函數構造輸入與輸出的非線性關系。全連接神經網絡結構如圖5所示。經驗證，在表頭識別任務中，隱含層采用ReLU激活函數比其他激活函數更能使模型快速地趨于收斂，所以在隱含層該文方法采用ReLU激活函數。在輸出層，由于Softmax函數可以將多分類轉化為概率，所以該文方法采用Softmax激活函數。此外，針對分類問題，交叉熵函數便于梯度下降反向傳播，因此，采用交叉熵函數作為網絡的損失函數。

圖5 全連接神經網絡的整體結構

為了在反向傳播中降低交叉熵，需要以一定的力度調整網絡參數。交叉熵與參數的偏導數指明了以多大力度調整該參數，以W11為例，經過一次反向傳播后，它的新值Wnew11更新情況如公式(7)所示：

(7)

式中，ETotal為交叉熵，η為學習速率。經過多次反向傳播，網絡參數可以更新為最優值。

網絡的配置參數如表1所示。其中Full為隱含層，η為學習速率。

表1 全連接神經網絡的網絡參數

在關聯關系識別中，首先剔除絕對無關聯的單元格對，然后基于規則將表格分割成較小的邏輯塊，再應用 Siamese-BiLSTM 模型對其進行關聯關系識別，并根據識別結果中相關聯的單元格對，構建表格邏輯結構樹。對應圖1，識別出的邏輯結構樹見圖6。

圖6 圖1的表格邏輯結構識別結果(簡化表示)

電子表格理解的具體算法詳見文獻[17]。

3 測試知識庫構建

如前文所述，在獲得測試數據的知識表示之后，為了形成規范的測試文檔，需要構建一個通用、穩定的測試知識本體。由于測試的概念體系是一個典型樹狀結構，并不適合用關系型數據來描述，因此采用XML Schema來描述測試數據的本體結構，對應圖1，測試知識本體的局部結構如圖7所示。

為了將來有效利用測試數據，并為測試文檔生成做準備，需要有效管理各個測試項目的Kp，為此采用XML數據庫管理系統eXist來進行測試知識的管理。

eXist是一個開源的原生XML數據庫管理系統[18]，能夠很好地支持數據索引，支持XSLT，XQuery和Java開發，特別是能夠支持無預定義的存儲結構，這樣能夠很好地適應測試數據結構的變化。此外eXist可以通過建立共享目錄和文件拷貝簡便地實現數據入庫，對于非專業的測試人員非常方便。

圖7 測試知識本體的局部結構

eXist數據庫的基本概念包括文檔集(collection)、資源(resource)和文檔(document)。eXist通過collection將一系列數據文件聚集起來，存儲所有文件的元數據以及多個resource。resource中以命名空間為單位存儲多條XML數據(document)。在該文的系統中，每一類測試項目c對應一個collection，其中包含各個pc的resource以及存放Kp的測試數據document。有了測試知識庫，便可以著手生成測試文檔了。

4 測試文檔自動生成

對于所有的測試項目，測試文檔均為符合標準的規范形式，這種形式一般用模板來表達。但是一般使用的靜態報告模板存在以下幾個問題。首先，難以處理動態變化的數據，例如對空的測試項進行去除，或對重復的測試項增加動態分節；其次，難以根據測試數據的特點按需展示內容，例如對于表格形式的數據，難以提供選擇以最適合的圖表(chart)形式來呈現；再有，人們習慣了紙質的測試文檔，而作為電子形式的測試文檔理應有更豐富的交互方式，例如通過插件或智能標簽來裁剪或定位報告中的特定內容，或對測試結果進行查詢統計。

為支持文檔的動態生成能力，采用局部模板，以自底向上的方式來生成測試文檔。為測試文檔的各個部分設計了局部的模板ti，每個ti可能有多個候選{ti1,ti2,…}，根據數據的呈現要求來選用，全部ti組成測試文檔的模板集合T，

ti∈T,0

ReportGeneration(Kp,T)

i=1;

whilei<=N

{

for eachti∈T

{

定位Kp的位置，得到數據d;

按d的特點和呈現要求選擇ti中的候選模板tij，tij∈ti;

用d填充tij，生成測試文檔的第i部分;

}

}

if需要動態查詢等擴展功能

{

構造基于XQuery查詢程序；

生成查詢插件或智能標簽；

}

項目要求將測試文檔保存成為Microsoft Word文檔形式，為降低對Microsoft Office產品的依賴，沒有采用Office SDK，而基于OOXML的開源接口POI[19]來開發模板。如果需要生成HTML形式的測試文檔，可使用XSLT構造測試文檔的轉換式樣單，此處不作贅述。這種在不同介質上按需生成文檔的能力，體現了復合出版的思想。圖8是該文生成的測試文檔部分內容。

圖8 生成的測試文檔(部分)

5 結束語

運用數據到文本的生成理論，提出了一種基于知識提取的測試文檔生成方法。該方法首先對原始的測試記錄數據進行分析和理解，重點進行電子表格的表頭識別和單元格關聯關系識別，抽取出XML形式的表格邏輯關系分析結果；其次按照預先設計的、標準化的測試本體，將表格邏輯關系分析結果轉換成規范的知識表達，存放在XML數據庫中，形成測試知識庫；最后依次用知識庫中的數據填充文檔局部模板，逐步獲得整體的測試文檔。該方法體現了如下的創新性：

較好的通用性和“低代碼”，可以支持多類測試和多個測試項目。在不同的測試類型之間切換時，只需要自動識別新的電子表格測試記錄，并替換第3節中的Tp即可。另外，如果測試項目對測試文檔的展現形式有特殊的要求，可以定制模板和腳本，此外無需更多的編程，避免了重復開發工作。

通過對測試數據的知識提取，避免了原始測試記錄的不穩定性，利于測試結果有效利用。雖然在測試過程中受各種因素影響，難以保證測試人員自始至終采用一致的電子表格記錄數據，但是只要表格的邏輯結構不變，總能從中得到正確的知識表示。另外規范化的知識表示可以用于后續對測試結果的各種查詢、統計和分析。

在填充局部模板的基礎上生成整體測試文檔，避免了傳統靜態模板帶來的缺點，能夠較好地處理動態的數據，并按需展示數據內容，同時可以擴充交互式的數據訪問能力。

系統有較好的跨平臺能力，采用開放的標準和開源軟件進行開發，不依賴于特定的商業軟件。

取得的成果已經通過驗收，成功應用于中國電子技術標準化研究院的產品測試部門，從浩繁的測試數據中生成一份測試文檔只需要幾分鐘的時間，在近期大負荷的信創產品測試任務中發揮了重要作用。

在未來可以繼續改進的方面有：

(1)考慮將RDF等知識表示語法用于測試知識的表示，以期更高效地實現對測試結果的語義檢索；

(2)構建更為靈活的文檔模板集合，配合智能化的作文規則，進一步提高測試文檔的可讀性；

(3)將成果推廣到其他領域的文檔編制，針對敏捷開發和DevOps等開發模式特點，探討從不同來源的原始數據生成完整的、規范的產品文檔的可能性。