Tud-e a mesterséges intelligencia asztali szoftvert tesztelni?
Egy alkalmazott árubeérkezést könyvel egy Windows-alkalmazásban, kinyomtat egy szállítólevelet, és átadja az adatokat a könyvelésnek. Egy frissítés után egy párbeszédablak más helyen jelenik meg, egy mező elveszíti a fókuszt, a nyomtatás már nem indul el. A "can AI test desktop software" kérdés ezért kevésbé elméleti, mint amennyire hangzik: fel tudja-e ismerni egy rendszer az ilyen hibákat a következő reggeli műszak előtt?
Igen. A mesterséges intelligencia képes tesztelni a Windows asztali szoftvert, különösen ott, ahol a klasszikus automatizálás kudarcot vall a változó felületeken, inkonzisztens vezérlőelemeken, vagy a karbantartás szempontjából drága szkripteken. Azonban nem helyettesíti a világos tesztcélokat, tiszta tesztadatokat, és az üzleti felelősséget. Az értéke akkor jelentkezik, amikor megbízhatóan átveszi az ismételhető munkát, és az embereket azon esetek felé irányítja, amelyek megítélést igényelnek.
Tud-e a mesterséges intelligencia asztali szoftvert tesztelni - és mit jelent ez a gyakorlatban?
Az asztali tesztek nem csak azt ellenőrzik, hogy megnyílik-e egy ablak. A valós működésben teljes munkafolyamatokról van szó: bejelentkezés helyes zárolási logikával, rendelésfelvitel, cikk kiválasztása, készletkönyvelés, címkenyomtatás, hibaüzenetek érvénytelen adatoknál, és a helyes átadás egy csatlakoztatott rendszernek.
Egy mesterséges intelligenciával működő tesztkörnyezet képes ezeket a munkafolyamatokat egy Windows-gépen végrehajtani, a látható felületet értékelni, és bizonyítékot generálni. Fel tudja ismerni például a gombokat szöveg és pozíció alapján, tartalmat tud olvasni párbeszédablakokból, és képernyőképeket tud összehasonlítani a várt állapottal. A merev szkripttel ellentétben jobban kezeli a kisebb vizuális változásokat - például amikor egy ikon, egy térköz, vagy egy vezérlőelem pontos technikai azonosítója megváltozik.
Ez különösen releváns az idővel kinőtt üzleti alkalmazásoknál. Sok ilyen program nem rendelkezik modern API-val minden folyamathoz. Némelyik saját tulajdonú felületeket, beágyazott táblázatokat, vagy olyan komponenseket használ, amelyeket nehéz konvencionális UI-automatizálással megszólítani. Egy mesterséges intelligencia ügynök inkább úgy tudja kezelni az alkalmazást, ahogy egy képzett felhasználó teszi: elolvassa a képernyőt, kiválaszt egy műveletet, ellenőrzi az eredményt.
Az "inkább" szót szándékosan választották. A mesterséges intelligencia nem látja automatikusan az üzleti folyamatot egy beviteli mező mögött. Meg tudja állapítani, hogy egy szállítólevél létrejött. Hogy a megfelelő szállítási feltételt kellett-e használni egy adott ügyfélhez, üzletileg meghatározott elvárást igényel.
Hol van értelme az AI teszteknek Windows-alkalmazásoknál
A legjobb kiindulópont az olyan munkafolyamatok, amelyek gyakran fordulnak elő, üzletileg kritikusak, és ma manuálisan ellenőrzik őket. Egy csapatnak ehhez nem kell a teljes tesztkatalógust automatizálnia. Jobb kiválasztani azt a néhány folyamatot, amelyek kiesése közvetlenül időt, pénzt, vagy bizalmat veszélyeztet.
A raktárban, gyártásban, és diszpozícióban ide gyakran tartozik az árubeérkezések létrehozása és könyvelése, a komissiózási és szállítási folyamatok, a jogosult készletkorrekciók, a címkék nyomtatása, valamint az import- és exportfolyamatok. Kereskedelmi alkalmazásoknál a bejelentkezés, a jogosultságváltás, a számlázás, a törzsadat-karbantartás, és az interfész-átadások tipikus jelöltek.
A mesterséges intelligencia különösen hasznos ott, ahol egy kiadás jelenleg egy manuális ellenőrzési napot vált ki. Egy tesztelő ekkor végigkattint egy hosszú listán, dokumentálja a rendellenességeket, és később megpróbálja rekonstruálni, hogy pontosan mi történt. Az automatizált futtatások ezt a részt átvihetik az éjszakára vagy egy rögzített kiadási folyamatba. Reggel nemcsak egy státusz áll rendelkezésre, hanem egy tesztnapló képernyőképekkel, időbélyegekkel, és az eltérés érthető leírásával.
A regressziós tesztek is hasznot húznak ebből. Amikor egy új funkciót építenek be a rendelési párbeszédablakba, a meglévő folyamatoknak nem szabadna észrevétlenül eltörniük. A mesterséges intelligencia megismétli a definiált forgatókönyveket minden releváns változtatás után. Ez nem szünteti meg minden kockázatot, de megakadályozza, hogy az ismert alapfolyamatok csupán az idő hiánya miatt ellenőrizetlenek maradjanak.
Mit tud megbízhatóan ellenőrizni a mesterséges intelligencia - és mit nem
Az AI-alapú felületi tesztek erősek a megfigyelhető elvárásoknál. "Mentés után megjelenik a rendelésszám." "Ha hiányzik egy kötelező adat, figyelmeztetés jelenik meg." "A készlet öttel csökken." "A nyomtatási párbeszédablak tartalmazza a szándékolt nyomtatót." Az ilyen állítások konkrét ellenőrzési lépésekre fordíthatók le.
Nehezebbek a pontatlanul megfogalmazott követelmények. "A felületnek professzionálisan kell kinéznie" vagy "a programnak gyorsnak kell lennie" nem elegendő tesztesetek. Itt kritériumokra van szükség: maximális várakozási idő definiált terhelés mellett, jóváhagyott elrendezés, vagy egyértelmű elfogadási szabályok a hibaüzenetekhez.
Az összetett üzleti speciális eseteknél az emberi tesztelés is nélkülözhetetlen marad. Ha egy visszáru-szabály egyetlen keretszerződésre vonatkozik, valakinek folyamatismerettel kell eldöntenie, hogy az eredmény helyes-e. A mesterséges intelligencia elő tudja készíteni, végre tudja hajtani, és dokumentálni tudja az esetet. Nem szabadna önkényesen új üzleti szabályokat kitalálnia.
Egy másik korlát a környezet stabilitása. Az asztali tesztek függenek a képernyőfelbontástól, a felhasználói jogosultságoktól, a hálózati kapcsolattól, a nyomtató-illesztőprogramoktól, a tesztadatoktól, és adott esetben a csatlakoztatott hardvertől. Ha egy címkenyomtató offline állapotban van, egy sikertelen teszt lehet valódi hiba - vagy környezeti probléma. A jó tesztrendszerek megkülönböztetik ezeket az eseteket, és átláthatóan jelentik őket, ahelyett hogy mindent egyszerűen termékhibaként értékelnének.
A technikai alap dönti el a hasznot
Egy használható asztali teszt több, mint egy sor egérkattintás. Szüksége van egy ellenőrzött gépre vagy egy virtuális Windows-környezetre, definiált felhasználói fiókokra, reprodukálható kiindulási adatokra, és egyértelmű visszaállítási szabályokra. Máskülönben a teszt keddi napon más állapotot ellenőriz, mint hétfőn, és vitákat generál a bizonyosság helyett.
Ugyanolyan döntő a bizonyíték. Egy kontextus nélküli zöld pipa keveset segít, amikor egy üzleti terület hibát jelent. Minden futáshoz ezért rendelkezésre kellene állnia a végrehajtott lépéseknek, a fontos pontokon készült képernyőképeknek, a látható hibaüzeneteknek, és egy időbélyegnek. Eltérések esetén felismerhetőnek kell lennie, hogy az alkalmazás helytelenül reagált-e, egy várt elemet nem találtak-e, vagy a tesztkörnyezet blokkolva volt-e.
Érzékeny alkalmazásoknál a végrehajtás helyének kérdése nem mellékes ügy. A képernyőképek, a hozzáférési adatok, az ügyféladatok, és a belső folyamatképernyők bizalmas információkat tartalmazhatnak. Aki külső szolgáltatásokon keresztül futtat teszteket, annak pontosan meg kell vizsgálnia, milyen adatok hagyják el a saját területüket, meddig tárolják őket, és ki kap hozzáférést.
A megfelelő követelményekkel rendelkező csapatok számára egy önállóan üzemeltetett környezet ésszerűbb lehet.
softify.pro ehhez üzemelteti a COCO-t, saját mesterséges intelligencia szerverét az automatizált web- és alkalmazástesztelésekhez. A végrehajtás, a tesztbizonyítékok, és az értékelés az ellenőrzött vállalati környezeten belül maradhatnak. Ez nem minden alkalmazáshoz szükséges, de belső üzleti rendszereknél, személyes adatoknál, vagy szigorú informatikai előírásoknál gyakran ez a tisztább architektúra.
Így indul egy csapat anélkül, hogy egy tesztautomatizálási projekt elszabadulna
Egy értelmes kezdés nem eszközválasztással kezdődik, hanem egy folyamattal. Vegyen egy munkafolyamatot, amelyet legalább hetente ellenőriznek, és amelynek hibakövetkezményei visszakövethetők. Egy szállítási folyamat jobban megfelel, mint húsz véletlenszerű képernyőmaszk gyűjteménye.
Ezután írja le az üzleti utat világos mondatokban: kiindulási helyzet, bemenetek, elvárt köztes állapotok, elvárt végeredmény. Egészítse ki a negatív esetet is. Mi történjen, ha hiányzik egy sarzsszám, egy felhasználónak nincs jogosultsága, vagy a készlet nem elegendő? Éppen ezeket a szabályokat hagyják gyakran ki a manuális tesztekben, pedig a mindennapi működésben költségessé válhatnak.
Ezután egy korlátozott pilot következik stabil tesztadatokkal és egy definiált környezettel. Ne csak azt mérje, hogy fut-e a teszt. Mérje, hány manuális ellenőrzési percet vált ki, hány téves riasztás fordul elő, és hogy a bizonyítékok elegendők-e a fejlesztéshez és az üzleti területhez. Csak amikor ez az alap működik, éri meg a kiterjesztés további folyamatokra.
A karbantartás ehhez az elejétől kezdve hozzátartozik. Ha egy képernyő üzletileg megváltozik, az elvárást is módosítani kell. Ez nem érv az automatizálás ellen. Ez normál szoftverkarbantartás - hasonlítható egy munkautasítás frissítéséhez, amikor egy raktári folyamat megváltozik.
Nem minden kattintást kell automatizálni
Néhány csapat teljes lefedettséget vár el a mesterséges intelligencia tesztektől. Ez gyorsan magas költségekhez vezet ritka kivételes esetekhez, amelyek ellenőrzése manuálisan gyorsabb és megbízhatóbb lenne. Egy jó tesztstratégia ehelyett kockázat, gyakoriság, és változási ütem szerint priorizál.
Egy ritkán használt, alacsony hibakövetkezményű adminisztrációs párbeszédablak továbbra is ellenőrizhető rövid manuális ellenőrzőlistával. Egy napi árubeérkezés több utólagos lépéssel viszont automatizált regressziós teszteket és tiszta bizonyítékokat érdemel. A Boring, provable reliability itt legyőzi a nagy, de törékeny tesztgyűjteményt.
Kezdje azzal a folyamattal, ahol egy hiba a következő munkanapon valóban érezhető lenne. Amikor ezt a munkafolyamatot automatizáltan, visszakövethetően, és megismételhetően ellenőrzik a saját környezetében, a tesztautomatizálás megbízható üzemeltetési előnnyé válik - nem egy másik IT-projekt szép diákkal.