今天，基于神經(jīng)網(wǎng)絡(luò)的人工智能正處于一個(gè)非常有趣的發(fā)展階段。它顯然已經(jīng)起飛：我們看到從讀取CT掃描到采摘水果的許多應(yīng)用。但采用率差異很大。推薦引擎、客戶支持機(jī)器人和其他被稱為“互聯(lián)網(wǎng) AI”的東西相當(dāng)普遍;我們在生活中隨處可見它。然而，大多數(shù)領(lǐng)域，包括軟件測試，還沒有完全實(shí)現(xiàn)。

是什么讓人工智能被廣泛采用，是什么讓它陷入困境？讓我們來看看我們自己的領(lǐng)域，軟件測試。具體來說，我想看看神經(jīng)網(wǎng)絡(luò)如何生成自動化測試，以及在我們的領(lǐng)域大規(guī)模采用人工智能存在哪些障礙。我將首先關(guān)注問題和困難，不是因?yàn)槲以噲D成為半空的玻璃杯，而是因?yàn)槌鲥e(cuò)的事情總是告訴我們更多關(guān)于系統(tǒng)如何運(yùn)作的信息，而不是正確的事情。

一旦我們完成了生成測試，我想看看人工智能在其他領(lǐng)域的應(yīng)用，比如醫(yī)學(xué)——那里有很多工作要做，尤其是閱讀掃描。也許他們有類似的成長痛苦？最后，為了鳥瞰，我將看看一個(gè)完全不同的行業(yè)，它已經(jīng)成熟和鞏固。它的經(jīng)驗(yàn)?zāi)芨嬖V我們今天人工智能的發(fā)展嗎？

有了這個(gè)角度，也許我們可以停止困擾新技術(shù)的炒作/幻滅鐘擺，也許可以瞥見人工智能的發(fā)展方向。

確認(rèn)

在我們繼續(xù)之前，我要感謝納塔利婭·波利亞科娃和阿爾喬姆·埃羅申科為我提供了這篇文章的時(shí)間和專業(yè)知識。但是，所寫一切的責(zé)任完全在于我。

另外，非常感謝Danil Churakov在此（和其他）帖子中提供的精彩圖片！

生成測試：現(xiàn)在的位置

今天，ChatGPT，GitHub Copilot和其他AI驅(qū)動的工具被廣泛用于編寫代碼和測試，我們最近對此進(jìn)行了一次非常有趣的采訪。然而，人們?nèi)匀淮蠖嗍鞘止ぞ帉懽詣踊瘻y試，神經(jīng)網(wǎng)絡(luò)的使用主要是情境化的。他們在這一領(lǐng)域達(dá)到目標(biāo)的速度仍然遠(yuǎn)低于人類的標(biāo)準(zhǔn)。 2020 年末的一篇論文預(yù)測了測試中 62% 的斷言陳述，這絕對是一個(gè)值得吹噓的結(jié)果。根據(jù)GitHub Copilot的常見問題解答，它的建議在26%的時(shí)間內(nèi)被接受。人們常說，它最好的用途是作為谷歌和StackOverflow的更快替代品。所以 - 情境用法。目前，軟件QA中的AI還不能與營銷等領(lǐng)域擁有相同的水平，在市場營銷中，神經(jīng)網(wǎng)絡(luò)創(chuàng)建的數(shù)字營銷和數(shù)據(jù)分析策略實(shí)際上優(yōu)于人類創(chuàng)建的數(shù)字營銷和數(shù)據(jù)分析策略。但是，請記住，GPT-4 可能會改變情況。

這些問題從何而來？讓我們四處打聽并做一些實(shí)際研究。我和我經(jīng)驗(yàn)豐富的測試人員同事談過，也修改了Machinet，這是一個(gè)非常流行的IDEA插件，可以生成單元測試。

我們使用的神經(jīng)網(wǎng)絡(luò)對于其預(yù)期應(yīng)用非常有用。Machinet可能是作為開發(fā)人員助手而不是通用工具創(chuàng)建的。他們的座右銘聽起來絕對像是針對開發(fā)人員而不是QA：“讓我們面對現(xiàn)實(shí)吧。單元測試是一件苦差事。只需自動化即可。這是有道理的——通常是開發(fā)人員編寫單元測試。對于沒有深入了解測試的人來說，該工具做得很好。只有當(dāng)我們從 QA 的角度來看待結(jié)果時(shí)，故障才會變得可見。那么存在哪些問題呢？

A. 問題

工作中的網(wǎng)絡(luò)

過度承保

Machinet 插件完成了它的工作，并且做得很徹底 - 它確保覆蓋 if-else 分支、使用不同的數(shù)據(jù)類型、檢查字符限制等。事實(shí)上，它完成的工作太徹底了，可以生成太多的測試，而不考慮資源負(fù)載。例如，檢查字段是否接受任何字符并檢查它是否將字符串長度限制為 255 個(gè)字符可以在單個(gè)測試中輕松完成 - 但 Machinet 為每種情況生成了一個(gè)單獨(dú)的測試。另一個(gè)示例涉及由多個(gè) API 方法使用的數(shù)據(jù)檢索功能。生成的測試將涵蓋每個(gè)方法中的函數(shù)，并且將為函數(shù)本身創(chuàng)建一個(gè)單獨(dú)的測試。同樣，我們顯然得到了過度的報(bào)道。

印象是，如果我們有幾個(gè)相交的數(shù)據(jù)集，插件將嘗試覆蓋所有可能的交集。假設(shè)您正在測試一個(gè)電子商務(wù)網(wǎng)站，并且您有多種交付選項(xiàng)（客戶取貨、付款類型等）。使用Machinet，所有可能的組合都可能會被測試，而人類測試人員可以使用決策表來涵蓋真正重要的組合。但是，這樣做可能需要未輸入神經(jīng)網(wǎng)絡(luò)的上下文數(shù)據(jù)。

代碼重復(fù)

一個(gè)相關(guān)的問題是代碼重復(fù)。我們正在測試一個(gè)需要填充對象的集合，它必須在 4 個(gè)不同的測試中使用。每個(gè)測試都從頭開始重新創(chuàng)建集合，而不是將其移動到單獨(dú)的字段或函數(shù)中。此外，代碼中已經(jīng)存在一個(gè)用于生成集合的函數(shù)，它執(zhí)行的操作與測試中所做的基本相同，但插件沒有使用它。神經(jīng)網(wǎng)絡(luò)能很好地使用本地的東西？很容易說，嗯，這是網(wǎng)絡(luò)以前從未遇到過的獨(dú)特情況。但這并不像神經(jīng)網(wǎng)絡(luò)在識別它以前見過的獨(dú)特貓照片時(shí)會遇到任何困難。這是一個(gè)有趣的問題，我們將在下面回到。

了解復(fù)雜代碼

神經(jīng)網(wǎng)絡(luò)生成的自動化測試在涵蓋簡單的模塊化代碼片段時(shí)處于最佳狀態(tài)。當(dāng)然，如果所有代碼都以這種方式編寫，那就太好了，但這可能是不可能的或不可行的。當(dāng)您需要涵蓋冗長而復(fù)雜的業(yè)務(wù)邏輯時(shí)，機(jī)器生成的測試的可靠性會受到很大影響。當(dāng)然，它們會被生成，但很難弄清楚它們是否正確地覆蓋了東西，或者它是否只是隨機(jī)的東西，幾乎不能指望用于煙霧測試。

了解上下文

在談到過度覆蓋時(shí)，我已經(jīng)談到了這一點(diǎn)：網(wǎng)絡(luò)并不真正知道該方法的用途，因此無法根據(jù)這些知識進(jìn)行優(yōu)化。例如，人類測試人員知道，如果我們在 Java 中測試 API 方法，我們應(yīng)該檢查空值;如果不是 API，則可以跳過此操作。我們看到的網(wǎng)絡(luò)似乎不會做出這樣的決定。

外部工具和模式的使用

我們還注意到，Machinet 使用硬編碼值填充集合，而不是使用庫隨機(jī)生成數(shù)據(jù)。我不知道這是否是一個(gè)過分的要求，但有一個(gè)相關(guān)的問題：我們使用的神經(jīng)網(wǎng)絡(luò)在外部依賴關(guān)系方面做得不好，使用模式也是一個(gè)問題。

清理

最后，網(wǎng)絡(luò)生成的代碼肯定需要徹底審查。當(dāng)然，所有由人類編寫的代碼也需要審查，這是標(biāo)準(zhǔn)做法，基于AI的工具的創(chuàng)建者總是警告這一點(diǎn)。在開發(fā)此類工具時(shí)，絕對必須牢記這一點(diǎn)：會有很多來回，使編輯變得容易應(yīng)該是首要考慮因素。但這可能是一個(gè)問題還有另一個(gè)原因。正如我所說，Machinet 似乎針對那些可能不太熟悉測試的開發(fā)人員;因此，審查機(jī)器工作的人可能無法糾正我剛才談到的所有缺陷。

問題背后的原因

因此，當(dāng)需要深入了解本地項(xiàng)目時(shí)，我們一直在使用的工具并不那么好，不“理解”他們正在測試的方法的上下文，他們不擅長在重復(fù)或資源使用方面優(yōu)化代碼，他們最擅長簡單和模塊化的代碼，他們創(chuàng)建的代碼也往往是這樣。

乍一看，這些似乎是相當(dāng)深層次的問題，但也許這是因?yàn)槲覀冊谡務(wù)摗袄斫狻倍皇窃谡務(wù)摂?shù)據(jù)。毫不奇怪，如果沒有對 RAM 和 CPU 使用率的數(shù)據(jù)進(jìn)行訓(xùn)練，網(wǎng)絡(luò)就無法根據(jù)資源消耗優(yōu)化代碼。ChatGPT 不了解您的特定項(xiàng)目，因?yàn)樗鼪]有接受過培訓(xùn)。最后，這些障礙不是代碼固有的，這只是一個(gè)經(jīng)濟(jì)學(xué)問題：在特定數(shù)據(jù)集上訓(xùn)練網(wǎng)絡(luò)是否可行。

更深層次的原因本身就是代碼嗎？

然而，這里有一個(gè)更深層次的問題：代碼與人類語言不同。這個(gè)問題已經(jīng)得到了很好的研究，并且已經(jīng)為自然語言開發(fā)的算法絆倒了一段時(shí)間。如果我們將自然語言與您主要“按原樣”使用的工具進(jìn)行比較，那么編程語言就是您用來構(gòu)建工具的工具，以構(gòu)建工具來構(gòu)建工具。它更加嵌套。

對XKCD最好的問候

程序員編寫的每個(gè)新函數(shù)或變量都有自己的名稱，這些名稱可能會變得非常長且難以理解 - 特別是Java因VariableNamesThatLookAndFeelLikeTrainWrecks而臭名昭著。

這意味著，例如，Ubuntu 的源代碼可以比大量的英語文本語料庫多兩個(gè)數(shù)量級的獨(dú)特“單詞”（嗯，標(biāo)記）。這是一個(gè)非常大且非常稀疏的詞匯;對于任何算法來說，這兩者都是壞消息。生僻詞意味著要學(xué)習(xí)的數(shù)據(jù)較少，詞匯量會影響算法的速度和內(nèi)存要求。

這些嵌套詞匯表也非常本地化。您在項(xiàng)目中使用的大多數(shù)單詞永遠(yuǎn)不會看到外部。這就是封裝的重點(diǎn)：突出的東西越少，代碼就越容易使用。因此，您擁有特定于應(yīng)用程序甚至開發(fā)人員的詞匯表。此外，人們使用的工具也在不斷變化，這也催生了新的詞匯。除此之外，還有風(fēng)格：我們編寫的代碼可能非常固執(zhí)己見。那是你剛剛寫的Pythonic嗎？還是你還在拖著你舊的Java習(xí)慣？同樣的問題可以用不同的方式解決，造成進(jìn)一步的混亂。

因此，想象一下您的技術(shù)堆棧。你有你的語言（也許是幾種語言），你的框架，你的數(shù)據(jù)庫，你在前端和后端擁有的所有庫，以及你使用的模式，以及開發(fā)人員的特質(zhì)。所有這些交叉上下文都嚴(yán)重限制了任何特定AI驅(qū)動工具的類似代碼的數(shù)量。因此，難怪這些工具在生成復(fù)雜代碼時(shí)會遇到麻煩。

問題很深，但還不夠深

當(dāng)然，這是一個(gè)問題，但遠(yuǎn)非不可克服。問題是，在由語言、框架、項(xiàng)目等定義的上下文中，代碼實(shí)際上比人類語言重復(fù)得多（另請參閱此處）。而那個(gè)重復(fù)的部分是占主導(dǎo)地位的部分。一項(xiàng)研究發(fā)現(xiàn)，大量 JavaScript 文件包含 2 萬個(gè)唯一標(biāo)識符，但其中只有 4k 個(gè)負(fù)責(zé)所有事件中的 10%。

因此，這不是數(shù)據(jù)（我們的代碼）的深層問題，而是數(shù)據(jù)如何組織以及如何將其輸入工具的問題。也許可以通過使用一種訓(xùn)練子詞而不是單詞的算法來解決。這樣的算法不必處理數(shù)百萬字長的詞匯表，但它會更耗費(fèi)資源?；蛘?，也許是關(guān)于擁有一個(gè)可以足夠快地重新估計(jì)的模型，以便它可以適應(yīng)您的本地環(huán)境。或者，也許我們應(yīng)該將上下文信息（如注釋）提供給算法。無論如何，答案始終是關(guān)于我們?nèi)绾谓M織數(shù)據(jù)以及處理數(shù)據(jù)的速度。

饋送網(wǎng)絡(luò)

縮小：人工智能的演變

讓我們試著把這些問題放在正確的角度，看看它們與人工智能在其他領(lǐng)域必須克服的困難相比如何。

無論如何，神經(jīng)網(wǎng)絡(luò)的歷史圍繞著在更短的時(shí)間內(nèi)處理更多的數(shù)據(jù)。這是我一開始不太明白的：對于神經(jīng)網(wǎng)絡(luò)，數(shù)量就是質(zhì)量;數(shù)據(jù)越多，答案就越復(fù)雜和準(zhǔn)確。

幾乎只要有計(jì)算機(jī)，人們就一直在嘗試構(gòu)建神經(jīng)網(wǎng)絡(luò)，但在大部分時(shí)間里，人工智能被不同的學(xué)校主導(dǎo)，即“基于規(guī)則”的方法：告訴你的系統(tǒng)規(guī)則并觀察它的工作;如果失敗 - 請咨詢專家，制定新規(guī)則。相比之下，神經(jīng)網(wǎng)絡(luò)根據(jù)它們處理的數(shù)據(jù)自己找出規(guī)則。那么，為什么網(wǎng)絡(luò)只是在過去一二十年才“起飛”呢？因?yàn)槟菚r(shí)我們獲得了大規(guī)模的數(shù)據(jù)存儲（特別是云）、瘋狂的大量生成數(shù)據(jù)（通過物聯(lián)網(wǎng)等）和巨大的處理能力（尤其是 GPU 計(jì)算）;就在那時(shí)，發(fā)生了幾項(xiàng)創(chuàng)新，大大提高了深度神經(jīng)網(wǎng)絡(luò)的訓(xùn)練效率，從 2000 年代中期的 Geoffrey Hinton 的工作到 2018 年變壓器的發(fā)明。長話短說，可以快速處理大量數(shù)據(jù)。

但僅僅擁有算法和硬件可能還不夠。醫(yī)療保健是一個(gè)收集和存儲大量數(shù)據(jù)的領(lǐng)域，一直在尋找尖端技術(shù)，并吸引大量投資。因此，在某些地方和某些領(lǐng)域（如眼科），人工智能已經(jīng)進(jìn)入日常使用也就不足為奇了。然而，在廣泛采用之前還有很長的路要走。在醫(yī)療保健領(lǐng)域，與編程不同，確實(shí)存在優(yōu)于人類的模型，但它們大多停留在開發(fā)階段，并且在實(shí)施中不斷失敗。

原因是，與用于訓(xùn)練模型的集合相比，現(xiàn)實(shí)生活中的數(shù)據(jù)是“臟的”。目前，醫(yī)院的數(shù)據(jù)都以不同的方式收集和存儲，醫(yī)院通常有幾個(gè)系統(tǒng)，除了通過pdf文件外，它們不會相互通信。當(dāng)然，數(shù)據(jù)基礎(chǔ)設(shè)施因醫(yī)院而異，因此您無法構(gòu)建任何大規(guī)模數(shù)據(jù)集。此外，患者可能與用于訓(xùn)練模型的人口統(tǒng)計(jì)數(shù)據(jù)不同。此外，從業(yè)者使用的一些信號沒有數(shù)字化，這降低了模型的比較效率。在本地?cái)?shù)據(jù)集上訓(xùn)練模型時(shí)，存在患者保密問題。

進(jìn)入狹窄的空間

一般來說，有兩種方法可以繞過這些障礙：使模型適合現(xiàn)實(shí)生活中的使用給我們帶來的狹窄空間，或者擴(kuò)大空間。

用于訓(xùn)練醫(yī)療保健中表現(xiàn)最佳的模型的大型數(shù)據(jù)集是通過由于專有原因無法在現(xiàn)實(shí)生活中重現(xiàn)的步驟創(chuàng)建的。因此，可以在局部環(huán)境中校準(zhǔn)模型以提高其準(zhǔn)確性，而合成數(shù)據(jù)集可用于保護(hù)機(jī)密性。

但是，如果不改變用于收集和存儲數(shù)據(jù)的基礎(chǔ)設(shè)施，所有這些都不可能非常有效。現(xiàn)有的系統(tǒng)必須能夠相互連接，數(shù)據(jù)應(yīng)該像STRIDES倡議所提議的那樣存儲在異地，最重要的是，它必須變得更加統(tǒng)一。

不出所料，代碼和醫(yī)療保健中采用問題背后的原因非常不同。解決方案則不然。我們可以預(yù)期這些模型在重新訓(xùn)練以適應(yīng)當(dāng)?shù)丨h(huán)境方面會變得更便宜、更有效。我們可以改變組織數(shù)據(jù)的方式。為了使網(wǎng)絡(luò)更高效地處理代碼和測試，我們需要更標(biāo)準(zhǔn)化的編寫和存儲方式。我們認(rèn)為的“干凈代碼”的許多實(shí)踐旨在使代碼對人類更具可讀性。也許我們現(xiàn)在需要的是使其對神經(jīng)網(wǎng)絡(luò)更具可讀性的方法。

或者也許它更簡單。如果神經(jīng)網(wǎng)絡(luò)可以生成簡單、重復(fù)的代碼，并且善于用測試來覆蓋它——那么也許我們讓它們做工作的兩面，完全忘記干凈的編碼實(shí)踐，而是專注于控制輸出的方法。

總結(jié)

當(dāng)一項(xiàng)新技術(shù)出現(xiàn)時(shí)，有兩種采用途徑：首先，該技術(shù)試圖適應(yīng)經(jīng)濟(jì)中已經(jīng)存在的一些角色;然后，經(jīng)濟(jì)發(fā)生變化，以適應(yīng)新技術(shù)的全面發(fā)展。第二條路徑意味著創(chuàng)建一個(gè)基礎(chǔ)設(shè)施網(wǎng)絡(luò)來支持該技術(shù)。如果你有汽車，你也會得到新道路的大規(guī)模建設(shè)，你會得到立法的變化，等等。如果你想要電動汽車，你需要充電器。

這是目前在QA中AI之前的兩條道路，可以幫助將技術(shù)與支持它所需的基礎(chǔ)設(shè)施相結(jié)合：

1. 制作能夠更好地適應(yīng)當(dāng)?shù)丨h(huán)境的人工智能驅(qū)動工具，能夠在特定項(xiàng)目和技術(shù)堆棧上學(xué)習(xí)的工具

2. 使測試的組織方式適應(yīng)神經(jīng)網(wǎng)絡(luò)的要求

審核編輯：郭婷