Programvare for automatisert kryptovalutahandel bør spesifiseres gjennom observerbar atferd. Et krav som utfør effektivt høres nyttig ut, men forteller ikke en kontrollør hva programmet må gjøre når et pristilbud utløper, midler allerede er reservert eller svaret på en innsending forsvinner. Et testbart krav navngir inndataene, den tillatte overgangen og dokumentasjonen som fastslår resultatet.
Denne veiledningen utvikler en kostnadsbevisst aksepttest for automatisering med en fiktiv spotkonto. Tallene er oppdiktet for å gjøre regnskapet mulig å gjenskape. De representerer verken en gjeldende gebyrplan eller en forventet avkastning. Målet er å avgjøre om programvaren overholder de erklærte reglene og bevarer kontotilstanden. Å bestå testen fastslår driftsatferd, ikke at handelsstrategien er lønnsom.
Krav til programvare for automatisert kryptovalutahandel begynner med invarianter
En invariant er et vilkår som bør forbli sant gjennom vanlige hendelser og feil. Et nyttig eksempel er at samlede forpliktede kontanter ikke må overskride tilgjengelige autoriserte ressurser. Et annet er at den samme varige hensikten ikke må skape en ekstra ordre bare fordi en hendelse leveres to ganger. Disse utsagnene er sterkere enn en samling skjermbilder fra vellykkede normalforløp fordi de gjelder gjennom hele arbeidsflyten.
Skriv invarianter i et språk en kontrollør kan undersøke. Systemet må identifisere kontoen før kapital reserveres. Et ukjent ordreutfall må beholde reservasjonen. En ny konfigurasjon må ikke omskrive begrunnelsen knyttet til en eldre hensikt. Hvert utsagn bør identifisere hvilken dokumentasjon som ville vise et brudd. Hvis ingen mulig observasjon kunne motbevise et krav, er det trolig for vagt for aksept.
Den eldre veiledningen til livsløpet for automatisert handel skiller konfigurasjon, observasjon og kontoaktivitet. Bruk disse trinnene når krav fordeles. En strategikomponent kan foreslå en handling, men en uavhengig risikokomponent avgjør om handlingen passer kontogrensene. Å holde ansvaret atskilt gjør det enklere å forklare hvorfor en tilsynelatende attraktiv observasjon ikke førte til utførelse.
Definer den fiktive kontoen presist
Anta at en hypotetisk konto begynner med 2 000 noteringsenheter og ingen posisjon i den valgte eiendelen. Av saldoen er 200 enheter reservert som driftsbuffer, og 300 er allerede forpliktet til en annen aktiv hensikt. Den nye beslutningen begynner derfor med 1 500 enheter i kapasitet etter de angitte reglene. Kategoriene bør kunne skilles fra hverandre på hver skjerm og i hver eksport.
Den nye strategien foreslår å kjøpe høyst 80 eiendelsenheter til en limitpris på 10 noteringsenheter hver. I denne øvelsen antar vi et handelsgebyr på en tidel av én prosent belastet i noteringseiendelen og en separat modellert utførelsesutgift på 2 enheter. Den maksimale nye reservasjonen er 800 pluss 0,80 pluss 2, altså 802,80 noteringsenheter. Faktiske plattformkostnader må kontrolleres separat.
Registrer testoppsettet som uforanderlige testinndata. Ta med kontoidentifikatoren, eiendelsidentiteten, noteringsidentiteten, startsaldoene, eksisterende forpliktelser og gebyrantakelser. Et skjermbilde av sluttresultatet er ikke nok til å gjenskape testen. En senere kontrollør trenger å vite hvilke ressurser som var tilgjengelige før den nye beslutningen, og hvilke kostnader som inngikk i autorisasjonsbudsjettet.
Angi hva signalet har lov til å foreslå
Signalet bør produsere et forslag med en begrunnelse, et dokumentasjonstidsstempel og en forespurt eksponering. Det bør ikke skape en saldo, endre kontofullmakten eller anta at en ordre er utført. I det fiktive tilfellet foreslår signalet kjøpet på 80 enheter fordi en forhåndsangitt observasjonsbetingelse er oppfylt. Akseptøvelsen trenger ikke hevde at denne betingelsen har prediktiv verdi.
Et forslag bør identifisere dokumentasjonsversjonen som ble brukt til å beregne det. Hvis den underliggende observasjonen revideres, bevares det opprinnelige forslaget og en ny vurdering opprettes fremfor å erstatte historikken i det stille. Det betyr noe ved gjennomgang av hvorfor systemet handlet. En beslutning kan ikke vurderes rettferdig mot informasjon som først ble tilgjengelig etter at den ble autorisert.
Veiledningen til kryptovalutaautomatisering forklarer hvordan et bredt automatiseringsmål deles i avgrensede ansvarsområder. Bruk delingen her: Signalet foreslår, risikolaget kontrollerer, reservasjonslaget forplikter kapasitet og utførelseslaget forsøker den tillatte handlingen. Navnene kan variere mellom implementeringer, men ansvaret bør forbli synlig i akseptregistreringen.
Autorisasjon må omfatte hele budsjettet
Risikokontrollen sammenligner den maksimale reservasjonen på 802,80 enheter med den tilgjengelige kapasiteten på 1 500 enheter. Etter de fiktive reglene passer forslaget og etterlater 697,20 enheter tilgjengelig for annen ny aktivitet. En test bør verifisere begge tallene. Å bare kontrollere at den forespurte nominelle verdien på 800 ligger under totalsaldoen, ville overse gebyrer, driftsbufferen og den tidligere forpliktelsen.
Definer om gebyrrammen er en absolutt grense eller et anslag. Hvis faktisk utførelse kan overskride det autoriserte budsjettet, trenger programvaren en annen håndhevbar begrensning eller en avvisningsregel. Å kalle en kostnad anslått gir ikke ubegrenset fullmakt. Akseptregistreringen bør forklare hva som skjer hvis det endelige pristilbudet eller transaksjonsutgiften overskrider antakelsen som ble brukt under autorisasjon.
Prøv også en grenseverdi. Øk det foreslåtte beløpet til reservasjonen ville overskride kapasiteten med en liten mengde. Det forventede resultatet er en dokumentert avvisning eller et nytt forslag som reglene uttrykkelig tillater. Størrelsesendring i det stille er ikke automatisk akseptabelt fordi det endrer den opprinnelige beslutningen. Hvis størrelsesendring støttes, bør reglene og beløpet som følger, være del av det angitte kravet.
Programvare for automatisert kryptovalutahandel trenger varige identiteter
Gi beslutningen en hensiktsidentifikator før innsending. Identifikatoren bør knytte den opprinnelige observasjonen, kontoautorisasjonen, kapitalreservasjonen og utførelsesforsøkene som følger, sammen. En separat ordre- eller transaksjonsidentifikator kan komme etter at forespørselen når utførelsessystemet. Bevar begge, slik at applikasjonen kan skille sin egen varige beslutning fra en ekstern representasjon av beslutningen.
Lever den samme inndatahendelsen to ganger under testen. Den andre leveringen bør oppdage den eksisterende hensikten, ikke reservere ytterligere 802,80 enheter. Det er et viktig akseptvilkår fordi mange datasystemer kan levere hendelser på nytt etter ny tilkobling. Duplisert transport er ikke det samme som en ny økonomisk mulighet, og kontoen bør ikke utlede ny autorisasjon fra gjentatt levering alene.
Den eldre samordningsveiledningen for flere lommebøker er nyttig når flere kontoarbeidsprosesser er involvert. En hensiktsidentitet må avgrenses nøye nok til å unngå forvirring mellom kontoer og samtidig hindre duplisert arbeid på den tiltenkte kontoen. En globalt unik etikett er nyttig, men det virkelige kravet er konsistent eierskap og tolkning gjennom arbeidsflyten.
Modeller en delutførelse uten å miste resten
Anta nå at den hypotetiske ordren utfører 50 enheter til 9,90. Den nominelle kostnaden er 495. Ved den antatte gebyrsatsen er utførelsesgebyret 0,495. Hvis utførelsesutgiften på 2 enheter påløper for dette forsøket, har den fullførte delen brukt 497,495 noteringsenheter. Kontoen har anskaffet 50 enheter, ikke de opprinnelig forespurte 80.
De gjenværende 30 enhetene er fortsatt knyttet til den aktive ordren. Deres maksimale nominelle verdi er 300 ved limitprisen, og det antatte maksimalgebyret er 0,30. Behold en reservasjon på 300,30 enheter for denne resten under øvelsens kostnadsmodell. Forskjellen mellom den opprinnelige reservasjonen og fullførte kostnader pluss gjenværende reservasjon er 5,005 enheter, som gjenspeiler den forbedrede utførelsesprisen og det lavere gebyret på den utførte mengden.
Testen bør verifisere frigivelsesreglene uttrykkelig. Noen systemer beholder hele den opprinnelige reservasjonen frem til fullføring for enkelhets skyld. Andre frigjør bekreftet overskytende kapasitet gradvis. Begge tilnærminger trenger en tydelig spesifikasjon. Det kritiske kravet er at systemet aldri frigjør penger som fortsatt kreves av en aktiv eller uavklart rest, og aldri behandler en uutført mengde som en eid eiendel.
Kansellering er en forespørsel med eget utfall
Etter delutførelsen ber strategien om kansellering av de gjenværende 30 enhetene. Forespørselen beviser ikke umiddelbart at ordren er borte. Utførelsessystemet kan bekrefte mottak før det rapporterer en endelig tilstand, og en ny utførelse kan skje i mellomtiden. Akseptscenarioet bør ta med denne muligheten fremfor å anta at kansellering sletter alt umiddelbart og synkront.
For det grunnleggende testoppsettet fastsettes det at kanselleringen bekreftes uten flere utførelser. Restreservasjonen på 300,30 enheter kan da frigjøres. Kontoen beholder de 50 anskaffede enhetene og den fullførte kostnaden på 497,495 enheter. Den andre forpliktelsen på 300 enheter og driftsbufferen på 200 enheter forblir uendret. En kansellert rest reverserer ikke det tidligere kjøpet eller utgiftene som påløp.
Legg til en annen variant der fem flere enheter utføres før kansellering er fullført. Systemet må ta med disse enhetene og deres faktiske kostnader før det endelige frigjorte beløpet fastslås. Det forventede resultatet bør beregnes fra den nye utførelsesdokumentasjonen, ikke tidspunktet operatøren trykket kanseller. Varianten prøver om implementeringen følger økonomiske hendelser fremfor grensesnitthensikter.
Henvis og tjen USDC
Henvis og tjen USDCPartnerprogrammet vårt betaler i sanntid.
Prøv et ukjent innsendingsutfall
Et gjenopprettingsscenario for automatisert handel bør avbryte kommunikasjonen umiddelbart etter innsending. Testoppsettet registrerer at forespørselen kan ha nådd utførelsessystemet, mens applikasjonen ikke får noe avgjørende svar. Den påkrevde tilstanden er uavklart, med reservasjonen bevart. En ny økonomisk ordre bør ikke opprettes bare fordi det opprinnelige kallet ga en feil eller fikk tidsavbrudd.
Gjenoppretting leter etter det eksisterende utfallet ved hjelp av de varige referansene integrasjonen støtter. Den kan undersøke kontohistorikk, åpne ordrer eller transaksjonsstatus. Spesifikasjonen bør beskrive hvilken dokumentasjon som er tilstrekkelig til å klassifisere forsøket som akseptert, avvist, fullført eller fortsatt ukjent. Den bør også beskrive hvordan usikkerhet eskaleres når tilgjengelige kilder er uenige eller forblir ufullstendige.
Veiledningen til kryptoarbitrasjeboter viser hvorfor uavklart innsending får særlig store konsekvenser når et annet ben kan ha blitt utført. Det samme prinsippet gjelder dette eksemplet med én ordre. Et tidsavbrudd endrer hva applikasjonen vet. Det endrer ikke nødvendigvis hva den eksterne kontoen har gjort, så aksepttesten må holde de to faktaene atskilt.
Mål kostnader uten å gjøre et anslag til et faktum
Etter avstemming erstattes anslåtte utførelseskostnader med observerte beløp, mens det opprinnelige anslaget bevares for sammenligning. Det lar en kontrollør se om budsjetteringsmodellen var konservativ, nøyaktig eller ufullstendig. Ett felt som overskrives fra anslag til faktisk verdi, ødelegger dokumentasjonen og gjør det vanskeligere å forbedre fremtidige kostnadsantakelser.
I det fiktive delutførelsestilfellet er den observerte totalkostnaden 497,495 enheter under de angitte antakelsene. Delt på 50 gir det 9,9499 noteringsenheter per anskaffet eiendelsenhet når den faste utgiften tilordnes kjøpet. Den gjennomsnittlige handelsprisen er fortsatt 9,90. Begge tallene kan være nyttige, men bør ha forskjellige etiketter fordi det ene inkluderer kostnader og det andre ikke.
Veiledningen til programvare for kryptoarbitrasje undersøker hvorfor skillet betyr noe når et tilsynelatende prisspenn er lite. For aksept er den viktige atferden regnskap som kan gjenskapes. Programvaren bør ikke bytte mellom brutto- og kostnadsinkluderende mål etter hvilket som ser best ut. En stabil definisjon lar kontrolløren sammenligne forventet økonomi med den faktiske kontoregistreringen.
Prøv foreldet dokumentasjon og endret konfigurasjon
Lag et testoppsett der observasjonen utløper mellom forslag og autorisasjon. Den forventede atferden bør være en ny kontroll, en avvisning eller en annen uttrykkelig tillatt overgang. Applikasjonen bør ikke tolke eksistensen av et signal som en gang var gyldig, som permanent fullmakt. Aldersgrensen for dokumentasjon må tilhøre beslutningsregelen og vises i avvisningsregistreringen.
Endre deretter strategikonfigurasjonen mens en hensikt venter. Den eksisterende hensikten bør forbli knyttet til versjonen som autoriserte den, med mindre en dokumentert endringsprosess endrer den. En ny konfigurasjon kan styre fremtidige beslutninger uten å omskrive fortiden. Det er særlig viktig når en kontrollør senere prøver å gjenskape hvorfor systemet forpliktet et bestemt beløp.
En nyttig test skiller konfigurasjonslagring fra aktivering. Å lagre en revidert grense betyr ikke nødvendigvis at hver kjørende komponent har tatt den i bruk. Programvaren bør vise den aktive versjonen og punktet der endringen trer i kraft. Ellers kan en operatør tro at en begrensning gjelder mens en arbeidsprosess fortsetter med et tidligere fullmaktssett.
Ta med negative tilfeller som lærer bort noe
Negative tester bør rette seg mot meningsfulle feilmåter. En eiendelsidentitet som ikke støttes, en oppbrukt transaksjonsressurs, et foreldet kontoøyeblikksbilde og et overforpliktet budsjett prøver hver sin grense. En stor samling nesten identiske ugyldige inndata kan gi et imponerende testantall uten å øke tilliten til systemets økonomiske atferd.
For hvert negativt tilfelle angis hva som må forbli uendret. Et avvist forslag bør ikke få en reell ordreidentifikator, bruke en handelskapitaltildeling eller vises som en fullført handel. Det kan fortsatt skape en kontrollregistrering og en driftskostnad, avhengig av hvor avvisningen skjer. Skillet bør være uttrykkelig, slik at testen ikke forveksler bevaring av dokumentasjon med uautorisert kontoaktivitet.
Det eldre vurderingsskjemaet for handelsprogramvare gir en nyttig vurderingsstruktur. Bruk det på demonstrert atferd fremfor påstått dekning. En mislykket test er verdifull informasjon når den identifiserer et krav som kan avklares, eller en implementeringsfeil som kan rettes før bredere bruk.
Gjenskap resultatet fra journalen
Ved slutten av akseptøkten eksporteres journalen, og kontoen rekonstrueres uten bruk av den kjørende applikasjonen. Kontrolløren bør identifisere startsaldoen på 2 000 enheter, de separate reservasjonene, de 50 anskaffede enhetene, den fullførte kostnaden og den frigjorte resten. Hver konklusjon bør vise til en registrert hendelse eller en angitt antakelse.
Denne rekonstruksjonen prøver mer enn bokføring. Den viser om programvaren bevarer kronologi, og om hendelsesetiketter betyr det de hevder. En hendelse som registrerer innsending, bør ikke telles som en utførelse. En kanselleringsforespørsel bør ikke telles som en bekreftet kansellering. En verdsettingsoppdatering bør ikke endre antallet eide eiendelsenheter. Journalen bør bevare disse skillene selv etter at grensesnittet forenkler dem.
En kontrollør bør også kunne identifisere hull. Hvis en utførelsesutgift er utilgjengelig, bør eksporten si at kostnadsregnskapet er ufullstendig fremfor å sette inn null. Manglende er en annen tilstand enn målt null. Ved å bevare skillet kan kontoeieren vurdere resultatets praktiske begrensninger uten å finne på presisjon.
Registrer aksept uten å hevde strategisuksess
En akseptrapport bør navngi kravsettet, testoppsettene, programvareversjonen og observerte utfall. Den bør identifisere gjenværende begrensninger og vilkårene som ville kreve ny testing av et resultat. En endring i ordrebetydning, kontofullmakter eller kostnadshåndtering kan gjøre et tidligere akseptresultat ugyldig selv om de synlige strategiinnstillingene er de samme.
Å bestå disse scenarioene fastslår at systemet oppfører seg i samsvar med den spesifiserte arbeidsflyten. Det fastslår verken at signalet forutsier fremtidige priser eller at den valgte kapitaltildelingen passer for en bestemt person. Dette er separate forsknings- og beslutningsspørsmål. Å holde dem atskilt hindrer at en teknisk vellykket demonstrasjon blir en udokumentert økonomisk påstand.
Det praktiske resultatet er en liten dokumentasjonspakke som kan gjentas: krav, fiktive inndata, forventede overganger, observerte registreringer og avstemt regning. Med pakken kan en annen kontrollør forstå hva programvaren ble bedt om å gjøre, og hvorfor resultatet regnes som bestått eller mislykket. Det er et sterkere automatiseringsgrunnlag enn tillit bygget på en uavbrutt demonstrasjon.
Bevar forskjellen mellom en testklokke og en markedsklokke
Et testoppsett som kan gjenskapes, bør kontrollere tid uttrykkelig. Testen trenger å vite når en observasjon skjedde, når den ble tilgjengelig for applikasjonen, og når den foreslåtte handlingen ble vurdert. Det kan være tre forskjellige tidspunkter. Hvis en gjentatt kjøring bruker en rettet historisk verdi før rettelsen opprinnelig kom, kan beslutningen virke bedre informert enn en virkelig operatør kunne ha vært.
Bruk det samme skillet når avbrudd simuleres. Flytt testklokken frem mens en kontooppdatering holdes tilbake, og verifiser deretter at reglene for foreldet tilstand aktiveres ved den tiltenkte grensen. Gjenoppta datastrømmen med forsinkede hendelser og kontroller om applikasjonen bevarer de opprinnelige hendelsestidspunktene. Øvelsen kan avdekke et system som merker en gammel observasjon som fersk bare fordi den ble mottatt etter ny tilkobling.
Bevar til slutt rekkefølgen på hendelser som deler et vist tidsstempel. Avrundede sekunder kan skjule rekkefølgen mellom en utførelse, en kanselleringsforespørsel og en saldooppdatering. En varig sekvensreferanse eller en mer presis tidsregistrering hjelper med å gjenskape resultatet. Aksept bør fastslå hvilken rekkefølgedokumentasjon implementeringen bygger på, og hvordan den oppfører seg når denne dokumentasjonen er ufullstendig.