專家系統的測試策略不可驗證

---專家系統給測試和測試人員帶來了不同的挑戰.

我們日常接觸到的軟體大多為通用軟體或者企業應用, 使用起來比較簡單, 易於理解. 與之對應的, 有一類軟體我們稱之為專家系統, 它們協助某個領域的專家來做出判斷和決策. 比如地質監測, 天氣預報, 還有我們經常在電影裡看到的科學家使用的各種模擬軟體: 龍捲風災難模擬, **教授的分子化學和新藥品實驗等.

直觀的感覺, 這類軟體已經與我們日常使用的軟體不同. 具體一點, 我們從軟體測試的角度來來理解一下專家系統帶給我們的不同於通用軟體的挑戰:

沒有找到太多這方面的資料, 僅就以往經驗和微博上的討論做些總結.

1. 測試問題本質上是設計問題. 可測試性是很重要的設計約束. 表示邏輯和業務邏輯的分離，在複雜系統中更顯必要和迫切. 所有的計算和推理的演算法，都應該是ui無關的. ui只負責處理使用者輸入和顯示計算結果. 這樣從測試的角度來看，核心邏輯可以不需要通過ui來測，那基於ui的測試的重點就可以轉移到驗證使用者互動而不是業務相關的邏輯. 這是我們一直推崇的, 但其它型別應用中ui測試的方便性降低了對它需求的迫切性.

2. 測試問題本質上還是知識問題. 測試人員必須具備判斷對錯的知識. 這看起來是常識, 但在專家系統的測試中，這一點並不總是被很好的滿足的. 軟體規模較小的時候, 我們可以通過教會專家程式設計讓他們自己來編寫自己需要的軟體. 軟體規模較大的時候，我們可以招聘相關專業的從業人員人員而不是軟體專業的人來幫助測試. 如果這些條件都不滿足的話，我們只能培訓目前的測試人員讓他們掌握領域知識了.

3. 專家系統演化的乙個約束是它的計算結果不應該變差, 要麼不變，要麼越來越精確. 這給了基於基準的測試(benchmark)乙個可能. 在軟體穩定執行一段時間之後, 我們可以收集一組使用者認為正確的輸入輸出，作為基準, 後續版本的改動不應該產生不一樣的結果, 除非改的就是演算法本身. 這是某種形式的regression, 但它的應用場景相對有限, 畢竟專家系統的核心就是演算法, 新feature大都是演算法的enhancement. 這樣基準測試就不work了.

4. 那麼好，演算法的測試如何做？我覺得這是專家系統測試最困難的部分. 困難在於演算法的輸入空間和結果空間是很廣泛的, 並且實際演算法的輸入和輸出之間的關聯不像求平方或斐波納契序列那樣明顯，好訊息是在現在的計算機體系結構中, 演算法總是確定的, 規範的, 即給定輸入, 你總是能得到相同的輸出. 這還是乙個設計問題：小處來講，演算法的分解；大了說，體系結構，比如知識庫和推理機的職責劃分. 簡單的數學公式的實現我們總是可以測的. 如果能把複雜演算法分解為簡單演算法的組合，我們至少可以保證每一步測試的直觀性和可理解性

這裡有乙個重要的區別: 驗證演算法本身的正確性和實現的正確性.

演算法本身可能是純數學的, 與程式設計無關的, 是solution，而不是implementation. 這個意義上的正確性超出了我們今天討論的範圍, 它應該由專家來保證. 在微博討論中提到的根據歷史資料來測試演算法的方法, 測的就是演算法本身, 而不是演算法的實現. 我們focus在實現的正確性上. 幾個具體的策略.

結論：附: 專家系統介紹

根據維基百科:

"專家系統是早期人工智慧的乙個重要分支，它可以看作是一類具有專門知識和經驗的計算機智慧型程式系統，一般採用人工智慧中的知識表示和知識推理技術來模擬通常由領域專家才能解決的複雜問題。

一般來說，專家系統=知識庫+推理機，因此專家系統也被稱為基於知識的系統。乙個專家系統必須具備三要素：

領域專家級知識

模擬專家思維

達到專家級的水平

專家系統適合於完成那些沒有公認的理論和方法、資料不精確或資訊不完整、人類專家短缺或專門知識十分昂貴的診斷、解釋、監控、**、規劃和設計等任務。一般專家系統執行的求解任務是知識密集型的. "

網上找到的乙個專家系統的圖:

專家系統的測試策略不可驗證

專家系統的測試策略不可驗證

Eresye 專家系統的最佳開發工具

人工智慧專家系統的簡單實現

專家系統的測試策略 不可驗證

專家系統的測試策略 不可驗證

Eresye 專家系統的最佳開發工具

人工智慧專家系統的簡單實現

相關推薦

專家系統的測試策略不可驗證

專家系統的測試策略不可驗證