Automatisert handelsprogramvare for Solana bør vurderes med situasjoner som har observerbare forventede utfall. En funksjonsliste kan si at programvaren støtter risikokontroller, nye forsøk eller gjenoppretting uten å vise virkningen når dokumentasjon er foreldet eller transaksjonsstatus usikker. Aksepttilfeller gjør påstandene til spørsmål som kan besvares fra registreringer.
Et aksepttilfelle begynner med kjent tilstand, innfører et kontrollert vilkår og spesifiserer atferden som teller som bestått. Det navngir også dokumentasjonen som trengs for å fastslå atferden. En grønn skjermmelding er utilstrekkelig hvis testen gjelder kontotilstand eller om en duplikathandling ble opprettet.
Tilfellene nedenfor er pedagogiske og leverandørnøytrale. De kan tilpasses et kontrollert miljø eller en modus uten signering der det passer. De verken autoriserer virkelig ibruktaking, foreskriver en bestemt strategi eller fastslår produksjonsutførelseskvalitet bare fordi et testmiljø oppfører seg riktig.
Aksept av automatisert Solana-programvare trenger omfang
Definer arbeidsflyten som skal aksepteres. En signaltjeneste bare for undersøkelser, et manuelt signert handelsverktøy og en ubemannet strategi har forskjellige fullmaktsgrenser. Testsettet bør passe foreslått bruk fremfor å anta at alle produkter skal utføre alle roller.
Oppgi støttet nettverk, eiendeler, programmer, handlingstyper og kontomodell. Identifiser komponentene som inngår og dem som simuleres. Et bestått resultat gjelder omfanget. Det bør ikke utvides til en påstand om ustøttede markeder eller uprøvde tillatelsesmekanismer.
Veiledningen om handelsautomatisering på Solana beskriver tidsstyring rundt token-, markeds- og lommeboktilstand. Aksepttilfeller bør prøve tilstandsavhengighetene direkte. Programvaren bør demonstrere hva den gjør når én forutsetning endres, ikke bare gjenta en vellykket handling under ideelle forhold.
Skriv dokumentasjonskravet før tilfellet kjøres
Avgjør for hvert tilfelle hvilken registrering som beviser forventet atferd. Et avvist forslag trenger en begrunnelse og fravær av et resulterende uautorisert forsøk. En fullført handling trenger hensikt, forsøksidentitet og avstemt kontovirkning. Et gjenopprettingstilfelle trenger tilstand før og etter avbrudd.
Bevar programvareversjon, konfigurasjon, inngangsobservasjoner og relevant kontoutgangspunkt. Uten dem kan en senere gransker være ute av stand til å gjenskape resultatet eller avgjøre om en reparert versjon oppfører seg annerledes. Testrapporten bør fortsatt være nyttig etter grensesnittendring.
Akseptdokumentasjon for automatisering bør omfatte negative utfall. Riktig avståelse eller avslag kan være tiltenkt bestått-vilkår. Å behandle alle avslag som testfeil oppmuntrer programvare til å handle når egen dokumentasjonsavtale sier stopp, motsatt av det akseptprosessen skal fastslå.
Tilfelle: Visningssymbolet samsvarer med feil mint
Opprett to fiktive eller kontrollerte registreringer med samme lesbare symbol, men forskjellige mintidentiteter. Presenter et forslag der visningsnavnet ligner den tillatte eiendelen mens minten ligger utenfor tillatt omfang. Forventet resultat er avslag eller uavklart identitet før signering eller innsending.
Dokumentasjonen bør vise hvilken identifikator autoriseringen kontrollerte. Hvis programvaren godtar forslaget fordi symbolet samsvarer, viser testen en grensesvikt. Hvis den avviser med bare generell feil, kan atferden være trygg mens forklaringen trenger forbedring.
Undersøk også eksporter. Forsøket med feil mint bør ikke senere vises under tillatt eiendels historikk bare fordi navnene ligner. Identitet må være konsekvent gjennom grensesnitt, autorisering, utførelse og rapportering. Riktig etikett på første skjerm er ikke nok hvis varig registrering slår eiendelene sammen.
Tilfelle: Tokenenheter avviker fra råbeløpet
Bruk en kontrollert tokenmengde med kjent desimaltolkning. Råbeløpet 1 250 000 under seks desimaler representerer for eksempel 1,25 tokener. Forslag, autoriseringsgrense og vist beløp bør være enige om tolkningen.
Forventet resultat er konsekvent enhetshåndtering fra inndata til kontoregistrering. En budsjettgrense i hele tokener bør ikke sammenlignes direkte med råheltallet. Et kopiert beløp bør ikke endre betydning mellom pristilbudsvisning og transaksjonsforhåndsvisning.
Registrer både rå og lesbare verdier der testen krever dem. En enhetsfeil kan gi en stor utilsiktet handling mens hvert enkelt felt ser numerisk og gyldig ut. Tilfellet er verdifullt fordi det tester forholdet mellom komponenter fremfor bare om én omregningsfunksjon gir forventet tall.
Tilfelle: Nødvendig dokumentasjon er foreldet
Gi et forslag der støttende pristilbud eller markedsobservasjon er eldre enn regelens ferskhetsgrense. Hold resten gyldig så feilen kan tilskrives alder. Forventet resultat er bestemt avståelse eller avslag, uten ny innsending autorisert fra foreldet dokumentasjon.
Gi så en fersk observasjon og verifiser at programvaren vurderer forslaget på nytt under gjeldende forhold. Den bør ikke bare gjenoppta gammel godkjenning uten å kontrollere om beløp, rute eller kontotilstand endret seg. Ferske data kan gi ny gjennomgang, men gjør ikke gammel dokumentasjon oppdatert i ettertid.
Testregistreringen bør skille hendelsestid, innhentingstid og vurderingstid. Hvis ferskhet måles fra meldingsankomst mens underliggende observasjon er gammel, kan tilfellet bestå overflatisk og likevel bryte tiltenkte regler. Undersøk klokken som faktisk brukes i beslutningen.
Tilfelle: To forslag konkurrerer om ett budsjett
Begynn med et hypotetisk tilgjengelig budsjett på 100 enheter og to samtidige forslag på seksti hver. Under regler uten lån eller overforpliktelse kan ikke begge få uavhengig full autorisering. Forventet atferd er samordnet reservasjon, avslag eller rekkefølge etter oppgitt regel.
Hvis første forslag reserverer seksti enheter, er bare førti ureserverte i det forenklede tilfellet. Andre forslag bør få et forklart resultat som gjenspeiler tilstanden. Nøyaktig rekkefølge kan variere, men samlede forpliktelser må være i samsvar med reglene.
Den tidligere veiledningen om varig Solana-automatisering forklarer hensikter og reservasjoner. Aksepttilfellet verifiserer at implementasjonen håndhever felles hovedbok ved samtidighet. En sekvensiell demonstrasjon av hvert forslag alene ville oversett konflikten helt.
Testtilfeller for Solana-programvaren trenger ukjente utfall
Mange feil er usikre fremfor tydelig negative. En forespørsel kan få tidsavbrudd etter innsending, en kilde gi ufullstendig status eller en prosess stoppe før et svar lagres. Tester bør representere tilstandene uttrykkelig fremfor å behandle hvert unntak som bevis på at ingen handling skjedde.
Forventet atferd er et varig uavklart forsøk knyttet til opprinnelig hensikt, med avhengige handlinger begrenset av avstemmingsreglene. Programvaren bør søke dokumentasjon om forsøket før den avgjør om en annen økonomisk handling tillates.
Testtilfeller for automatisert handelsprogramvare på Solana bør derfor inkludere ukjente utfall som egne fullverdige tilfeller. Et system som håndterer vellykkede og mislykkede transaksjoner riktig, kan fortsatt skape duplikateksponering hvis perioden mellom dem håndteres feil. Akseptregistreringen må undersøke intervallet, ikke bare endelig status.
Tilfelle: Innsending godtas, men er ikke bekreftet ennå
Simuler eller observer et innsendingssvar som gir forsøksidentitet mens bekreftelse venter. Grensesnittet bør vise innsendt eller tilsvarende tilstand, bevare relevant ressursreservasjon og fortsette utfallskontroll etter reglene.
Solana dokumenterer at et vellykket sendTransaction-svar ikke i seg selv garanterer behandling eller bekreftelse. Aksepttesten bør verifisere at programvaren ikke merker kontoresultatet komplett bare fordi RPC-kallet var vellykket. Solanas innsendingsdokumentasjon.
Bestått-dokumentasjonen omfatter tilstandsovergangshistorikken og fravær av for tidlig avstemming. En suksessanimasjon kan være akseptabel som innsendingskvittering med tydelig ordlyd, men bør ikke antyde at ønsket tokensaldo allerede er fastslått.
Tilfelle: Et nytt forsøk følger en ukjent innsending
Avbryt svarveien etter at et forsøk kan være sendt inn. Utløs dokumentert nytt forsøk eller gjenopprettingsprosedyre. Forventet resultat er fortsatt håndtering av samme hensikt med nok forsøksidentitet til å unngå en ny ordre bare fordi første svar manglet.
Undersøk varige registreringer for dupliserte hensikter og ressursreservasjoner. Flere nettverksforsøk kan inngå i dokumenterte innsendingsregler, men bør ikke bli separate økonomiske handlinger. Testen bør identifisere nøyaktig forhold mellom forsøkene og opprinnelig autorisert forespørsel.
Den tidligere veiledningen om API-gjenoppretting på Solana drøfter avgrensede nye forsøk og gjenoppretting. Tilfellet tester om mekanismene bevarer betydning. Et nytt forsøk som til slutt gir saldoendring, er ikke automatisk riktig hvis kontoen også inneholder en utilsiktet duplikathandling.
Henvis og tjen USDC
Henvis og tjen USDCPartnerprogrammet vårt betaler i sanntid.
Tilfelle: Et delvis salg etterlater en reell posisjon
Begynn med en kontrollert posisjon på 1 000 tokener og foreslått salg av 400. Etter et støttet utfall bør programvaren bevare en posisjon på 600 tokener under dette forenklede mengdeeksemplet, med kostnader og innbetalinger separat. Den bør ikke merke hele posisjonen avsluttet fordi en salgshandling ble fullført.
Undersøk deretter senere salgsregler. De bør bruke gjenværende mengde og gjeldende kontodokumentasjon. En ny utløser bør ikke forsøke å selge de opprinnelige 1 000 tokenene eller anta at første salg fjernet all eksponering. Posisjonsforløpet må overleve utover ett handelskort.
Veiledningen om automatiske Solana-handlere dekker delvise salg og gebyrer, mens den tidligere veiledningen om gevinstsikring og tapsgrenser på Solana forklarer samordning av salgsvilkår. Tilfellet kontrollerer den felles posisjonsregistreringen begge kontrolltyper avhenger av.
Tilfelle: Et gebyr endrer kontoen uten en vellykket handel
Bruk et støttet feilscenario der kontoen pådrar seg et transaksjonsgebyr uten at tiltenkt bytte fullføres. Programvaren bør registrere mislykket forsøk og aktuell kostnad fremfor å behandle hendelsen som helt uten kontovirkning.
Solanas dokumenterte transaksjonsmodell sier at mislykket utførelse fortsatt kan gi gebyrer. Aksepttilfellet bør undersøke om regnskapet gjenspeiler faktisk observert virkning i kontrollert miljø. Det bør ikke anta et fast universelt gebyrbeløp. Solanas transaksjonsdokumentasjon.
Bestått-dokumentasjonen omfatter forsøksstatus, kontoendring og kostnadsklassifisering. En rapport med bare vellykkede handler ville ikke forklare resultatet selv om synlig posisjonsmengde var riktig. Komplett regnskapsføring inkluderer driftsforsøk som ikke oppnådde tiltenkt bytte.
Tilfelle: En ustøttet tokenegenskap dukker opp
Presenter en token- eller kontokonfigurasjon utenfor dokumentert tolkningsstøtte. Forventet resultat er tydelig ustøttet eller uavklart tilstand uten automatisk erstatning med gunstige standardverdier. Vellykket henting av kontodata fastslår ikke at programvaren forstår hver relevant egenskap.
Testen bør identifisere grensen som stoppet arbeidsflyten. Det kan være tolkeren, kvalifiseringsregelen, pristilbudsveien eller autoriseringskontrollen. En navngitt begrensning lar brukeren skille manglende støtte fra midlertidig nettverksfeil og hindrer meningsløse gjentatte forsøk.
Ikke krev støtte for hvert mulig tilfelle for å bestå en avgrenset vurdering. Krev ærlig håndtering av oppgitt grense. Ustøttede tilfeller blir farlige når grensesnittet skjuler dem som vanlige støttede eiendeler eller utelater begrensningen fra forslagets dokumentasjonsregistrering.
Tilfelle: Fullmakt trekkes tilbake under arbeidsflyten
Forbered et forslag og trekk deretter relevant signerings- eller delegert fullmakt tilbake gjennom mekanismen i den kontrollerte testen. Neste trinn bør svikte trygt og forklare at fullmakten er utilgjengelig. Tidligere intern godkjenning bør ikke erstatte gjeldende ekstern tillatelse.
Programvaren bør bevare forslag og mislykket autoriseringsvei uten gjentatte krav om bredere tilgang. Hvis en ny tillatelse trengs, bør det være en separat uttrykkelig gjennomgang. Testen bør også verifisere at avstemming med bare lesing fortsatt er tilgjengelig der oppsettet støtter det.
Nøyaktig tilbakekallingsprosedyre avhenger av fullmaktsmodellen. Akseptrapporten bør navngi mekanismen som faktisk ble testet og unngå generalisering til alle lommebok- eller delegeringsoppsett. Bestått demonstrerer riktig håndtering av definert grense, ikke universell oppbevaringstrygghet.
Tilfelle: Prosessen starter på nytt med åpent arbeid
Opprett varig tilstand med én fullført hensikt, ett autorisert, men ikke innsendt forslag og ett uavklart innsendt forsøk. Start programvaren på nytt. Hvert punkt bør komme tilbake med riktig identitet og status fremfor å flates ut til en generell venteliste.
Det ikke innsendte forslaget kan trenge utløp eller ny vurdering. Det innsendte forsøket trenger avstemming. Fullført hensikt bør ikke kjøres igjen. Forskjellige utfall gjør tilfellet mer informativt enn omstart av et tomt program med kontroll av hjemmeskjerm.
Undersøk ressursreservasjoner etter omstart. De bør samsvare med gjenopprettet tilstand uten uforklart frigjøring eller duplisering. Riktig omstart bevarer økonomiske forhold mellom registreringer så vel som registreringene selv.
Tilfelle: Regelversjonen endres midt i en episode
Åpne et kontrollert signal eller forslag under versjon A og aktiver så versjon B med endret kvalifiserings- eller størrelsesregel. Programvaren bør følge dokumenterte overgangsregler: fortsette gammel episode under A, avslutte den eller migrere med uttrykkelig registrering.
Forventet resultat er ikke ett universelt overgangsvalg. Det er samsvar med oppgitte regler og bevaring av opprinnelig versjon. En gransker bør kunne forklare hvorfor lignende observasjoner før og etter aktivering ga forskjellige beslutninger.
Veiledningen om handelsalgoritmer for Solana følger én algoritme gjennom observasjoner, regler og gjennomgang. Aksepttesting kontrollerer at kjeden er intakt når implementasjonen endres. Stille nytolkning av gamle beslutninger under gjeldende versjon gjør senere undersøkelser og hendelsesgjennomgang upålitelige.
Tilfelle: Eksport rekonstruerer en mislykket arbeidsflyt
Eksporter et tilfelle med en avståelse, et avvist forslag, et ukjent forsøk som senere ble avklart og en delvis posisjon. Be en gransker rekonstruere sekvensen uten det aktive grensesnittet. Eksporten bør bevare identiteter, tidspunkter, enheter, versjoner, kostnader og rettelsesforhold som trengs.
En liste over vellykkede transaksjoner består ikke den bredere testen. Den utelater beslutninger og usikkerhet som forklarer arbeidsflyten. Rapporten bør oppgi manglende registreringer fremfor å anta at en nedlastbar fil er komplett fordi den åpnes.
Undersøk også eksporten for hemmelig materiale. Driftsreferanser bør identifisere fullmaktsveien uten å eksponere privat legitimasjon. En nyttig akseptregistrering kan deles til gjennomgang og holde evnen til eiendelskontroll atskilt fra evnen til å forstå hva som skjedde.
Bedøm feil etter følge og årsak
Når et tilfelle feiler, identifiser om problemet gjelder korrekthet, fullmakt, regnskapsføring, gjenopprettbarhet eller forklaring. Kategoriene hjelper med å prioritere reparasjon. En misvisende statusetikett og en utilsiktet duplikathandling er begge mangler, men har forskjellige følger og krever forskjellig senere validering.
Bevar feildokumentasjonen og reparert versjon. Kjør berørt tilfelle og nært beslektede tilfeller som prøver endret grense, på nytt. Ikke behandle en reparasjon som ferdig bare fordi opprinnelig feilmelding forsvinner; underliggende konto- og tilstandsatferd må oppfylle forventet resultat.
Tester bør fortsatt være meningsfulle når programvaren utvikles. Fjern tilfeller bare når omfanget ikke lenger støttes og produktdefinisjonen endres tilsvarende. Et krympende testsett bør ikke i det stille forbedre tilsynelatende beståttandel ved å utelate vanskelig atferd arbeidsflyten fortsatt avhenger av.
Bevar tilfeller som består ved å gjøre ingenting
Noen av de viktigste tilfellene ender uten transaksjon: Foreldet dokumentasjon gir avståelse, utilstrekkelig budsjett gir avslag og tilbakekalt fullmakt hindrer signering. Bevar tilfellene i akseptrapporten fremfor å behandle dem som innledende oppsett til suksessveien.
Dokumentasjonen bør vise hvorfor ingen handling skjedde og om ressurser eller tillatelser feilaktig var aktive etterpå. Et riktig avslag kan fortsatt etterlate en reservasjon som ikke ble frigjort, eller misvisende åpen status. Undersøkelse av hele ingen-handling-utfallet bekrefter at programvaren både respekterte grensen og returnerte arbeidsflyten til en forståelig tilstand.
Aksepter en definert arbeidsflyt, ikke et løfte
Endelig akseptrapport bør identifisere testet versjon, miljø, fullmaktsmodell, støttet omfang, tilfelleresultater og uprøvde begrensninger. Den bør skille observert dokumentasjon fra påstander bare støttet av dokumentasjon og simulert atferd fra produksjonsatferd.
Aksept av automatisert handelsprogramvare for Solana er sterkest når den viser både handling og tilbakeholdenhet. Programvaren bør handle når definerte krav oppfylles, avslå eller avstå når de ikke gjør det og bevare usikkerhet til kontoresultatet kan fastslås. Atferden er mer informativ enn en bred påstand om automatiseringsevne.
En samling konkrete tilfeller gir leseren et gjennomgåelig grunnlag for innføring eller videre arbeid. Den verken fjerner markedsrisiko eller beviser strategiverdi. Den fastslår om programvaren håndterer spesifisert arbeidsflyt på en måte som kan forklares, gjenopprettes og kontrolleres mot fullmakten den faktisk fikk.