Automatiseret kryptovalutahandelssoftware bør specificeres gennem observerbar adfærd. Et krav såsom udfør effektivt lyder nyttigt, men fortæller ikke en bedømmer, hvad programmet skal gøre, når et tilbud udløber, midler allerede er reserverede, eller et indsendelsessvar forsvinder. Et afprøveligt krav navngiver input, tilladt overgang og den dokumentation, der fastslår resultatet.
Vejledningen udvikler en omkostningsbevidst accepttest for automatisering med en fiktiv spotkonto. Tallene er opfundet for at gøre bogføringen reproducerbar. De repræsenterer ikke en aktuel gebyrplan eller et forventet afkast. Målet er at afgøre, om software følger sine erklærede regler og bevarer kontotilstand. Beståelse fastslår driftsadfærd, ikke at handelsstrategien er indbringende.
Krav til automatiseret kryptovalutahandelssoftware begynder med invarianter
En invariant er en betingelse, der bør forblive sand gennem almindelige hændelser og fejl. Ét nyttigt eksempel er, at samlede bundne kontanter ikke må overstige tilgængelige godkendte ressourcer. Et andet er, at samme varige hensigt ikke må skabe endnu en ordre, blot fordi en hændelse leveres to gange. Udtalelserne er stærkere end en samling skærmbilleder af vellykkede standardforløb, fordi de gælder gennem hele forløbet.
Skriv invarianter i sprog, en bedømmer kan gennemgå. Systemet skal identificere kontoen før kapitalreservation. Et ukendt ordreudfald skal bevare sin reservation. En ny konfiguration må ikke omskrive begrundelsen knyttet til en ældre hensigt. Hver udtalelse bør identificere den dokumentation, der ville vise en overtrædelse. Hvis ingen mulig observation kunne afkræfte et krav, er det sandsynligvis for vagt til accept.
Den ældre vejledning om automatiseret handelslivscyklus adskiller konfiguration, observation og kontoaktivitet. Brug trinnene ved tildeling af krav. En strategikomponent kan foreslå en handling, men en uafhængig risikokomponent afgør, om handlingen passer til kontogrænser. Adskillelse gør det lettere at forklare, hvorfor en tilsyneladende attraktiv observation ikke førte til udførelse.
Definér den fiktive konto præcist
Antag, at en hypotetisk konto begynder med 2.000 enheder af noteringsaktivet og ingen position i det valgte aktiv. Af saldoen er 200 enheder reserveret som driftspude, og 300 er allerede bundet til en anden aktiv hensigt. Den nye beslutning begynder derfor med en kapacitet på 1.500 enheder under den angivne politik. Kategorierne bør forblive adskillelige i hver skærm og eksport.
Den nye strategi foreslår køb af højst 80 aktivenheder til en limitpris på 10 enheder af noteringsaktivet hver. Antag til øvelsen et handelsgebyr på en tiendedel af én procent opkrævet i noteringsaktivet og en særskilt modelleret udførelsesudgift på 2 enheder. Den maksimale nye reservation er 800 plus 0,80 plus 2 eller 802,80 enheder af noteringsaktivet. Faktiske platformsomkostninger skal kontrolleres særskilt.
Registrér testdatasættet som uforanderligt testinput. Medtag kontoidentifikator, aktividentitet, noteringsidentitet, startsaldi, eksisterende forpligtelser og gebyrantagelser. Et skærmbillede af slutresultatet er ikke nok til at gengive testen. En senere bedømmer skal vide, hvilke ressourcer der var tilgængelige før den nye beslutning, og hvilke omkostninger der indgik i godkendelsesbudgettet.
Specificér det, signalet må foreslå
Signalet bør skabe et forslag med begrundelse, dokumentationstidsstempel og ønsket eksponering. Det bør ikke skabe en saldo, ændre kontotilladelsen eller antage, at en ordre er udført. I det fiktive tilfælde foreslår signalet købet på 80 enheder, fordi en på forhånd erklæret observationsbetingelse er opfyldt. Acceptøvelsen behøver ikke hævde, at betingelsen har forudsigende værdi.
Et forslag bør identificere den dokumentationsversion, der blev brugt til beregningen. Hvis den underliggende observation revideres, skal det oprindelige forslag bevares, og en ny vurdering skabes frem for tavs erstatning af historik. Det er vigtigt ved gennemgang af systemets handlingsgrund. En beslutning kan ikke retfærdigt vurderes mod information, der først blev tilgængelig efter godkendelsen.
Vejledningen om kryptovalutaautomatisering forklarer opdeling af et bredt automatiseringsmål i afgrænsede ansvarsområder. Anvend opdelingen her: Signalet foreslår, risikolaget kontrollerer, reservationslaget binder kapacitet, og udførelseslaget forsøger den tilladte handling. Navnene kan variere mellem implementeringer, men ansvaret bør forblive synligt i acceptregistreringen.
Godkendelse skal omfatte hele budgettet
Risikokontrollen sammenligner den maksimale reservation på 802,80 enheder med den tilgængelige kapacitet på 1.500 enheder. Under den fiktive politik passer forslaget og efterlader 697,20 enheder til anden ny aktivitet. En test bør verificere begge tal. Kontrol alene af, at den ønskede nominelle værdi på 800 ligger under den samlede saldo, ville overse gebyrer, driftspuden og den tidligere forpligtelse.
Definér, om gebyrreserven er en fast grænse eller et estimat. Hvis faktisk udførelse kunne overskride det godkendte budget, kræver softwaren endnu en håndhævelig begrænsning eller en afvisningsregel. Betegnelsen estimeret om en omkostning giver ikke ubegrænset beføjelse. Acceptregistreringen bør forklare det, der sker, hvis det endelige tilbud eller transaktionsudgiften overstiger antagelsen brugt ved godkendelse.
Afprøv også en grænseværdi. Forøg den foreslåede mængde eller det foreslåede beløb, indtil reservationen ville overskride kapaciteten en smule. Det forventede resultat er en dokumenteret afvisning eller et nyt forslag, som politikken udtrykkeligt tillader. Tavs størrelsesændring er ikke automatisk acceptabel, fordi den ændrer den oprindelige beslutning. Hvis størrelsesændring understøttes, bør reglerne og den resulterende mængde eller det resulterende beløb være del af det angivne krav.
Automatiseret kryptovalutahandelssoftware kræver varige identiteter
Giv beslutningen en hensigtsidentifikator før indsendelse. Identifikatoren bør forbinde oprindelig observation, kontogodkendelse, kapitalreservation og resulterende udførelsesforsøg. En særskilt ordre- eller transaktionsidentifikator kan forekomme, efter at anmodningen når udførelsessystemet. Bevar begge, så applikationen kan skelne sin egen varige beslutning fra en ekstern repræsentation af beslutningen.
Levér samme inputhændelse to gange under testen. Anden levering bør finde den eksisterende hensigt, ikke reservere yderligere 802,80 enheder. Det er en vigtig acceptbetingelse, fordi mange datasystemer kan genlevere hændelser efter genforbindelse. Dobbelt transport er ikke det samme som endnu en økonomisk mulighed, og kontoen bør ikke udlede en ny godkendelse fra gentaget levering alene.
Den ældre vejledning om koordinering af flere wallets er nyttig, når flere kontoprocesser involveres. En hensigtsidentitet skal afgrænses omhyggeligt nok til at undgå kontoforveksling og samtidig forebygge dobbeltarbejde inden for den tilsigtede konto. Et globalt entydigt mærkat er nyttigt, men det virkelige krav er konsekvent ansvar og fortolkning gennem hele forløbet.
Modellér en delvis udførelse uden at miste resten
Antag nu, at den hypotetiske ordre får 50 enheder udført til 9,90. Den nominelle omkostning er 495. Ved den antagne gebyrsats er udførelsesgebyret 0,495. Hvis udførelsesudgiften på 2 enheder påløber for forsøget, har den gennemførte del brugt 497,495 enheder af noteringsaktivet. Kontoen har anskaffet 50 enheder, ikke de oprindeligt ønskede 80.
De resterende 30 enheder er stadig knyttet til den aktive ordre. Deres maksimale nominelle værdi er 300 ved limitprisen, og det antagne maksimale gebyr er 0,30. Bevar en reservation på 300,30 enheder til resten under øvelsens omkostningsmodel. Forskellen mellem den oprindelige reservation og gennemførte omkostninger plus resterende reservation er 5,005 enheder, hvilket afspejler forbedret udførelsespris og lavere gebyr på den udførte mængde.
Testen bør verificere frigivelsespolitikken udtrykkeligt. Visse systemer bevarer hele den oprindelige reservation til gennemførelse for enkelhedens skyld. Andre frigiver bekræftet overskydende kapacitet trinvist. Begge tilgange kræver en klar specifikation. Det kritiske krav er, at systemet aldrig frigiver penge stadig nødvendige for en aktiv eller uafklaret rest og aldrig behandler en uudført mængde som et ejet aktiv.
Annullering er en anmodning med eget udfald
Efter den delvise udførelse anmoder strategien om annullering af de resterende 30 enheder. Anmodningen beviser ikke øjeblikkeligt, at ordren er væk. Udførelsessystemet kan kvittere for modtagelse før rapportering af en endelig tilstand, og endnu en udførelse kan ske i intervallet. Acceptscenariet bør medtage muligheden frem for at antage, at annullering er et synkront viskelæder.
Fastlæg i det grundlæggende testdatasæt, at annullering bekræftes uden yderligere udførelse. Restreservationen på 300,30 enheder kan da frigives. Kontoen beholder de 50 anskaffede enheder og den gennemførte omkostning på 497,495 enheder. Den særskilte, allerede eksisterende forpligtelse på 300 enheder og driftspuden på 200 enheder forbliver uændrede. En annulleret rest omgør ikke det tidligere køb eller de påløbne udgifter.
Tilføj en anden variant, hvor yderligere fem enheder udføres før afsluttet annullering. Systemet skal indarbejde enhederne og deres faktiske omkostninger før bestemmelse af det endeligt frigivne beløb. Det forventede resultat bør beregnes fra den nye udførelsesdokumentation, ikke tidspunktet for operatørens klik på annullér. Varianten afprøver, om implementeringen følger økonomiske hændelser frem for brugerfladehensigter.
Henvis og tjen USDC
Henvis og tjen USDCVores affiliateprogram udbetaler i realtid.
Afprøv et ukendt indsendelsesudfald
Et genopretningsscenarie for automatiseret handel bør afbryde kommunikationen øjeblikkeligt efter indsendelse. Testsystemet registrerer, at anmodningen kan have nået udførelsessystemet, mens applikationen ikke modtager noget endeligt svar. Den krævede tilstand er uafklaret med bevaret reservation. En ny økonomisk ordre bør ikke skabes, blot fordi det oprindelige kald returnerede en fejl eller fik timeout.
Genopretning søger efter det eksisterende udfald med de varige referencer, integrationen understøtter. Den kan gennemgå kontohistorik, åbne ordrer eller transaktionsstatus. Specifikationen bør beskrive den dokumentation, der er tilstrækkelig til at klassificere forsøget som accepteret, afvist, gennemført eller stadig ukendt. Den bør også beskrive eskalering af usikkerhed, når de tilgængelige kilder er uenige eller forbliver ufuldstændige.
Vejledningen om kryptoarbitragebots viser, hvorfor uafklaret indsendelse er særligt vidtrækkende, når et andet ben kan være udført. Samme princip gælder dette eksempel med én ordre. En timeout ændrer applikationens viden. Den ændrer ikke nødvendigvis den eksterne kontos handlinger, så accepttesten skal holde de to fakta adskilt.
Mål omkostninger uden at gøre et estimat til et faktum
Efter afstemning erstattes estimerede udførelsesomkostninger med observerede mængder eller beløb, mens det oprindelige estimat bevares til sammenligning. Det lader en bedømmer se, om budgetmodellen var forsigtig, nøjagtig eller ufuldstændig. Ét felt overskrevet fra estimat til faktisk værdi ødelægger dokumentationen og gør forbedring af fremtidige omkostningsantagelser sværere.
I det fiktive tilfælde med delvis udførelse er den observerede samlede omkostning 497,495 enheder under de angivne antagelser. Division med 50 giver 9,9499 enheder af noteringsaktivet pr. anskaffet aktivenhed, når den faste udgift henføres til købet. Den gennemsnitlige handelspris forbliver 9,90. Begge tal kan være nyttige, men bør have forskellige mærkater, fordi det ene omfatter omkostninger, og det andet ikke gør.
Vejledningen om kryptoarbitragesoftware udforsker forskellens betydning, når et tilsyneladende spread er lille. Ved accept er den vigtige adfærd reproducerbar bogføring. Softwaren bør ikke skifte mellem bruttomål og mål inklusive omkostninger efter, hvad der ser bedst ud. En stabil definition lader bedømmeren sammenligne forventet økonomi med den faktiske kontoregistrering.
Afprøv forældet dokumentation og ændret konfiguration
Opret testdata, hvor observationen udløber mellem forslag og godkendelse. Den forventede adfærd bør være en ny kontrol, en afvisning eller en anden udtrykkeligt tilladt overgang. Applikationen bør ikke fortolke eksistensen af et engang gyldigt signal som permanent beføjelse. Aldersgrænsen for dokumentation skal tilhøre beslutningsreglen og fremgå af afvisningsregistreringen.
Ændr derefter strategikonfigurationen, mens en hensigt afventer. Den eksisterende hensigt bør forblive knyttet til den version, der godkendte den, medmindre et dokumenteret ændringsforløb ændrer den. En ny konfiguration kan styre fremtidige beslutninger uden at omskrive fortiden. Det er særligt vigtigt, når en bedømmer senere forsøger at gengive, hvorfor systemet bandt en bestemt mængde eller et bestemt beløb.
En nyttig test skelner konfigurationslagring fra aktivering. Lagring af en revideret grænse betyder ikke nødvendigvis, at hver kørende komponent har taget den i brug. Softwaren bør vise den aktive version og tidspunktet, hvor ændringen træder i kraft. Ellers kan en operatør tro, at en begrænsning gælder, mens en proces fortsætter med et tidligere tilladelsessæt.
Medtag negative tilfælde, der lærer noget
Negative test bør målrettes meningsfulde fejlmåder. En ikke-understøttet aktividentitet, en opbrugt transaktionsressource, et forældet kontosnapshot og et overforpligtet budget afprøver hver sin grænse. En stor samling næsten identiske ugyldige input kan give et imponerende testantal uden at forbedre sikkerheden om systemets økonomiske adfærd.
Specificér for hvert negativt tilfælde det, der skal forblive uændret. Et afvist forslag bør ikke få en ordreidentifikator i drift, bruge en handelsallokering eller optræde som en gennemført handel. Det kan stadig skabe en revisionsregistrering og en driftsomkostning afhængigt af afvisningsstedet. Forskellen bør være udtrykkelig, så testen ikke forveksler dokumentationsbevarelse med uautoriseret kontoaktivitet.
Den ældre dokumentationsoversigt for handelssoftware giver en nyttig vurderingsstruktur. Anvend den på demonstreret adfærd frem for påstået dækning. En mislykket test er værdifuld information, når den identificerer et krav, der kan afklares, eller en implementeringsfejl, der kan rettes før bredere brug.
Gengiv resultatet fra journalen
Eksportér journalen ved acceptsessionens afslutning, og rekonstruér kontoen uden at bygge på applikationen i drift. Bedømmeren bør identificere startsaldoen på 2.000 enheder, de særskilte reservationer, de 50 anskaffede enheder, den gennemførte omkostning og den frigivne rest. Hver konklusion bør pege på en registreret hændelse eller en angivet antagelse.
Rekonstruktionen afprøver mere end bogføring. Den afslører, om softwaren bevarer kronologi, og om hændelsesmærkater betyder det påståede. En indsendt hændelse bør ikke tælles som en udførelse. En annulleringsanmodning bør ikke tælles som en bekræftet annullering. En værdiansættelsesopdatering bør ikke ændre antallet af ejede aktivenheder. Journalen bør vedligeholde forskellene, selv efter brugerfladens forenkling af dem.
En bedømmer bør også kunne identificere huller. Hvis en udførelsesudgift er utilgængelig, bør eksporten angive ufuldstændig omkostningsbogføring frem for at indsætte nul. Manglende er en anden tilstand end målt nul. Bevarelse af forskellen lader kontoejeren vurdere resultatets praktiske begrænsninger uden at opfinde præcision.
Registrér accept uden at hævde strategisucces
En acceptrapport bør navngive kravsæt, testdata, softwareversion og observerede udfald. Den bør identificere resterende begrænsninger og betingelserne for nødvendig gentest. En ændring i ordrebetydning, kontotilladelser eller omkostningshåndtering kan ugyldiggøre et tidligere acceptresultat, selv hvis de synlige strategiindstillinger forbliver ens.
Beståelse af scenarierne fastslår, at systemet opfører sig i overensstemmelse med sit specificerede forløb. Den fastslår ikke, at signalet forudsiger fremtidige priser, eller at den valgte allokering er passende for en bestemt person. Det er særskilte undersøgelses- og beslutningsspørgsmål. Adskillelsen forhindrer en teknisk vellykket demonstration i at blive en udokumenteret økonomisk påstand.
Den praktiske leverance er en lille, gentagelig dokumentationspakke: krav, fiktive input, forventede overgange, observerede registreringer og afstemt regning. Med pakken kan en anden bedømmer forstå softwarens opgave, og hvorfor resultatet tæller som bestået eller fejlet. Det er et stærkere automatiseringsgrundlag end sikkerhed bygget på en uafbrudt demonstration.
Bevar forskellen mellem et testur og et markedsur
Et reproducerbart testdatasæt bør styre tid udtrykkeligt. Testen skal vide, hvornår en observation fandt sted, hvornår den blev tilgængelig for applikationen, og hvornår den foreslåede handling blev vurderet. Det kan være tre forskellige tidspunkter. Hvis en genafspilning bruger en korrigeret historisk værdi før korrektionens oprindelige ankomst, kan den få beslutningen til at virke bedre informeret, end nogen virkelig operatør kunne have været.
Brug samme skelnen ved simulering af nedbrud. Flyt testuret frem, mens en kontoopdatering tilbageholdes, og verificér derefter aktivering af politikken for forældet tilstand ved den tilsigtede grænse. Genoptag datakilden med forsinkede hændelser, og kontrollér, om applikationen bevarer deres oprindelige hændelsestider. Øvelsen kan afsløre et system, der mærker en gammel observation aktuel, blot fordi den blev modtaget efter genforbindelse.
Bevar endelig rækkefølgen af hændelser med samme viste tidsstempel. Afrundede sekunder kan skjule rækkefølgen mellem en udførelse, en annulleringsanmodning og en saldoopdatering. En varig rækkefølgereference eller mere præcis tidsregistrering hjælper med at gengive resultatet. Accept bør fastslå den rækkefølgedokumentation, implementeringen bygger på, og dens adfærd, når dokumentationen er ufuldstændig.