例如我們公司在特征抽取算法上就提供了近百個特征抽取的接口，可以根據不同的情況使用不同的方式提取數據中的特征。 數據拆分也有很多種不同的拆分方法，按隨機拆分，分層拆分，規(guī)則拆分。

每個子模塊都會提供一些接口供上層調用。 所以既然提到接口層面的東西了，大家應該都知道怎么測了吧。 只不過有些接口并不是http或者RPC協(xié)議的。 有時候需要我們在產品的repo里寫測試用例。

訓練集與測試集對比

這是我們的第三種測試思路。 我們剛才一直用來舉例的分類算法是一種監(jiān)督學習。 什么是監(jiān)督學習呢，就是我們的歷史數據中是有答案的。還拿剛才的反欺詐的例子說，就是我們的數據中都有一個字段標明了這條數據是否是欺詐場景。 所以我們完全可以把歷史數據拆分為訓練集和測試集。將測試集輸入到模型中以評價模型預測出的結果的正確率如何。所以每次版本迭代都使用同樣的數據，同樣的參數配置。 統(tǒng)計模型效果并進行對比。當然這種測試方式是一種模糊的方式。就如我再剛開始說的一樣，這種方式無法判斷問題出在哪里。是bug，還是參數設置錯了？我們無法判斷。

常見的測試場景

1.自學習

幾乎所有的人工智能服務都必須要支持自學習場景。就像阿爾法狗一樣，它輸了一局，就會從輸的這一局中學習到經驗，以后他就不會那么下了，這也是機器學習恐怖的地方，它會變的越來越無懈可擊，以前人類還能贏上一局，但是未來可能人類再也贏不了阿爾法狗了。 做法就是我們的數據每天都是在更新的，用戶行為也是一直在變化的。所以我們的模型要有從最新的數據中進行學習的能力。

上面是常見的自學習場景流程圖。假如我們用歷史上n天的數據訓練出一個模型并發(fā)布成了一個預測的服務。 那么到了隔天的時候。我們拋棄之前第一天的數據，使用第二天到第n+1天的數據重新訓練一個模型并代替之前的模型發(fā)布一個預測服務。這樣不停的循環(huán)，每一天都收集到最新的數據參與模型訓練。 這時候大家應該明白該測試什么了。每天收集到的新數據，就是測試重點。就是我們剛才說的第一種測試思路，使用spark，Hbase這些技術，根據業(yè)務指定規(guī)則，掃描這些數據。一旦有異常就要報警。

2.預測服務

下面一個場景是預測服務的。預測服務的架構一般都滿復雜的，為了實現(xiàn)高可用，負載均衡等目的，所以一般都是標準的服務發(fā)現(xiàn)架構。以etcd這種分布式存儲機制為載體。 所有的預測服務分別以自注冊的方式來提供服務。

上面的一個圖是一個比較流行的預測服務的架構。當然我做了相應的簡化，隱去了一些細節(jié)。所有的部署任務由master寫入ETCD。 所有agent以自注冊的方式將自己的信息寫入ETCD以接受master的管理并執(zhí)行部署任務。 而router也同樣讀取etcd獲取所有agent提供的預測服務的信息并負責負載均衡。 有些公司為了做高可用和彈性伸縮甚至將agent納入了kubernetes的HPA中進行管理。由此我們需要測試這套機制能實現(xiàn)他該有的功能。例如：

·router會按規(guī)則把壓力分發(fā)到各個agent上。

·把某個agent的預測服務被kill掉后，router會自動切換。

·預估服務掛掉，agent會自動感知并重新拉起服務。

·agent被kill掉后，也會被自動拉起。

·如果做了彈性伸縮，需要將預測服務壓到臨界點后觀察系統(tǒng)是否做了擴容等等。

性能測試