基於人工智慧的系統，也稱為神經網路（NN Neural Networks），和其他應用程式一樣是 "系統"，因此需要測試。本文將指導你測試AI和基於NN的系統，並理解相關概念。
測試人工智慧系統的不同之處是什麼？
"傳統 "的軟體是建立在內部確定的演算法基礎上的。例如，對於將攝氏度轉換為華氏度的系統，它將使用簡單的F=1.8C+32公式。
人工智慧用於 "公式 "未知的情況，但你有足夠的輸入和輸出的例子，可以根據例子來估計公式。
最終，人工智慧並不創造公式，而是根據以前的知識創造一個決策網路。如果人們知道這個公式，那麼用人工智慧來解決這個問題的價值就非常小。
我們能一直使用一個公式嗎？比如，這幅畫裡是一隻企鵝嗎？沒有簡單的公式來確定圖片中的企鵝是什麼樣子。有無窮無盡的 "企鵝圖片 "的例子，它們的大小、位置、顏色、燈光、型別等都不一樣。
人工智慧實際上是模仿人腦在訓練方面的運作方式，並根據以前學到的例子給出最佳猜測（即準確性）。對於人類，我們將判斷 "企鵝 "的能力視為我們智力的一部分。
就像人類一樣，AI也會犯錯或被欺騙。這就是 "測試AI "發揮作用的地方。看一下上面和下面的例子。這是一隻企鵝，或者，如果你倒過來看，也許是一隻長頸鹿？
測試AI應用： 重要的考慮因素
- 準確度
人工智慧會給出具有一定準確性的結果。對於積極的結果，獲得100%的準確性是非常罕見的，對於消極的結果，獲得0%的準確性也是非常罕見的。
好的人工智慧將在和作為正數和絕對準確率（100%）的因素之間有一個明顯的delta。當你在測試時，你會得到不同程度的準確性。這很正常，但如果你在物件A上得到99.99%的陽性結果，而在物件B上得到98%的陰性結果，要確定哪個是陽性，哪個不是，可能會有問題。
99%並不總是比90%好。它是相對於其他結果而言的。如果陽性是80%，陰性是30%及以下，你的人工智慧是可以的。如果正數高於99%，負數低於98%，那就有問題了，要確定。永遠不可能測試所有的輸入，所以測試者的作用是確定人工智慧的質量。
- 靜態或動態
靜態人工智慧是 "按原樣 "提供給應用程式的。在更新之前，它將有相同的輸入結果。靜態人工智慧通常由外部供應商提供。例如，你的應用程式可能使用由第三方提供的影像識別或NLP引擎。
從測試的角度來看，靜態人工智慧主要是作為開發過程的一部分（作為驗收）和作為版本釋出的理智測試的一部分來測試的，這一點很重要。但是，由於是靜態的，開發人員和測試人員並不真的需要反覆測試它們。無論你現有的OEM策略是什麼，包括外部第三方元件，它應該是測試靜態AI的相同策略。
動態人工智慧正在不斷改進自己。它的開始方式與靜態人工智慧相同，但一旦釋出，經過驗證的輸出會再次注入人工智慧，作為額外的 "教學資料"，以提高準確性。這與我們大腦的工作方式非常相似。
與我們的大腦一樣，更多並不總是更好。"改進 "可能會對人工智慧產生負面影響，測試人員應始終執行 "生產測試"，以確保人工智慧確實在改進，或至少保持它過去的樣子。
要做到這一點，要使用一組靜態的測試資料和準確率數字（如果有的話）。你可以使用與開發原始人工智慧時相同的20%的測試資料，因為它不是教學資料的一部分。測試資料應該產生相同或更好的結果。節奏通常與教學資料的增長百分比有關。一個好的起點是1%。
例如，如果原始的人工智慧教學資料是100,000個輸入點，每引入一個新的1000個額外的資料來改進人工智慧，執行測試資料並檢查其結果。小於1%可能不會對AI值產生重大影響。
- 單NN還是多NN？
這是一個非常重要的問題，可能會很難理解。讓我們以一個聊天機器人為例。聊天機器人可能是基於訊息平臺或語音平臺的。在語音平臺的情況下，在用於確定對話背景的任何NLP之前，有一個基於NN的語音到文字。
這意味著，這裡有兩個NN在起作用。在某些情況下，這可能是很棘手的。例如，一個碰撞檢測系統可能使用人工智慧來分析基礎影像，並使用相對簡單的演算法來確定是否可能發生碰撞。
在大多數多NN的情況下，你實際上只測試一個NN，你依靠其餘的NN來提供基本資訊。
- 虛假或欺詐：人工智慧的安全
幾乎在所有情況下，人工智慧都有潛在的攻擊載體，可以用來進行欺詐。在相關的研究中，有人舉了一個例子，"紅色交通燈 "+額外的11個白色畫素可以被確定為 "烤箱"。
即使影像的輕微變化也會使人工智慧感到困惑，使其容易受到欺詐。
為了更好地確定你的測試需求，請考慮以下幾點：
1.我是否期待欺詐輸入？為什麼？
例如，在上面的例子中，如果有人想造成車禍，他可能會使用上述的異常情況來欺騙一個特定的交通燈。
然而，對於聊天機器人來說，如果輸入沒有被正確識別，其結果很可能在本質上不是欺詐性的。這意味著，你可以造成錯誤的識別，但出於什麼原因？
2.錯誤檢測的代價是什麼？
在交通燈的例子中，無論是否有欺詐行為，不良檢測的結果可能是災難性的。它可能是由有邪惡意圖的人或幾滴雨造成的。好的測試應該檢測出這樣的異常情況，因為錯誤的檢測可能會帶來很高的成本。
在你的聊天機器人的例子中，錯誤的檢測通常會導致一個 "對不起，我沒有收到 "的回應，除了一個惱人的介面，沒有任何傷害。雖然你顯然想確保將錯誤檢測降到最低，但錯誤檢測的成本並不是災難性的。
3.系統是自主的還是不自主的？
在大多數情況下，自主系統的錯誤檢測的成本更高。它並不總是像上面的交通燈例子那樣與生命對待的情況有關。但它仍然可能導致高成本。
一個錯誤的車牌檢測可能意味著停車場障礙物不會及時升起，或者一個司機可能被錯誤地收取收費公路的費用。
如果系統的FLOW包括一個可以 "修復 "人工智慧錯誤的人，錯誤檢測的成本通常會低很多。
- 可能的輸入數量
在大多數情況下，人工智慧被用於可能的輸入數量非常大或幾乎是無限的地方。例如，在一個用於確定給定圖片是否是企鵝的系統中，根據定義，可能的輸入是 "任何圖片"。
實際上，瞭解有多少個可能的輸入並不重要。而且很明顯，你不可能對所有的人進行測試。需要的是確定一個可靠的測試資料策略。
1.測試輸入的數量
有幾個因素可以幫助減少測試輸入的數量。
你有興趣測試的輸入
之前，我們討論了多層NN。例如，如果你的系統是依靠計算機視覺（CV）元件來識別物體（例如，返回給定圖片中的動物列表的系統），你其實不需要太多或者太頻繁地測試這個元件。而且它可以大大減少輸入的列表，即 "動物列表"。
2.邏輯分組
NN是以這樣的方式建立的，它們根據輸入的低階值來分組。這可能解釋起來太複雜了，但如果我們正在搜尋企鵝，可能的分組可能是 "非動物"、"其他動物 "或 "企鵝"。繼續關注上下文，如果你的系統應該檢測企鵝，那麼 "椅子 "和 "桌子 "之間就沒有什麼區別，也就是說，測試所有的傢俱沒有意義。
其他分組可以是照明條件、尺寸、位置、顏色等等。
3.向量
NN往往對輸入的輕微變化很敏感。如果你對這些型別的測試很敏感（即主要是自主系統），可以增加一些透過某個引數迴圈的測試。例如，相同的影像，但有不同的照明條件。
這對非CV、非音訊輸入也有幫助。例如，如果NN引數是年齡，試著以單日的頻率給出日期的向量。
3.欺騙系統
你的 "錯誤檢查 "的一部分應該包括噪音水平測試，這包括帶有額外噪音水平的正面輸入，如影像噪音、音訊噪音等。
注意點
雖然人工智慧測試似乎不能自動化，但事實並非如此。如果給予客觀的測量，大多數測試可以自動化。
- 如果你有一組已知的輸入，並有一組已知的輸出（即使這些是數字的範圍），它可以被自動化。
- 如果你坐在系統前面，思考如何使系統失敗，你就做錯了事。
- 如果你做了一次，它可以被新增到已知的輸入和輸出中。
- 人工智慧不被認為是重在處理。雖然有許多可能的輸入，但人工智慧是極其最佳化的，通常人工智慧的決定應該花費很少的時間（在許多情況下，以毫秒或更少的時間衡量）。
- 如果測試花費太多時間，你可能會推遲CI週期，所以考慮每天和每週的週期。然而，只有在你受到效能不佳的影響時才做出這個決定，而不是在之前。如前所述，人工智慧處理通常非常快。
ML和AI自動化工具
差異化的工具
利用AI和ML演算法的工具旨在積極主動地自動識別程式碼質量問題、迴歸、安全漏洞等。這是透過程式碼掃描、單元測試自動建立等方式完成的。
如果你的團隊缺乏解決上述目標的技能，或者沒有時間持續解決這些任務，請考慮其中一些選項。其結果將是更快的釋出，透過減少逃逸的缺陷來提高質量，以及提高開發人員的生產力。
- Facebook Infer
- Launchable
- DiffBlue
- Google OSS-Fuzz
讓我們以DiffBlue為例來看看。DiffBlue連線到你的原始碼控制庫（Git、Perforce等），並透過人工智慧自動建立單元測試的基礎線。一旦發現迴歸，就會丟擲一個標誌，報告這個問題。DiffBlue建立其解決方案的動機主要是透過幫助那些不喜歡自己建立測試的開發者來提高程式碼質量。
Launchable在程式碼拉動請求時自動檢視程式碼，並執行一種程式碼影響分析，以適應最近的程式碼變化。然後，它只選擇你的迴歸套件中最相關的子集，以節省時間來批准程式碼更改並將其整合到管道中。
最後，Facebook的Infer專案也透過其AI演算法實現更好的程式碼質量。
來自Facebook的人工智慧引擎可以自動發現Android和Java程式碼中的空指標異常、記憶體洩漏、併發競賽條件等。同樣，它也可以在C、C++和iOS/Objective C程式碼中找到同樣的問題以及錯誤的編碼習慣或不可用的API。
視覺AI自動化工具
相對於差異化的工具，視覺測試解決了使用者體驗層的測試，並在數字平臺（主要是移動和網路）上擴充套件了驗證和UI（使用者介面）的外觀和感覺。
視覺化人工智慧測試工具解決了UI層不斷變化的痛苦，加上不斷增加的平臺、螢幕尺寸和配置，使得測試覆蓋率成為測試工程師和開發人員的噩夢。
屬於這個類別的一些AI/ML工具有：
- Applitools
- Percy.io
對於Applitools和Percy，開發者和/或測試工程師需要將SDK或程式碼片嵌入測試自動化（Selenium，Appium，其他），以建立網路/移動應用程式的視覺基線。在測試平臺內的所有目標平臺上進行下一步執行時，工具將突出實際和基線之間的差異，將責任轉交給測試所有者，以報告一個缺陷或忽略這個問題。
宣告式工具
宣告式工具與其他工具有不同的使用情況，但仍然旨在提高測試自動化的生產力和穩定性。利用ML和AI的宣告式工具具有與NLP、DSL、RPA(robotic process automation)和MBTA方法相關的重要能力。
這些方法之間的共同點是透過智慧自動化消除繁瑣的、容易出錯的、重複的動作。雖然在這個類別中，我們列出了RPA，但這種特定的方法並不只是圍繞著測試的自動化，也是圍繞著人工完成的過程和任務的自動化。
專注於宣告性測試，我們可以把以下工具作為一個例子：
- Functionize
- Tricentis
- UIPath
- Automation Anywhere
這些只是不斷變化的市場中可用工具的一個子集。而且上述每個工具都有不同的方法來使用AI建立測試自動化。
例如，Eggplant AI使用的模型是模仿被測試的應用程式而建立的，然後AI引擎自動透過模型流並建立測試自動化場景。
即使是人工智慧，測試工程師也需要考慮維護，隨著時間的推移，測試資源的管理，以及規模的執行。如果這樣的工具支援所有這些，那就很好，否則可能會有顛簸。
上面列出的其他工具，特別是Functionize，指定利用NLP來建立測試自動化指令碼，不需要任何編碼技能或開發語言。
這種工具型別的主要好處如下
- 快速的測試自動化建立。
- 不需要編碼技能。
- 更快地維護測試自動化方案。
這類工具的缺點是：
- 不涉及編碼技能/程式碼。
- 與工具鏈和DevOps CI/CD管線的整合有問題。
- 版本管理和測試管理能力。
自我修復的工具
如果我們要說出人工智慧和ML在測試自動化領域出現的首要原因之一，那就是由於測試自動化的鬆散性、可靠性和維護。
基於程式碼的測試自動化在本質上不太穩定。它需要不斷調整每個平臺或環境，其整個基礎是應用程式物件。這些物件往往每隔幾周就會改變，或者最壞的情況是它們的使用效率低下（例如XPATH與Object ID等）。
為此，一個新時代的工具已經發展起來，測試維護由機器學習來協助。在這些工具中，主要的ML引擎存在於記錄指令碼的自我修復中。
有些工具就像安裝網路瀏覽器外掛一樣簡單（Mabl, Testim）。一些用機器學習輔助測試維護的工具能力更豐富，並被整合到一個端到端的持續測試解決方案中（Perfecto, Tricentis）。
- Perfecto
- Mabl
這些工具的核心是一個ML演算法，在每次執行時和執行之間 "學習 "被測網站和/或應用程式。它根據可靠性和成功找到的機率，對應用程式中每個螢幕的元素定位器進行評分。
報告和分析工具
測試資料來自多個來源：測試自動化工程師、開發人員、安全和運營工程師、分析人員和其他人。團隊需要能夠理解所有這些來源，並快速做出資料驅動的決定。
報告中的ML有助於對資料進行分類，對其進行切片和切塊，在高階情況下，還可以自動對失敗的根本原因進行分類，提高團隊的生產力。
- Perfecto
- ReportPortal
透過採用利用ML的報告解決方案，團隊可以不必擔心資料的大小，讓機器為他們自動分類，這就消除了管道中的噪音，這樣他們就可以更快地釋出，並充滿信心。
原文 https://www.softwaretestinghelp.com/database-testing-process/
相關python書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
為了讓人、流程和技術在有效的協調和規模下無縫工作，我建議你從小處著手，確定應用人工智慧/ML的關鍵場景。調整工具以補充不同角色的技能，如業務測試人員和開發人員。而且一定要了解你如何擴大測試自動化套件的規模，並連線到CI/CD。