Software pro automatizované obchodování kryptoměn má být specifikován pozorovatelným chováním. Požadavek typu provádět efektivně zní užitečně, hodnotiteli však neříká, co má program dělat při vypršení kotace, již rezervovaných prostředcích nebo zmizení odpovědi na odeslání. Testovatelný požadavek pojmenovává vstup, povolený přechod a důkazy dokládající výsledek.
Tento průvodce rozvíjí přejímací test automatizace zohledňující náklady na smyšleném spotovém účtu. Čísla jsou vymyšlena pro reprodukovatelnost účetnictví. Nepředstavují aktuální sazebník ani očekávaný výnos. Cílem je zjistit, zda software dodržuje vyhlášená pravidla a uchovává stav účtu. Úspěch v testu dokládá provozní chování, nikoli ziskovost obchodní strategie.
Požadavky softwaru pro automatizované obchodování kryptoměn začínají invarianty
Invariant je podmínka, která má zůstávat pravdivá napříč běžnými událostmi i selháními. Užitečným příkladem je, že celkové zavázané peníze nesmějí překračovat dostupné autorizované zdroje. Dalším je, že stejný trvalý záměr nesmí vytvářet další příkaz jen kvůli dvojímu doručení události. Výroky jsou silnější než soubor snímků bezproblémové cesty, protože platí v celém postupu.
Invarianty pište jazykem, který hodnotitel dokáže prozkoumat. Systém musí před rezervací kapitálu určit účet. Neznámý výsledek příkazu musí zachovat rezervaci. Nová konfigurace nesmí přepisovat odůvodnění připojené ke staršímu záměru. Každý výrok má určit důkaz porušení. Nelze-li požadavek vyvrátit žádným možným pozorováním, je pro přejímku nejspíš příliš neurčitý.
Starší průvodce životním cyklem automatizovaného obchodování odděluje konfiguraci, pozorování a aktivitu účtu. Fáze použijte při přiřazování požadavků. Strategická součást může navrhnout úkon, ale nezávislá riziková součást rozhoduje, zda vyhovuje limitům účtu. Oddělení odpovědností usnadňuje vysvětlení, proč zdánlivě přitažlivé pozorování nevedlo k provedení.
Přesně definujte smyšlený účet
Předpokládejte hypotetický účet začínající s 2 000 kotovacími jednotkami a bez pozice ve vybraném aktivu. Ze zůstatku je 200 jednotek rezervováno jako provozní polštář a 300 již zavázáno jinému aktivnímu záměru. Nové rozhodnutí proto podle uvedených pravidel začíná s kapacitou 1 500 jednotek. Kategorie mají zůstat rozlišitelné na každé obrazovce a v každém exportu.
Nová strategie navrhuje nákup nejvýše 80 jednotek aktiva za limitní cenu 10 kotovacích jednotek za kus. Pro cvičení předpokládejte obchodní poplatek jedné desetiny procenta účtovaný v kotovacím aktivu a samostatně modelovaný realizační výdaj 2 jednotky. Maximální nová rezervace je 800 plus 0,80 plus 2, tedy 802,80 kotovacích jednotek. Skutečné náklady platformy je nutné ověřit samostatně.
Testovací sadu zaznamenejte jako neměnný testovací vstup. Zahrňte identifikátor účtu, identitu aktiva, identitu kotovacího aktiva, počáteční zůstatky, existující závazky a předpoklady poplatků. Snímek konečného výsledku k reprodukci testu nestačí. Pozdější hodnotitel potřebuje vědět, které zdroje byly dostupné před novým rozhodnutím a které náklady byly zahrnuty do autorizačního rozpočtu.
Určete, co smí signál navrhovat
Signál má vytvořit návrh obsahující důvod, časovou značku důkazů a požadovanou expozici. Nemá vytvářet zůstatek, měnit oprávnění účtu ani předpokládat provedení příkazu. Ve smyšleném případě signál navrhuje nákup 80 jednotek, protože je splněna předem vyhlášená pozorovací podmínka. Přejímací cvičení nemusí tvrdit, že má podmínka prediktivní hodnotu.
Návrh má určit verzi důkazů použitých k výpočtu. Při revizi podkladového pozorování zachovejte původní návrh a vytvořte nové hodnocení místo tichého nahrazení historie. Záleží na tom při přezkumu důvodu jednání systému. Rozhodnutí nelze spravedlivě hodnotit vůči informacím dostupným až po jeho autorizaci.
Průvodce automatizací kryptoměn vysvětluje dělení širokého cíle automatizace na omezené odpovědnosti. Dělení použijte zde: signál navrhuje, riziková vrstva kontroluje, rezervační vrstva zavazuje kapacitu a realizační vrstva se pokouší o povolený úkon. Názvy se mohou mezi implementacemi lišit, odpovědnosti však mají zůstat viditelné v přejímacím záznamu.
Autorizace musí zahrnovat úplný rozpočet
Riziková kontrola porovnává maximální rezervaci 802,80 jednotky s dostupnou kapacitou 1 500 jednotek. Podle smyšlených pravidel návrh vyhovuje a ponechává 697,20 jednotky pro jinou novou aktivitu. Test má ověřit obě čísla. Kontrola pouze toho, že požadovaná nominální hodnota 800 je pod celkovým zůstatkem, by přehlédla poplatky, provozní polštář i dřívější závazek.
Definujte, zda je příděl na poplatek pevnou hranicí, nebo odhadem. Mohlo-li by skutečné provedení překročit autorizovaný rozpočet, software potřebuje jiné vynutitelné omezení nebo pravidlo odmítnutí. Označení nákladu jako odhadovaného neuděluje neomezenou pravomoc. Přejímací záznam má vysvětlit dění při překročení autorizačního předpokladu konečnou kotací nebo transakčním výdajem.
Otestujte i hraniční hodnotu. Zvětšujte navrženou částku, až by rezervace překročila kapacitu o malé množství. Očekávaným výsledkem je zdokumentované odmítnutí nebo nový návrh výslovně povolený pravidly. Tichá změna velikosti není automaticky přijatelná, protože mění původní rozhodnutí. Je-li změna velikosti podporována, její pravidla a výsledná částka mají patřit k uvedenému požadavku.
Software pro automatizované obchodování kryptoměn potřebuje trvalé identity
Rozhodnutí dejte identifikátor záměru před odesláním. Identifikátor má spojovat původní pozorování, autorizaci účtu, rezervaci kapitálu a výsledné pokusy o provedení. Samostatný identifikátor příkazu nebo transakce se může objevit po dosažení realizačního systému požadavkem. Uchovejte oba, aby aplikace odlišila vlastní trvalé rozhodnutí od jeho vnějšího vyjádření.
Při testu doručte stejnou vstupní událost dvakrát. Druhé doručení má objevit existující záměr, nikoli rezervovat dalších 802,80 jednotky. Jde o důležitou přejímací podmínku, protože mnoho datových systémů může znovu doručovat události po připojení. Duplicitní přenos není totéž jako druhá ekonomická příležitost a účet nemá odvozovat novou autorizaci jen z opakovaného doručení.
Starší průvodce koordinací více peněženek je užitečný při zapojení několika pracovních procesů účtů. Identita záměru musí být vymezena dost pečlivě, aby zabránila záměně mezi účty a zároveň duplicitní práci v zamýšleném účtu. Globálně jedinečný štítek pomáhá, skutečným požadavkem je však konzistentní vlastnictví a výklad v celém postupu.
Modelujte částečné plnění bez ztráty zbytku
Nyní předpokládejte plnění hypotetického příkazu v množství 50 jednotek za 9,90. Nominální náklad činí 495. Při předpokládané sazbě je poplatek plnění 0,495. Vznikne-li pro tento pokus realizační výdaj 2 jednotky, dokončená část spotřebovala 497,495 kotovací jednotky. Účet pořídil 50 jednotek, nikoli původně požadovaných 80.
Zbývajících 30 jednotek je stále spojeno s aktivním příkazem. Při limitní ceně činí jejich maximální nominální hodnota 300 a předpokládaný maximální poplatek je 0,30. Podle nákladového modelu cvičení ponechte pro zbytek rezervaci 300,30 jednotky. Rozdíl mezi původní rezervací a součtem dokončených nákladů se zbývající rezervací činí 5,005 jednotky a odráží lepší cenu plnění i nižší poplatek naplněného množství.
Test má výslovně ověřit pravidla uvolňování. Některé systémy pro jednoduchost ponechávají celou původní rezervaci až do dokončení. Jiné postupně uvolňují potvrzenou přebytečnou kapacitu. Oba přístupy potřebují jasnou specifikaci. Zásadním požadavkem je, aby systém nikdy neuvolnil peníze stále potřebné pro aktivní nebo nevyřešený zbytek a nikdy nepovažoval nenaplněné množství za vlastněné aktivum.
Zrušení je požadavek s vlastním výsledkem
Po částečném plnění strategie požádá o zrušení zbývajících 30 jednotek. Požadavek okamžitě nedokládá zánik příkazu. Realizační systém může potvrdit přijetí před oznámením konečného stavu a mezitím může nastat další plnění. Přejímací scénář má možnost zahrnout místo předpokladu, že zrušení je synchronní guma.
Pro základní testovací sadu stanovte potvrzení zrušení bez dalšího plnění. Rezervaci zbytku 300,30 jednotky lze poté uvolnit. Účet si ponechává 50 pořízených jednotek a dokončený náklad 497,495 jednotky. Nesouvisející závazek 300 jednotek i provozní polštář 200 jednotek zůstávají beze změny. Zrušený zbytek nevrací dřívější nákup ani vzniklé výdaje.
Přidejte druhou variantu s plněním dalších pěti jednotek před dokončením zrušení. Systém musí před určením konečné uvolněné částky zahrnout jednotky a jejich skutečné náklady. Očekávaný výsledek se má počítat z nových důkazů plnění, nikoli z času klepnutí provozovatele na zrušit. Varianta testuje, zda implementace následuje ekonomické události, nikoli záměry rozhraní.
Doporučujte a vydělávejte USDC
Doporučujte a vydělávejte USDCNáš partnerský program vyplácí v reálném čase.
Procvičte neznámý výsledek odeslání
Scénář obnovy automatizovaného obchodování má přerušit komunikaci bezprostředně po odeslání. Testovací prostředí zaznamenává, že požadavek mohl dosáhnout realizačního systému, zatímco aplikace nedostává definitivní odpověď. Požadovaný stav je nevyřešený se zachovanou rezervací. Nový ekonomický příkaz se nemá vytvářet jen kvůli chybě nebo vypršení limitu původního volání.
Obnova hledá existující výsledek pomocí trvalých odkazů podporovaných integrací. Může zkoumat historii účtu, otevřené příkazy nebo stav transakce. Specifikace má popsat důkazy dostatečné ke klasifikaci pokusu jako přijatého, odmítnutého, dokončeného nebo stále neznámého. Má také popsat eskalaci nejistoty při neshodě nebo neúplnosti dostupných zdrojů.
Průvodce kryptoměnovým arbitrážním botem ukazuje zvláštní důležitost nevyřešeného odeslání, když se již mohla provést jiná část. Stejný princip platí pro příklad jediného příkazu. Vypršení limitu mění znalost aplikace. Nemusí měnit to, co vnější účet udělal, takže přejímací test musí fakta oddělit.
Měřte náklady bez přeměny odhadu ve skutečnost
Po odsouhlasení nahraďte odhadované realizační náklady pozorovanými částkami a zachovejte původní odhad pro porovnání. Hodnotitel tak uvidí, zda byl rozpočtový model konzervativní, přesný nebo neúplný. Jediné pole přepsané z odhadu na skutečnost ničí důkaz a ztěžuje zlepšování budoucích nákladových předpokladů.
Ve smyšleném případě částečného plnění činí podle uvedených předpokladů pozorovaný celkový náklad 497,495 jednotky. Po vydělení 50 vychází 9,9499 kotovací jednotky za pořízenou jednotku aktiva při přiřazení pevného výdaje tomuto nákupu. Průměrná obchodní cena zůstává 9,90. Obě čísla mohou být užitečná, mají však mít jiné štítky, protože jedno zahrnuje náklady a druhé nikoli.
Průvodce softwarem pro kryptoměnovou arbitráž zkoumá důležitost rozdílu při malém zdánlivém rozpětí. Pro přejímku je důležité reprodukovatelné účetnictví. Software nemá přepínat mezi hrubými mírami a mírami zahrnujícími náklady podle příznivějšího vzhledu. Stabilní definice hodnotiteli umožňuje porovnat očekávanou ekonomiku se skutečným záznamem účtu.
Testujte zastaralé důkazy a změny konfigurace
Vytvořte testovací sadu s pozorováním, jehož platnost vyprší mezi návrhem a autorizací. Očekávaným chováním má být opětovná kontrola, odmítnutí nebo jiný výslovně povolený přechod. Aplikace nemá vykládat existenci dříve platného signálu jako trvalou pravomoc. Limit stáří důkazů musí patřit k rozhodovacímu pravidlu a objevit se v záznamu odmítnutí.
Poté změňte konfiguraci strategie při čekajícím záměru. Existující záměr má zůstat spojen s verzí, která jej autorizovala, pokud jej nezmění zdokumentovaný proces úprav. Nová konfigurace může řídit budoucí rozhodnutí bez přepisování minulosti. Zvlášť důležité je to při pozdější snaze hodnotitele reprodukovat důvod zavázání konkrétní částky systémem.
Užitečný test odlišuje uložení konfigurace od aktivace. Uložení upraveného limitu nemusí znamenat jeho přijetí každou běžící součástí. Software má zpřístupnit aktivní verzi a bod účinnosti změny. Jinak se provozovatel může domnívat, že omezení platí, zatímco pracovní proces dále používá dřívější soubor oprávnění.
Zahrňte negativní případy, které něco učí
Negativní testy mají cílit na smysluplné režimy selhání. Nepodporovaná identita aktiva, vyčerpaný transakční zdroj, zastaralý snímek účtu a příliš zavázaný rozpočet testují každý jinou hranici. Velká sbírka téměř totožných neplatných vstupů může vytvořit působivý počet testů bez zlepšení důvěry v ekonomické chování systému.
Pro každý negativní případ určete, co musí zůstat beze změny. Odmítnutý návrh nemá získat identifikátor skutečného aktivního příkazu, spotřebovat obchodní příděl ani se objevit jako dokončený obchod. Stále může vytvořit auditní záznam a provozní náklad podle místa odmítnutí. Rozdíl má být výslovný, aby test nezaměňoval uchovávání důkazů za neautorizovanou aktivitu účtu.
Starší hodnoticí karta důkazů pro obchodní software poskytuje užitečnou strukturu hodnocení. Použijte ji na prokázané chování místo tvrzeného pokrytí. Neúspěšný test je cenná informace, pokud určuje požadavek k objasnění nebo vadu implementace opravitelnou před širším použitím.
Reprodukujte výsledek z deníku
Na konci přejímací relace exportujte deník a rekonstruujte účet bez aktuální aplikace. Hodnotitel má určit počáteční zůstatek 2 000 jednotek, samostatné rezervace, 50 pořízených jednotek, dokončený náklad a uvolněný zbytek. Každý závěr má odkazovat na zaznamenanou událost nebo uvedený předpoklad.
Rekonstrukce testuje více než vedení účetnictví. Odhaluje, zda software uchovává chronologii a zda štítky událostí znamenají, co tvrdí. Událost odesláno se nemá počítat jako plnění. Žádost o zrušení se nemá počítat jako potvrzené zrušení. Aktualizace ocenění nemá měnit počet vlastněných jednotek aktiva. Deník má rozdíly udržovat i po jejich zjednodušení rozhraním.
Hodnotitel má také dokázat určit mezery. Není-li realizační výdaj dostupný, export má uvést neúplnost účtování nákladů místo dosazení nuly. Chybějící je jiný stav než naměřená nula. Zachování rozdílu vlastníkovi účtu umožňuje posoudit praktické meze výsledku bez vymýšlení přesnosti.
Zaznamenejte přejímku bez tvrzení o úspěchu strategie
Přejímací zpráva má pojmenovat soubor požadavků, testovací sady, verzi softwaru a pozorované výsledky. Má určit zbývající omezení a podmínky nutného opakování testu výsledku. Změna významu příkazů, oprávnění účtu nebo zacházení s náklady může zneplatnit dřívější výsledek přejímky i při stejných viditelných nastaveních strategie.
Úspěch ve scénářích dokládá konzistentní chování systému vůči specifikovanému postupu. Nedokládá předpovídání budoucích cen signálem ani vhodnost vybrané alokace pro konkrétního člověka. Jde o samostatné výzkumné a rozhodovací otázky. Jejich oddělení brání přeměně technicky úspěšné ukázky v nepodložené ekonomické tvrzení.
Praktickým výstupem je malý opakovatelný soubor důkazů: požadavky, smyšlené vstupy, očekávané přechody, pozorované záznamy a odsouhlasené výpočty. S ním jiný hodnotitel dokáže pochopit, co se po softwaru požadovalo a proč se výsledek počítá jako úspěch nebo selhání. Je to silnější základ automatizace než důvěra vytvořená nepřerušenou ukázkou.
Zachovejte rozdíl mezi testovacím a tržním časem
Reprodukovatelná testovací sada má výslovně řídit čas. Test potřebuje vědět, kdy pozorování nastalo, kdy se zpřístupnilo aplikaci a kdy se hodnotil navržený úkon. Může jít o tři různé okamžiky. Použije-li přehrávání opravenou historickou hodnotu před původním příchodem opravy, může rozhodnutí vypadat lépe informované, než mohl být kterýkoli skutečný provozovatel.
Stejné rozlišení používejte při simulování výpadků. Posuňte testovací čas při zadržení aktualizace účtu a ověřte aktivaci pravidel zastaralého stavu na zamýšlené hranici. Obnovte proud se zpožděnými událostmi a ověřte zachování jejich původních časů aplikací. Cvičení může odhalit systém označující staré pozorování jako čerstvé jen proto, že jej přijal po obnovení spojení.
Nakonec zachovejte pořadí událostí se stejnou zobrazenou časovou značkou. Zaokrouhlené sekundy mohou skrývat sled mezi plněním, žádostí o zrušení a aktualizací zůstatku. Trvalý odkaz na pořadí nebo přesnější časový záznam pomáhá reprodukovat výsledek. Přejímka má doložit, na kterých důkazech pořadí implementace závisí a jak se chová při jejich neúplnosti.