被炒上天了的AI，嗨得太離譜！

作者| Mush Honda

策劃| 雲昭

去年年底，彷彿一夜之間，人工智慧又嗨起來了，先是DALL-E 2 的生成圖像惟妙惟肖，那副「騎馬的太空人」讓人過目難忘，緊接著是Stable Diffusion 這個文本生成圖像的公開版權的作圖AI，最後的「王炸」：出道即巔峰的ChatGPT，給OpenAI 賺足了面子。甚至在春節期間，許多網路人都在感嘆“岌岌可危”，生怕這波人工智慧的高潮，真要搶走飯碗了。然而，現實真的會這樣嗎？ AI 會讓電腦應用軟體迎來復興時刻嗎？本文以一個具體的領域應用為例，闡述 AI 被工具化的三個階段，並說明 AI 不應該，也不可能發展成完全自主的幾點理由。此外，筆者也分享了真正的 AI 角色應該是怎麼樣的。我們需要警惕，但無須驚慌。

「有了人工智慧，交付時間將從幾分鐘減少到幾秒鐘！」「供應商和客戶將重回到廉價和用戶友好的體驗的時代，計算機應用軟體將迎來復興時刻！」

可打臉的是，廉價的儲存空間、高速的處理速度、隨時可用的AI 訓練設備以及網路已經將這一承諾變成了誇大其詞的炒作。

以軟體測試為例，搜尋“人工智慧在軟體測試中的應用”，系統會返回一系列向潛在買家承諾的“神奇”的解決方案。許多解決方案提供了減少手工勞動、提高品質和降低成本的方法。有些奇葩的是，有些廠商承諾他們的AI 方案能完美解決軟體測試問題，用詞更是驚掉下巴——軟體測試的「聖杯」ーー想法是這樣說的ーー就是把人們從伴有困難和煩惱的軟體開發循環中解脫出來，使測試週期更短、更有效、更簡單。

AI 真可以化身為萬能的「聖杯」嗎？而且，我們也該讓 AI 全取代人類嗎？這些近乎荒誕的炒作，實在是該歇歇了。

1、現實的真相

在現實世界中，將人類排除在軟體開發過程之外要複雜得多，也令人望而生畏。無論使用瀑布、快速應用開發、DevOps、敏捷和其他方法，人們仍然是軟體開發的中心，因為他們定義了他們創建的軟體的邊界和潛力。在軟體測試中，由於業務需求通常不明確且不斷變化，所以「目標」總是在變化。使用者要求改變可用性，甚至開發人員對軟體可能性的期望也會改變。

軟體測試的最初標準和方法(包括術語品質保證)來自製造產品測試領域。在這種情況下，產品是定義良好的，二者相比，測試更加機械化，但軟體的特性是可塑的，並且經常變化。軟體測試不適用於這種保證品質的統一的機器方法。

在現代軟體開發中，許多事情是開發人員無法預料和知悉的。例如，使用者體驗(UX)期望可能在軟體的第一次迭代之後就已經改變了。具體的例如：人們對更快的螢幕載入時間或更快的滾動需求有更高的期望、用戶不再想要冗長的向下滾動螢幕，因為它不再流行。

種種原因表明，人工智慧永遠無法獨自預測或測試，連它的創造者都無法預測的東西。所以在軟體測試領域，不可能有真正自主的人工智慧。創建軟體測試「終結者」可能會激起吃瓜者和潛在買家的興趣，但這種部署注定是海市蜃樓。相反，在人工智慧與人類協同工作的背景下，軟體測試自主性更有意義。

2、AI需要經歷三個成熟階段

#軟體測試AI 開發，基本上分為三個成熟的階段:

• 操作階段（Operatinal）
• 過程性階段（Process）  
• 系統性階段（Systemic）

目前絕大多數基於人工智慧的軟體測試都處於操作性階段。最基本的操作測試包括建立模仿測試人員執行數百次的例程的腳本。這個例子中的「AI」遠遠不夠智能，它可以幫助縮短腳本創建、重複執行和儲存結果。

過程性 AI 是操作性 AI 的一個更成熟的版本，測試人員使用流程 AI 進行測試產生。其他用途可能包括測試覆蓋範圍分析和建議、缺陷根本原因分析和工作量估計，以及測試環境最佳化。過程 AI 還可以促進基於模式和用法的合成資料創建。

過程性 AI 的好處顯然易見，它提供了一雙額外的“眼睛”，以抵消和對沖掉測試人員在設置測試執行策略時所承擔的一些風險。在實際應用中，過程性 AI 可以讓修改程式碼後的測試變得更容易。

#

• 手動測試，經常會看到測試人員重新測試整個應用程序，尋找程式碼變更時的意外後果。
• 另一方面，過程性 AI 可以建議對單一單元(或有限影響區域)進行測試，而不是對整個應用程式進行大規模重新測試。

在這個層級的人工智慧，我們發現在開發時間和成本方面有明顯的優勢。

然而，目光切換到第三階段——系統性 AI 時，畫風就會朦朧起來，因為，未來可能會成為一個滑坡的、無回報的承諾而已。

3、不可靠的系統性AI

系統性(或說完全自主的) AI 測試，之所以不可能(至少目前不可能) ，原因之一是AI 將需要大量的培訓。測試人員可以確信製程 AI 將建議一個單元測試來充分保證軟體品質。然而，對於系統 AI，測試人員無法高度自信地知道軟體將滿足所有需求。

如果這個等級的人工智慧真的是自主的，它將不得不測試所有可以想像的要求——甚至是那些人類沒有想像到的要求。然後，他們需要檢視自主 AI 的假設和結論。要證實這些假設是正確的，需要花費大量的時間和精力，才能提供高度可信的證據。

自主軟體測試永遠不可能完全實現。因為人們不會信任它，而這就等於失去了實現完全自主的目標與前提。

4、人工智慧需要調教

儘管完全自主的人工智慧是一個神話，但支持和擴展人類在軟體品質方面的努力的人工智慧是一個值得追求的目標。在這種情況下，人類可以支持人工智慧: 測試人員依舊需要保持耐心地監督、糾正和教導人工智慧以及其依賴的不斷進化的訓練集。挑戰在於如何訓練人工智慧，同時為測試軟體中的各種 bug 分配風險。這種訓練必須是持續的，不僅限於測試領域。自動駕駛汽車製造商訓練人工智慧，以區分一個人究竟是在過馬路還是在騎自行車。

測試人員必須用過去的資料訓練和測試人工智慧的軟體，以建立他們對人工智慧能力的信心。同時，真正自主的人工智慧在測試中需要預測未來的條件ーー開發人員引導和使用者引導ーー這是它無法根據歷史資料做到的。相反，訓練者往往會根據自身的偏見，基於資料集訓練人工智慧。這些偏見限制了人工智慧探索的可能性，就好比盲人為了確定性，會阻止馬匹偏離既定路徑一般。人工智慧表現的越有偏見，可信度就會越糟糕。人工智慧所能接受的最好訓練，就是處理風險機率，並得出最終由人類評估的風險緩解策略。

5、風險緩解措施

說到底，軟體測試關乎測試人員的成就感和自信。它們衡量和評估，初始實現的可能結果以及可能為開發人員和使用者帶來問題的程式碼變更。但不可否認的是，即便軟體測試已經充分探索了應用程式崩潰的每一種可能性，可信度都不可能是 100% 的。無論是人工執行還是自動執行，在所有軟體測試中都存在風險因素。

測試人員必須根據程式碼造成問題的可能性來決定測試覆蓋率。他們還必須使用風險分析來決定哪些領域應該集中在覆蓋範圍之外。即使人工智慧確定並顯示了軟體在用戶活動鏈中任何一點發生故障的相對機率，但測試人員仍然需要手動確認計算結果。

人工智慧為受歷史偏差影響的軟體連續性提供了可能性。然而，人們對人工智慧的風險評估和降低風險的秘方，仍然沒有很高的信心。

支援 AI 的軟體測試工具應該是實用且有效的，以便幫助測試人員產生真實的結果，同時減輕測試人員的手工勞動。

人工智慧在軟體測試中最令人興奮(也可能具有破壞性)的部署，是處於人工智慧開發成熟度的第二級: 過程性 AI。正如Katalon 的一位研究人員指出的那樣，「應用於軟體測試的AI 最大的實際用途是在流程級別，即自主測試創建的第一階段。這將是我能夠創建自動化測試的時候，這些測試可以由我創建，也可以服務於我。」

自主和自我導向的人工智慧，取代所有人類參與軟體測試過程等雲雲的話，皆是炒作。期望人工智慧能夠擴大和補充人類的努力並縮短測試時間，這是更現實和可取的。

參考連結：https://dzone.com/articles/ai-in-software-testing-the-hype-the-facts-the-pote

以上是被炒上天了的AI，嗨得太離譜！的詳細內容。更多資訊請關注PHP中文網其他相關文章！