Wang J, Cui Q, Wang S, et al. Domain adaptation for test report classification in crowdsourced testing[C]//2017 IEEE/ACM 39th International Conference on Software Engineering: Software Engineering in Practice Track (ICSE-SEIP). IEEE, 2017: 83-92.
摘要眾包測試中的自動測試報告分類是一項極具使用價值的技術，它能夠自動地從眾包工人提交的大量測試報告中找出真正能夠反映軟體缺陷的報告。該類技術中的大部分都透過採用歷史資料訓練得到分類器，利用該分類器對新提交的報告進行分類。但是，作者團隊在觀察真實工業資料後發現：由於眾包測試專案來自不同的領域，因此測試報告中通常包含許多用於描述某個特定領域軟體行為的技術術語。當將這些報告分類器應用於跨領域報告分類時，跨領域的資料分佈很可能會嚴重降低分類模型的效能。
為了構建高效的跨領域分類模型，作者團隊利用深度學習，透過探究領域特定術語和領域無關術語之間的共存方式來發掘跨域中間表示。具體地，作者團隊使用堆疊式降噪自動編碼器從原始文字術語中提取出高階特徵，並將這些特徵用於分類。為了評估本文提出的分類技術，作者團隊從一箇中國大型眾測平臺上挑選了來自 10 個不同領域的 58 個專案作為資料集，並在該資料集上分別比較了 3 個常用的基線技術。此外，為了進一步評估了技術的實用價值，作者團隊還利用該技術在現實世界場景下進行了案例學習。參與評估的眾包測試人員所給出的積極反饋反映了技術的實用性。
關鍵詞：眾包測試；測試報告分類；領域適配；深度學習
1 引言眾包測試作為一種新興的軟體工程實踐，在學術界和工業界受到普遍採納並逐漸成為一種趨勢。在眾包測試平臺完成眾測任務後，眾測工人通常需要按要求提交測試報告。在經濟和其他效益的引導下，眾包工人通常會提交數千份測試報告。然而不幸的是，眾包工人提交的測試報告常常存在誤報的現象，即：眾包工人認為的、程式的異常行為（疑似漏洞）實際上是程式的正確行為。為了去除這些誤報，專案經理或是測試人員需要人工對提交上來的測試報告進行審查。通常來說，只有不到 50%的測試報告能夠反映真正的程式漏洞。不難看出：測試報告的審查分類是一項費時、低效且異常乏味的工作。一項能夠對大量測試報告進行分類並提取出其中反映真實漏洞測試報告的自動化技術是十分必要且有價值的。
基於對真實工業資料的觀察，眾包測試的目標專案橫跨旅行、音樂、安全、攝像等多個領域，描述不同專案領域的測試報告也相應地會包含不同的術語（Term）。譬如：旅行領域的測試報告包含 “位置”、“導航”和“地點”等術語；而“播放”、“歌詞”、“歌曲”則是音樂領域的常用術語。從這兩個領域派生出的文字特徵在分佈上有很大的不同。在進行跨域分類時，不同領域的不同特徵分佈會降低機器學習分類器的效能。這是因為大多數機器學習模型都是基於“訓練集和測試集來自相同資料分佈”這一假設設計並訓練得出的。
大多數現有的報告分類方法都直接採用文字特徵構建模型而沒有考慮跨領域場景下資料分佈不同的問題，因此在應對眾包測試報告分類時通常效能不佳。為了克服不同的資料分佈以實現更加有效的跨域報告分類，本文提出了一種領域適應報告分類（Domain Adaptation Report Classification，DARS）方法。該方法利用堆疊式降噪自動編碼器（Stacked Denoising Autoencoders，SDA。一種深度學習技術）來學習並提取眾包報告中高階特徵，進而將這些特徵用於分類。為了從凝練高階特徵，SDA 首先需要從原始文字中挖掘出跨域中間表示。直觀地說，SDA 能夠分析詞彙在不同領域中重複出現的情況，並利用這一資訊區分出領域特定屬於（Domain-Specific Term）和領域無關術語（Domain-Unaware Term）。例如：“按鈕”（Button）、“開啟”（Open）、“錯誤”（Wrong）等就是常見的領域無關術語。
2 背景2.1 眾包測試本文的實驗藉助百度眾包測試平臺完成（www.test.baidu.com）。眾包測試的一般流程為：首先，測試人員準備測試任務並分發到眾測平臺上；然後，眾包工人登陸眾測平臺以執行眾測任務，並在完成任務後提交眾測報告。表1是一個典型的眾包測試報告，包含若干標準屬性如操作步驟、結果描述、螢幕截圖以及眾包工人對軟體行為的評估（Assessment）：當眾包工人認定程式行為正確時，眾包工人需要在評估一欄寫上“透過（Passed）”；反之，當認定程式行為錯誤時，眾包工人則需要在評估一欄寫上“失敗（Failed）”。[1]
表 1 眾包測試報告舉例
眾測任務通常會提供一定的經濟獎勵以吸引更多的眾包工人參與到測試任務中來。並且，評估為“失敗”的眾測報告所給的獎勵往往更多（因為這種報告可能發現了潛在的 Bug）。在這種模式下，眾包工人提交的報告通常數量巨大。以百度眾測平臺為例：該平臺每月大約交付 100 個專案，平均每天能夠收到 1000 餘份測試報告。然而不巧的是，“失敗”測試報告中有很多是誤報，即：標記為失敗但實際上描述的是一項正確的程式行為。目前，該平臺的測試人員需要透過人工審查的方式去除誤報。手動檢查 1000 餘份報告通常需要將近半個星期，且提交報告的正報通常只有不到 50%。不難看出：手工審查眾測報告是一項費時費力、低效乏味的工作。
2.2 堆疊式降噪自動編碼器（SDA）堆疊式降噪自動編碼器（SDA）是一種用於有效表示（Effective Representation）的無監督學習人工神經網路，由多層降噪自動編碼器（Denoising Autoencoder，DA）組成。
圖 1 自動編碼器（左）和堆疊式降噪自動編碼器（右）
如圖 1（左）所示：自動編碼器（Autoencoder）以向量 x ∈ [0, 1]d 為輸入，透過確定性對映 y = fθ(x) = s(Wx + b)將其編碼為隱藏表示（Hidden Representation）y ∈ [0, 1]d’。該對映透過 θ = W, b 進行引數化。其中：W 是一個權重為 d’×d 的矩陣，而 b 是一個偏移向量（Bias Vector）。自動編碼器生成的隱藏表示 y 將被進一步解碼為來自輸入空間 z = gθ’(y) = s(W’y + b’)（θ’ = W’, b’）的“重建（Reconstructed）”向量 z。反向對映對應的權重矩陣 W’和權重矩陣 W 之間存在約束，即 W’ = WT。
模型的訓練目的是找到能夠最小化平均重建錯誤（Average Reconstruction Error，ARE）的引數，對應公式 1。其中：L 是對應重建交叉入口（Reconstruction Cross-Entry）的損失函式。自動編碼器透過隨機梯度下降的方式進行訓練。其中：訓練迭代的次數是一個能夠平衡重建向量（Reconstructed Vector）與輸入向量的時間成本和錯誤率的輸入引數。
如圖 1（右）所示：堆疊式降噪自動編碼器（SDA）透過將一系列 DA 堆疊在一起的方式構建深度體系結構。訓練以逐層貪婪的方式進行，第 t 個 DA 輸出的隱藏表示將作為輸入傳遞到第 t+1 個 DA 中，且最後一個 DA 輸出潛在表示將被視為高階特性並輸出。隱藏層數和每層節點數由使用者按需設定。
2.3 研究動機大多數現有的測試報告分類方法以“訓練集和測試集來自相同資料分佈”作為前提假設，因此在面對跨域資料時效能會可能會大幅度下降。而事實上，作者團隊在觀察真實工業資料後發現：眾包測試報告經常來自旅遊、音樂、攝像等多個領域，資料分佈多種多樣。不同的領域通常會使用不同的技術術語來描述軟體行為。作者團隊隨機挑選了 4 個不同的軟體領域（旅遊、音樂、攝像和安全），對其中出現的詞彙進行了總結並透過術語雲的方式展現出來，如圖 2 所示。
圖 2 眾包測試報告中存在的不同資料分佈
圖 2 有效地說明了術語分佈情況以及分佈帶來的影響。從圖中我們不難看出術語跨領域分佈產生的巨大差異。例如，旅行領域測試報告（圖 2 左上）常常包含“位置（Location）”、“導航（Navigation）”和“地點（Place）”等詞彙；而音樂領域測試包含則通常與“演奏（Play）”、“歌詞（Lyric）”和“歌曲（Song）”等術語相關，兩類域派生的文字特徵在資料分佈上有很大不同。為了解決這一問題，作者團隊挖掘了不同領域專案之間共享的一些術語。譬如：描述動作的“顯示（Display）”、“設定（Setup）”和“下載（Download）”；描述屬性的“無（None）”、“錯誤（Wrong）”和“缺失（Missing）”等。這些通用術語能夠彌合跨領域鴻溝，比如：旅行領域測試報告可能會出現類似“顯示建築物位置（Display location of building）”的描述；而音樂領域則更可能出現“顯示歌曲的歌詞（Display lyrics of song）”。藉助深度學習演算法，“歌曲和歌詞”、“建築和位置”這些原本毫無關聯的術語將透過“顯示（Display）”一詞建立關係；利用“單詞在不同領域的重複出現”，學習演算法能夠將原始術語對映成高階特徵。當這樣兩個術語共享的上下文越相似時它們對應的高階特徵也就越相似。將這些高階特徵作為分類依據輸入到分類器中將大大提高測試報告分類的精度。
3 方法圖 3 展示了 DARS 的整體框架。DARS 分類方法可以分為四步（1）提取文字特徵；（2）訓練 SDA 模型；（3）利用 SDA 生成基於文字特徵的高階特性，以及（4）構建分類器並使用學習得出的高階特徵執行報告分類。
圖 3 DARS 架構概覽
3.1 提取文字特徵該階段的任務是從眾包測試報告中獲取基本特徵，並將這些特徵用作後續訓練 SDA 的輸入。作者團隊選擇從測試報告的文字描述中提取特徵：作者團隊首先將來自操作步驟、結果描述等不同來源的文字描述彙集起來，然後統一進行分詞。由於實驗中的眾包報告全部採用中文編寫，因此作者團隊選擇使用 ICTCLAS（http://ictclas.nlpir.org/）並將收集到的文字描述分割成若干單詞。之後，為了減少噪音，作者團隊首先對停用詞進行了刪除，然後又引入同義詞庫LTP（http://www.ltp-cloud.com/）將表達相同主題的不同詞彙替換成同一個。在完成上述預處理操作後，剩餘的每個術語都將對應一個基本文字特徵。作者團隊使用詞頻（Term Frequency，TF），即某個術語在描述中出現的頻率作為該術語（特徵）對應的特徵值。作者團隊沒有選擇使用 TF-IDF，因為 IDF（Inverse Document Frequency，反向文件頻率）是一種針對跨報告詞彙的懲罰機制，這與本工作想要“透過領域無關詞彙構建跨領域關聯”的初衷相悖。最後，作者團隊將獲取到的所有基本特徵組織成基本特徵向量，每個向量值都是對應術語的詞頻。
3.2 訓練 SDA為了生成用於分類的高階特徵，首先需要完成對 SDA 模型的訓練。訓練 SDA 的過程就是調整權重矩陣 w 和偏移向量 b 的過程，最終確定的 w 和 b 要能夠有效地實現對輸入特徵的編碼。在訓練過程中，作者團隊需要對 4 個引數進行調整，分別是（1）隱藏層數量，（2）每個隱藏層包含的節點數量，（3）噪音水平，以及（4）訓練迭代的次數。輸入和輸出層的節點數量等於特徵向量的維度。為了簡化模型，作者團隊將其他層也設定為相同的節點數。由於 SDA 要求輸入向量的長度相同，因此作者團隊需要首先收集了訓練集中出現的所有特徵並將其轉換成聯合向量特徵（Joint Vector Feature）。具體地：對於基本特徵向量中已有的特徵值，作者團隊直接留用並作為聯合特徵向量的值。否則就將聯合向量中對應位置的特徵值設定為 0。此外，SDA 還要求輸入資料的值介於 01 之間。為了將詞頻（通常大於 1）轉換成 01 之間的值，作者團隊進一步使用最小最大規範化（Min-Max Normalization）對聯合特徵向量中的每一個特徵值進行了歸一化處理。
3.3 生成高階特徵SDA 訓練完畢後，權重 w 和偏差 b 全部固定。對於訓練集和測試集的特徵向量，作者團隊首先將它們對映成聯合特徵向量（如 3.2 節所述），然後再透過最小最大規範化處理將特徵值限定在 0~1 之間。經過歸一化後的聯合特徵向量將作為輸入傳遞到 SDA 中，而 SDA 的最後一個隱藏層輸出的表示行為將被視作最終的高階特徵。
3.4 構建分類器在獲取到高階特徵完畢之後，作者團隊根據訓練集的高階特徵進一步完成機器學習分類器的構建。為了更好地輔助人工審查，分類器將針對輸入的測試報告提供正報機率（即，測試報告描述的缺陷是真實軟體缺陷的可能性）。機率值越大表示該報告包含真實缺陷的可能性越大。為了計算 F1 值，作者團隊使用 0.5 作為劃分報告種類的界限，即：正報機率大於 0.5 的就認定為真實缺陷，反之則認為是誤報缺陷。
4 評估4.1 研究問題本文從三個維度對 DARS 進行了評估，分別是有效性、優越性和實用性。具體地：
RQ1（有效性）：DARS 在執行眾包報告分類時是否有效？
RQ2（優越性）：DARS 是否超過了現有眾包報告分類技術？
RQ3（實用性）：對於軟體測試人員，DARS 是否真的有使用價值？
4.2 資料集本文的實驗基於百度眾包測試平臺儲存庫中的眾包報告。作者團隊收集了 2015 年 10 月 1 日至 2015 年 10 月 31 日之間所有已經完成了的眾包測試專案的資料，並按照領域名稱對這些專案進行分組。表 2 展示了資料集詳細資訊，包括專案數量、已提交報告數、已提交的失敗報告數以及失敗報告中真實錯誤的數量和比例等。
表 2 參與調查的專案
4.3 評估指標本文使用 F1 和 AUC 兩個指標對本文提出的方法 DARS 進行評估。F1（F-Measure）是廣泛用於評估報告分類技術的指標，它是精確度和召回率的諧波平均值；AUC（Area Under Curve）是用於評估不平衡分類器效能的最為常用的指標之一。作者團隊採用該指標的原因在於眾包報告的資料集通常是不平衡的，即真實錯誤的數量要少於誤報錯誤的數量。
4.4 實驗基線為了進一步評估方法效能，作者將 DARS 與三種典型的基線方法進行了比較，分別是領域無感知分類（Domain-unaware Classification，DUC）、轉移成分分析（Transfer Component Analysis，TCA+）以及基於簇的分類方法（Cluster-based Classification Approach，CURES）。
4.5 實驗結果及分析4.5.1 有效性分析（RQ1）
圖 4 展示了在不同訓練集大小下，DARS 在所有實驗領域下的 50 個實驗的 F1 和 AUC 分佈。從圖中可以看到：隨著訓練集規模的增加，F1 和 AUC 都會先提高、然後幾乎保持不變。為了確定最佳訓練集大小，作者在相鄰集上執行了 Mann-Whitney 檢驗，並得出最優的訓練集規模為 1500.
圖 4 DARS 的有效性
接下來在訓練集規模為 1500 的情況下分析 DARS 的效能。在這種情況下，F1 值的取值範圍為 0.720.82，中位數為 0.77；AUC 的取值範圍為 0.800.90，中位數為 0.84。這意味著：DARS 僅需要 1500 個帶標籤的資料例項作為訓練集就可以訓練得到相對令人滿意的效能。
表 3 各領域測試報告分類效能一覽
表 3 展示了在訓練集大小為 1500 時，DARS 在不同測試領域上的分類效能。不難看出，DARS 在不同領域測試集上的分類效能有所不同。不同領域對應的 F1 中位數取值範圍 0.710.83，而 AUC 取值則在 0.790.89 內浮動。其中，分類效果最差的是安全領域和音樂領域。透過進一步分析作者發現：這兩個領域測試集的眾包報告出現了大量全新的術語，例如歌曲的名稱。這些術語會引入噪音，對中間表示的建立造成干擾。
4.5.2 優越性分析（RQ2）
表 4 與基線技術的比對結果
表 4 是 DARS 與其他三個基準技術的的效能比對結果。本文對四種技術 F1 和 AUC 的最小值、最大值、中位值進行了分別比較（第一列），每種資料的最佳 F1 或 AUC 值（橫向比對）用深色背景標出。
對於任意訓練集大小，DARS 的 F1 和 AUC 值都由於 TCA+。這是意料之內的，因為 TCA+是在基本特徵的基礎上進行線性投影生成新特徵的，而屬於深度學習技術的 SDA 則會利用非線性對映從基本特徵學習得出高階特徵，從而能夠應對更加複雜的資料變化；另外，DARS 的效能也同樣優於 CURES。這是因為 CURES 需要依賴大量的歷史報告完成分類器的構造。在訓練集不夠大時，CURES 的效能將有所降低。
4.5.3 實用性分析（RQ3）
為了進一步評估 DARS 的有效性，作者團隊在百度公司內部進行了案例研究和調研。作者團隊隨機選擇了 3 個專案進行案例研究，並挑選了 6 名來自眾包測試小組的測試人員參與實驗。作者依照測試人員的工作經驗將他們分成 3 組，詳細資訊彙總在表 5 中。
表 5 案例研究參與者一覽
本案例研究的目的是評估 DARS 在真實眾包測試分類場景下的實用價值。如前面提到的，DARS 會最終為每份測試報告賦予正報機率。該實驗旨在評估這一機率能夠為測試人員的手動分類提供多少參考價值。
在實驗中，A、B 兩組測試人員需要為每份報告都標上“是”或“否”的標籤以表明該報告是否描述了真正的軟體缺陷（即正報）。B 組人員僅能看到眾包測試報告；而 A 組人員除原本的眾包測試報告外，還會得到 DARS 為每份報告預測的正報機率。報告將按照機率值倒序展示。為了得到參考答案（Ground Truth），作者團隊首先集合部分從業人員進行討論，並最終達成一致。以該參考答案為基礎，作者最終得到的案例研究結果如表 6 所示。
表 6 案例研究結果
由於測試人員只能簡單的給出“是”或“否”的答案（正報機率很難透過人工測量），因此作者團隊無法統計需要機率值的 AUC。為了豐富實驗結果，除 F1 值外，作者還在表 6 中展示了精度、召回率以及人工分類所用的時間。
表 7 調研結果
此外，為了進一步評估 DARS 的實用性，作者還設計了問卷並對受試人員進行了調查。問卷由一段關於 DARS 的簡短描述和三個問題組成。三個問題如表 7（第一列）所示。其中，Q1 和 Q2 是選擇題；Q3 則是開放性問題。受訪者可以針對第三個問題自由發表看法。作者團隊透過電子郵件的方式向參與過百度眾測報告分類的 47 名測試人員進行了訪問並收到了 21 份反饋，反饋結果彙總如表 7（第 2、3 列）所示。在 21 分反饋中，有 16 位（76%）測試人員認為 DARS 對報告分類很有幫助，並表示“希望使用 DARS”。這表明大部分測試人員都認同了 DARS 的使用價值。在剩下的 5 人中，有 3 人表示不同意，而另外兩人則持中立態度。在回答第三個問題時，他們主要表達了對 DARS 是否能夠領會應對新專案表示了擔憂。同時，DARS 在召回率方面表現不佳，需要進一步改進。值得一提的是，有一位專案經理對 DARS 表達出極大的興趣，並表示他計劃將 DARS 部署在平臺上以協助測試人員完成報告分類工作。
References[1] www.test.baidu.com）。眾包測試的一般流程為：首先，測試人員準備測試任務並分發到眾測平臺上；然後，眾包工人登陸眾測平臺以執行眾測任務，並在完成任務後提交眾測報告。表1是一個典型的眾包測試報告，包含若干標準屬性如操作步驟、結果描述、螢幕截圖以及眾包工人對軟體行為的評估（Assessment）：當眾包工人認定程式行為正確時，眾包工人需要在評估一欄寫上“透過（Passed）”；反之，當認定程式行為錯誤時，眾包工人則需要在評估一欄寫上“失敗（Failed）”。: http://www.test.baidu.com）。眾包測試的一般流程為：首先，測試人員準備測試任務並分發到眾測平臺上；然後，眾包工人登陸眾測平臺以執行眾測任務，並在完成任務後提交眾測報告。表1是一個典型的眾包測試報告，包含若干標準屬性如操作步驟、結果描述、螢幕截圖以及眾包工人對軟體行為的評估（Assessment）：當眾包工人認定程式行為正確時，眾包工人需要在評估一欄寫上“透過（Passed）”；反之，當認定程式行為錯誤時，眾包工人則需要在評估一欄寫上“失敗（Failed）”。