Ezen az oldalon
Egy zöld teszt eltakarhat egy hiányzó szabályt. Ebben a képzeletbeli esetben egy ügynök áruházat köt össze e-mail-platformmal. A tesztszerver elfogadja a kapcsolat frissítését, és szabályos 200 választ ad. Az ügynök befejezi a feladatot, a teszt sikeres.
A valódi célrendszerben van még egy szabály: az egyedi attribútumot deklarálni kell, mielőtt kapcsolatfrissítéssel beállítható lenne. A tesztszerver ezt nem modellezte. Zöld eredménye az ügynökről a tesztvilágban bizonyít valamit. Az élő rendszer hiányzó szabályáról semmit.
Ez a szimuláció alapvető kompromisszuma. Ismételhetővé teszi a veszélyes vagy drága műveleteket. Ugyanakkor létrehoz egy második rendszert, amelynek viselkedése eltérhet az elsőétől.
A helyettesítő lehetővé teszi a műveletek vizsgálatát
A cselekvő ügynök teszteléséhez adj neki célt, környezetet és megfigyelhető végállapotot. A szimulált ügynöki környezetekről szóló forrásbeszélgetés ezt a felépítést böngészős és tudásmunkafeladatoknál írja le. A környezetben az ellenőrző összevetheti, mit hagyott hátra az ügynök az ismert helyes eredménnyel.
Integrációnál a helyettesítő kevés célműveletet kínálhat: mezők felsorolását, kapcsolat létrehozását és frissítését, majd visszaolvasását. A tesztadatok között lehet deklarált FNAME mező és hiányzó CUSTOM_TIER mező. A teszt megkérheti az ügynököt leképezés javaslatára, majd visszautasíthatja a CUSTOM_TIER mezőre írást, amíg nincs definíciója.
A helyettesítő azért hasznos, mert minden futás ugyanabból az állapotból indul. Egyszerre egy feltételt változtathatsz: hiányzó mezőt, megtagadott jogosultságot, elavult sémaverziót, kétértelmű azonosítót. Összevetheted az ügynök hívássorrendjét és az eredményállapotot különböző modellek vagy promptok között.
Ez erősebb, mint egy szöveges kérdés arról, mit tenne az ügynök. Azt teszteli, mit hívott meg ténylegesen az ellenőrzött világban.
Az előre beállított válasz mellett minden hívás előtt és után adj állapotot a tesztadatnak. Ha az ügynök kétszer hoz létre kapcsolatot, a második hívás mutassa meg a vizsgálni kívánt duplikációs viselkedést. Ha írás után mezőt olvas, a visszaolvasás a tárolt állapotot adja. Különben az ügynök átmehet a teszten egy hihető kérés elküldésével, miközben a teszt sosem deríti ki, hogy a műveletsor létrehozta-e a megfelelő rekordot.
A hűség a teszt része
Jogos ellenvetés: „A szolgáltatónak van tesztkörnyezete; minek másikat építeni?” Használd a szolgáltatói tesztkörnyezetet, ha támogatja a szükséges esetet, és biztonságban tartja az adatokat. A helyi helyettesítő akkor éri meg, ha determinisztikus visszaállítás, szándékosan előidézett hiba vagy a szolgáltatói környezetben nem előállítható hívás kell. Fenntartási költsége is van. Minden modellezett szabály lehet hibás vagy elavulhat.
A hivatalos Brevo-kapcsolat API-dokumentáció szerint a kapcsolatattribútumoknak létezniük kell a fiókban, és a deklarált típustól eltérő értékeket a rendszer figyelmen kívül hagyja. Az a helyettesítő, amely minden hibás értéket elutasít, eltérően viselkedne ettől a dokumentált esettől. Olyan hibára taníthatná az ügynököt, amely a valóságban nem érkezik meg.
Írd le, mely szolgáltatói viselkedéseket fedi a helyettesítő. Tarts fenn néhány szerződéspróbát a valódi API-val vagy a támogatott tesztkörnyezettel szemben. Ha egy próba eltérést talál, frissítsd a helyettesítőt, és add hozzá az eltérést feltáró esetet. A szimuláció a szolgáltató modellje, nem maga a szolgáltató.
Ugyanez érvényes az időre. Ha a helyettesítő minden írást azonnal láthatóvá tesz, elszalaszthat olyan folyamatot, amely túl hamar olvas vissza. Ha minden írást késleltet, nem létező hibákat találhat ki. Csak ott modellezd az időzítést, ahol befolyásolja a vizsgált döntést, a többit jelöld a szimuláció határán kívülinek. Így a sikeres tesztnek pontos jelentése van: az ügynök ezeket a műveleteket ezekkel a modellezett szabályokkal elvégezte.
A Tajo Brevo-csatlakozóról szóló útmutatója ugyanezt a gyakorlati gondot a kereskedő oldaláról írja le: egy sikeres kérés után is hiányozhat a mező. A teszt csak akkor hasznos, ha a mezőt nézi, nem pusztán a HTTP-választ.
A szimulált célrendszer modellezett szabályok között teszteli az ügynököt. A szerződéspróbák ezeket a szabályokat összevetik az élő célrendszerrel egy szűk előnézet előtt.
A biztonságos próbától a szűk valódi bizonyítékig
A sikeres szimuláció után jöjjön egy kis élő előnézet. Válassz néhány rekordot, amelyek várt célállapota kifejezett. Legyen köztük normál rekord, hiányzó választható mező és olyan rekord, amelynek hozzájárulása tiltja a marketingfelhasználást. Ellenőrizd, mit tárol ténylegesen a célrendszer. Ne csak a kérés törzséből következtesd ki.
A szintetikus előnézet és a célrendszer ellenőrzése más kérdésekre válaszol. A Tajo leképezési előnézete az átalakítást teszteli, a célrendszerbe írás nélkül. Az alábbi javasolt tevékenységnézet a következő határt mutatja: még az alkalmazott módosítás célállapotát is ellenőrizni kell. Az utolsó lépés függőben marad, hogy a próbát ne tekintsük bizonyítéknak.
Az elvégzett íráshoz még bizonyíték kell
Befejeződött a vásárlók szinkronizálása?
Az írás megtörtént. Az ellenőrzés függőben van.
A célrendszer állapotát még nem ellenőriztük.
Szinkronizálási tevékenység
- Kérés elfogadva
- Módosítás alkalmazva
- A célrendszer ellenőrzése függőben
Példafuttatás · 14:32 UTC
Amit tudunk
- Szolgáltatói válasz
- Elfogadva
- Írás eredménye
- Alkalmazva
- Visszaolvasás a célrendszerből
- Függőben
A sikeres hívás nem bizonyítja a végső állapotot.
A javasolt elrendezés a Tajo tevékenységfolyamán alapul. Az ábra ellenőrzési állapotot ad hozzá; nem állítja, hogy a célrendszerből való visszaolvasás már megvalósult.
Az előnézet hatóköre legyen szűk, és legyen egyértelmű megállási feltétele. A hiba akadályozza meg a széles aktiválást, és mutasson a konkrét eltérésre: meződefinícióra, azonosítóra, típusra, jogosultságra vagy időzítésre. A sikeres előnézet nem bizonyítja, hogy minden jövőbeli rekord ugyanúgy viselkedik, de azt igen, hogy a szerződés a kiválasztott eseteknél ma működik.
Ez a sorrend két kérdést választ szét. A szimuláció azt kérdezi: „Követi az ügynök a tervezett szabályt egy általunk ellenőrzött világban?” Az élő előnézet pedig ezt: „Illik a tervezett szabály ehhez a szolgáltatói fiókhoz?” Egyik sem helyettesíti a másikat.
A fordított ETL-ről szóló útmutató elmagyarázza, miért ismétlődik a végső feladat sok rekordon. Az ismétlés felnagyítja a szimulált és a valódi szerződés közti minden megmaradt eltérést.
Gyakorolj abban a világban, amelyet visszaállíthatsz. Utána vizsgáld meg azt, amelyet nem.
Gyakran Ismételt Kérdések
Mit tesztelhet egy szimulált célrendszer?
Vizsgálhatja, hogy az ügynök a várt hívásokat választja-e, tiszteletben tartja-e a jogosultságokat, kezeli-e az ismert hibákat, és létrehozza-e a várt állapotot a szimulációban.
Mit nem bizonyíthat?
Nem bizonyíthatja, hogy a szolgáltatóról alkotott modellje teljes. A dokumentálatlan viselkedés, az időzítés és a fiókspecifikus beállítás eltérhet a szimulációtól.
Mi következzen sikeres szimuláció után?
Végezz szűk előnézetet vagy próbafuttatást a valódi célrendszerben, majd a széles aktiválás előtt vizsgáld meg a tényleges eredményállapotot.