基于人工智能的系統，也稱為神經網路（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，
釘釘或微信號: pythontesting 微信公眾號：python測驗開發1024轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/550454.html
標籤：其他