Oprogramowanie automatycznego handlu kryptowalutami należy opisywać przez obserwowalne zachowanie. Wymaganie „wykonuj sprawnie” brzmi przydatnie, ale nie mówi osobie sprawdzającej, co program musi zrobić po wygaśnięciu kwotowania, przy już zarezerwowanych środkach lub zniknięciu odpowiedzi na wysłanie. Sprawdzalne wymaganie określa dane wejściowe, dozwolone przejście i dowody ustalające wynik.
Poradnik rozwija test odbioru automatyzacji uwzględniający koszty na fikcyjnym koncie spot. Liczby są wymyślone, aby księgowanie dało się odtworzyć. Nie reprezentują obecnego cennika ani oczekiwanego zwrotu. Celem jest ustalenie, czy oprogramowanie przestrzega deklarowanych zasad i zachowuje stan konta. Zaliczenie testu wykazuje zachowanie operacyjne, a nie rentowność strategii handlowej.
Wymagania oprogramowania automatycznego handlu kryptowalutami zaczynają się od niezmienników
Niezmiennik jest warunkiem, który powinien pozostawać prawdziwy podczas zwykłych zdarzeń i awarii. Przydatny przykład mówi, że całkowita zaangażowana gotówka nie może przekraczać dostępnych autoryzowanych zasobów. Inny mówi, że ten sam trwały zamiar nie może tworzyć dodatkowego zlecenia tylko przez dwukrotne dostarczenie zdarzenia. Stwierdzenia są silniejsze niż zbiór zrzutów udanej ścieżki, ponieważ obowiązują w całym procesie.
Zapisuj niezmienniki językiem nadającym się do sprawdzenia. System musi wskazać konto przed rezerwacją kapitału. Nieznany wynik zlecenia musi zachować jego rezerwację. Nowa konfiguracja nie może przepisywać uzasadnienia przypisanego wcześniejszemu zamiarowi. Każde stwierdzenie powinno wskazywać dowód naruszenia. Jeśli żadna możliwa obserwacja nie mogłaby obalić wymagania, jest ono prawdopodobnie zbyt niejasne do odbioru.
Wcześniejszy poradnik cyklu automatycznego handlu oddziela konfigurację, obserwację i aktywność konta. Używaj tych etapów przy przypisywaniu wymagań. Komponent strategii może proponować działanie, ale niezależny komponent ryzyka decyduje, czy mieści się ono w limitach konta. Zachowanie osobnych obowiązków ułatwia wyjaśnienie, dlaczego obserwacja wyglądająca na atrakcyjną nie doprowadziła do wykonania.
Precyzyjnie zdefiniuj fikcyjne konto
Załóż hipotetyczne konto zaczynające z 2 000 jednostek kwotowanych i bez pozycji w wybranym aktywie. Z tego salda 200 jednostek jest zarezerwowane jako bufor operacyjny, a 300 już zaangażowano w inny aktywny zamiar. Nowa decyzja zaczyna więc z pojemnością 1 500 jednostek według podanej polityki. Kategorie powinny pozostać odróżnialne na każdym ekranie i w eksporcie.
Nowa strategia proponuje zakup najwyżej 80 jednostek aktywa z limitem ceny 10 jednostek kwotowanych za każdą. W ćwiczeniu załóż opłatę handlową jednej dziesiątej procenta pobieraną w aktywie kwotowanym oraz osobno modelowany wydatek wykonania 2 jednostek. Maksymalna nowa rezerwacja wynosi 800 plus 0,80 plus 2, czyli 802,80 jednostki kwotowanej. Rzeczywiste koszty platformy trzeba sprawdzić osobno.
Zapisz przypadek testowy jako niezmienne dane wejściowe. Uwzględnij identyfikator konta, tożsamość aktywa, tożsamość aktywa kwotowanego, początkowe salda, istniejące zobowiązania i założenia opłat. Zrzut końcowego wyniku nie wystarcza do odtworzenia testu. Późniejsza osoba sprawdzająca potrzebuje wiedzy o zasobach dostępnych przed nową decyzją i kosztach uwzględnionych w budżecie autoryzacji.
Określ, co wolno proponować sygnałowi
Sygnał powinien tworzyć propozycję z powodem, znacznikiem czasu dowodów i żądaną ekspozycją. Nie powinien tworzyć salda, zmieniać uprawnienia konta ani zakładać wykonania zlecenia. W fikcyjnym przypadku sygnał proponuje zakup 80 jednostek, ponieważ spełniono wcześniej zadeklarowany warunek obserwacji. Ćwiczenie odbioru nie musi twierdzić, że warunek ma wartość prognostyczną.
Propozycja powinna wskazywać wersję dowodów użytych do jej obliczenia. Przy zmianie bazowej obserwacji zachowaj pierwotną propozycję i utwórz nową ocenę zamiast cicho zastępować historię. Ma to znaczenie przy badaniu powodów działania systemu. Nie można uczciwie oceniać decyzji według informacji dostępnych dopiero po jej autoryzacji.
Poradnik automatyzacji kryptowalut wyjaśnia dzielenie szerokiego celu automatyzacji na ograniczone obowiązki. Zastosuj podział tutaj: sygnał proponuje, warstwa ryzyka sprawdza, warstwa rezerwacji angażuje pojemność, a warstwa wykonawcza podejmuje próbę dozwolonego działania. Nazwy mogą różnić się między implementacjami, ale obowiązki powinny pozostać widoczne w zapisie odbioru.
Autoryzacja musi obejmować pełny budżet
Kontrola ryzyka porównuje maksymalną rezerwację 802,80 jednostki z dostępną pojemnością 1 500 jednostek. Przy fikcyjnej polityce propozycja się mieści i pozostawia 697,20 jednostki do innej nowej aktywności. Test powinien sprawdzać obie liczby. Sprawdzenie wyłącznie tego, czy żądana wartość nominalna 800 jest niższa niż całkowite saldo, pominęłoby opłaty, bufor operacyjny i wcześniejsze zobowiązanie.
Określ, czy przydział na opłatę jest twardą granicą, czy szacunkiem. Jeśli rzeczywiste wykonanie mogłoby przekroczyć autoryzowany budżet, oprogramowanie potrzebuje innego egzekwowalnego ograniczenia lub reguły odmowy. Nazwanie kosztu szacowanym nie przyznaje nieograniczonych uprawnień. Zapis odbioru powinien wyjaśniać postępowanie po przekroczeniu przez końcowe kwotowanie lub wydatek transakcji założenia użytego podczas autoryzacji.
Testuj też wartość graniczną. Zwiększaj proponowaną kwotę aż rezerwacja przekroczy pojemność o niewielką ilość. Oczekiwany wynik to udokumentowane odrzucenie lub nowa propozycja jawnie dopuszczona przez politykę. Cicha zmiana wielkości nie jest automatycznie akceptowalna, ponieważ zmienia pierwotną decyzję. Jeśli jest obsługiwana, jej reguły i wynikowa kwota powinny należeć do podanego wymagania.
Oprogramowanie automatycznego handlu kryptowalutami potrzebuje trwałych tożsamości
Nadaj decyzji identyfikator zamiaru przed wysłaniem. Identyfikator powinien łączyć pierwotną obserwację, autoryzację konta, rezerwację kapitału i wynikowe próby wykonania. Osobny identyfikator zlecenia lub transakcji może pojawić się po dotarciu żądania do systemu wykonawczego. Zachowuj oba, aby aplikacja odróżniała własną trwałą decyzję od jej zewnętrznej reprezentacji.
Podczas testu dostarcz dwa razy to samo zdarzenie wejściowe. Drugie dostarczenie powinno odnaleźć istniejący zamiar, a nie rezerwować kolejne 802,80 jednostki. To ważny warunek odbioru, ponieważ wiele systemów danych może ponownie dostarczać zdarzenia po nawiązaniu połączenia. Podwójny transport nie jest drugą okazją ekonomiczną, a konto nie powinno wywodzić nowej autoryzacji wyłącznie z ponownego dostarczenia.
Wcześniejszy poradnik koordynacji wielu portfeli przydaje się przy wielu procesach obsługujących konta. Tożsamość zamiaru musi mieć dość starannie określony zakres, aby unikać pomyłek między kontami, nadal zapobiegając podwójnej pracy na zamierzonym koncie. Globalnie unikalna etykieta pomaga, lecz rzeczywistym wymaganiem jest spójne przypisanie odpowiedzialności i interpretacja w całym procesie.
Modeluj częściowe wykonanie bez utraty reszty
Załóż teraz, że hipotetyczne zlecenie wykonuje się na 50 jednostek po 9,90. Koszt nominalny wynosi 495. Przy założonej stawce opłata wykonania wynosi 0,495. Jeśli dla tej próby poniesiono wydatek wykonania 2 jednostek, ukończona część zużyła 497,495 jednostki kwotowanej. Konto nabyło 50 jednostek, a nie pierwotnie żądane 80.
Pozostałe 30 jednostek nadal wiąże się z aktywnym zleceniem. Ich maksymalna wartość nominalna przy cenie limitu wynosi 300, a założona maksymalna opłata 0,30. Zachowaj rezerwację 300,30 jednostki na tę resztę przy modelu kosztów ćwiczenia. Różnica między pierwotną rezerwacją a ukończonymi kosztami plus pozostałą rezerwacją wynosi 5,005 jednostki, odzwierciedlając lepszą cenę i niższą opłatę wykonanej ilości.
Test powinien jawnie sprawdzać politykę zwalniania zasobów. Niektóre systemy dla prostoty zatrzymują całą pierwotną rezerwację do ukończenia. Inne stopniowo zwalniają potwierdzoną nadwyżkę pojemności. Oba podejścia wymagają jasnej specyfikacji. Kluczowym wymaganiem jest niewypuszczanie pieniędzy nadal potrzebnych aktywnej lub nierozstrzygniętej reszcie i nietraktowanie niewykonanej ilości jako posiadanego aktywa.
Anulowanie jest żądaniem z własnym wynikiem
Po częściowym wykonaniu strategia żąda anulowania pozostałych 30 jednostek. Żądanie nie dowodzi natychmiast zniknięcia zlecenia. System wykonawczy może potwierdzić otrzymanie przed zgłoszeniem stanu końcowego, a w tym czasie może nastąpić kolejne wykonanie. Scenariusz odbioru powinien obejmować tę możliwość zamiast zakładać, że anulowanie jest synchronicznym wymazaniem.
Dla podstawowego przypadku ustal potwierdzenie anulowania bez dodatkowego wykonania. Można wtedy zwolnić rezerwację reszty 300,30 jednostki. Konto zachowuje 50 nabytych jednostek i ukończony koszt 497,495 jednostki. Niepowiązane zobowiązanie 300 jednostek i bufor operacyjny 200 jednostek pozostają bez zmian. Anulowana reszta nie odwraca wcześniejszego zakupu ani poniesionych wydatków.
Dodaj drugi wariant, w którym przed zakończeniem anulowania wykonuje się jeszcze pięć jednostek. System musi uwzględnić je i rzeczywiste koszty przed ustaleniem końcowej zwalnianej kwoty. Oczekiwany wynik należy obliczyć z nowych dowodów wykonania, a nie czasu kliknięcia anulowania przez operatora. Wariant sprawdza, czy implementacja podąża za zdarzeniami ekonomicznymi zamiast zamiarami interfejsu.
Polecaj i zarabiaj USDC
Polecaj i zarabiaj USDCNasz program partnerski wypłaca prowizje w czasie rzeczywistym.
Przećwicz nieznany wynik wysłania
Scenariusz odzyskiwania automatycznego handlu powinien przerywać komunikację natychmiast po wysłaniu. Środowisko testowe zapisuje, że żądanie mogło dotrzeć do systemu wykonawczego, ale aplikacja nie otrzymuje definitywnej odpowiedzi. Wymagany stan to nierozstrzygnięty, z zachowaną rezerwacją. Nie należy tworzyć nowego zlecenia ekonomicznego tylko dlatego, że pierwotne wywołanie zwróciło błąd lub przekroczyło limit czasu.
Odzyskiwanie szuka istniejącego wyniku przez trwałe oznaczenia obsługiwane przez integrację. Może sprawdzać historię konta, otwarte zlecenia lub status transakcji. Specyfikacja powinna opisywać dowody wystarczające do sklasyfikowania próby jako przyjętej, odrzuconej, ukończonej lub nadal nieznanej. Powinna też opisywać eskalację niepewności przy sprzecznych lub nadal niepełnych źródłach.
Poradnik bota arbitrażowego krypto pokazuje szczególną wagę nierozstrzygniętego wysłania, gdy inna część operacji mogła się wykonać. Ta sama zasada dotyczy przykładu jednego zlecenia. Przekroczenie czasu zmienia wiedzę aplikacji. Niekoniecznie zmienia działania zewnętrznego konta, więc test odbioru musi zachować odrębność tych faktów.
Mierz koszty bez zamieniania szacunku w fakt
Po uzgodnieniu zastąp szacowane koszty wykonania zaobserwowanymi kwotami, zachowując pierwotny szacunek do porównania. Pozwala to sprawdzić, czy model budżetu był ostrożny, dokładny czy niepełny. Jedno pole nadpisane z szacunku na wartość rzeczywistą niszczy dowody i utrudnia poprawianie przyszłych założeń kosztów.
W fikcyjnym przypadku częściowego wykonania zaobserwowany całkowity koszt wynosi 497,495 jednostki przy podanych założeniach. Dzielenie przez 50 daje 9,9499 jednostki kwotowanej na nabytą jednostkę aktywa, gdy stały wydatek przypisano temu zakupowi. Średnia cena handlowa nadal wynosi 9,90. Obie liczby mogą być przydatne, ale powinny mieć inne etykiety, ponieważ jedna obejmuje koszty, a druga nie.
Poradnik oprogramowania arbitrażu krypto bada znaczenie tego rozróżnienia przy niewielkiej widocznej różnicy cen. Przy odbiorze istotne jest odtwarzalne księgowanie. Oprogramowanie nie powinno przełączać miar brutto i obejmujących koszty zależnie od korzystniejszego wyglądu. Stabilna definicja pozwala porównać oczekiwaną ekonomikę z rzeczywistym zapisem konta.
Testuj nieaktualne dowody i zmienną konfigurację
Utwórz przypadek, w którym obserwacja wygasa między propozycją a autoryzacją. Oczekiwane zachowanie to ponowna kontrola, odmowa lub inne jawnie dozwolone przejście. Aplikacja nie powinna interpretować istnienia niegdyś ważnego sygnału jako trwałego uprawnienia. Limit wieku dowodów musi należeć do reguły decyzji i pojawiać się w zapisie odrzucenia.
Potem zmień konfigurację strategii przy oczekującym zamiarze. Istniejący zamiar powinien pozostać związany z wersją, która go autoryzowała, chyba że zmieni go udokumentowany proces poprawek. Nowa konfiguracja może rządzić przyszłymi decyzjami bez przepisywania przeszłości. Jest to szczególnie ważne przy późniejszej próbie odtworzenia powodów zaangażowania konkretnej kwoty przez system.
Przydatny test odróżnia zapis konfiguracji od aktywacji. Zapisanie zmienionego limitu niekoniecznie oznacza przyjęcie go przez każdy działający komponent. Oprogramowanie powinno ujawniać aktywną wersję i moment wejścia zmiany w życie. W przeciwnym razie operator może sądzić, że ograniczenie obowiązuje, gdy proces nadal używa wcześniejszego zestawu uprawnień.
Uwzględniaj negatywne przypadki, które czegoś uczą
Testy negatywne powinny celować w istotne sposoby niepowodzenia. Nieobsługiwana tożsamość aktywa, wyczerpany zasób transakcji, nieaktualny obraz konta i nadmiernie zaangażowany budżet testują różne granice. Duży zbiór niemal identycznych błędnych danych wejściowych może dawać imponującą liczbę testów bez zwiększania zaufania do ekonomicznego zachowania systemu.
Dla każdego negatywnego przypadku określ, co musi pozostać bez zmian. Odrzucona propozycja nie powinna uzyskać identyfikatora rzeczywistego zlecenia, zużyć przydziału handlowego ani pojawić się jako ukończona transakcja. Nadal może tworzyć zapis audytowy i koszt operacyjny zależnie od miejsca odrzucenia. Rozróżnienie powinno być jawne, aby test nie mylił zachowania dowodów z nieautoryzowaną aktywnością konta.
Wcześniejsza karta oceny dowodów oprogramowania handlowego daje przydatną strukturę oceny. Stosuj ją do wykazanego zachowania zamiast deklarowanego pokrycia. Niezaliczony test jest wartościową informacją, gdy wskazuje wymaganie do wyjaśnienia lub wadę implementacji do poprawienia przed szerszym użyciem.
Odtwórz wynik z dziennika
Na końcu sesji odbioru wyeksportuj dziennik i odtwórz konto bez działającej aplikacji. Osoba sprawdzająca powinna wskazać początkowe saldo 2 000 jednostek, osobne rezerwacje, 50 nabytych jednostek, ukończony koszt i zwolnioną resztę. Każdy wniosek powinien wskazywać zapisane zdarzenie lub podane założenie.
Odtwarzanie testuje więcej niż księgowość. Ujawnia, czy oprogramowanie zachowuje chronologię i czy etykiety zdarzeń oznaczają to, co deklarują. Zdarzenia wysłania nie należy liczyć jako wykonania. Żądania anulowania nie należy liczyć jako potwierdzonego anulowania. Aktualizacja wyceny nie powinna zmieniać liczby posiadanych jednostek aktywa. Dziennik powinien utrzymywać rozróżnienia także po ich uproszczeniu w interfejsie.
Osoba sprawdzająca powinna też móc wskazać luki. Jeśli wydatek wykonania jest niedostępny, eksport powinien mówić o niepełnym księgowaniu kosztów zamiast wstawiać zero. Brak to inny stan niż zmierzone zero. Zachowanie różnicy pozwala właścicielowi konta ocenić praktyczne granice wyniku bez wymyślania precyzji.
Zapisuj odbiór bez twierdzenia o sukcesie strategii
Raport odbioru powinien nazywać zestaw wymagań, przypadki testowe, wersję oprogramowania i zaobserwowane wyniki. Powinien wskazywać pozostałe ograniczenia i warunki wymagające ponownego testu. Zmiana znaczenia zleceń, uprawnień konta lub obsługi kosztów może unieważniać wcześniejszy wynik odbioru nawet przy tych samych widocznych ustawieniach strategii.
Zaliczenie scenariuszy wykazuje spójność zachowania systemu z określonym procesem. Nie wykazuje przewidywania przyszłych cen przez sygnał ani odpowiedniości wybranego przydziału dla konkretnej osoby. To osobne pytania badawcze i decyzyjne. Zachowanie podziału zapobiega przekształceniu udanej demonstracji technicznej w niepoparte twierdzenie ekonomiczne.
Praktyczny rezultat to mały, powtarzalny pakiet dowodów: wymagania, fikcyjne dane wejściowe, oczekiwane przejścia, zaobserwowane zapisy i uzgodniona arytmetyka. Dzięki niemu inna osoba sprawdzająca może zrozumieć, o co poproszono oprogramowanie i dlaczego wynik liczy się jako zaliczenie lub niepowodzenie. To mocniejsza podstawa automatyzacji niż pewność budowana nieprzerwaną demonstracją.
Zachowuj różnicę między zegarem testu a zegarem rynku
Odtwarzalny przypadek powinien jawnie kontrolować czas. Test potrzebuje wiedzy, kiedy wystąpiła obserwacja, kiedy stała się dostępna aplikacji i kiedy oceniono proponowane działanie. Mogą to być trzy różne chwile. Jeśli odtwarzanie używa poprawionej historycznej wartości przed pierwotnym nadejściem korekty, może sprawiać wrażenie decyzji lepiej poinformowanej niż mógł być jakikolwiek rzeczywisty operator.
Stosuj to samo rozróżnienie przy symulowaniu awarii. Przesuwaj zegar testu, wstrzymując aktualizację konta, i sprawdź aktywację polityki nieaktualnego stanu na zamierzonej granicy. Wznów strumień opóźnionymi zdarzeniami i sprawdź, czy aplikacja zachowuje ich pierwotne czasy zdarzeń. Ćwiczenie może ujawnić system oznaczający starą obserwację jako świeżą tylko dlatego, że otrzymał ją po ponownym połączeniu.
Na koniec zachowaj kolejność zdarzeń ze wspólnym wyświetlanym znacznikiem czasu. Zaokrąglone sekundy mogą ukrywać sekwencję wykonania, żądania anulowania i aktualizacji salda. Trwałe oznaczenie sekwencji lub dokładniejszy zapis czasu pomaga odtworzyć wynik. Odbiór powinien ustalać dowody kolejności używane przez implementację i zachowanie przy niepełnych dowodach.