軟件測試技術(shù)在人機(jī)對話系統(tǒng)中的應(yīng)用研究

林曉欲,Yuan Tommy，雷倩茹

(1.洛陽光電技術(shù)發(fā)展中心，河南 洛陽 471000；2.約克大學(xué) 計算機(jī)科學(xué)學(xué)院，英國 約克 YO10 5GH)

0 引 言

人工智能技術(shù)毫無疑問地被列為即將改變世界的突破性技術(shù)之一。而人機(jī)對話[1]是人工智能領(lǐng)域的一個子方向，通俗地講就是讓人可以通過人類的語言(即自然語言:文字、語音，甚至兩者皆含)與計算機(jī)進(jìn)行交互，來完成確定任務(wù)的人與計算機(jī)之間的信息交換過程。[2]

人機(jī)對話系統(tǒng)陸續(xù)上線使用，越來越貼近人類的工作、學(xué)習(xí)和生活，其類型多種多樣，狀態(tài)各異，對話目標(biāo)也各不相同，已經(jīng)滲透到社會的方方面面。人機(jī)對話系統(tǒng)的復(fù)雜性和普遍性也使人們意識到其質(zhì)量保證的重要性。

人機(jī)對話系統(tǒng)的本質(zhì)是軟件通過一定的載體來達(dá)到其目標(biāo)。傳統(tǒng)軟件的質(zhì)量保證通常通過軟件測試來實現(xiàn)。人機(jī)對話系統(tǒng)既符合軟件產(chǎn)品的基本屬性，又具有其固有特點(diǎn)。針對其特點(diǎn)，如何運(yùn)用軟件測試技術(shù)研究出一種有效的方法開展測試，來達(dá)到對人機(jī)對話系統(tǒng)軟件質(zhì)量保證的目標(biāo),成為人機(jī)對話系統(tǒng)相關(guān)研究的熱點(diǎn)和難點(diǎn)。

本文結(jié)合傳統(tǒng)的軟件測試方法，將8種基本對話類型按照實現(xiàn)用途歸結(jié)為4類，并分析4類對話系統(tǒng)的特征，提出針對性的測試方法和思路。將軟件測試技術(shù)用于英國約克大學(xué)開發(fā)研究的某人機(jī)辯論系統(tǒng)中，通過測試工作，發(fā)現(xiàn)該系統(tǒng)的一些缺陷，提出了改進(jìn)建議。通過具體的對話系統(tǒng)測試實踐，驗證了測試方案的有效性，為后續(xù)研究提供了基礎(chǔ)。

1 對話系統(tǒng)

1.1 基本對話類型

從文獻(xiàn)[3]資料中已經(jīng)認(rèn)識到的7種人類基本類型的對話是：說服、調(diào)查(詢問)、發(fā)現(xiàn)、談判、信息查詢、審議、爭論。這7種是基于參與者有明確目標(biāo)的，即任務(wù)型對話系統(tǒng)，如果再加上開放域?qū)υ挘戳奶?，那么基本的對話類型?種，如表1所示。

目前，人機(jī)對話系統(tǒng)根據(jù)基本對話類型和實現(xiàn)用途進(jìn)行歸類，可以分為4類：問答、任務(wù)驅(qū)動的多輪對話、推薦和開放域聊天。

(1)問答：接近一個自然語言理解加信息檢索的過程，側(cè)重于一問一答，即直接根據(jù)用戶的問題給出精準(zhǔn)的答案。基本對話類型中的發(fā)現(xiàn)、調(diào)查和信息查詢與該功能相對應(yīng)。

(2)任務(wù)驅(qū)動的多輪對話：由于用戶需求比較復(fù)雜，有很多限制條件，可能需要分多輪進(jìn)行陳述，所以更是一個決策過程，需要機(jī)器在對話過程中不斷根據(jù)當(dāng)前的狀態(tài)決策下一步應(yīng)該采取的最優(yōu)動作(如提供結(jié)果、詢問特定限制條件、澄清或確認(rèn)需求等)，從而最有效地輔助用戶完成服務(wù)獲取或解決問題?；緦υ掝愋椭械恼f服、談判、商議和爭論與該功能相對應(yīng)。

(3)推薦：根據(jù)當(dāng)前的用戶需求和歷史的用戶畫像主動推薦用戶可能感興趣的信息或者服務(wù)。基本對話類型與該功能沒有直接相關(guān)，可以說是對對話系統(tǒng)的技術(shù)衍生。常言道，需求不存在因為技術(shù)不存在。在當(dāng)今信息爆發(fā)的時代，推薦技術(shù)在幫助用戶尋找信息、幫助服務(wù)商尋找客戶的環(huán)節(jié)中扮演了舉足輕重的地位。

(4)開放域聊天：在用戶沒有明確的信息或服務(wù)獲取需求時系統(tǒng)做出的回應(yīng)。自然語言聊天在現(xiàn)有的人機(jī)對話系統(tǒng)中，主要起到拉近距離、建立信任關(guān)系、情感陪伴、順滑對話過程(如在任務(wù)類對話無法滿足用戶需求時)和提高用戶粘性的作用?；緦υ掝愋椭械牧奶炫c該功能對應(yīng)。

1.2 對話系統(tǒng)工作過程

常見的對話系統(tǒng)工作過程主要為：系統(tǒng)首先理解人類發(fā)出的信息，將其表示為一種內(nèi)部狀態(tài)，然后根據(jù)對話狀態(tài)的政策采取相應(yīng)的行動，最后將行動轉(zhuǎn)化為一種自然語言的表現(xiàn)形式，如圖1所示。主要由以下部分組成：自然語言理解(Natural Language Understanding，NLU)、對話狀態(tài)跟蹤(Dia-logue State Tracking，DST)、對話策略學(xué)習(xí)(Dialogue Policy Learning,DPL)、自然語言生成(Natural Language Generation，NLG)[4]。其中DST和DPL統(tǒng)稱為對話管理(Dialogue Management，DM)[5]，即根據(jù)對話歷史信息，決定對用戶的反應(yīng)。

圖1 對話系統(tǒng)工作過程Fig.1 Dialogue system working process

1.3 軟件測試方法[6]

由于軟件開發(fā)人員思維上的主觀局限性，且軟件系統(tǒng)的復(fù)雜性，軟件非常容易出錯。而軟件一旦發(fā)生故障，造成的后果可能非常嚴(yán)峻。減少軟件缺陷、提高軟件質(zhì)量是一項艱巨的任務(wù)。

軟件測試是為了發(fā)現(xiàn)軟件產(chǎn)品所存在的任何意義上的軟件缺陷，從而糾正這些軟件缺陷，使軟件系統(tǒng)更好地滿足用戶的需求[7]。從哲學(xué)觀點(diǎn)看，分析問題和解決問題的方法有兩種：白盒方法和黑盒方法。軟件測試沿用哲學(xué)思想，將測試方法也分為白盒測試方法和黑盒測試方法。

白盒測試(White Box Testing)[8]又稱結(jié)構(gòu)測試或者邏輯驅(qū)動測試，是把測試對象看作一個打開的盒子，如圖2所示。白盒測試需要測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程，不需要測試軟件產(chǎn)品的功能。白盒測試方法的覆蓋標(biāo)準(zhǔn)有邏輯覆蓋、循環(huán)覆蓋和基本路徑測試等。

圖2 白盒測試Fig.2 White box testing

黑盒測試(Black Box Testing)[9]又稱功能測試或者數(shù)據(jù)驅(qū)動測試，是根據(jù)軟件的規(guī)格對軟件進(jìn)行的測試，這類測試不考慮軟件內(nèi)部的運(yùn)作原理，因此軟件對用戶來說就像一個黑盒子，如圖3所示。軟件測試人員從用戶的角度，通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件存在的缺陷，而不關(guān)心程序具體如何實現(xiàn)。黑盒測試的類型有功能、性能、接口、兼容性、易用性等。黑盒測試方法的覆蓋標(biāo)準(zhǔn)為需求覆蓋。

圖3 黑盒測試Fig.3 Black box testing

2 人機(jī)對話系統(tǒng)測試策略

2.1 對話系統(tǒng)應(yīng)用程序的特點(diǎn)

對話系統(tǒng)應(yīng)用程序是一系列按照特定順序組織的計算機(jī)數(shù)據(jù)和指令的集合，既符合軟件的基本特點(diǎn)，也具有其特殊性，主要有：不確定性和概率性、對大數(shù)據(jù)具有依賴性、隨機(jī)性的輸入/輸出、難以預(yù)測所有應(yīng)用場景、需要從過去的行為中不斷自我學(xué)習(xí)。具體表現(xiàn)是：

(1)對話系統(tǒng)是由巨大而多樣的數(shù)據(jù)驅(qū)動的，在做出任何決定之前都需要進(jìn)行處理；這些數(shù)據(jù)可以是任何格式，如文本、語音、圖像、視頻等，來源也各不相同；這些數(shù)據(jù)可能是一次性攝入的，也可能是一個連續(xù)的過程；數(shù)據(jù)是人機(jī)對話系統(tǒng)所采取的任何預(yù)測、決定或行動的基礎(chǔ)。

(2)對話系統(tǒng)是機(jī)器學(xué)習(xí)系統(tǒng)，系統(tǒng)通過學(xué)習(xí)、訓(xùn)練來執(zhí)行某些動作。根據(jù)需要和上下文，這些算法可能在種類和復(fù)雜性上有所不同，可以組合多個算法來給出特定的期望輸出。

(3)與第三方系統(tǒng)有豐富的接口，通常被應(yīng)用于其他更大的應(yīng)用程序以滿足最終的業(yè)務(wù)目標(biāo)。

2.2 測試策略[10]

2.2.1 基本測試策略

人機(jī)對話的核心是利用對歷史數(shù)據(jù)的處理訓(xùn)練，得出可以在將來數(shù)據(jù)上有良好輸出的模型[11]。所以，對于測試而言，應(yīng)該關(guān)心數(shù)據(jù)模型在對待正常數(shù)據(jù)、邊界數(shù)據(jù)、異常數(shù)據(jù)作為輸入時，模型的輸出是否能夠符合期望；數(shù)據(jù)模型在經(jīng)過訓(xùn)練后，用測試集數(shù)據(jù)預(yù)測的正確率如何。因此，應(yīng)開展數(shù)據(jù)測試、分層測試、訓(xùn)練集和測試集對比測試。

(1)開展數(shù)據(jù)測試。用等價類劃分、邊界值分析等方法進(jìn)行功能測試，尤其是邊界、異常數(shù)據(jù)測試，如輸入與訓(xùn)練時一樣的數(shù)據(jù)、與訓(xùn)練時完全不同的數(shù)據(jù)、訓(xùn)練時的邊界值等，看是否達(dá)到期望輸出；以此來驗證模型對數(shù)據(jù)的容錯能力，算法是否能夠通過迭代和對比來減少誤差；驗證系統(tǒng)能夠接受來自各種來源和各種格式的數(shù)據(jù)；驗證所攝入的數(shù)據(jù)是按照目標(biāo)系統(tǒng)所期望的格式轉(zhuǎn)換。

(2)開展分層測試。針對人機(jī)對話系統(tǒng)的復(fù)雜性，對模型進(jìn)行分層測試。模型工作的過程是：數(shù)據(jù)引入、數(shù)據(jù)處理(清洗、拆分、拼接等)、特征工程、模型訓(xùn)練、模型上線。通過測試分層后每一個部分的功能、性能和各層的接口實現(xiàn)對模型的測試。

(3)開展訓(xùn)練集和測試集對比測試。對話策略學(xué)習(xí)的算法主要是機(jī)器根據(jù)數(shù)據(jù)特征和特征的權(quán)重來預(yù)測一個行為，是一個結(jié)果概率。因此，使用訓(xùn)練數(shù)據(jù)集來理解和建模系統(tǒng)行為，并使用測試數(shù)據(jù)來驗證系統(tǒng)的準(zhǔn)確性或響應(yīng)也是一種測試方法。

值得注意的是，傳統(tǒng)的測試需要有準(zhǔn)確的預(yù)期結(jié)果，這是邏輯思維的結(jié)果。而人機(jī)對話(除了問答)往往沒有準(zhǔn)確的預(yù)期結(jié)果，也不需要保證每次數(shù)據(jù)的正確性。應(yīng)該考察即便數(shù)據(jù)有一點(diǎn)問題，最后得出的模型效果還不差這樣的結(jié)果；需要驗證隨著數(shù)據(jù)規(guī)模的增長，數(shù)據(jù)結(jié)果的正確性和優(yōu)化效果。因此，對人機(jī)對話系統(tǒng)測試的思路應(yīng)該從注重“邏輯分析”轉(zhuǎn)換到“知識學(xué)習(xí)能力的驗證”上。

主要測試類型有：

(1)功能測試：用等價類劃分、邊界值分析等方法進(jìn)行數(shù)據(jù)、模型過程的功能劃分，測試功能的正確實現(xiàn)；模型是否能夠根據(jù)處理數(shù)據(jù)的量從少到多而自動不斷優(yōu)化、調(diào)整輸出。

(2)性能測試：用場景法確定不同的性能需求，測試模型在處理數(shù)據(jù)時的效率(學(xué)習(xí)過程、cpu占用率、內(nèi)存消耗等)；在同一平臺通過不斷點(diǎn)擊運(yùn)行，以及快速退出和快速進(jìn)入，處理大量數(shù)據(jù)、空數(shù)據(jù)等觀察性能指標(biāo)的變化等。

(3)接口測試：測試模型分層后數(shù)據(jù)的正確轉(zhuǎn)換和傳輸；測試模型輸入輸出的正確性。

(4)易用性測試：測試模型是否有良好的用戶交互；測試具體使用時，是否有良好的告知用戶的提示，不能一直處于安裝或等待狀態(tài)等；測試模型是否有人性化的參數(shù)調(diào)整入口，供運(yùn)營人員以及測試人員對上線后、上線前進(jìn)行調(diào)整。

(5)兼容性測試：測試不同的操作系統(tǒng)下運(yùn)行對話系統(tǒng)的兼容性；測試軟件與其他軟件共同運(yùn)行的情況。

2.2.2 特殊測試策略

(1)問答系統(tǒng)DM測試策略

問答系統(tǒng)DM主要實現(xiàn)過程是：在問句的類型識別與分類的基礎(chǔ)上，進(jìn)行文本的檢索[12]以及知識庫的匹配。也就是分為問題分析、信息檢索、答案抽取三部分。其路徑排列的數(shù)量非常大，因此，在測試中不可能運(yùn)行路徑的每一種組合，所以要進(jìn)行針對性測試，通過對系統(tǒng)業(yè)務(wù)需求和業(yè)務(wù)流程的分析，從宏觀角度考慮用例應(yīng)該包括哪些基本流和備選流。通過用例場景[13]來描述流經(jīng)用例的路徑，繼而確定從用例開始到結(jié)束遍歷這條路徑上所有的基本流和備選流，形成比較高的場景覆蓋率，指導(dǎo)測試的實施，以保證軟件的質(zhì)量。

測試首先抽取業(yè)務(wù)流程圖，即從系統(tǒng)需求說明書或相關(guān)文檔中提取出相關(guān)的業(yè)務(wù)流程，形成業(yè)務(wù)流程圖；其次，確定關(guān)系圖，即根據(jù)具體的業(yè)務(wù)流程圖，畫出基本流和備選流的關(guān)系圖；然后，確定觸發(fā)條件，即經(jīng)過以上對系統(tǒng)(子系統(tǒng))的運(yùn)作流程的分析，根據(jù)業(yè)務(wù)流程圖，按照傳統(tǒng)的用例分析方法分析出每個基本流與備選流的觸發(fā)條件；最后，進(jìn)行場景分析，即根據(jù)確定的基本流和備選流的關(guān)系，再加上確定的觸發(fā)條件的描述，確定出不同的用例場景。

測試類型與基本測試類型相同。需特別說明，在功能測試時，通過備選流的測試，保證對系統(tǒng)異常情況的測試覆蓋。

(2)多輪對話系統(tǒng)DM測試策略

多輪對話系統(tǒng)DM就是在NLU(領(lǐng)域分類和意圖識別、槽填充)的基礎(chǔ)上，進(jìn)行對話狀態(tài)的追蹤(DST)以及對話策略的學(xué)習(xí)(DPL)，以便于DPL階段策略的學(xué)習(xí)以及NLG階段澄清需求、引導(dǎo)用戶、詢問、確認(rèn)、對話結(jié)束語等。

產(chǎn)生的狀態(tài)數(shù)跟意圖和槽值對的數(shù)成指數(shù)關(guān)系，與問答系統(tǒng)DM測試策略相同。同樣通過用例場景來描述流經(jīng)用例的路徑，形成比較高的場景覆蓋率，以保證軟件的質(zhì)量。

其特殊性在于，存在上下文處理及決策過程，由于多輪交互時，有很多信息在交互的上文中已經(jīng)出現(xiàn)，用戶不會再在當(dāng)前的問題中進(jìn)行重復(fù)，所以需要一個上下文的記憶模塊，根據(jù)所有對話歷史信息推斷當(dāng)前對話狀態(tài)St和用戶目標(biāo)。常用的方法是運(yùn)用人工規(guī)則、生成式模型、判別式模型、Web Rank等，因此，對這部分的測試可以與基本測試策略相同。

測試方法為問答系統(tǒng)DM測試方法與基本測試方法結(jié)合。測試實現(xiàn)為問答系統(tǒng)DM測試實現(xiàn)與基本測試實現(xiàn)結(jié)合。

(3)推薦系統(tǒng)DM測試策略

推薦系統(tǒng)DM就是進(jìn)行用戶興趣的匹配以及推薦內(nèi)容評分、排序和篩選等，以便于NLG階段生成更好的給用戶推薦的內(nèi)容。對推薦系統(tǒng)測試可以算作大數(shù)據(jù)測試和算法測試。

基于大數(shù)據(jù)算法的測試方法可以用結(jié)果反饋的方式去測試，即對結(jié)果進(jìn)行實時監(jiān)控，發(fā)現(xiàn)異常后及時反饋；也可以自己構(gòu)造一些數(shù)據(jù)，然后用算法去跑自己構(gòu)造的數(shù)據(jù)，檢查結(jié)果是否正確。

推薦系統(tǒng)的測試實現(xiàn)方式分別為：從所有的結(jié)果當(dāng)中進(jìn)行抽樣，然后進(jìn)行基本的業(yè)務(wù)測試；自己構(gòu)造測試數(shù)據(jù)，然后對這些數(shù)據(jù)的輸出結(jié)果進(jìn)行測試；基于效果的監(jiān)控，通過監(jiān)控算法上線后點(diǎn)擊率、平均瀏覽時長、平均停留時長、留存情況、覆蓋率等常用的評估指標(biāo)是否有上升。

(4)開放域聊天系統(tǒng)DM測試策略

聊天系統(tǒng)DM就是對上下文進(jìn)行序列建模、對候選回復(fù)進(jìn)行評分、排序和篩選等，以便于NLG階段生成更好的回復(fù)。其本質(zhì)與多輪對話系統(tǒng)相同。

測試方法為問答系統(tǒng)DM測試方法與基本測試方法結(jié)合。測試實現(xiàn)為問答系統(tǒng)DM測試實現(xiàn)與基本測試實現(xiàn)結(jié)合。

3 對某人機(jī)對話系統(tǒng)的測試實踐

3.1 被測軟件概述

約克大學(xué)人工智能小組開發(fā)的“人機(jī)對話系統(tǒng)”對話模型DE[14]是建立在正式辯論系統(tǒng)DC的基礎(chǔ)上的辯論系統(tǒng)模型。該系統(tǒng)旨在提高辯論系統(tǒng)基本對話模型在辯論過程中發(fā)現(xiàn)錯誤論點(diǎn)和常見錯誤的能力。

設(shè)計者使用Java編程語言構(gòu)建了一個功能完整的原型，對對話模型DE進(jìn)行操作。這個系統(tǒng)可以讓用戶與其就有爭議的問題進(jìn)行辯論。

系統(tǒng)有五個主要部分：界面部分、對話部分、承諾部分、計劃部分和知識庫部分。系統(tǒng)設(shè)計時對表達(dá)方式、庫集規(guī)則、對話規(guī)則進(jìn)行了規(guī)定。該辯論系統(tǒng)架構(gòu)如圖4所示。

圖4 某辯論系統(tǒng)架構(gòu)Fig.4 Debate system architecture

3.2 測試內(nèi)容與方法

辯論系統(tǒng)本質(zhì)上是一個以說服為目的的多輪對話系統(tǒng)，所以參考本文2.2節(jié)的測試策略開展測試。

目前，對人機(jī)系統(tǒng)的測試研究，無論是方法還是標(biāo)準(zhǔn)都處于探索階段，還未形成規(guī)范和標(biāo)準(zhǔn)，因此，本次測試是一次研究性的測試。由于該系統(tǒng)的輸入為列表選擇輸入，輸出為文字輸出，因此，本次測試涉及對話系統(tǒng)中的對話狀態(tài)跟蹤和對話策略學(xué)習(xí)，不涉及語音識別和文字輸入，不涉及語音輸出。

本次人機(jī)對話系統(tǒng)測試應(yīng)符合以下技術(shù)要求：

(1)系統(tǒng)的每個特性應(yīng)至少被一個正常測試用例和一個被認(rèn)可的異常測試用例所覆蓋；

(2)測試用例的輸入應(yīng)至少包括有效等價類值和邊界數(shù)據(jù)值；

(3)測試系統(tǒng)的輸出及其格式；

(4)對不同的實際問題應(yīng)外加相應(yīng)的專門測試。

考慮測試投入，結(jié)合軟件特點(diǎn)，制定對應(yīng)的測試策略如下：

(1)根據(jù)重要程度，排定測試的優(yōu)先順序為：功能性測試、易用性測試、兼容性測試、維護(hù)性測試；

(2)與委托方溝通項目建設(shè)經(jīng)驗，針對委托方關(guān)注的業(yè)務(wù)內(nèi)容進(jìn)行重點(diǎn)測試；

(3)根據(jù)對軟件特點(diǎn)進(jìn)行分析，應(yīng)重點(diǎn)針對人機(jī)對話系統(tǒng)中決策的轉(zhuǎn)換場景進(jìn)行測試；

(4)使用歷史已有的測試數(shù)據(jù)輔助測試分析；

(5)對測試中提出的軟件問題，應(yīng)與軟件承研單位充分溝通、確認(rèn)。

經(jīng)分析，本次測試需要開展的測試類型為功能性測試(包括接口測試)、易用性測試、維護(hù)性測試和兼容性測試。

對界面部分、對話部分、承諾部分、計劃部分、知識庫部分、輸入、知識響應(yīng)、規(guī)則等以及識別出來的重要場景進(jìn)行測試項分解，并進(jìn)行易用性、維護(hù)性和兼容性分析，結(jié)果如表2所示。

測試內(nèi)容充分性分析：

(1)對軟件中的功能需求及非功能需求進(jìn)行全面分析，并結(jié)合用戶提出的需求，共整理出19項測試需求，對應(yīng)19個測試項目，細(xì)化為64個測試子項，實現(xiàn)測試需求對可測軟件需求100%覆蓋。

(2)描述測試環(huán)境與實際運(yùn)行環(huán)境一致，滿足測試要求。

3.3 測試環(huán)境

測試環(huán)境配置如表3所示。

人機(jī)對話系統(tǒng)在計算機(jī)系統(tǒng)中完成其功能，本次測試環(huán)境為計算機(jī)系統(tǒng)，因此，測試環(huán)境與真實環(huán)境一致，無環(huán)境差異。

表2 功能測試需求分解Table 2 Test demand decomposition

表3 動態(tài)測試環(huán)境配置列表Table 3 Dynamic test environment configuration list

3.4 測試設(shè)計

對于確定的測試內(nèi)容，按照分解的測試子項設(shè)計測試用例。每個單獨(dú)的測試都進(jìn)行了詳細(xì)描述。測試用例的基本表達(dá)如表4所示。

表4 測試用例Table 4 Test cases

注：>表示當(dāng)前活動的角色。

3.5 測試執(zhí)行

按照測試用例的描述執(zhí)行測試。

3.6 測試總結(jié)

本次測試運(yùn)行測試用例125例，借用133個對話場景[15]，開展了功能性(含接口)、易用性、兼容性、維護(hù)性測試，覆蓋了用戶提出的需求。

被測軟件在系統(tǒng)智能、用戶體驗、系統(tǒng)價值和用戶界面幾個方面均滿足使用要求，特別是DE對話模型和所采取的策略實現(xiàn)了開發(fā)目的；被測軟件具有良好的兼容性和可維護(hù)性。

測試過程中提出軟件問題5個，其中功能性2個、易用性3個，均為一般性問題。問題具體描述為：

問題1：測試人員扮演支持CP方，在經(jīng)過多輪辯論后，同意了對方的觀點(diǎn)(反方)，這時候裁判并沒有進(jìn)行裁決，而是讓辯論繼續(xù)。測試人員認(rèn)為此測試結(jié)果與需求不一致。

問題2：幫助菜單中的部分功能未實現(xiàn)。

問題3：辯論過程中，運(yùn)用“I don’t think” 或者“Why”作為論述開始時，界面表示中不容易找到支持觀點(diǎn)的陳述。

問題4：辯論過程中，運(yùn)用“I don’t think” 或者“Why”作為論述開始時，可在用戶觀點(diǎn)和機(jī)器觀點(diǎn)里進(jìn)行多項選擇，系統(tǒng)不能及時給出限制提示。

問題5：幫助菜單內(nèi)容多次點(diǎn)擊會在屏幕上多個顯示，系統(tǒng)不能進(jìn)行限制。

與開發(fā)方進(jìn)行溝通，對于問題1，開發(fā)方認(rèn)為該系統(tǒng)設(shè)計的目的是用于教學(xué)的辯論系統(tǒng)，所以在辯論策略設(shè)計上還考慮了辯論內(nèi)容覆蓋的全面性，基于這個考慮，裁判進(jìn)行裁決的時機(jī)會跟真實辯論過程不同。針對該問題，開發(fā)方會在相應(yīng)文件中進(jìn)行說明。此外，接受其余4個問題并進(jìn)行改進(jìn)。

4 總 結(jié)

本文通過研究不同對話系統(tǒng)的特點(diǎn)，提出相應(yīng)的軟件測試方法和思路。經(jīng)研究表明，傳統(tǒng)的測試類型同樣適用于人機(jī)對話系統(tǒng)測試，但是在測試策略制定時，需要考慮由于人機(jī)對話系統(tǒng)中用到大量機(jī)器學(xué)習(xí)方法，這部分測試應(yīng)針對其特點(diǎn)，在測試用例設(shè)計時，改變傳統(tǒng)的需要準(zhǔn)確預(yù)期結(jié)果的思路，重心放在模型能力的驗證上。

通過對某人機(jī)辯論系統(tǒng)的測試實踐，驗證了方法和思路的可操作性。測試結(jié)果表明，測試方法可行，測試思路正確，對提高軟件質(zhì)量有突出的貢獻(xiàn)。此測試可以作為人機(jī)對話系統(tǒng)測試的基礎(chǔ)。

同時，本文提出的方法和思路還需要開展更深入、充分的研究和試驗，并應(yīng)用到人機(jī)對話系統(tǒng)的評估中。