Solanan automatisoitua kaupankäyntiohjelmistoa tulee arvioida tilanteilla, joiden odotetut tulokset ovat havaittavia. Ominaisuusluettelo voi sanoa ohjelmiston tukevan riskinhallintaa, uusintoja tai palautumista näyttämättä niiden toimintaa vanhalla näytöllä tai epävarmassa transaktiotilassa. Hyväksyntätapaukset muuttavat väitteet kysymyksiksi, joihin tietueet vastaavat.

Hyväksyntätapaus alkaa tunnetusta tilasta, tuo hallitun ehdon ja määrittää läpäisyksi laskettavan toiminnan. Se nimeää myös toiminnan osoittavan näytön. Vihreä ruutuviesti ei riitä testin koskiessa tilitilaa tai kaksoistoimen syntymistä.

Seuraavat tapaukset ovat opetuksellisia ja toimittajariippumattomia. Ne voidaan sovittaa hallittuun ympäristöön tai allekirjoittamattomaan tilaan soveltuvin osin. Ne eivät valtuuta todellista käyttöönottoa, määrää strategiaa eivätkä osoita tuotantototeutuksen laatua pelkän testiympäristön oikean toiminnan perusteella.

Solanan automatisoidun kaupankäyntiohjelmiston hyväksyntä tarvitsee rajauksen

Määritä hyväksyttävä työnkulku. Pelkkä tutkimussignaalipalvelu, käsin allekirjoitettava kaupankäyntityökalu ja valvomaton strategia sisältävät eri valtuusrajat. Testijoukon tulee vastata aiottua käyttöä olettamatta joka tuotteen olevan tarkoitettu joka rooliin.

Kerro tuettu verkko, omaisuuserät, ohjelmat, toimintotyypit ja tilimalli. Yksilöi testiin sisältyvät ja simuloidut komponentit. Läpäisy koskee tätä rajausta. Sitä ei saa laajentaa väitteeksi tukemattomista markkinoista tai testaamattomista käyttöoikeusmekanismeista.

Solanan kaupankäyntiautomaation opas kuvaa ajoituksen tokenin, markkinan ja lompakon tilan mukaan. Hyväksyntätapausten tulee testata tilariippuvuuksia suoraan. Ohjelmiston tulee osoittaa toimintansa yhden edellytyksen muuttuessa eikä vain toistaa onnistumista ihanneoloissa.

Kirjoita näyttövaatimus ennen tapauksen ajamista

Päätä jokaiselle tapaukselle odotetun toiminnan todistava tietue. Hylätty ehdotus tarvitsee syyn ja sen, ettei siitä synny luvatonta yritystä. Valmis toimi tarvitsee aikomuksen, yritysidentiteetin ja täsmäytetyn tilivaikutuksen. Palautumistapaus tarvitsee keskeytystä edeltävän ja seuraavan tilan.

Säilytä ohjelmistoversio, asetukset, syötehavainnot ja olennainen tilin lähtötila. Ilman niitä myöhempi arvioija ei ehkä voi toistaa tulosta tai ratkaista korjatun version toimintaeroa. Testiraportin tulee hyödyttää liittymän muuttumisen jälkeenkin.

Automaation hyväksyntänäyttöön tulee sisältyä kielteisiä tuloksia. Oikea pidättäytyminen tai hylkäys voi olla aiottu läpäisyehto. Jokaisen kieltäytymisen pitäminen testivirheenä rohkaisee toimintaa oman näyttösopimuksen vaatiessa pysähtymistä, mikä on hyväksyntäprosessin tarkoituksen vastaista.

Tapaus: näyttötunnus vastaa väärää mint-osoitetta

Luo kaksi kuvitteellista tai hallittua tietuetta samalla luettavalla tunnuksella mutta eri mint-identiteeteillä. Esitä ehdotus, jonka näyttönimi muistuttaa sallittua varaa mutta mint on rajauksen ulkopuolella. Odotettu tulos on hylkäys tai selvittämätön identiteettitila ennen allekirjoitusta tai lähetystä.

Näytön tulee kertoa valtuutuksen tarkistama tunniste. Jos ohjelmisto hyväksyy pelkän tunnuksen vastaavuudella, testi paljastaa rajavirheen. Pelkkä yleisvirhe hylkäyksessä voi merkitä turvallista toimintaa mutta silti parannettavaa selitystä.

Tutki myös viennit. Väärän mintin yritys ei saa myöhemmin näkyä sallitun varan historiassa vain nimien samankaltaisuuden vuoksi. Identiteetin on säilyttävä liittymän, valtuutuksen, toteutuksen ja raportoinnin läpi. Oikea etunäkymän nimike ei riitä pysyvän tietueen yhdistäessä varat.

Tapaus: tokenyksiköt eroavat raakamäärästä

Käytä hallittua token-määrää tunnetulla desimaalitulkinnalla. Esimerkiksi 1 250 000 raakamäärä kuudella desimaalilla tarkoittaa 1,25 tokenia. Ehdotuksen, valtuutusrajan ja näyttömäärän tulee vastata samaa tulkintaa.

Odotus on johdonmukainen yksikkökäsittely syötteestä tilitietueeseen. Kokonaisissa tokeneissa ilmaistua budjettirajaa ei verrata suoraan raakaan kokonaislukuun. Kopioidun määrän merkitys ei saa muuttua noteerausnäkymän ja transaktioesikatselun välillä.

Kirjaa raaka ja ihmisluettava arvo testin niitä vaatiessa. Yksikkövirhe voi tuottaa suuren tahattoman toimen jokaisen kentän näyttäessä numeroarvoltaan kelvolliselta. Tapaus on arvokas testatessaan komponenttien suhteita eikä vain yhden muuntofunktion odotettua lukutulosta.

Tapaus: vaadittu näyttö on vanhentunut

Anna ehdotus, jonka tukinoteeraus tai markkinahavainto ylittää säännön ilmoitetun tuoreusrajan. Pidä muu tapaus kelvollisena, jotta syy kohdistuu ikään. Odotus on täsmällinen pidättäytyminen tai hylkäys ilman vanhaan näyttöön perustuvaa uutta lähetysvaltuutusta.

Anna sitten tuore havainto ja varmenna uudelleenarviointi nykyoloissa. Ohjelmisto ei saa vain jatkaa vanhaa hyväksyntää tarkistamatta määrän, reitin tai tilitilan muutoksia. Tuore tieto voi luoda uuden arvion mutta ei tee vanhasta näytöstä takautuvasti ajantasaista.

Testitietueen tulee erottaa tapahtuma-, vastaanotto- ja arviointiaika. Viestin saapumisesta mitattu tuoreus vanhalla taustahavainnolla voi läpäistä pintapuolisesti ja silti rikkoa käytäntöä. Tutki päätöksessä todella käytetty kello.

Tapaus: kaksi ehdotusta kilpailee yhdestä budjetista

Aloita kuvitteellisesta 100 yksikön vapaasta budjetista ja kahdesta samanaikaisesta kuudenkymmenen yksikön ehdotuksesta. Lainaamisen ja ylisitoutumisen kieltävä käytäntö ei voi antaa molemmille itsenäistä täyttä valtuutusta. Odotus on koordinoitu varaus, hylkäys tai järjestäminen ilmoitetun säännön mukaan.

Ensimmäisen varatessa kuusikymmentä jää tässä yksinkertaistetussa tapauksessa vain neljäkymmentä varaamatta. Toisen tulee saada tätä tilaa kuvaava selitetty tulos. Tarkka järjestys voi vaihdella, mutta yhteissitoumusten on pysyttävä käytännön mukaisina.

Aiempi Solanan pysyvän automaation opas selittää aikomukset ja varaukset. Tämä tapaus varmentaa yhteiskirjanpidon valvonnan rinnakkaisuudessa. Kummankin ehdotuksen yksittäinen peräkkäisesittely ohittaisi ristiriidan kokonaan.

Solanan automatisoidun kaupankäyntiohjelmiston testit tarvitsevat tuntemattomia

Moni virhe on epävarma eikä selvästi kielteinen. Pyyntö voi aikakatketa lähetyksen jälkeen, lähde palauttaa puutteellisen tilan tai prosessi pysähtyä ennen vastauksen tallentamista. Testien tulee esittää tilat nimenomaisesti pitämättä jokaista poikkeusta todisteena toimettomuudesta.

Odotus on pysyvä selvittämätön yritys yhdistettynä alkuperäiseen aikomukseen, riippuvien toimien pysyessä täsmäytyskäytännön rajoissa. Ohjelmiston tulee etsiä yrityksen näyttöä ennen toisen taloudellisen toimen sallittavuuspäätöstä.

Solanan automatisoidun kaupankäyntiohjelmiston testien tulee siksi sisältää tuntemattomat tulokset varsinaisina tapauksina. Onnistuneet ja epäonnistuneet transaktiot oikein käsittelevä voi silti luoda kaksoisaltistuksen käsitellessään niiden välisen ajan väärin. Hyväksyntätietueen on tutkittava väli eikä vain lopullinen tila.

Tapaus: lähetys hyväksytään mutta vahvistus odottaa

Simuloi tai havaitse lähetysvastaus, joka antaa yritysidentiteetin vahvistuksen vielä odottaessa. Liittymän tulee näyttää lähetetty tai vastaava tila, säilyttää olennainen resurssivaraus ja jatkaa tuloksen tarkistamista käytännön mukaan.

Solana dokumentoi, ettei onnistunut sendTransaction-vastaus itsessään takaa käsittelyä tai vahvistusta. Varmenna testissä, ettei ohjelmisto merkitse tilitulosta valmiiksi vain onnistuneen RPC-kutsun perusteella. Solanan lähetysdokumentaatio.

Läpäisynäyttö sisältää tilasiirtymähistorian ja ennenaikaisen täsmäytyksen puuttumisen. Onnistumisanimaatio voi sopia lähetyskuittaukseksi sanamuodon ollessa selkeä, mutta se ei saa vihjata halutun token-saldon jo syntyneen.

Tapaus: uusinta seuraa tuntematonta lähetystä

Katkaise vastauspolku yrityksen mahdollisen lähetyksen jälkeen. Käynnistä dokumentoitu uusinta tai palautuminen. Odotus on saman aikomuksen käsittelyn jatkuminen riittävällä yritysidentiteetillä, jotta uutta toimeksiantoa ei luoda vain ensimmäisen vastauksen puuttuessa.

Tutki pysyvien tietueiden kaksoisaikomukset ja resurssivaraukset. Useat verkkoyritykset voivat kuulua dokumentoituun lähetyskäytäntöön, mutta ne eivät saa muuttua irrallisiksi taloustoimiksi. Testin tulee yksilöidä yritysten ja alkuperäisen valtuutetun pyynnön tarkka suhde.

Aiempi Solanan rajapinnan palautumisopas käsittelee rajattuja uusintoja ja palautumista. Tapaus testaa mekanismien merkityksen säilymistä. Lopulta saldomuutoksen tuottava uusinta ei automaattisesti ole oikein, jos tilillä on myös tahaton kaksoistoimi.

Tapaus: osasulkeminen jättää todellisen position

Aloita hallitusta 1 000 tokenin positiosta ja 400 tokenin myyntiehdotuksesta. Tuetun tuloksen jälkeen tulee säilyä tässä yksinkertaistetussa määräesimerkissä 600 tokenin positio kulut ja tuotot erikseen kirjattuina. Koko positiota ei merkitä suljetuksi yhden sulkemistoimen valmistuttua.

Tutki sitten myöhemmät sulkemissäännöt. Niiden tulee käyttää loppumäärää ja nykyistä tilinäyttöä. Toinen laukaisu ei yritä myydä alkuperäistä 1 000 tokenia eikä oleta ensimmäisen myynnin poistaneen kaikkea altistusta. Position elinkaaren on jatkuttava yhden kauppakortin yli.

Solanan automaattikauppiaan opas kattaa osasulkemiset ja maksut, aiempi Solanan voitonotto- ja tappiorajaopas sulkemisehtojen yhteensovituksen. Tapaus tarkistaa molempien hallintakeinojen tarvitseman yhteisen positiotietueen.

Tapaus: maksu muuttaa tiliä ilman onnistunutta kauppaa

Käytä tuettua virhetilannetta, jossa tilille tulee transaktiomaksu tarkoitetun vaihdon valmistumatta. Ohjelmiston tulee kirjata epäonnistunut yritys ja soveltuva kulu eikä pitää tapahtumaa kokonaan tilivaikutuksettomana.

Solanan dokumentoitu transaktiomalli huomauttaa epäonnistuneen toteutuksen voivan yhä aiheuttaa maksuja. Keskity hyväksyntätapauksessa todellisen havaitun vaikutuksen kirjanpitoon hallitussa ympäristössä. Älä oleta kiinteää yleispätevää maksua. Solanan transaktiodokumentaatio.

Läpäisynäyttö sisältää yritystilan, tilimuutoksen ja kululuokan. Vain onnistuneiden kauppojen raportti ei selittäisi tulosta, vaikka näkyvä positiomäärä pysyisi oikeana. Täydellinen kirjanpito sisältää yritykset, jotka eivät saavuttaneet aiottua vaihtoa.

Tapaus: tukematon tokenominaisuus ilmestyy

Esitä token- tai tiliasetus dokumentoidun tulkintatuen ulkopuolelta. Odotus on selkeä tukematon tai selvittämätön tila ilman suotuisten oletusten automaattista käyttöä puuttuvan tiedon sijasta. Tilitietojen onnistunut haku ei osoita kaikkien olennaisten ominaisuuksien ymmärtämistä.

Testin tulee yksilöidä työnkulun pysäyttänyt raja. Se voi olla jäsennin, kelpoisuussääntö, noteerauspolku tai valtuutustarkistus. Nimetty rajoitus auttaa erottamaan tuen puutteen tilapäisestä verkkoviasta ja estää turhat toistouusinnat.

Älä vaadi kaikkien mahdollisten tapausten tukea rajatun arvion läpäisyyn. Vaadi ilmoitetun rajan rehellistä käsittelyä. Tukematon muuttuu vaaralliseksi liittymän naamioidessa sen tavalliseksi tuetuksi varaksi tai jättäessä rajoituksen pois ehdotuksen näyttötietueesta.

Tapaus: valtuus poistetaan kesken työnkulun

Valmistele ehdotus ja poista sitten olennainen allekirjoitus- tai delegoitu valtuus hallitun testin mekanismilla. Seuraavan vaiheen tulee epäonnistua turvallisesti ja selittää valtuuden puuttuminen. Aiempi sisäinen hyväksyntä ei korvaa nykyistä ulkoista lupaa.

Ohjelmiston tulee säilyttää ehdotus ja epäonnistunut valtuutuspolku vaatimatta toistuvasti laajempaa pääsyä. Uusi lupa tarvitsee erillisen nimenomaisen arvion. Varmenna myös vain luettavan täsmäytyksen saatavuus rakenteen sitä tukiessa.

Tarkka poistomenettely riippuu valtuusmallista. Raportin tulee nimetä todella testattu mekanismi yleistämättä tulosta kaikkiin lompakko- tai delegointimalleihin. Läpäisy osoittaa määritetyn rajan oikean käsittelyn eikä yleistä säilytysturvaa.

Tapaus: valtuus poistetaan kesken työnkulunRejectAbstainReserveReconcileRecoverTRADING FIELD NOTESEDUCATIONAL RESOURCE
Hylkää → Pidättäydy → Varaa → Täsmäytä → Palaudu. Arvioi automatisoitua kaupankäyntiohjelmistoa konkreettisilla hyväksyntätapauksilla, jotka määrittävät lähtötilan, odotetun toiminnan ja läpäisyyn tarvittavan näytön.

Tapaus: prosessi käynnistyy avoimen työn kanssa

Luo pysyvä tila, jossa on yksi valmis aikomus, yksi valtuutettu lähettämätön ehdotus ja yksi selvittämätön lähetetty yritys. Käynnistä ohjelmisto uudelleen. Kunkin tulee palautua oikealla identiteetillä ja tilalla eikä litistyä yleiseen odotuslistaan.

Lähettämätön ehdotus voi tarvita vanhenemisen tai uuden arvion. Lähetetty yritys tarvitsee täsmäytyksen. Valmis aikomus ei saa toimia uudestaan. Eri tulokset kertovat enemmän kuin tyhjän sovelluksen uudelleenkäynnistys ja kotinäkymän tarkistus.

Tutki resurssivaraukset käynnistyksen jälkeen. Niiden tulee vastata palautettua tilaa ilman selittämätöntä vapautusta tai kahdennusta. Oikea käynnistys säilyttää tietueiden lisäksi niiden taloudelliset suhteet.

Tapaus: sääntöversio vaihtuu kesken jakson

Avaa hallittu signaali tai ehdotus versiolla A ja aktivoi sitten B muuttuneella kelpoisuus- tai mitoitussäännöllä. Ohjelmiston tulee soveltaa dokumentoitua siirtymäkäytäntöään: jatkaa vanhaa jaksoa A:lla, sulkea se tai siirtää nimenomaisella tietueella.

Odotus ei ole yksi yleispätevä siirtymävalinta vaan ilmoitetun käytännön noudatus ja alkuversion säilytys. Arvioijan tulee voida selittää samanlaisten havaintojen erilaiset päätökset ennen aktivointia ja sen jälkeen.

Solanan kaupankäyntialgoritmin opas seuraa algoritmia havaintojen, sääntöjen ja arvion läpi. Hyväksyntätestaus tarkistaa ketjun säilymisen toteutuksen muuttuessa. Vanhojen päätösten hiljainen uudelleentulkinta nykyversiolla tekee myöhemmästä tutkimuksesta ja häiriöarviosta epäluotettavia.

Tapaus: vienti rekonstruoi epäonnistuneen työnkulun

Vie tapaus, jossa on pidättäytyminen, hylätty ehdotus, myöhemmin ratkaistu tuntematon yritys ja osittainen positio. Pyydä arvioijaa rekonstruoimaan sarja ilman toimivan liittymän pääsyä. Viennin tulee säilyttää tarvittavat identiteetit, ajat, yksiköt, versiot, kulut ja korjaussuhteet.

Onnistuneiden transaktioiden lista ei läpäise laajempaa testiä. Se ohittaa työnkulun selittävät päätökset ja epävarmuudet. Kerro puuttuvat tietueet olettamatta ladattavaa tiedostoa täydelliseksi sen avautumisen perusteella.

Tutki viennistä myös salaisuudet. Toimintaviitteiden tulee yksilöidä valtuuspolku paljastamatta salaisia todentamistietoja. Hyödyllinen hyväksyntätietue voidaan jakaa arvioon pitäen varojen hallintakyky erillään tapahtuneen ymmärtämiskyvystä.

Arvioi virheet seurauksen ja syyn mukaan

Tapauksen epäonnistuessa tunnista oikeellisuus-, valtuus-, kirjanpito-, palautuvuus- tai selitysongelma. Luokat auttavat korjausjärjestyksessä. Harhaanjohtava tilanimike ja tahaton kaksoistoimi ovat molemmat vikoja, mutta niiden seuraukset ja myöhempi validointi eroavat.

Säilytä virhenäyttö ja korjattu versio. Aja uudelleen kyseinen tapaus ja läheiset muuttunutta rajaa testaavat tapaukset. Korjaus ei ole valmis vain alkuperäisen virheilmoituksen kadottua; taustan tili- ja tilatoiminnan tulee täyttää odotus.

Testien tulee pysyä mielekkäinä ohjelmiston kehittyessä. Poista tapauksia vain niiden rajauksen poistuessa tuesta ja tuotemääritelmän muuttuessa vastaavasti. Kutistuva testijoukko ei saa hiljaa parantaa läpäisyosuutta sulkemalla pois vaikeaa toimintaa, josta työnkulku yhä riippuu.

Säilytä toimettomuudella läpäisevät tapaukset

Osa tärkeimmistä päättyy ilman transaktiota: vanha näyttö tuottaa pidättäytymisen, riittämätön budjetti hylkäyksen ja poistettu valtuus estää allekirjoituksen. Pidä tapaukset raportissa äläkä pidä niitä vain onnistuneen polun valmisteluna.

Niiden näytön tulee kertoa toimettomuuden syy ja väärin aktiivisiksi jääneet resurssit tai oikeudet. Oikeakin kieltäytyminen voi jättää vapautumattoman varauksen tai harhaanjohtavan avoimen tilan. Koko toimettomuustuloksen tutkiminen vahvistaa rajan noudatuksen ja työnkulun palautumisen ymmärrettävään tilaan.

Hyväksy määritelty työnkulku, älä lupausta

Lopullisen raportin tulee yksilöidä testattu versio, ympäristö, valtuusmalli, tuettu rajaus, tapaustulokset ja testaamattomat rajoitukset. Erota havaittu näyttö pelkän dokumentaation väitteistä ja simuloitu toiminta tuotantotoiminnasta.

Solanan automatisoidun kaupankäyntiohjelmiston hyväksyntä on vahvimmillaan osoittaessaan sekä toimintaa että pidättäytymistä. Ohjelmiston tulee toimia vaatimusten täyttyessä, hylätä tai pidättäytyä niiden jäädessä täyttymättä ja säilyttää epävarmuus tilituloksen selviämiseen asti. Toiminta kertoo enemmän kuin laaja automaatiokyvyn väite.

Konkreettisten tapausten joukko antaa arvioitavan perustan käyttöönotolle tai jatkotyölle. Se ei poista markkinariskiä eikä todista strategian arvoa. Se osoittaa määritellyn työnkulun käsittelyn selitettävästi, palautettavasti ja todella myönnettyihin valtuuksiin verrattavasti.

Jatka oppimista

Tutustu kaikkiin aineistoihin