Clean-Account testaus missaa tärkeän vian
Uusi Unity rakentaa voi näyttää täydelliseltä, kun se alkaa tyhjällä profiililla. Tuore tili ei ole eläkkeellä kentät, puolivalmiita quests, välimuistissa luetteloviittauksia, vanhoja varaston pinot, keskeytyneet ostot, tai arvot, jotka olivat voimassa aiemmin säännöt. Se osoittaa vain, että uusi muoto voi luoda uuden valtion. Se kertoo hyvin vähän siitä, voiko peli turvallisesti kuljettaa pelaajaa eilisestä maailmasta tänään.
Muuttotyön pitäisi alkaa vahvemmasta kysymyksestä: voiko tämä tarkka historiallinen tila tulla nykyiseen rakenteeseen, säilyttää merkityksen, joka on edelleen tärkeä, ja joko tulla voimassa nykytilaksi tai epäonnistua tavalla, joka on hyödyllinen diagnosoida? Se on tuotekysymys niin paljon kuin sarjamurhaaja kysymys. Kenttä voi pettää onnistuneesti samalla, kun vielä rikkoen progressio sääntöä, viittaa puuttuvaan sisältöön, tai muuttaa osto-oikeuden. Ladataan tavuja ei riitä.
Tässä artikkelissa kuvataan paikallisen ensimmäisen harjoituksen prosessia. Se ei tarkoituksellisesti ole lupaus, että yksi työkalu voi ymmärtää jokaisen Unity serialisoinnin asetukset, backend, tai alustan integrointi. Unity tietomallit vaihtelevat, ja peli voi lisätä oman salauksen, pilvi synkronointi, binäärimuoto, tai mukautetun adapterit. Kestävä osa on testikuri: säilyttää historiallisia muotoja, kopioida niitä ennen mutaatiota, tehdä siirtymäpolku eksplisiittinen, ja tarkistaa pelin invariants jälkeen jokaisen rajan.
Rakenna historiallinen valtion corpus
Käsittele vanhat tallennukset versioituna corpus, ei niin löysät tiedostot kulkevat ympäri chat. Jokainen laite tarvitsee vakaan tunnisteen, version, joka tuotti sen, lyhyen skenaarion etiketti, format ilmoitus, ja yksityisyyden luokittelu. Skenaario etiketti on tärkeä, koska migraatio sviitin pitäisi sisältää mielekkäitä valtioita, ei vain satunnaisia JSON. Esimerkkejä ovat uusi pelaaja, pelaaja lukurajalla, varasto sen pino raja, keskeytynyt opetusohjelma, vanha tapahtumapalkinto, käyttäjä valinnainen kosmeettinen sisältö, ja profiili, joka tarkoituksellisesti sisältää virheellinen perintö yhdistelmä.
Käytä muuttumattomia työkopioita. Testin suorittimen ei pitäisi koskaan korvata lähdelaitteistoa samalla kun yritetään siirtyä. Kopioi laite väliaikaiseen työhakemistoon, tallenna sen tarkistussumma tai sisältö hash, suorita adapteri, ja säilyttää tulos erikseen. Tämä kääntää yllättävän tuloksen todisteeksi joku muu voi toistaa. Se myös estää testin hiljaa parantaa omaa syöttöään kunnes alkuperäinen ongelma häviää.
Pidä tuotantoympäristön pelaajatiedot poissa yleisestä kehityksen testiaineistohakemistosta. Historiallinen testiaineisto voi olla synteettinen, suostumuksella käytettävä, huolellisesti peitetty tai deterministisistä skenaarioista tuotettu. Olennaista on, että siinä säilyvät merkitykselliset rakenteelliset ja semanttiset rajatapaukset. Tietosuojaa ei saa jättää jälkikäteen mietittäväksi: poista suorat tunnisteet, laitetunnisteet, yhteystiedot, maksutunnisteet, käsittelemättömät kuitit ja salaisuudet ennen kuin testiaineisto tulee laajemmin saataville.
Piirrä siirtymäkaavio ennen muuntimen kirjoittamista
Versionumerot eivät ole siirtymäsuunnitelma. Peli voi siirtyä 1 - 2, 2 - 3, 3 - 4, sitten kohdata pelaaja, joka on ohittanut suoraan 1 - 4. Se voi lähettää hotfix, joka muuttaa vain pesiytynyt varastonoteeraus, tai eläkkeelle kenttä, että vanha sisältö vielä odottaa. Kaavio tekee nämä valinnat näkyvissä: jokainen solmu on tallentaa skeema tai semanttinen versio; jokainen reuna on nimenomainen muutos tai tahallinen hylkäys; jokainen reuna on edellytykset ja post ehdot.
Jokaisen tuetun aloitusversion osalta päätä, muuttaako, käyttääkö vieressä oleva peliketju suoraan muuntaa, vai vaatiiko se palvelupuolen päivityksen ennen asiakkaan kuormitusta. Älä jätä ohitettuja versioita siihen, mitä tapahtuu, kun kentät ovat poissa. Ketju voi olla turvallisempi, kun jokainen vaihe on pieni ja testattu. Suora muutos voi olla turvallisempi, kun välimuotoa ei ole koskaan tarkoitettu havaittavaksi. Molemmat lähestymistavat tarvitsevat selkeän omistajuuden ja toistettavat kalusteet.
Graafissa pitäisi olla enemmän kuin serialisoitu tyyppi. Tallenna sisältöluettelo riippuvuudet, konfiguraatioversiot, ominaisuus liput, jotka vaikuttavat tulkintaan, ja nykyinen sovellusversio. Tallennus voi olla syntactically nykyinen mutta virheellinen, koska viittaus kohde ei enää ole olemassa tai sääntö muutti merkitystä. Nämä ovat yhteensopivuus rajat, ei ärsyttäviä reuna tapauksissa.
Tehkää kierrosretkistä havainnoitavissa
Kun laite tulee siirtymäpolulle, suorita täysi kierros: lataa historiallinen syöte, siirrä se, rakenna pelin sisäinen malli, tallenna se nykyisen kirjaimen avulla, sitten lataa nykyinen tulos uudelleen. Ensimmäinen kuorma tarkistaa, voiko historiallinen levy tulla järjestelmään. Toinen kuorma tarkistaa, onko nykyinen kirjailija luonut vakaa, itsetietoinen tulos. Vertaa tilaa semanttisten sääntöjen mukaisesti, ei vain raaka tavu tasa-arvo.
Raw tasa-arvo on usein väärä väite. Uusia oletuksia voidaan lisätä, kenttäjärjestys voi muuttua, aikaleimat voidaan päivittää, ja kokoelmat voivat saada vakaa tilaus. Määrittele normalisoija arvoja, jotka ovat tarkoituksellisesti ei-semanttinen, sitten verrata loput. Normalizer itse ansaitsee tarkistaa; se ei saa tulla peitto sivuuttaa luettelo, joka kätkee todellinen menetys. Hyvä vertailu raportteja, jotka kentät lisättiin, poistettu, muutettu tai tarkoituksella jätetty huomiotta.
Testitulos pitäisi nimetä ensimmäinen virheellinen tila. Jos siirtymäketjussa on kolme siirtymää, älä ilmoita vain, että lopullinen kuormitus epäonnistui. Ota tila jälkeen kunkin tarkistuspisteen, validoida se, ja lopettaa aikaisintaan rajan, joka rikkoo invariant. Että lokalisointi muuntaa epämääräinen ... vanha tallentaa rikki.. raportti tietyn siirtymän reuna, kiinnitys, ja tila ero.
Pikapelikohtaiset invariantit
Yleinen migraatiovaljakko ei voi tietää, mitä eteneminen tietyssä pelissä. Peli on annettava oma invariants. Kirjoita ne kielellä, joka yhdistää pelaaja tuloksia: taso on nykyisen valikoiman; varaston määrä on ei-negatiivinen ja rajoittaa; jokainen omistettu kohde on tunnettu määritelmä tai nimenomainen perintö varasuunnitelma; valmis tutoriaalin oleskelun päätökseen; valuutta on rajallinen; etsintäviittaus kuuluu nykyiseen luetteloon; oikeus on ainutlaatuinen; maailman siemen ja luotu maailman valtio.
Erillinen invariants osaksi kerroksia. Rakenteellinen invariants vastaus onko tarvittavat kentät ja tyypit olemassa. Referentiaalinen invariants vastaus onko IDs osoittaa tunnettuja määritelmiä. Domain invariants vastaa, onko arvot noudattavat pelin sääntöjä. Turvallisuus invariants vastaus onko tiedot rajallinen, rajoitettu, ja turvallinen näyttää. Kun laite epäonnistuu, kerros kertoo tiimille, tarvitseeko se sarjanmuuttaja muutos, luettelo adapteri, sääntöjen päätös, tai palautuspolitiikka.
Käytä deterministiset mutaatiot tehdä corpus työtä kovempaa. Aloita tunnetun laitteen ja tarkoituksellisesti poistaa kentän, kopioida varaston ID, korvata luettelo viite, ohittaa versio, uudelleen tilata toimintaluettelo, tai muuttaa rajamäärä. Jokainen mutaatio pitäisi olla odotettu tulos: muuttaa dokumentoitu oletus, hylätä diagnostinen luokka, karanteenin hyödyntämistä, tai vaatia omistajan hyväksymä tietojen korjaus. . Se ei ole riittävä odotettu tulos.
Vähennä vikatallennusta menettämättä vikaa
Suuri pelaaja valtiot ovat vaikea ymmärtää. Jos laite sisältää satoja kenttiä ja migraatio epäonnistuu, kehittäjä voi viettää tunteja lukemalla asiaan liittymättömiä tietoja. Counterexample minimization vähentää laitteen säilyttäen rikkonut invariant. Poista kenttäryhmä, yritä uudelleen sama deterministinen migraatio, ja pitää poiston vain silloin, kun vika vielä tapahtuu. Sitten osio kokoelmat, kutistaa arvoja kohti rajoja, ja vähentää toimintahistoriaa, jos toistaa käyttäytymistä asioita.
Pienentäminen vaatii uusittavuus. Lukitse laitteen hash, migraatioversio, adapteriversio, deterministinen siemen, relevantti konfiguraatiokuva ja odotettu invariantti. Jos ympäristö muuttuu jokaisen retryn aikana, reduktori voi tuottaa pienemmän tilan eri ongelma. Pidä toisto ilmentymän kanssa nämä syötteet ja havaittu tulos. Tuloksena ei ole vain pienempi tiedosto; se on regressio tapaus joku muu voi suorittaa.
Generoitu regressio kalusteet tulisi syöttää sama tarkastelu polku kuin käsin tehty ne. Antaa kullekin laite vakaa nimi, lyhyt selitys vika, invariant se säilyttää, ja odotettu luokitus. Regressiolaite on arvokas, koska se tekee aiemmin yllättävä raja rutiini. Se ei pitäisi tulla piilotettu lähde tuotannon pelaaja tiedot tai catch-all selittämättömiä virheitä.
Laita harjoitukset CI: lle ilman melua
Suorita nopea edustava osajoukko kaikista olennaisista muutoksista: nykyiset siirtymäreunat, suuririskiset historialliset tilat, ja pieni joukko deterministisiä mutaatioita. Suorita koko corpus suunnitellusta työstä, vapauttaa ehdokas, tai muutos, joka koskettaa serialisointia, etenemistä, luettelotulkintaa, pilvi synkronointia, tai save-formaatti koodi. Jaa asetelman perheen tai siirtymä reunan sijaan lähettää jokainen testi yhden pitkän sekvenssin.
CI-tulosteen tulisi olla ytimekäs mutta tarkastettavissa. Ilmoita laitteen ID-, aloitus- ja kohdeversiot, siirtymäreuna, invarianttikerros, ensimmäinen virheellinen tarkastuspiste ja polku reducted artefaktiin tai diff. Vältä tulostamasta täyttä profiilin sisältöä lokeihin. Kun vika on uusi, säilytä pienin tieto, jota tarvitaan sen jäljentämiseen paikallisesti; kun se on odotettavissa, kirjaa, että luokitus niin julkaisu ei hiljaa normalisoi tunnettua riskiä.
Vapautuspäätöksessä on ilmoitettava, mitä todisteet tarkoittavat. Siirtotestit tukevat rajoitettua väitettä: testattu corpus ja ilmoitetut polut käyttäytyvät odotetulla tavalla kyseisessä ympäristössä. Ne eivät todista, että jokainen pelaaja säästää, laite, tai ulkoinen palvelu käyttäytyy samalla tavalla. Joukkueet tarvitsevat edelleen varasuunnitelma, asiakastuki käsittely, ja valvonta, joka kunnioittaa yksityisyyttä.
Käytännön tarkistuslista
- Säilytä versioitu historiallinen corpus skenaarioiden tarroja ja yksityisyyden luokitukset.
- Kopioi syötteet ennen muuttoa ja säilytä häsit lähde- ja lähtöesineitä varten.
- Piirrä tuetut siirtymäreunat, mukaan lukien ohitettu-version politiikka ja selkeät hylkäykset.
- Validoidaan rakenteelliset, referentiaaliset, domain, ja turvallisuus invariants jälkeen jokaisen tarkastuspisteen.
- Round-trip muutti lähtö kautta nykyisen kirjailijan ja lukijan.
- Käyttää deterministisiä mutaatioita testata puuttuvat kentät, päällekkäiset tietueet, eläkkeellä oleva sisältö ja raja-arvot.
- Vähennetään toistettavissa olevia vikoja tarkistettuihin regressiokiinnikkeisiin, joissa on uusintanäytöt.
- Suorita riskipainotteiset subsets jatkuvasti ja koko corpus ennen vapautua-herkät muutokset.
- Pidä lokit ja esineet remontoituna; älä muuta CI:tä pelaaja-tietoarkistoksi.
Usein kysytyt kysymykset
Tarvitsemmeko oikeaa pelaajaa, jotta voimme testata migraatiota?
Ei. Todelliset historialliset muodot ovat hyödyllisiä, mutta corpus voi olla synteettinen tai huolellisesti reacted. Tärkeintä on säilyttää vaikea tilayhdistelmiä: eläkkeellä sisältö, pitkä eteneminen, keskeytykset, valinnaiset tiedot, ja arvot mielekkäillä rajoilla. Jos tuotantotietoja käytetään löytämään reuna tapauksessa, johtaa turvallinen laite, joka säilyttää vain testattava ominaisuus.
Pitäisikö jokaisen vanhan version pysyä tukena ikuisesti?
Ei välttämättä. Tuki on tuote ja toiminnallinen päätös. Tärkeintä on tehdä rajasta selkeä: mitkä versiot muuttavat, jotka vaativat aikaisemman päivityksen, joka hylätään, ja miten pelaajalle tiedotetaan. Dokumentoimaton vahingossa polku on vähiten turvallinen vaihtoehto, koska se ei ole luotettavasti tuettu tai selvästi hylätty.
Voiko sarjamurhaajatesti korvata pelattavuustestit?
Ei. Serializer-testit vahvistavat, että tiedot voidaan lukea ja kirjoittaa ilmoitettujen muotojen mukaisesti. Pelin ja verkkotunnuksen testit osoittavat, että tuloksena oleva tila on järkevä nykyisessä sääntösarjassa. Vankka migraatioharjoitus tarvitsee molempia sekä sisällön ja konfiguraatioviittausten katsaus, joka vaikuttaa tallennettujen arvojen merkitykseen.
Mikä on Persistium...
Persistium on kehitteillä oleva paikallinen ja ensimmäinen luotettavuustuoteperhe. Tämän muistion ohjeistus on käytännön tekninen neuvonta, ei väite siitä, että julkinen Persistium-tuote on saatavilla tai että se on diagnosoinut todellisia asiakastietoja. Sen jatkuvuussuunta tutkii edellä kuvattua eksplisiittistä migraatiota, toistoa, vertailua ja työn karsimista.
