答案是：需要的。與傳統測試相對，後者測試物件、方法、策略存在較大差異。由傳統的對被測物件的實際結果與明確的期望結果驗證，轉向了基於測試集資料設計的演算法模型指標驗證及結果分析。

隨著人工智慧的快速發展與應用，如OCR識別、推薦演算法、目標檢測演算法等等。演算法測試也逐漸進入到軟體測試行業的視野之中，傳統的功能測試策略對於演算法測試而言，難以滿足對人工智慧 (AI)產品的質量保障，對測試提出了更高的要求。

結合在人臉檢測、檢索演算法上的測試探索、實踐的過程，本文將從以下幾個方面介紹人工智慧 (AI) 演算法測試策略。

演算法測試集資料準備演算法功能測試演算法效能測試演算法效果測試（模型評估指標）演算法指標結果分析演算法測試報告

我們將演算法測試測試流程中的幾個核心環節提煉如上幾點，也就組成了我們目前演算法測試的測試策略。

演算法測試集資料準備

測試集的準備對於整體演算法測試而言非常重要，一般測試集準備過程中需考慮以下幾點：

測試集的覆蓋度測試集的獨立性測試集的準確性

測試集的覆蓋度

如果，測試集準備只是隨機的選取測試資料，容易造成測試結果的失真，降低演算法模型評估結果的可靠性。

好比我們的功能測試，根據功能測試設計，構造對應的資料進行測試覆蓋。演算法測試亦然，以人臉檢測演算法而言，除了考慮選取正樣本、負樣本外，還需要考慮正樣本中人臉特徵的覆蓋，如人臉佔比、模糊度、光照、姿態（角度）、完整性（遮擋）等特徵。

選擇好對應的測試資料後，後來後期的指標計算、結果分析，還需對資料進行標註，標註對應的特徵，以人臉檢測為例，使用工具對人臉圖示進行人臉座標框圖，並將對應特徵進行標註記錄及儲存，如下圖。

另外，除了資料特徵的覆蓋，也需要考慮資料來源的覆蓋，結合實際應用環境、場景的資料進行資料模擬、準備。比如公共場所攝像頭下的人臉檢索，圖片一般比較模糊、圖片光照強度不一，因此準備資料時，也需要根據此場景，模擬資料。一般來講，最好將真實生產環境資料作為測試資料，並從其中按照資料特徵分佈選取測試資料。

此外，關於測試資料的數量，一般來講測試資料量越多越能客觀的反映演算法的真實效果，但出於測試成本的考慮，不能窮其盡，一般以真實生產環境為參考，選取20%，如果生產環境資料量巨大，則選取1%~2%，或者更小。由於我們的生產環境資料量巨大，考慮到測試成本，我們選取了2W左右的圖片進行測試。

測試集的獨立性

測試集的獨立性主要考慮測試資料集相互干擾導致測試結果的失真風險。

我們以人臉檢索為例，我們準備200組人臉測試資料，每組為同一個人不同時期或角度的10張人臉照片，對人臉檢索演算法模型指標進行計算時，如計算TOP10的精確率，此時若在資料庫中，存在以上200組人的其他照片時，便會對指標計算結果造成影響，比如我們200組人臉中包含Jack，但資料庫中除了Jack的10張，還存在其他的8張Jack的照片。若演算法微服務介面返回的TOP10圖片中有我們測試集中的Jack圖片6張，非測試集但在資料庫中的其他Jack照片2張，還有2張非Jack的照片，測試的精確率該如何計算，按照我們的測試集（已標註）來看，精確率為60%，但實際精確率為80%，造成了精確率指標計算結果的失真。

測試集的準確性

資料集的準確性比較好理解，一般指的是資料標註的準確性，比如Jack的照片不應標註為Tom，照片模糊的特徵不應標註為清晰。如果資料標註錯誤，那麼直接影響了演算法模型指標計算的結果。

對於測試集的準備，為了提高測試集準備效率及複用性，我們嘗試搭建了演算法數倉平臺，實現資料（圖片）的線上標註、儲存等功能，作為演算法測試資料的同一獲取入口。

同時測試集一般也包含資料清洗操作，資料清洗是為保障後續模型評估指標結果、指標分析、特徵分析的有效性，降低垃圾資料、干擾資料的影響。

演算法功能測試

以我現在接觸的人工智慧系統而言，將演算法以微服務介面的形式對外提供服務，類似於百度AI開放平臺。

因此需要對演算法微服務介面進行功能性驗證，比如結合應用場景從功能性、可靠性、可維護性角度對必填、非必填、引數組合驗證等進行正向、異向的測試覆蓋。此處不多做介紹，同普通的API介面測試策略一致，結合介面測試質量評估標準，大概從如下幾個角度進行設計：

業務功能覆蓋是否完整業務規則覆蓋是否完整引數驗證是否達到要求(邊界、業務規則)介面異常場景覆蓋是否完整效能指標是否滿足要求安全指標是否滿足要求演算法效能測試

微服務介面的效能測試大家也比較瞭解，對於演算法微服務同樣需要進行效能測試，如基準測試、效能測試（驗證是否符合效能指標）、長短穩定效能測試，都是演算法微服務每個版本中需要測試的內容，同時產出版本間的效能橫向對比，感知效能變化。常關注的指標有平均響應時間、95%響應時間、TPS，同時關注GPU、記憶體等系統資源的使用情況。

一般使用Jmeter進行介面效能測試。不過，我們在實際應用中為了將演算法微服務介面的功能測試、效能測試融合到一起，以降低自動化測試開發、使用、學習成本，提高可持續性，我們基於關鍵字驅動、資料驅動的測試思想，利用Python Request、Locust模組分別實現了功能、效能自定義關鍵字開發。每輪測試執行完演算法微服務功能自動化測試，若功能執行透過，則自動拉起對應不同執行策略的效能測試用例，每次測試執行結果都進行儲存至資料庫中，以便輸出該演算法微服務介面的不同版本效能各項指標的比較結果。

演算法模型評估指標

首先，不同型別演算法的其關注的演算法模型評估指標不同。

比如人臉檢測演算法常以精確率、召回率、準確率、錯報率等評估指標；人臉檢索演算法常以TOPN的精確率、召回率、前N張連續準確率。

其次，相同型別演算法在不同應用場景其關注的演算法模型評估指標也存在差異。

比如人臉檢索在應用在高鐵站的人臉比對（重點人員檢索）的場景中，不太關注召回率，但對精確率要求很多，避免抓錯人，造成公共場所的秩序混亂。但在海量人臉檢索的應用場景中，願意犧牲部分精確率來提高召回率，因此在該場景中不能盲目的追求精準率。

除了上述演算法模型評估指標，我們還常用ROC、PR曲線來衡量演算法模型效果的好壞。

我們在演算法微服務功能、效能測試中介紹到，使用了基於關鍵字驅動、資料驅動的測試思想，利用Python Request、Locust模組分別實現功能、效能自定義關鍵字開發。考慮到測試技術棧的統一以及可複用性，我們基於上述設計，實現了演算法模型評估指標的自定義關鍵字開發，每次執行輸出相同測試集下的不同版本模型評估指標的橫向比較。

當然除了不同版本的比較模型評估指標的比較，如果條件允許，我們還需要進行一定的競品比較，比較與市場上相同類似的演算法效果的差異，取長補短。

演算法指標結果分析

我們對演算法模型指標評估之後，除了感知演算法模型評估指標在不同版本的差異，還希望進一步的進行分析，已得到具體演算法模型的最佳化的最佳化方向，這時候就需要結合資料的標註資訊進行深度的分析，挖掘演算法優劣是否哪些資料特徵的影響，影響程度如何。比如透過資料特徵組合或者控制部分特徵一致等方式，看其他特徵對演算法效果的影響程度等等。

這時候我們一般透過開發一些指令碼實現我們的分析過程，根據演算法微服務介面的響應體以及資料準備階段所標註的資料特徵，進行分析指令碼的開發。

另外指標結果的進一步分析，也要結合演算法設計，比如人臉檢索演算法，每張圖片的檢索流程為“輸入圖片的人臉檢測“ -> “輸入圖片的人臉特徵提取“ -> “相似特徵檢索“，透過此查詢流程不難看出人臉檢索的整體精確率受上述三個環節的影響，因此基於指標結果的深度分析也需要從這三個層次入手。

演算法測試報告

一般演算法測試報告由以下幾個要素組成：

演算法功能測試結果演算法效能測試結果演算法模型評估指標結果演算法指標結果分析

由於演算法微服務測試的複雜度相對普通服務介面較高，在報告注意簡明扼要。