清華大學自動化系系統工程研究所副教授李力作為第一作者以及林懿倫，鄭南寧，王飛躍，劉躍虎，曹東璞，王坤峰，黃武陵等發表了一篇關于人工智能測試和無人車測試的英文論文《Artificial intelligence test： a case study of intelligent vehicles》，集中探討了人工智能應用領域中關于智能性的測試和設計方法。文章認為，智能性測試和機器學習的過程類似，兩者如同一個硬幣的兩面，“終生測試”將是一場持久戰。文章最后還提出了虛實結合的平行測試方法。

1. 概述

本篇文章主要是講述在人工智能應用領域對智能性的測試，基于場景和任務的測試體系的描述，以及介紹了如何設計智能性測試中基于仿真的測試及其測試指標，并在智能車這一典型人工智能領域舉例說明。

2. 無人駕駛和人工智能

人工智能（AI）通常是指機器表現出來的和人類類似的智能?，F如今，人工智能已經極大的改變了我們的生活，大到自動駕駛汽車，小到掃地機器人，都是人工智能的應用領域。我們堅信，人工智能將會在未來的20年內進一步的改變我們生活包括健康，教育，娛樂，安全等各個領域。在享受人工智能的帶來的各種便利的同時，也帶來一些疑問：如何保證人工智能機器按照人類設計的思路來正確運行？無人駕駛車輛是否會在某些極端環境中失控照成事故？廚房機器人是否會把房子點燃？基于以上，我們迫切的需要對人工智能的可靠性進行規范的測試和衡量。

為了回答以上問題，我們需要思索一下人工智能的定義：維基百科對于人工智能的定義：機器所展現出來的智能；我們對其進行擴展，給出的定義：人工智能是指機器（在同樣的任務中）表現出（和人類似的、或一樣的、甚至是超過人類的）智能，明斯基（Minsky 1968）對人工智能給出過類似的定義“［AI］ is the science of making machines capable of performing tasks that would require intelligence if done by ［humans］”。 明斯基的定義更加注重對完成任務的所需要的智能（原因導向），而本文的定義則更加傾向于所完成的任務所表現的智能（結果導向）。

同時必須注意到的是，為測試智能性所選擇的任務也是有特定針對性的，不同的任務測試不同方面的智能性，例如，一個文盲可能能成為一個很好的司機，但是一個眼盲的飽學之士卻無法開車。

圖靈測試是迄今為止我們所知的最早的針對智能性的測試。圖靈測試是圖靈對于人工智能的睿智思考，其核心思想是：要求計算機在沒有直接物理接觸的情況下，盡可能把自己偽裝成人類回答人類的詢問。但是，圖靈測試在無人車智能性測試方面也無法全盤套用。

當今，智能性測試有越來越多的應用領域，那么我們到底應該用何種方法來測試智能性呢？我們所提出的基于任務的智能性測試方法又有哪些優越性呢？接下來，我們將會列舉智能性測試的難點，以及我們提出測試方法如何解決這些難點，以及如何更好的設計基于“任務”的測試用例。

3. 無人駕駛智能的設計和測試

3.1. 智能性測試的困境

3.1.1. 任務的定義/描述

第一個困境是如何來更好的定義智能性測試中的任務：

圖靈測試中最大的短板就是任務的描述。需要指出的是，當今的無人駕駛車輛智能測試和中文屋等早期圖靈測試已經有了很大差別：其一，早期圖靈測試并未明確的規定測試任務以及何種答案可以視為正確，這導致一些試圖通過圖靈測試的機器經常采用摸棱兩可的方式來試圖避免直接回答。而當今的無人駕駛車輛智能測試都對任務進行了明確的界定；其二，早期圖靈測試有人來判定測試結果，而為了檢驗無人駕駛車輛的識別算法是否通過各種可能場景的測試，我們必須使用機器來幫助判定數以萬記的測試任務是否通過。

總之，我們需要建立一系列的可以量化的測試任務，這是智能性測試最根本的基礎。

3.1.2. 任務的驗證

第二個困境是：如何保證被測智能機器在所遇到的所有場景中表現出其行為的一致性。因此需要保證任務測試的枚舉性/覆蓋性。

通俗的講，我們可以把任務看作是對智能機器測試的輸入，如果完成該任務，輸出“是”，反之輸出“否”。對于一些相對簡單的智能性測試，通過枚舉所有可能的任務組合，我們可以窮盡可能的交通場景。如果車輛能通過所有這些場景，則車輛將足夠智能。但由于任務空間的時空連續性，枚舉是不可能完成的。因此，必須依賴虛擬采樣測試來加大如何合理采樣，在降低場景生成復雜度的同時，提升測試覆蓋性成為測試的關鍵技術。通過記錄受試車輛和其他車輛的軌跡，我們可以定量刻畫車輛的智能水平（駕駛性能）。

3.1.3. 仿真測試的設計

為了在有限的時間和財力內盡量解決任務覆蓋問題，現在的研究者多采取仿真測試來彌補實地測試的不足［4］。由此出發，研究者進一步研究了如下諸多衍生問題：

1）如何保證虛擬測試中虛擬物行為的真實性；

2）如何保證虛擬測試中虛擬物表現的豐富性；

3）如何保證虛擬測試中場景和任務的覆蓋性；

4）如何實現虛擬測試中機器判定的正確性。

例如在仿真測試方面，目前的無人駕駛車輛研究者考慮了如何從現實采集的2D圖像數據中提取物體的3D屬性，并在3D引擎中重新渲染并產生新的2D虛擬測試數據。而另外一些研究者則考慮了如何基于生成式對抗網絡來直接從2D實測圖像數據來生成新的2D虛擬測試數據。

再者，測試標準的設定也是研究者探討的熱點之一。對于駕駛這類典型的多目標問題，如何評價不同算法的優劣并設計適應不同用戶要求的測試標準尚有很大的難度。

3.1.4. 測試指標的設定

測試指標的設定的方法有幾種，第一種是要求智能機器做出類似人的行為表現。這種方法里首先需要確定人在完成該任務時會如何表現，然后再根據智能機器在完成該任務的過程中的表現和人的表現的區別來做判定。

第二種測試指標設定方式是要求智能機器有最好的表現。比如，在設計針對圍棋的人工智能機器時，我們要求其能夠一直勝利，而不是像一個人類選手的方式去下棋。對于這一類目標相對簡單的情況下，這種方式更加合適。在智能車測試中，目標往往比較復雜，不能像圍棋一樣以贏得棋局為目標，需要考慮行駛安全性，速度，燃油效率等其他復雜的因素。以不同的因素為目標會導致完全不同的設計。例如在2016，2017年的中國無人車未來挑戰賽中，智能車通過設定的10個特定場景任務的時間被作為評價指標之一，如果發生了碰撞，壓線，闖紅燈，也會扣去相應的分數。當人的感受被納入考察因素的時候，考慮到每個人對于同一件事物的感受都會有一定的區別，測試指標的設定會變的更加艱難。

3.2. 智能車的智能性測試

我們這里以智能車的智能性測試為例，來說明我們的觀點：

3.3.1. 智能性測試中測試任務的設定

傳統的無人駕駛車輛智能測試主要分為兩大流派：場景測試流派和功能測試流派。

1） 場景測試

往往是指處在特定時空中的測試系統。例如，交通場景一般指的是由眾多交通參與者和特定道路環境共同構成的交通系統。如果受試車輛能夠自主行駛通過該交通系統，則稱為通過該特定場景的駕駛測試。例如DARPA 2005 年無人車挑戰賽便選取了212 公里的沙漠道路作為測試場景（其實2004年也是選擇了沙漠作為測試場景，但是“全軍覆沒”，相比之下，2005年則是一段光輝歲月）（Grand Challenge 2005）。DARPA 2007 年無人車挑戰賽則選取了96 公里的城市道路作為測試場景（Urban Challenge 2007）。

2） 功能測試

功能測試更加側重無人駕駛的單項或多項功能實現。依據人類智能的功能歸類方式，可將駕駛智能劃分成信息感知、分析決策、動作執行等較為概括的三大類能力。例如路徑規劃就屬于分析決策類的單項智能。該定義方式強調的是實現這些單項智能的方法和技術上的共性。但由于不能與具體的交通場景以及無人駕駛測試任務聯系起來，在衡量無人駕駛的智能水平方面有所不足。功能測試的隱含假設是，如果無人駕駛通過某種功能的一次或幾次測試，那么，以后需要使用該功能時也可以順利執行。這一假設看似合乎邏輯，但事實證明，也過于樂觀。此外，目前的功能測試還存在其它問題：

單一功能測試較多，綜合測試涉及較少，無法檢驗多項功能之間的協同配合能力

缺少完備、公平、公開的Benchmark集。

我們認為，無人駕駛車輛的智能可以用廣義的語義網絡來定義。

語義網絡是一種采用網絡形式表示人類知識的方法，如今已在人工智能領域中得到了比較廣泛的應用。語義網絡用有向圖來表達復雜的概念及其之間的相互關系。圖中的頂點表示概念，而邊則表示這些概念間的語義關系。

針對無人駕駛智能的廣義語義網絡分為場景、任務、單項能力和綜合能力四類節點。其中任務將場景和能力打通并連接起來，應該是無人駕駛智能研究的核心，參見下圖。

*圖1. 無人駕駛智能定義的語義關系圖釋

場景一詞源于戲劇，是指在一定的時間、空間（主要是空間）內發生的一定的任務行動或因人物關系所構成的具體人事片段。在系統學研究中，場景多被定義為處于特定時空中的特定系統。交通場景一般指的是由眾多交通參與者和特定道路環境共同構成的特定交通系統。

任務原指交派的工作。駕駛任務既可以指跟馳、換道、停車等某類一般性的駕駛工作，亦可指特定環境中的某項特定駕駛工作。

如果受試車輛能夠自主行駛完成某項特定任務，則稱為通過該特定任務的駕駛測試。相對于駕駛場景而言，駕駛任務更為具體，時空范圍更為明確。一個特定的駕駛場景通常包含多個駕駛任務。近兩年，中國智能車未來挑戰賽注意到了任務測試的重要性，精心設計了任務庫，測試無人駕駛車輛的特定能力。

不過，這里還存在一個問題：通過測試任務，仍然不能說明被測系統具備了無人駕駛智能和駕駛能力。駕駛能力一般指的是完成某種特定駕駛行為的能力。完成一個特定的駕駛任務通常需要受試車輛具有多種駕駛能力。不同于場景和任務，每項駕駛能力可以被量化評估。進一步將各個能力進行匯總，即可定量評估整個無人駕駛車輛的駕駛能力。

在圖1所示的語義網絡中，沿著場景、任務直到能力之間的正向連接，我們可以從駕駛場景中梳理出具體駕駛能力，將能夠量化的駕駛能力指標進行細分和標準化，以便建立完備的測試體系。

而沿著從能力、任務直到場景之間的反向連接，我們可以根據功能測試需求，自動產生合理的駕駛任務乃至駕駛場景，解決測試配套的駕駛環境自動設計問題。待駕駛場景確定之后，便可以自動化虛擬生成配套駕駛環境，用于無人駕駛智能的仿真測試和實路測試。

3.3.2. 智能性測試中測試場景的生成

基于圖1，場景測試位于該語義網絡的左端，而功能測試位于該語義網絡的右端。我們提出的無人駕駛智能體系，實際上是將已有的兩種無人駕駛智能定義方式融為一體，相輔相成?；谏鲜龆x，我們可以進一步生成特定的測試場景。

生成測試場景，第一個要考慮的因素是，如何確定場景中所含有的任務，并確定這一系列任務的出現和需要完成的時間—空間位置。下圖2描述了一個非常簡單場景中，受試車輛A的若干不同任務在任務時空圖中是如何排布的。受試車輛需要在每個任務需要完成的截止時間和截止空間前完成該任務。同時下圖3描述了從抽象的測試場景到具體測試實例的轉換過程。

每個場景中的任務數目和時空排列決定了該測試場景的難易程度。任務數據越多越難，需要同時處理的任務數量越多越難。

*圖2. a） 一種典型的城市駕駛場景; b） 分配任務的時空排列; c） 隨時間變化的相應計算開銷

*圖3. 一個駕駛任務逐級細化的過程也就是對于任務空間的抽樣過程，包括逐級確定分配任務的時空排列和創建實例

3.3.3. 智能車智能性測試框架

在傳統汽車測試開發中我們經常使用V字型開發方法。如下圖所示，在這種方法中，人們在開發階段就定義了相應級別的測試用例。

*圖4. 傳統汽車測試V字形開發流程

V模型的第一階段是整體需求確認階段，在該階段與整體需求對應的測試用例也會提前定義。第二階段，第三階段分別是系統級別（High-Level-Design）以及子系統級別（Low-Level-Design）的設計和對應測試用力的書寫。在這兩個階段系統的功能會被分解細化，軟件中的各種類，以及類間關系會被定義。同時，也需要在這兩個階段書寫同樣級別的測試用例。第四階段是模塊設計，在這個階段，子系統會進一步分解成為小的模塊，對應的對于模塊的測試用例也會在這個階段定義完成。

如果把我們提出的測試方法和V模型一一對應，就能得到如下的Λ-V模型：不斷學習新示例，舉一反三，逐步完善任務描述。

*圖5. Λ-V模型測試框架

V模型對于傳統汽車研發這一類系統性和可推導性比較強的系統工程有較好的效果，但是由于我們需要在具體的編程之前就設計好所有的測試用例，這使得該模型在較為復雜的人工智能系統開發中很難直接套用。

我們認為，在開發智能系統過程中，機器學習和測試如同一個硬幣的兩面，智能性測試應該和機器學習有著類似的流程。

（a）

（b）

*圖6. 智能車測試框架

在平行學習的框架下，首先要解決的問題是如何獲取新的數據用來學習，該階段我們稱為描述性學習階段；在第二階段，會從第一階段中提取特定的數據有針對性的進行學習，從而獲得“小知識”，該階段我們稱為特定數據學習階段；第三階段是預測性學習階段，在該階段，會把前兩階段得來的數據和知識一一對應，這種聯系也會被記錄下來。最后，所有的新數據會在第三階段已有聯系的基礎上找到對應的“小知識”。

與此類似的，如圖6（b）所示，智能車的智能性測試也有著類似的流程。第一階段是創建新的測試任務。在這個過程中，在場景中的測試任務都會被逐步分解成為細化的功能。第二階段是在第一階段創建的測試任務中選取有挑戰性的部分（測試取樣）。最后一個階段是測試的執行，也就是在前兩個階段創建的任務中觀察智能車的表現。在這個階段，我們需要從測試結果中得到兩類關聯信息，第一類是車輛智能性和其在我們搭建的測試環境中的表現的關聯，這種關聯對于我們在新的測試任務中取樣有很大的幫助；第二種關聯是測試本身和測試環境的關聯，我們需要從不同的測試環境中學習到如何更好的創建測試任務。

我們提出了以上的智能性測試框架是基于以下考慮：

1） 如果不進行測試，我們無法預知智能車的行為表現。所以，在沒有測試之前，我們也無法確認哪些測試任務更加的具有挑戰性。所以我們需要通過不斷的測試，取樣，執行，分析這樣一個循環來達到最優的測試效果。

2） 測試本身就是一個自我標定的自循環過程，我們必須根據測試結果來判定車輛的智能性。

3） 如果測試要覆蓋所有的智能車的功能所需要的資源是巨大無比的，所以，我們需要一些更優的方法和工具來縮短這個過程。

3.3. 平行測試

3.3.1. 傳統虛擬仿真

目前很多研究人員都把更多的精力放在視覺領域的虛擬仿真，當然，也有人開始注意到駕駛員行為的重要性。在視覺領域的仿真中，有以下幾種圖像注入方式：1.采集真實的2D數據，然后基于該數據建立3D模型，再在此3D模型的基礎上上投影成2D的圖像注入智能車的感知系統；2.使用對抗式網絡生成新的2D模型注入； 3.基于以上兩種方法盡可能多的圖像注入。

3.3.2. 平行測試方法

我們這里提出一種新型的虛實結合的智能車平行測試方法。如圖7所示，車輛智能性測試可以分為三步：測試環境，測試規劃和測試執行。同樣，我們在虛擬世界里也能夠建立一一映射的測試流程。

圖7. 平行測試方法

1） 首先在真實環境下建立有多種交通元素（十字路口，交通燈）的場景，對應的在虛擬空間內，根據不同的測試目標，可以把該場景細分成不同的任務，功能團，單個功能；

2） 基于這種分解模式，可以建立相應的測試計劃來有針對性的測試不同的功能。例如假設我們要測試交通標示識別和變道這兩個功能團，很容易發現，交通標示識別重要性沒有那么高，而測試變道能更好的提升車輛的可靠性。在測算了場景中包含的任務，以及任務中包含的功能團之后，我們能選出包含更多的變道的任務來在真實環境中進行測試，而包含更多交通標志識別的任務可以在仿真環境中進行測試；

3） 一旦制訂了在真實和虛擬環境中的測試計劃，按照計劃執行之后對測試結果可信度以及功能重要性進行加權就能得到相應的加權分數。同時，在真實環境中得到的測試數據又能注入仿真環境，通過這種方式，仿真環境能夠不斷更新加強。真實環境和虛擬環境中的測試是異步的，我們可以在真實環境進行某一項測試的同時，在虛擬環境中進行多項測試。

和傳動的仿真測試環境相比，平行測試體系有如下兩個不同。

1. 平行的虛擬環境不僅僅是真實環境的一一映射，同時也和真實環境在狀態上存在交互，真實環境會影響虛擬環境，虛擬環境也會影響真實環境，這樣就形成了一個自我不斷增強系統；

2.平行系統是一種自我學習的系統，一些在虛擬環境中的關鍵元素是數據驅動型，這使得平行系統比那些基于隨機模型的系統要更加自動化，可信度也更高。

3.3.3. 平行測試實際應用

在江蘇省常熟市，這樣一個平行測試系統已經建立起來，并且很好的支持了2017年中國智能車未來挑戰賽。如圖8所示，我們先在虛擬環境中找到最具挑戰性的測試任務然后再在真實環境中進行測試。

圖8. 平行測試實際應用

4. 智能性測試的相關討論

4.1. 倫理道德問題

包括圖靈在內的大部分研究者都認為人能夠按照自己的經驗做出正確的決定，而智能機器也應該和人類一樣來完成這些決定，因此我們的工作就簡化成為在智能測試中去判斷智能機器是否完成了和人類一樣的決定。

但是在某些情況下，哪怕是人類也很難確定什么是正確的，例如著名的鐵軌問題：你是一輛剎車失靈的火車司機，在你前面的鐵軌上有5個人被綁在軌道上，你可以選擇切換到另外軌道，另外那條軌道上只有1個人綁在鐵軌上，那么請問你會選擇撞死5個人還是切換軌道撞死1個人？對于這個問題本文中不做更多的討論，即使是人類，在這個問題上都很難做出“正確的”決定，更何況智能機器？所以在本文中我們不去討論這些問題，我們也不會為倫理問題設置智能性測試。

4.2. 測試結果的自動實時分析

圖靈測試和現在很多新的智能測試的區別在于，圖靈測試用人來做判定，而新的智能測試使用的是機器來做判定。之所以這么做的原因在于我們清晰的定義了任務，同時很多情況下沒有機器的幫助人很難完成正確的判定。

以智能車測試為例，為了節約成本，我們往往在某一條測試路線上設置了多個測試任務，車輛需要不停歇的完成多個測試任務。

例如在中國智能車未來挑戰賽中就設置了14個測試任務，分別是U-Turn，通過T字型路口，通過十字路口，避讓作業車，隧道，停止標志，避讓行人，右轉，鄉村道路，避讓自行車，施工區域，限速，停車。車輛需要連續通過這些任務點，為了能夠自動測評，我們需要使用V2X設備連接車輛上的傳感器和數據中心，上傳車輛數據到數據中心來完成自動測評。

*圖9. 智能車比賽測試項

青島慧拓智能機器有限公司聯合清華大學一起開發了自動測評系統并成功應用于此次比賽中。如圖10所示，左邊展示的是正在比賽中的5輛車的實時軌跡和實時排名，右邊屏幕里是實時的視頻回傳數據，展示著裁判車數據，比賽車輛數據，以及場邊攝像頭數據。這些數據通過V2X或者4G的方式傳回數據中心。

在2009年-2015年的比賽中，比賽由裁判來人工打分，這種方式比較主觀，也非常耗時。在2017年比賽中，大部分的任務可以通過回傳過來的數據實現自動打分。我們同樣能夠通過深度學習的方式用視覺的方式來檢查車輛是否有壓線，來實現自動打分，如圖11所示。

*圖10. 智能車比賽實時評測

*圖11. 實時壓線檢測

4.3. 駕駛員在環測試

按照上文中說到，我們最終的目的是讓機器代替人來評價智能性測試結果。但是目前階段，這種情況卻難以完全實現。

首先，測試任務的描述需要由人類專家來完成。所有的任務描述都是使用人類語言，目前也并沒有一種計算機語言能夠更好的完成該任務。機器的智能水平往往受限于它的設計者，所以我們最終總是還是需要用人類的智慧來在衡量測試結果的基礎上提升機器的智能性水平。

其次，人類專家能夠按照自己的經驗更好的幫助機器設計那些極限的測試任務。

最后，人類是智能性測試的最后決策者，往往由機器做出的判斷還要由人類來檢查。就像在2017年中國智能車未來挑戰賽中視頻回傳系統就是方便人類專家隨時能夠監督智能車的表現，這能夠讓人類和自動打分系統同時以對方的判斷為基礎改善自己的評判能力。

4.4. 用測試來進行智能水平分級

SAE把汽車自動化水平分為從無自動化到完全自動化六個級別，但是在該分級體系中并沒有給出明確的需要完成的任務?，F在有更多人認為，只有明確了分級系統中的測試任務，才能更好的對汽車智能性水平進行分級。

智能機器在特定的領域越來越智能，甚至在某些領域（比如圍棋領域的阿法狗，射擊領域的Top Gun）已經超過了人類。也許在未來的某一天，機器能夠取代人成為智能性水平的最終定義者。

4.5. 可釋性測試

如同圖靈測試一樣，我們現在更多的關注智能機器的外在表現多于機器內部的運行機制。如果某智能機器通過了所有的測試任務，我們就承認了其在該領域的智能性。但是我們很難知道怎樣的外在表現是最優的。

當今的智能機器越來越復雜，我們很難完全搞懂其內部的算法（例如復雜的深度學習算法），這就類似于一個“黑盒子”。并且我們基于傳統可釋性邏輯制造出來的機器很難和這種“黑盒子”媲美，距今為止，很少有人能找出一種“內外兼修”的測試方法，這將是未來一個很重要的研究方向。

4.6. 智能性測試在智能機器軟件開發中的必要性

鑒于目前大部分AI的程序都是在電腦中通過編程完成，所以測試實現AI的軟件顯得尤為重要，所以我們需要建立一套完善的對這些軟件的測試體系。例如測試驅動型開發（TDD）就在當今工業界被廣為接受：TDD最基礎的思路是首先把需求分解轉換成相應的測試用例，然后不停的優化軟件讓其通過這些測試。在這種研發思路中，我們能很好的保證軟件的質量并能讓軟件有更好的可讀性。

目前在該領域最缺乏的是良好的測試和調試工具，這種對于AI軟件的測試工具市面上非常少。

4.7. 終生測試

就像前文所述的，現在有越來越多的方法來測試智能性，但是這些測試方法的落地還需要很長一段時間。我們把這一落地過程稱之為“終生測試”（Life-long Testing）。我們應該把AI機器的研發和測試當作一個整體來考慮，隨著測試的不斷深入，機器的智能性也會因此而提升。

在當今工業界，我們更多的是把多種“低級別”的簡單機器進行組合來制造“高級別”機器。很難想象，我們400年前只能制造一些很小的玩具，而如今我們卻有著十分復雜的GPU，CPU等。同樣的，我們相信在AI領域，也會是如此，會有更多的“高智能性”機器從“低智能性”機器中衍生而來，我們可以一起見證這一時刻的到來。

4.8. 測試的商業化

目前的AI革命正在極大的改變我們的生活，有很多人類的工作正在或者在不就的將來就會被機器代替。同時，新的AI領域也催生了一大批新的工作，智能性測試當然也在其中之列，例如我們現在需要非常多的人來標定視頻數據來訓練我們的深度學習模型。

5. 結論

本文主要討論了智能性測試的難點，并以此為基礎提出了智能性測試方法：智能性測試和機器學習的過程類似，兩者如同一個硬幣的兩面。并且我們提出了虛實結合的平行測試方法：首先在虛擬環境中描述測試任務，然后進行取樣，最后執行測試，通過這個流程我們能夠找到其中最難的測試任務；另外，虛擬測試需要平行的去執行，這樣可以幫助我們更好的找到更“真實”更“豐富”的測試數據集，這將極大的改善測試的效率和經濟性。

但是，“終生測試”將是一場持久戰，目前我們還沒有能夠找到一個脫離人能夠自己運行的虛實結合的平行測試系統，我們相信，這一天遲早會到來。