På denne side
En grøn test kan skjule en manglende regel. I dette tænkte eksempel bliver en agent bedt om at forbinde en butik til en e-mailplatform. En testserver accepterer en kontaktopdatering og returnerer et pænt 200. Agenten afslutter opgaven, og testen består.
Det rigtige målsystem har en ekstra regel: Den brugerdefinerede attribut skal være defineret, før en kontaktopdatering kan sætte den. Testserveren modellerede ikke den regel. Dens grønne resultat beviser noget om agenten i testverdenen. Det beviser intet om den manglende regel i den virkelige verden.
Det er simuleringens centrale afvejning. Den gør farlige eller dyre handlinger gentagelige. Den skaber også et andet system, hvis adfærd kan glide væk fra det første.
Et testmiljø gør handlingstests mulige
Hvis du vil teste en agent, der handler, skal du give den et mål, et miljø og en observerbar sluttilstand. En samtale om simulerede agentmiljøer beskriver den struktur for browseropgaver og vidensarbejde. Miljøet lader en kontrol sammenligne det, agenten efterlod, med et kendt korrekt resultat.
I en integration kan testmiljøet tilbyde et lille sæt handlinger i målsystemet: vis felter, opret en kontakt, opdater en kontakt, og læs en kontakt tilbage. Det kan have et testgrundlag med et defineret felt FNAME og et manglende felt CUSTOM_TIER. En test kan bede agenten foreslå en mapping og derefter afvise en opdatering, der bruger CUSTOM_TIER, før definitionen findes.
Testmiljøet er nyttigt, fordi hver kørsel begynder i samme tilstand. Du kan ændre én betingelse ad gangen: et manglende felt, en afvist tilladelse, en forældet skemaversion eller et tvetydigt id. Du kan sammenligne agentens kaldrækkefølge og sluttilstand på tværs af modeller eller prompts.
Det er stærkere end et rent tekstspørgsmål om, hvad agenten ville gøre. Det tester, hvad agenten faktisk kaldte i en kontrolleret verden.
Giv testgrundlaget en tilstand før og efter hvert kald, ikke kun et standardsvar. Hvis agenten opretter en kontakt to gange, bør det andet kald vise den dubletadfærd, du vil teste. Hvis den læser et felt efter en opdatering, bør læsningen returnere den gemte tilstand. Ellers kan en agent bestå ved at sende en rimelig forespørgsel, mens testen aldrig opdager, om rækkefølgen skabte den tilsigtede post.
Simuleringens nøjagtighed er en del af testen
Den rimelige indvending er: »Leverandøren har en sandbox. Hvorfor bygge en til?« Brug leverandørens testmiljø, når det understøtter den nødvendige sag og holder dataene sikre. Et lokalt testmiljø fortjener sin plads, når du har brug for ensartet nulstilling, bevidste fejl eller en måde at teste kald på, som leverandørens sandbox ikke kan iscenesætte. Det koster også vedligeholdelse. Hver regel, du modellerer, kan være forkert eller blive forældet.
Det officielle Brevo-API til kontakter siger, at kontaktattributter skal findes på kontoen, og at værdier med forkert defineret type ignoreres. Et testmiljø, der afviser enhver forkert værdi, ville opføre sig anderledes end det dokumenterede tilfælde. Det kan lære agenten at forvente en fejl, der aldrig kommer.
Skriv ned, hvilken leverandøradfærd testmiljøet dækker. Vedligehold et lille sæt kontraktkontroller mod det rigtige API eller dets understøttede testmiljø. Når en kontrol finder en forskel, skal du opdatere simuleringen og tilføje den sag, der afslørede forskellen. Simuleringen er en model af leverandøren, ikke en erstatning for leverandøren.
Samme disciplin gælder tid. Et testmiljø, der gør hver opdatering synlig straks, kan overse en arbejdsgang, der læser for tidligt. Et testmiljø, der forsinker alle opdateringer, kan opfinde fejl, som leverandøren ikke har. Modellér kun timing, hvor den påvirker den beslutning, der testes, og markér resten som uden for simuleringen. En bestået test får dermed en præcis betydning: Denne agent udførte disse handlinger under disse modellerede regler.
Tajos guide til Brevo-connectoren beskriver samme praktiske problem fra butikkens side: En vellykket forespørgsel kan betyde, at et felt stadig mangler. En test er kun nyttig, hvis den kontrollerer feltet, ikke blot HTTP-svaret.
Et simuleret målsystem tester en agent under modellerede regler. Kontraktkontroller sammenligner reglerne med det rigtige målsystem før en afgrænset forhåndsvisning.
Gå fra sikker øvelse til afgrænset dokumentation
En bestået simulering bør føre til en lille forhåndsvisning i det rigtige system. Vælg nogle få poster med klart forventede tilstande i målsystemet. Medtag en normal post, et manglende valgfrit felt og en post, hvis samtykkestatus forbyder marketingbrug. Kontrollér, hvad målsystemet faktisk gemmer. Udled ikke resultatet alene fra de data, anmodningen sendte.
En syntetisk forhåndsvisning og en destinationskontrol besvarer forskellige spørgsmål. Tajos mappingforhåndsvisning tester en oversættelse uden skrivning til destinationen. Den foreslåede aktivitetsvisning viser næste grænse: Selv en anvendt opdatering kræver kontrol af destinationens tilstand. Når sidste trin står som afventende, bliver øvelsen ikke forvekslet med bevis.
En afsluttet skrivning kræver stadig bevis
Blev kundesynkroniseringen færdig?
Skrivning anvendt. Verifikation afventer.
Destinationens tilstand er endnu ikke kontrolleret.
Synkroniseringsaktivitet
- Anmodning accepteret
- Opdatering anvendt
- Destinationskontrol afventer
Eksempelkørsel · 14:32 UTC
Det ved vi
- Udbyderens svar
- Accepteret
- Skriveresultat
- Anvendt
- Tilbagelæsning fra destination
- Afventer
Et vellykket kald beviser ikke sluttilstanden.
Foreslået layout inspireret af Tajos aktivitetslog. Illustrationen tilføjer en verifikationstilstand; den påstår ikke, at tilbagelæsning fra destinationen allerede er implementeret.
Forhåndsvisningen bør have et snævert omfang og en klar stopbetingelse. En fejl bør forhindre bred aktivering og pege tilbage på den præcise afvigelse: feltdefinition, id, type, tilladelse eller timing. En bestået forhåndsvisning beviser ikke, at alle fremtidige poster opfører sig ens. Den dokumenterer, at kontrakten virker for de valgte sager i dag.
Rækkefølgen adskiller to spørgsmål. Simuleringen spørger: »Følger agenten den designede regel, når vi kontrollerer verden?« Forhåndsvisningen i det rigtige system spørger: »Passer den designede regel til denne leverandørkonto?« Det ene spørgsmål kan ikke erstatte det andet.
Guiden til reverse ETL forklarer, hvorfor den endelige opgave gentages for mange poster. Gentagelsen forstørrer enhver tilbageværende forskel mellem den simulerede og den rigtige kontrakt.
Øv dig i en verden, du kan nulstille. Undersøg derefter den verden, du ikke kan.
Ofte Stillede Spørgsmål
Hvad kan et simuleret målsystem teste?
Det kan teste, om en agent vælger de forventede kald, respekterer tilladelser, håndterer kendte fejl og efterlader den forventede tilstand i simuleringen.
Hvad kan det ikke bevise?
Det kan ikke fastslå, at dets model af leverandøren er fuldstændig. Udokumenteret adfærd, timing og kontospecifik opsætning kan afvige fra simuleringen.
Hvad bør følge efter en vellykket simulering?
Kør en afgrænset forhåndsvisning eller en lille prøve mod det faktiske målsystem, og undersøg derefter resultatets tilstand før bred aktivering.