Nyereség:
- Képes megtervezni a mesterséges intelligencia és az emberi jóváhagyási pontok szerepét a végpontokig terjedő minőségbiztosítási folyamatban, az ötlettől a kiadásig a CI/CD kontextusában
- CI/CD esetén nem engedélyezi az AI-t, hogy automatikusan „átmenjen” a teszten, de korlátozza a bizalmas adatok és kulcsok védelmét
- Képes hatósági kereteken belül és védelmi célból biztonsági tesztelést végezni, valamint felelősségteljes közzétételi és etikai átláthatósági elveket alkalmazni.
Az előző tíz egységben az AI-t egyéni feladatokban alkalmaztuk: forgatókönyv generálás, automatizálási kód, hibajelentés, fedezetelemzés, mutációteszt. Ez az utolsó egység ezeket egyetlen felelős munkafolyamatba egyesíti. A modern minőségbiztosítás nem olyan munka, amely egy ember asztalánál ér véget; Ez egy folyamat, amely a CI/CD-n belül él (Continuous Integration / Continuous Delivery – a folyamat, ahol a kódot folyamatosan kombinálják, automatikusan tesztelik, és gyakran és biztonságosan előkészítik a közzétételre). Az AI a folyamat minden szakaszát érintheti. De ahogy az AI ereje növekszik, úgy növekszik a felelősségteljes használat fontossága is: a magánélet védelme, a biztonsági tesztelés tekintélye, az etika, és ami a legfontosabb, hogy a minőségi döntés az emberen maradjon. Ebben az egységben megtanulja a végpontok közötti áramlást és a határokat.
Végpontok közötti, mesterséges intelligencia által táplált minőségbiztosítási folyamat
A mesterséges intelligencia szerepe egy szolgáltatás útjában az ötlettől a kiadásig:
1. Követelményelemzés. Az AI megjelöli a követelmények kétértelműségét és a hiányzó elfogadási feltételeket ("ez a szabály nem mondja meg, hogy a jelszó minimum hány karakterből áll").
2. Teszttervezés. A forgatókönyv- és esetvázlatok (2. egység), az éles esetek (3. egység) szerepelnek az elfogadási kritériumok között.
3. Automatizálás. Unit (6), API (5) és UI (4) tesztkódvázlatok; mindegyiket mutáció erősíti meg (10).
4. CI/CD integráció. A tesztek minden kódegyesítéskor automatikusan lefutnak. Az AI elkészíti a folyamatkonfigurációt (YAML), összefoglalja a sikertelen tesztek naplóit, és javaslatot tesz a lehetséges kiváltó okra.
5. Elengedési határozat. A kockázatelemzés (8) és a regresszió (9) eredményeit összegyűjtik – de a szakértő dönti el, hogy sikeres lehet-e.
6. Gyártásfigyelés és visszacsatolás. Az élőben előforduló hibák jövőbeli tesztekké válnak; Az AI regressziós esetet javasol egy gyártási hibából.
Tipp: Állítsa be a mesterséges intelligencia réteget a CI/CD-ben, amely „gyorsítja az ember által felülvizsgált piszkozatokat”, nem pedig „teszteket ír és döntéseket hoz”. Egyetlen automatikusan generált teszt sem kerülhet be a folyamatba anélkül, hogy egy ember átnézné és jóváhagyná azokat.
AI CI/CD-ben: hol igen, hol nem
Színpad
AI illeszkedik
az ember elengedhetetlen
Teszt kódtervezet
Igen
Revízió + mutáció
Pipeline YAML tervezet
Igen
Hitelesítés + titkos kulcs ellenőrzése
Sikertelen naplóösszegzés
Igen
A kiváltó ok megerősítése
Törékeny teszt diagnózis
Igen
Állandó megoldási döntés
– Lehet-e verzió?
nem
Szakértői ítélet és felelősség
Automatikusan "átmenni" a teszten
soha
—
Vigyázat: Soha ne adjon az AI-nak olyan megbízást, mint a „javítsa ki, hogy sikeres legyen a teszt” CI/CD-ben. Ez meghiúsítja a tesztelés célját, és automatikusan elfedi a hibákat. A mesterséges intelligencia meg tudja magyarázni a hibát, javasolja a javítást; de "a teszt zöldre festése" az ember tudatos, megfontolt döntése kell, hogy legyen.
Magánélet, adatok és biztonság: megváltoztathatatlan határok
Adatvédelem. A tesztkörnyezetben a tényleges ügyféladatok, a termelési adatbázis-másolatok, az API-kulcsok és a belső rendszerinformációk érzékenyek. Ne adja ki ezeket nyilvános AI-eszközöknek. A személyes adatokra a KVKK és hasonló szabályozások vonatkoznak; Maszk naplók és képernyőképek. Lehetőség szerint használjon szintetikus (fiktív) tesztadatokat.
Biztonsági tesztelés – védekező és engedélyezett. Az ebben a modulban elsajátított biztonsági tesztek (engedélyezési/IDOR tesztek, fájlfeltöltési korlátok, bemeneti érvényesítés) csak saját termékének tesztelésére szolgálnak az írásos felhatalmazáson és meghatározott körön belül. A mesterséges intelligencia használata valaki más rendszeréhez engedély nélkül való hozzáférésre, valódi sebezhetőségek felfegyverzésére vagy hatókörön kívüli tesztelésre egyaránt etikátlan és illegális. Ha biztonsági rést talál, tartsa be a felelősségteljes nyilvánosságra hozatal elvét – tartsa bizalmasan a sérülékenységet, és jelentse azt az érintett félnek a javítás érdekében.
Etika és átláthatóság. Ne mutassa be az AI által készített teszteket saját munkájaként; Ha kijelenti, hogy mesterséges intelligenciát használ a csapaton belül, az átláthatóság. Ön felelős a mesterséges intelligencia által előállított kimenet pontatlanságáért – az „AI írta” nem kifogás.
Gyenge felszólítás / Erős felszólítás
Gyenge: "Tesztfolyamat beállítása CI-hez."
Erős: "Vázlat egy CI-munkafolyamat YAML-t a GitHub-műveletekhez: futtasson egység + API-teszteket minden PR-on, lefedettségi jelentést készítsen, mutációtesztet (Stryker) futtasson hetente. Ne ágyazz be titkokat a kódba; csak a titkokra vonatkozó hivatkozást használd. Blokk-összevonás, ha a tesztek pirosak. Ez egy VÁZLAT; Átnézem és szerkesztem. A titkos kulcs kezelését és az érvényesítést NEM javítom." „migráció” lépés."
Erőteljes felszólítás; Korlátokat szab a titoktartásra, az emberi felülvizsgálatra és az „automatizált tesztelés tilalmára”.
Négy másolható sablon
1) Teljes körű tesztelési terv:
Az Ön szerepe: vezető minőségbiztosítási vezető. Készítsen teljes körű tesztelési tervet az ötlettől a kiadásig a következő funkcióhoz: [szolgáltatás + elfogadási feltételek]. Fázisok: követelmények elemzése (bizonytalanságok), teszttervezés, automatizálási rétegek (egység/API/UI), CI/CD integráció, kiadási döntési feltételek, gyártáskövetés. Határozza meg az AI és az EMBER jóváhagyási pontok szerepét minden szakaszban külön-külön.
2) CI/CD folyamatvázlat:
CI YAML-vázlat [GitHub Actions/GitLab CI/Azure Pipelines] számára:- Egység + API-teszt + hatókör a PR-ban- Egyesítés megakadályozása piros teszttel- Titkos értékek csak titkokkal; beágyazás kódbaEz egy piszkozat; Áttekintem a kulcskezelési és jóváhagyási lépéseket. Automatikus javítás/megfelelt tesztlépés hozzáadása.
3) Sikertelen tesztnapló-elemzés:
A CI-nyomatban a tesztek pirosak. Vizsgálja meg a naplót; csoportosítsa a meghibásodásokat, különböztesse meg a lehetséges kiváltó okokat, és hogy MELYIK lehet a valódi hiba, és melyik lehet törékeny teszt/környezeti probléma. Ha vannak személyes adatok, takarja el azokat. A döntés és a helyesbítés az enyém lesz. Napló: [beillesztés]
4) Biztonsági/adatvédelmi előzetes ellenőrzés:
Mielőtt ezt a tesztadatot/naplót elküldené az AI-eszköznek, ellenőrizze: tartalmaz-e személyes adatokat, API-kulcsot, belső rendszercímet, gyártási adatokat? Sorolja fel, hogy mely területeket kell maszkolni/eltávolítani, ha vannak ilyenek. Feldolgozás úgy ahogy van. Tartalom: [beillesztés]
három mini tok
1. eset – A végpontok közötti áramlás sebessége. Az egyik csapat egy új „előfizetés-megújítási” funkcióval foglalkozott egy mesterséges intelligencia által vezérelt végpontok közötti áramlással: a követelmények bizonytalanságait előre jelezték, háromrétegű teszteket készítettek és mutációval validáltak, CI-hez kötve. A funkció 2 napra csökkentette a tesztelési ciklust, amely a hagyományos eljárásban 5 napig tartott; de az emberi jóváhagyást minden szakaszban megőrizték, és a követelmények bizonytalanságát (mi történik, ha a frissítés sikertelen) lezárták az éles előtt.
2. eset – Visszatérés kulcsszivárgásból. Egy fejlesztő az AI-val generálta a CI YAML-t, és az AI egy valós kinézetű API-kulcsot ágyazott be példaként a YAML-be. A „biztonsági/adatvédelmi előzetes ellenőrzés” lépés ezt rögzítette; kulcs titkos hivatkozássá konvertálva. Az audit lépés nélkül a kulcs kiszivárogna a verziókezelésbe (git történelem).
3. eset – Hatékonyság határa. A csapat egyik tagja az általa tanult IDOR-tesztet egy üzleti partner élő rendszerére akarta alkalmazni „kíváncsi voltam”. A minőségbiztosítási vezető megállt: illegális más rendszeren biztonsági tesztelést végezni írásos felhatalmazás és meghatározott hatókör nélkül. A tesztelést kizárólag saját termékeik tesztkörnyezetében végezték, felhatalmazással; A nyílt felelős felet értesítették az illetékes csapatnál.
Gyakori hibák
- A mesterséges intelligencia kiadási döntéseket hoz. Felteszi a kérdést: "Kiadható?" az AI-hoz, és az aláírás helyére helyezzük a választ.
- Az automatizált teszt "megfelelt". CI-ben az AI zöldre festi a tesztet; elfedni a hibákat.
- Bizalmas adatok/kulcs átadása a járműnek. Gyártási adatok, személyes adatok vagy API-kulcsok megosztása felügyelet nélkül.
- Jogosulatlan biztonsági tesztelés. Támadótesztelés egy másik rendszeren hatókör és engedély nélkül.
- Tesztek bevezetése a csővezetékbe felülvizsgálat nélkül. Az AI vázlat automatikus futtatása emberi jóváhagyás nélkül.
- Az MI-t hibáztatva. A hibás kimenet védelme azzal, hogy "AI írta".
Összefoglalva
A végpontok közötti minőségbiztosítás egy olyan folyamat, amely a követelményektől a gyártáskövetésig terjed, és a CI/CD-n belül él; Az AI minden szakaszban piszkozatokat készít, összefoglalja a naplót, és javaslatot tesz a kiváltó okokra. De a határok megváltoztathatatlanok: az emberek tesztelési döntéseket hoznak, és kiadják a jóváhagyást; Az AI soha nem kap felhatalmazást arra, hogy automatikusan „átmenjen” a teszten; bizalmas adatok és kulcsok nem jutnak be a járműbe; Biztonsági tesztelést csak az Ön saját termékén, az írásos engedély és meghatározott körben, védekezési célból végeznek, a megállapításokat felelősségteljes nyilvánosságra hozatal mellett jelentik. Legyen átlátható, amikor AI-t használ; Ön felelős a kimenet pontosságáért. Az AI felgyorsul; Ön garantálja a minőséget és az etikát.
Pályázati feladat
Készítsen tervet az ötlettől a kiadásig egy „végponttól végpontig terjedő tesztterv” sablonnal a saját projektje egy funkciójához; Minden szakaszban külön jelölje meg az AI és az emberi jóváhagyási pontok szerepét. Ezután hozzon létre egy YAML-t „CI/CD-folyamatvázlattal”, és alkalmazza a „biztonsági/adatvédelmi előzetes ellenőrzést” erre a YAML-re a beágyazott kulcs/titkos adatok ellenőrzéséhez. Végül sorold fel a tervedben szereplő összes „emberi döntés” pontot, és egy mondatban indokold meg, miért nem delegálhatók ezek a döntések az MI-re.
ellenőrző lista
- [ ] A kiadási és tesztelési döntéseket emberi jóváhagyásnak tulajdonítom; Nem adtam át az AI-nak.
- [ ] A CI/CD-ben nem adtam engedélyt az AI-nak arra, hogy automatikusan "átmenjen/javítsa" a tesztet.
- [ ] Bizalmas adatokat, személyes adatokat és kulcsokat ellenőriztem és elfedtem, mielőtt elküldtem volna azokat a járműnek.
- [ ] Csak a saját termékemen végzett biztonsági tesztelést vettem figyelembe, az írásos felhatalmazáson és hatályon belül.
- [ ] A feltárt sebezhetőségeket a felelősségteljes nyilvánosságra hozatal elvével orvosoltam.
- [ ] Átláthatóan kijelentettem, hogy mesterséges intelligenciát használtam, és felelősséget vállalok a kimenet pontosságáért.
Modul vizsga
1. Hogyan határozható meg a legpontosabban a „hamis minősítés” a minőségbiztosítási kontextusban?
- A) Bár a teszt zöldre vált, valójában nem erősít meg semmilyen viselkedést; ✔ Nem válik pirosra még akkor sem, ha a kód sérült
- B) A teszt nagyon lassan fut, és időtúllépéssel.
- C) A teszt valódi hibát észlel, és pirosra vált
- D) A teszt csak éles környezetben fut
Magyarázat: Pszeudo-megfelelt, amikor a teszt azt mondja, hogy „megfelelt”, de valójában nem erősít meg semmi értelmeset; A teszt zöld, de még ha a szoftver hibás is, akkor sem fogja el. Ez a mesterséges intelligencia első számú kockázata a minőségbiztosításban, mivel a mesterséges intelligencia hajlamos olyan teszteket produkálni, amelyek jól néznek ki, de üresek.
2. Mi a mesterséges intelligencia legpontosabb pozicionálása a tesztelési és minőségbiztosítási folyamatban?
- A) A mesterséges intelligencia el tudja dönteni, hogy a verzió kiadható-e emberi jóváhagyás nélkül
- B) A mesterséges intelligencia olyan asszisztens, amely vázlatokat és ötleteket generál; A „közzétételre kész-e” döntése és felelőssége a szakértőt illeti ✔
- C) A mesterséges intelligencia csak szöveget ír, tesztkóddal egyáltalán nem tud bánni
- D) A mesterséges intelligencia mindig helyes tesztet ír, mint az ember, ezért az áttekintés felesleges
Leírás: A mesterséges intelligencia tesztelési asszisztens, vázlatgenerátor és ötletszorzó; tesztforgatókönyveket, automatizálási kódokat és jelentéstervezeteket készít. Azonban a minőséggel kapcsolatos döntések felelőssége és végső jóváhagyása, mint például „kész-e ez a szoftver közzétételre” vagy „megfelelt-e ez a teszt”, az illetékes szakértőé.
3. Abból a tényből kiindulva, hogy a hibák többnyire küszöbértékeknél fordulnak elő, melyik teszttervezési technika a 17, 18 és 19 külön-külön tesztelése a 18 éves korhatárhoz?
- A) Állapotátmeneti teszt
- B) Döntési táblázat
- C) Határérték elemzés ✔
- D) Feltáró tesztelés
Magyarázat: A határérték-elemzés azon a megfigyelésen alapul, hogy a hibák leggyakrabban a határoknál fordulnak elő, és külön-külön teszteli a küszöbértékeket (a határérték alatti, feletti és éppen feletti). Ez egy hatékony technika, amely kiegészíti az ekvivalencia osztályokat.
4. Melyik megközelítést érdemes előnyben részesíteni az elemkiválasztás során a mesterséges intelligenciával előállított felhasználói felület tesztautomatizálási kódjának törékenységének csökkentése érdekében?
- A) A lehető leghosszabb XPath útvonal használata
- B) Az elem kiválasztása pixelpozíciója szerint a képernyőn
- C) CSS osztályneveken alapuló szelektorok használata
- D) A teszteléshez hozzáadott stabil attribútumok (data-testid) használata ✔
Magyarázat: A hosszú XPath elérési utak és a CSS-osztálynevek rendkívül függenek az oldal szerkezetétől és kialakításától; A legkisebb interfész-módosításra is megszakad. A kifejezetten teszteléshez hozzáadott stabil attribútumokat (pl. data-testid) nem érintik a tervezési változtatások, és a teszteket robusztussá teszik.
5. Miért nem elég, ha egy API teszt csak a HTTP állapotkódot (pl. 200) ellenőrzi?
- A) Mivel a helyes állapotkóddal rendelkező testadatok megsérülhetnek, és az állapotellenőrzés önmagában ezt nem fogja fel (pszeudo-bizalom) ✔
- B) Mert az állapotkódok egyáltalán nem megbízhatóak az API-tesztekben
- C) Mert az állapotkód ellenőrzése nagyon lelassítja a tesztet
- D) Mivel az állapotkód soha nem kerül visszaadásra az API-tesztekben
Magyarázat: Bár a kiszolgáló a helyes állapotkódot adja vissza, előfordulhat, hogy a törzsben hibás adatokat ad vissza (rossz típus, hiányzó mező, helytelenül számított érték). Az a teszt, amely csak a helyzetet nézi, ezt nem látja, és hamis önbizalmat ad. Tehát a séma/szerződés és az üzleti szabály érvényesítését is hozzá kell adni.
6. Miért kritikus az AI-nak megmondani, hogy „manuálisan számítsa ki a várható értéket az elfogadási szabály szerint, ne hivatkozzon a függvény aktuális kimenetére” a nyomtatási egységtesztek során?
- A) Mivel a kézi számítás gyorsabban futtatja a teszteket
- B) Mert egyébként a teszt elfogadja a kód jelenlegi (talán hibás) viselkedését „helyesnek”, és megerősíti a hibát ✔
- C) Mert a mesterséges intelligencia egyáltalán nem tud decimális számokat kiszámítani
- D) Mert a tesztekben soha nem használnak elfogadási szabályokat
Magyarázat: Ha az AI a várt értéket a tesztelt függvény kimenetéből származtatja, akkor a tesztet akkor is „megfelelt”, ha a funkció hibás; Vagyis bármit is produkál a kód, a teszt igaznak számít. A várható értéknek az elfogadási szabálytól függetlenül történő kiszámítása biztosítja, hogy a teszt a szabály kapuőre, nem pedig a kód tükre.
7. Az alábbiak közül melyik a legmeghatározóbb jellemzője a jó hibajelentésnek?
- A) Legyen a lehető leghosszabb és technikásabb
- B) Mesterséges intelligencia írta
- C) Olyan determinisztikus reprodukálási lépéseket tartalmaz, amelyeket a fejlesztő önállóan követhet, és hibát okozhat ✔
- D) Ez csak egy képernyőkép
Magyarázat: A hibajelentés valódi értéke az, hogy a fejlesztő az Ön segítsége nélkül is reprodukálhatja a hibát. Determinisztikus, nyomon követhető reprodukálási lépések a semmiből biztosítják ezt; Ha ezek a lépések hiányoznak, a jelentés gyakran „nem sikerült elkészíteni” üzenetet zárni.
8. Melyik a legpontosabb kifejezés a súlyosság és a prioritás kapcsolatára a kezdőlapon szereplő cégnév elírási hibájában?
- A) Az intenzitás és a prioritás mindig azonos értékű legyen
- B) Ennek a hibának mind a súlyossága, mind a prioritása határozottan alacsony
- C) A súlyosság és a prioritás ugyanaz, egyetlen címke is elegendő
- D) Lehet, hogy a technikai intenzitás alacsony, de az üzleti prioritás (hírnév) magas; A kettőt eltérően értékelik ✔
Magyarázat: A súlyosság a hiba technikai hatása (technikailag alacsony elírás), a prioritás az, hogy milyen sürgősen kell kijavítani (magas, mert ez egy hírnév elem, amelyet minden látogató lát). A kettő nem mindig megy ugyanabba az irányba; Ez a példa egy alacsony súlyosságú, magas prioritású helyzet.
9. Melyik a legpontosabb értelmezése a 90%-os vonallefedettséggel rendelkező tesztcsomagnak?
- A) Megmutatja, hogy a sorok végrehajtásra kerültek, de nem bizonyítja, hogy helyesen viselkednek; ✔ A magas lefedettség hamis magabiztosságot adhat
- B) Határozottan bizonyítja, hogy a szoftver 90%-a hibamentes
- C) Ez a kiváló tesztminőség végleges mérőszáma.
- D) Azt jelzi, hogy nincs szükség további tesztek írására
Magyarázat: A sorlefedettség azt jelzi, hogy csak sorokat hajtottak végre; Ez nem bizonyítja, hogy megfelelő eredményeket produkál. Még az assertless tesztekkel is 90%-os lefedettség érhető el. A hatókör egy „soha nem néztem hova” térkép, nem pedig „mindent teszteltünk” biztosíték; a tényleges védelmet mutációteszttel mérik.
10. Kockázatalapú tesztelés során hogyan számítják ki egy adott funkció kockázatát a korlátozott tesztelési erőfeszítések irányítására?
- A) Csak a kódsorok száma szerint
- B) A meghibásodás valószínűségének és a meghibásodáskor bekövetkező hatásnak a szorzásával ✔
- C) Csak a funkció fejlesztésének sorrendjében
- D) Csak annak a funkciónak adjon prioritást, amelyhez a legkönnyebb teszteket írni
Magyarázat: A kockázat alapú tesztelés során a kockázat értékelése a valószínűség = valószínűség (a meghibásodás valószínűsége) × hatás (sérülés, ha törött). A nagy valószínűségű és nagy hatású tartományok (fizetés, hitelesítés) megérdemlik a legintenzívebb tesztelést, míg az alacsony × alacsony tartományok könnyű tesztelést kapnak.
11. Mi a fő kockázata annak, ha újrapróbálkozást adunk egy olyan teszthez, amely néha sikeres, néha pedig sikertelen (törékeny/pelyhes), bár a kód nem változott?
- A) A teszt lefutási idejének lerövidítése
- B) Csökkenti a lefedettséget
- C) Valódi párhuzamossági hiba vagy kiváltó ok elfedése és a tünet elfojtása ✔
- D) A teszt nevének megváltoztatása
Magyarázat: Az újrapróbálkozás diagnosztikai eszköz, nem kezelés. A határozatlanság gyakran tényleges faji állapotból vagy függőségből ered; Ha a tesztet újrapróbálkozással sikeressé teszi, az elfedi ezt a valódi hibát, és komoly problémákat okozhat élőben. Először a kiváltó okot kell megtalálni.
12. Hogyan működik a mutációs tesztelés, a legőszintébb módszer annak mérésére, hogy egy tesztkészlet valóban véd-e?
- A) A tesztek futási sebességének mérésével
- B) Megszámolva, hogy hány sornyi kódot írtak
- C) A tesztek különböző sorrendben történő futtatásával
- D) Szándékosan kis töréseket hozva létre a kódban, és megmérve, hogy a tesztek elkapják-e őket ✔
Leírás: A mutációtesztelés kis szándékos torzításokat (mutációkat) hoz létre a forráskódban; Egy jó tesztcsomagnak el kell fogadnia ezeket a torzításokat, és pirosra kell váltania. A nem elkapott (túlélt) mutációk azt jelzik, hogy a tesztek nem őrzik meg ezt a viselkedést. A mutációs pontszám sokkal őszintébb minőségmérő, mint a százalékos lefedettség.
13. Mi a fő követendő korlát a biztonsági tesztelés (pl. engedélyezési/IDOR tesztek) végrehajtása során?
- A) Csak saját termékén szabad, írásos felhatalmazáson belül és meghatározott körben, védekezési célból végezni ✔
- B) Bármilyen érdeklődési rendszerre szabadon alkalmazható
- C) Üzleti partnerek élő rendszerein engedély nélkül kipróbálható
- D) A talált sebezhetőségeket haladéktalanul nyilvánosan közzé kell tenni.
Leírás: Az ebben a modulban elsajátított biztonsági tesztek kizárólag saját termékének védekezési célú tesztelésére szolgálnak, írásos felhatalmazáson belül és meghatározott körben. Valaki más rendszeréhez engedély nélkül hozzáférni vagy a hatókörön kívüli tesztelést végezni etikátlan és illegális; A talált sebezhetőségeket felelősségteljes nyilvánosságra hozatal útján jelentik.
14. Milyen felhatalmazást soha nem szabad az MI-nek adni a CI/CD folyamatban?
- A) Sikertelen tesztnaplók összegzése
- B) Jogosultság a sikertelen (piros) teszt automatikus „átmenésére”, vagy zöldre festésére ✔
- C) Teszt kódtervezet javaslata
- D) Pipeline YAML fájl vázlat
Leírás: A mesterséges intelligencia tesztkód vázlatot, YAML-folyamatot és naplóösszegzést tud készíteni CI/CD-ben; azonban soha nem szabad megadni a sikertelen teszt automatikus „átmenő/javításának” lehetőségét. Ez meghiúsítja a tesztelés célját, és automatikusan elfedi a hibákat. A teszt zöldre festése az ember tudatos és megfontolt döntése kell, hogy legyen.