Automatizovaný obchodní software Solany: akceptační případy

Akceptace automatizovaného obchodního softwaru potřebuje rozsah

Definujte přijímaný postup. Signální služba pouze pro výzkum, ručně podepisovaný obchodní nástroj a strategie bez dohledu mají různé hranice pravomoci. Testovací sada by měla odpovídat navrženému použití, místo předpokladu určení každého produktu pro každou roli.

Uveďte podporovanou síť, aktiva, programy, typy akcí a model účtu. Určete komponenty zahrnuté do testu a komponenty simulované. Úspěšný výsledek platí pro tento rozsah. Neměl by se rozšiřovat v tvrzení o nepodporovaných trzích nebo netestovaných mechanismech oprávnění.

Průvodce automatizací obchodování na Solaně popisuje plánování kolem stavu tokenu, trhu a peněženky. Akceptační případy by měly tyto stavové závislosti přímo zkoušet. Software by měl ukázat chování při změně jednoho předpokladu, nikoli pouze opakovat úspěšnou akci za ideálních podmínek.

Zapište požadavek na podklady před spuštěním případu

U každého případu rozhodněte, který záznam prokáže očekávané chování. Odmítnutý návrh potřebuje důvod a nepřítomnost výsledného neschváleného pokusu. Dokončená akce potřebuje záměr, identitu pokusu a účinek na účet ověřený porovnáním záznamů se skutečným stavem. Případ obnovy potřebuje stav před přerušením a po něm.

Zachovávejte verzi softwaru, konfiguraci, vstupní pozorování a relevantní výchozí stav účtu. Bez nich pozdější hodnotitel nemusí dokázat reprodukovat výsledek nebo určit, zda se opravená verze chová jinak. Zpráva o testu by měla zůstat užitečná po změně rozhraní.

Akceptační podklady automatizace by měly zahrnovat negativní výsledky. Správné zdržení se akce nebo odmítnutí může být zamýšlenou podmínkou úspěchu. Považování každého odmítnutí za neúspěch testu podporuje jednání softwaru v situaci, kdy vlastní požadavky na podklady říkají zastavit, což je opak cíle akceptačního procesu.

Případ: zobrazený symbol odpovídá nesprávnému mintu

Vytvořte dva smyšlené nebo řízené záznamy se stejným čitelným symbolem, ale různými identitami mintu. Předložte návrh, jehož zobrazený název připomíná povolené aktivum, zatímco mint leží mimo povolený rozsah. Očekávaným výsledkem je odmítnutí nebo nevyřešený stav identity před podepsáním nebo odesláním.

Podklady by měly ukazovat identifikátor kontrolovaný při schvalování. Pokud software přijme návrh kvůli shodě symbolu, test odhaluje selhání hranice. Pokud návrh odmítne pouze s obecnou chybou, chování může být bezpečné, ale vysvětlení stále potřebuje zlepšení.

Zkoumejte také exportované záznamy. Pokus s nesprávným mintem by se později neměl objevit v historii povoleného aktiva pouze kvůli podobnosti názvů. Identita musí zůstat konzistentní napříč rozhraním, schvalováním, provedením a vykazováním. Správné označení na úvodní obrazovce nestačí, pokud trvalý záznam aktiva slučuje.

Případ: tokenové jednotky se liší od surového množství

Použijte řízené množství tokenů se známou interpretací desetinných míst. Například surové množství 1 250 000 při šesti desetinných místech představuje 1,25 tokenu. Návrh, limit schválení a zobrazené množství by se měly v této interpretaci shodovat.

Očekávaným výsledkem je konzistentní zacházení s jednotkami od vstupu po záznam účtu. Rozpočtový limit vyjádřený v celých tokenech by neměl být přímo porovnáván se surovým celým číslem. Zkopírované množství by nemělo změnit význam při přesunu mezi pohledem na kotaci a náhledem transakce.

Zaznamenávejte surové i lidsky čitelné hodnoty tam, kde je test vyžaduje. Chyba jednotek může vytvořit velkou nezamýšlenou akci, zatímco každé jednotlivé pole vypadá číselně a platně. Tento případ je cenný, protože testuje vztah mezi komponentami, nikoli pouze návrat očekávaného čísla jednou převodní funkcí.

Případ: požadované podklady jsou zastaralé

Poskytněte návrh, jehož podpůrná kotace nebo tržní pozorování jsou starší než uvedený limit aktuálnosti pravidla. Zbytek případu ponechte platný, aby selhání šlo připsat stáří. Očekávaným výsledkem je konkrétní zdržení se akce nebo odmítnutí bez schválení nového odeslání ze zastaralých podkladů.

Potom poskytněte čerstvé pozorování a ověřte opětovné vyhodnocení návrhu softwarem za současných podmínek. Neměl by pouze obnovit staré schválení bez kontroly změny množství nebo částky, trasy či stavu účtu. Čerstvá data mohou vytvořit nové posouzení, ale zpětně nedělají ze starých podkladů aktuální.

Záznam testu by měl odlišovat čas události, přijetí do systému a hodnocení. Pokud se aktuálnost měří od příchodu zprávy při starém podkladovém pozorování, případ může povrchně projít a přesto porušit zamýšlené pravidlo. Zkoumejte skutečné měření času použité v rozhodnutí.

Případ: dva návrhy soutěží o jeden rozpočet

Začněte hypotetickým dostupným rozpočtem 100 jednotek a dvěma souběžnými návrhy každý na šedesát jednotek. Podle pravidla nepovolujícího půjčování ani nadměrné závazky nemohou oba získat nezávislé úplné schválení. Očekávaným chováním je koordinovaná rezervace, odmítnutí nebo seřazení podle uvedeného pravidla.

Pokud první návrh rezervuje šedesát jednotek, v tomto zjednodušeném případě zbývá nerezervovaných pouze čtyřicet. Druhý návrh by měl získat vysvětlený výsledek odrážející tento stav. Přesné pořadí se může lišit, ale kombinované závazky musejí zůstat v souladu s pravidlem.

Starší průvodce trvalou automatizací na Solaně vysvětluje záměry a rezervace. Tento akceptační případ ověřuje vynucování sdílené evidence implementací při souběhu. Postupná ukázka každého návrhu samostatně by rozpor zcela přehlédla.

Testovací případy automatizovaného obchodního softwaru potřebují neznámé stavy

Mnohá selhání jsou nejistá, nikoli jasně negativní. Požadavek může po odeslání překročit časový limit, zdroj může vrátit neúplný stav nebo se proces může zastavit před uložením odpovědi. Testy by měly tyto stavy výslovně představovat, místo považování každé výjimky za důkaz, že žádná akce nenastala.

Očekávaným chováním je trvalý nevyřešený pokus propojený s původním záměrem při omezení závislých akcí pravidlem kontroly souladu záznamů. Software by měl hledat podklady o tomto pokusu před rozhodnutím, zda je dovolena další ekonomická akce.

Testovací případy automatizovaného obchodního softwaru Solany by proto měly zahrnovat neznámé výsledky jako plnohodnotné případy. Systém správně zvládající úspěšné i neúspěšné transakce může stále vytvářet duplicitní expozici při chybném zacházení s obdobím mezi nimi. Akceptační záznam musí zkoumat tento interval, nikoli pouze konečný stav.

Případ: odeslání je přijato, ale ještě nepotvrzeno

Simulujte nebo pozorujte odpověď na odeslání poskytující identitu pokusu při stále čekajícím potvrzení. Rozhraní by mělo ukazovat stav odesláno nebo rovnocenný, zachovat relevantní rezervaci prostředků a pokračovat v kontrole výsledku podle svých pravidel.

Solana dokumentuje, že úspěšná odpověď sendTransaction sama nezaručuje zpracování nebo potvrzení. Akceptační test by měl ověřit, že software neoznačuje výsledek účtu za dokončený pouze kvůli úspěšnému návratu volání RPC. Dokumentace odesílání Solany.

Podklady úspěchu zahrnují historii přechodů stavů a nepřítomnost předčasného prohlášení souladu záznamů. Animace úspěchu může být přijatelná jako potvrzení přijetí odeslání při jasné formulaci, ale neměla by naznačovat již prokázaný požadovaný zůstatek tokenu.

Případ: po neznámém odeslání následuje opakovaný pokus

Přerušte cestu odpovědi poté, co mohl být pokus odeslán. Spusťte zdokumentovaný postup opakování nebo obnovy. Očekávaným výsledkem je pokračující zpracování stejného záměru s dostatečnou identitou pokusu k zabránění vytvoření nového pokynu pouze kvůli chybějící první odpovědi.

Zkoumejte trvalé záznamy kvůli duplicitním záměrům a rezervacím prostředků. Více síťových pokusů může být součástí zdokumentovaného pravidla odesílání, ale neměly by se stát nesouvisejícími ekonomickými akcemi. Test by měl určit přesný vztah mezi pokusy a původním schváleným požadavkem.

Starší průvodce obnovou API Solany probírá omezené opakované pokusy a obnovu. Tento případ testuje, zda provozní mechanismy zachovávají význam. Opakovaný pokus nakonec vytvářející změnu zůstatku není automaticky správný, pokud účet obsahuje také nezamýšlenou duplicitní akci.

Případ: částečný výstup ponechá skutečnou pozici

Začněte řízenou pozicí 1 000 tokenů a navrženým prodejem 400. Po podloženém výsledku by software měl v tomto zjednodušeném množstevním příkladu zachovat pozici 600 tokenů se samostatným záznamem nákladů a výnosu z prodeje. Neměl by označit celou pozici za uzavřenou kvůli dokončení výstupní akce.

Potom zkoumejte navazující pravidla výstupu. Měla by používat zbývající množství a současné podklady účtu. Druhý spouštěč by se neměl pokoušet prodat původních 1 000 tokenů ani předpokládat odstranění veškeré expozice prvním prodejem. Životní cyklus pozice musí přežít jednu obchodní kartu.

Průvodce automatickým obchodníkem Solany pokrývá částečné výstupy a poplatky, zatímco starší průvodce výběrem zisku a omezením ztráty na Solaně vysvětluje koordinaci výstupních podmínek. Tento případ kontroluje sdílený záznam pozice, na němž oba druhy kontrol závisejí.

Případ: poplatek změní účet bez úspěšného obchodu

Použijte podporovaný scénář selhání, v němž účtu vznikne transakční poplatek, ale zamýšlená směna se nedokončí. Software by měl zaznamenat neúspěšný pokus a příslušný náklad, místo zacházení s událostí jako se zcela nulovým účinkem na účet.

Zdokumentovaný transakční model Solany uvádí, že i neúspěšné provedení může nést poplatky. Akceptační případ by se měl zaměřit na to, zda účtování softwaru odráží skutečně pozorovaný účinek v řízeném prostředí. Neměl by předpokládat pevnou univerzální výši poplatku. Dokumentace transakcí Solany.

Podklady úspěchu zahrnují stav pokusu, změnu účtu a klasifikaci nákladu. Zpráva obsahující pouze úspěšné obchody by tento výsledek nedokázala vysvětlit, i kdyby viditelné množství pozice zůstalo správné. Úplné účtování zahrnuje provozní pokusy, které nedosáhly zamýšlené směny.

Případ: objeví se nepodporovaná vlastnost tokenu

Předložte konfiguraci tokenu nebo účtu mimo zdokumentovanou podporu interpretace softwaru. Očekávaným výsledkem je jasný nepodporovaný nebo nevyřešený stav bez automatického dosazení příznivých výchozích hodnot. Úspěšné získání dat účtu neprokazuje, že software rozumí každé relevantní vlastnosti.

Test by měl identifikovat hranici, která postup zastavila. Může jí být zpracování, pravidlo způsobilosti, cesta kotace nebo kontrola schválení. Pojmenované omezení pomáhá uživatelům odlišovat chybějící podporu od dočasného síťového selhání a brání nesmyslným opakovaným pokusům.

Nevyžadujte, aby software podporoval každý možný případ pro úspěch ve vymezeném hodnocení. Vyžadujte poctivé zacházení s uvedenou hranicí. Nepodporované případy se stávají nebezpečnými, když je rozhraní maskuje jako běžná podporovaná aktiva nebo vynechává omezení ze záznamu podkladů návrhu.

Případ: pravomoc je odňata během postupu

Připravte návrh a potom odejměte relevantní podpisovou nebo delegovanou pravomoc mechanismem použitým v řízeném testu. Další krok by měl bezpečně selhat a vysvětlit nedostupnost pravomoci. Dřívější vnitřní schválení by nemělo být považováno za náhradu současného vnějšího oprávnění.

Software by měl zachovat návrh a neúspěšnou cestu schválení bez opakovaného požadování širšího přístupu. Pokud je potřebné nové oprávnění, mělo by jít o samostatné výslovné posouzení. Test by měl také ověřit, že kontrola souladu záznamů pouze ke čtení zůstává dostupná tam, kde ji návrh podporuje.

Přesný postup odnětí závisí na modelu pravomoci. Akceptační zpráva by měla pojmenovat skutečně testovaný mechanismus a nezobecňovat výsledek na všechny návrhy peněženek nebo delegací. Úspěch demonstruje správné zvládnutí této definované hranice, nikoli univerzální bezpečnost úschovy.

Případ: proces se restartuje s otevřenou prací

Vytvořte trvalý stav obsahující jeden dokončený záměr, jeden schválený, ale neodeslaný návrh a jeden nevyřešený odeslaný pokus. Restartujte software. Každá položka by se měla vrátit se správnou identitou a stavem, místo sloučení do obecného seznamu čekajících.

Neodeslaný návrh může potřebovat ukončení platnosti nebo nové vyhodnocení. Odeslaný pokus potřebuje prověření a sladění záznamů se skutečným stavem. Dokončený záměr by se neměl znovu spustit. Tyto různé výsledky činí případ informativnějším než restart prázdné aplikace a kontrola objevení domovské obrazovky.

Zkoumejte rezervace prostředků po restartu. Měly by odpovídat obnovenému stavu bez nevysvětleného uvolnění nebo duplikace. Správný restart zachovává ekonomické vztahy mezi záznamy i samotné záznamy.

Případ: verze pravidla se změní uprostřed epizody

Otevřete řízený signál nebo návrh ve verzi A a potom aktivujte verzi B se změněným pravidlem způsobilosti nebo velikosti. Software by měl použít zdokumentované pravidlo přechodu: pokračovat ve staré epizodě pod A, uzavřít ji nebo migrovat s výslovným záznamem.

Očekávaným výsledkem není jediná univerzální volba přechodu. Je jím soulad s uvedeným pravidlem a zachování původní verze. Hodnotitel by měl dokázat vysvětlit, proč podobná pozorování před aktivací a po ní vytvářela různá rozhodnutí.

Průvodce obchodním algoritmem Solany sleduje jeden algoritmus přes pozorování, pravidla a posouzení. Akceptační testování kontroluje zachování tohoto řetězce při změně implementace. Tichá reinterpretace starých rozhodnutí podle současné verze činí pozdější výzkum a šetření incidentů nespolehlivými.

Případ: export rekonstruuje neúspěšný postup

Exportujte případ obsahující zdržení se akce, odmítnutý návrh, neznámý pokus později vyřešený a částečnou pozici. Požádejte hodnotitele o rekonstrukci posloupnosti bez přístupu k živému rozhraní. Export by měl zachovávat identity, časy, jednotky, verze, náklady a vztahy oprav potřebné pro tuto úlohu.

Seznam úspěšných transakcí tímto širším testem neprojde. Vynechává rozhodnutí a nejistoty vysvětlující postup. Zpráva by měla uvádět chybějící záznamy, místo předpokladu úplnosti stažitelného souboru kvůli jeho úspěšnému otevření.

Zkoumejte export také kvůli tajným údajům. Provozní odkazy by měly identifikovat cestu pravomoci bez odhalení soukromých přihlašovacích údajů. Užitečný akceptační záznam lze sdílet k posouzení při oddělení schopnosti kontrolovat aktiva od schopnosti porozumět dění.

Posuzujte selhání podle důsledku a příčiny

Když případ selže, určete, zda se problém týká správnosti, pravomoci, účtování, obnovitelnosti nebo vysvětlení. Tyto kategorie pomáhají určovat prioritu opravy. Zavádějící označení stavu a nezamýšlená duplicitní akce jsou obě vady, ale mají různé důsledky a vyžadují různé následné ověření.

Uchovávejte podklady selhání a opravenou verzi. Znovu spusťte dotčený případ a blízce související případy zkoušející změněnou hranici. Nepovažujte opravu za dokončenou pouze kvůli zmizení původní chybové zprávy; podkladové chování účtu a stavu musí splnit očekávaný výsledek.

Testy by měly zůstávat smysluplné při vývoji softwaru. Odstraňujte případy pouze tehdy, když jejich rozsah již není podporován a definice produktu se podle toho mění. Zmenšující se testovací sada by neměla tiše zlepšovat zdánlivou úspěšnost vyloučením obtížného chování, na němž postup stále závisí.

Uchovávejte případy, které uspějí nečinností

Některé nejdůležitější případy končí bez transakce: zastaralé podklady vedou ke zdržení se akce, nedostatečný rozpočet k odmítnutí a odňatá pravomoc brání podepsání. Uchovávejte tyto případy v akceptační zprávě, místo zacházení s nimi jako s předběžným nastavením úspěšné cesty.

Jejich podklady by měly ukazovat důvod neprovedení akce i to, zda nějaké prostředky nebo oprávnění zůstaly následně nesprávně aktivní. Správné odmítnutí může stále zanechat neuvolněnou rezervaci nebo zavádějící otevřený stav. Zkoumání úplného výsledku bez akce potvrzuje, že software respektoval hranici a vrátil postup do srozumitelného stavu.

Přijímejte definovaný postup, nikoli slib

Konečná akceptační zpráva by měla identifikovat testovanou verzi, prostředí, model pravomoci, podporovaný rozsah, výsledky případů a netestovaná omezení. Měla by odlišovat pozorované podklady od tvrzení pouze z dokumentace a simulované chování od produkčního.

Akceptace automatizovaného obchodního softwaru Solany je nejsilnější, když ukazuje jednání i zdrženlivost. Software by měl jednat při splnění definovaných požadavků, odmítat nebo se zdržet akce při jejich nesplnění a zachovávat nejistotu do možnosti prokázání výsledku účtu. Tato chování jsou informativnější než široké tvrzení automatizační schopnosti.

Sbírka konkrétních případů dává čtenáři přezkoumatelný základ pro přijetí nebo další práci. Neodstraňuje tržní riziko ani nedokazuje hodnotu strategie. Prokazuje, zda software zvládá určený postup způsobem, který lze vysvětlit, obnovit a zkontrolovat vůči skutečně udělené pravomoci.