Testarea contului curat ratează defectul important
Un nou Unity construi poate arăta perfect atunci când începe cu un profil gol. Un cont proaspăt nu are câmpuri retrase, quest-uri semi-finite, referințe catalog cache, stive vechi de inventar, achiziții întrerupte, sau valori care au fost valabile în conformitate cu un regulit mai devreme. Prin urmare, se dovedește doar că noul format poate crea un nou stat. Se spune foarte puțin dacă jocul poate transporta în siguranță un jucător din lumea de ieri în ziua de azi.
Munca în materie de migrație ar trebui să înceapă de la o întrebare mai puternică: poate acest stat istoric exact să intre în clădirea actuală, să păstreze sensul că încă mai contează, și fie să devină starea actuală validă sau să nu reușească într-un mod util pentru a diagnostica? Aceasta este o întrebare de produs la fel de mult ca o întrebare serializor. Un câmp poate deserializa cu succes în timp ce încă încalcă o regulă de progresie, arătând la un conținut lipsă, sau schimbarea unui drept de cumpărare. Încărcarea octeților nu este suficient.
Acest articol descrie un proces local-prima repetiție. Nu este în mod deliberat o promisiune că un instrument poate înțelege fiecare setup de serializare Unity, backend, sau integrarea platformei. Modelele de date Unity variază, iar un joc poate adăuga propria criptare, sincronizare nor, format binar, sau adaptoare personalizate. Partea durabilă este disciplina de testare: păstrează forme istorice, copiați-le înainte de mutație, face calea de migrare explicită, și verificați variabilele de joc după fiecare limită.
Construieşte un corp istoric de stat
Tratează vechi salvează ca un corp modificat, nu ca fișiere libere transmise în jurul valorii de chat. Fiecare element are nevoie de un identificator stabil, versiunea care a produs-o, o etichetă de scenariu scurt, o declarație de format, și o clasificare de confidențialitate. Eticheta de scenariu contează, deoarece un suită de migrare ar trebui să includă state semnificative, nu doar aleatorii JSON. Exemple includ un nou jucător, un jucător la un capitol limită, un inventar la limita sa de stivă, un tutorial întrerupt, o recompensă de eveniment vechi, un utilizator cu conținut cosmetic opțional, și un profil care conține în mod intenționat o combinație moștenire invalidă.
Utilizați copii de lucru imuabile. Runner test nu ar trebui să suprascrie dispozitivul sursă în timp ce încearcă o migrare. Copiați dispozitivul la un director de lucru temporar, înregistrați hash său de control sau conținut, executați adaptorul, și păstrați ieșire rezultat separat. Acest lucru transformă un rezultat surprinzător în dovezi altcineva poate replay. De asemenea, previne un test de la îmbunătățirea în liniște propria intrare până când problema inițială dispare.
Păstrați datele jucătorului de producție dintr-un director general de fixare de dezvoltare. Un corp istoric poate fi sintetic, consimțit, redactat cu atenție, sau generate din scenarii deterministe. Cheia este că păstrează cazurile de margine structurală și semantică care contează. Confidențialitatea nu este un gând ulterior: elimina identificatori directe, identificatori de dispozitiv, informații de contact, jetoane de plată, chitanțe brute, și secrete înainte ca un element devine larg accesibil.
Desenează graficul de migrare înainte de a scrie un convertor
Numerele versiunii nu sunt un plan de migrare. Un joc se poate muta de la 1 la 2, 2 la 3, și 3 la 4, apoi întâlni un jucător care a sărit direct de la 1 la 4. Acesta poate trimite un hotfix care schimbă doar un record de inventar cuib, sau retrage un câmp pe care conținutul vechi încă se așteaptă. Un grafic face aceste alegeri vizibile: fiecare nod este o schemă de salvare sau o versiune semantică; fiecare margine este o transformare explicită sau o respingere intenționată; fiecare margine are precondiții și postcondiții.
Pentru fiecare versiune de pornire susținută, decideți dacă lanțurile de joc adiacente se transformă, utilizează o transformare directă, sau necesită un upgrade de service-side înainte de încărcarea clientului. Nu lăsați versiuni omise la orice se întâmplă atunci când câmpurile sunt absente. Un lanț poate fi mai sigur atunci când fiecare pas este mic și testat. O transformare directă poate fi mai sigură atunci când formate intermediare nu au fost niciodată destinate să fie observabile. Ambele abordări au nevoie de proprietate clară și dispozitive repetabile.
Graficul ar trebui să includă mai mult decât tipul serializat. Catalogul de conținut înregistrări dependențe, versiuni de configurare, steaguri caracteristică care afectează interpretarea, și versiunea curentă de aplicare. O salvare poate fi syntactic curent, dar invalid, deoarece un element de referință nu mai există sau o regulă schimbat sens. Acestea sunt limite de compatibilitate, nu cazuri enervante margine.
Asigurați-save-load excursii rotunde observabile
Odată ce un dispozitiv intră în calea migraţiei, efectuaţi o călătorie rotundă completă: încărcaţi intrarea istorică, migraţi-l, construiţi modelul în joc, salvaţi-l folosind scriitorul curent, apoi încărcaţi acea ieşire curentă din nou. Prima sarcină verifică dacă un record istoric poate intra în sistem. Al doilea de încărcare verifică dacă scriitorul curent a creat un rezultat stabil, auto-consistent. Comparaţi starea după prima şi a doua încărcătură conform regulilor semantice, nu numai o egalitate brută octet.
Egalitatea brută este adesea o afirmație greșită. Pot fi adăugate noi cazuri de neîndeplinire a obligațiilor, ordinea de teren poate fi modificată, pot fi reîmprospătate ștampile de timp, iar colecțiile pot primi comenzi stabile. Definește un normalizator pentru valori care sunt intenționat nesemantice, apoi compară restul. Normalizatorul însuși merită revizuire; nu trebuie să devină o listă de ignorare a păturii care ascunde pierderi reale. Un raport de comparație bun pe care câmpurile au fost adăugate, eliminate, transformate sau ignorate intenționat.
Rezultatul testului ar trebui să numească prima stare invalidă. În cazul în care un lanț de migrare are trei tranziții, nu raportează doar că sarcina finală a eșuat. Captura starea după fiecare punct de control, validați-l, și opriți-l la limita cea mai timpurie care încalcă un invariant. Că localizarea convertește un raport vag de salvare vechi rupt într-o margine de migrare specifică, și diferența de stat.
Invariante specifice jocului Express
Un ham de migrare generală nu poate ști ce înseamnă progresia într-un anumit joc. Jocul trebuie să ofere propriile sale invarianți. Scrieți-le în limba care se conectează la rezultatele jucătorului: un nivel este în gama curentă; o cantitate de inventar este non-negativă și delimitată; fiecare element deținut are o definiție cunoscută sau o rezervă moștenire explicită; un tutorial completat; moneda este finită; o referință de căutare aparține unui catalog curent; un drept este unic; o sămânță mondială și un stat mondial generat sunt de acord.
Invariantii separati in straturi. Invarianti structurali raspund daca exista campuri si tipuri necesare. Invariantii referendumali raspund daca ID-urile indica definitii cunoscute. Invariantii domeniului raspund daca valorile se supun regulilor jocului. Invariantii de siguranta raspund daca datele sunt finite, delimitate si sigure de afisat. Atunci cand un dispozitiv esueaza, stratul spune echipei daca are nevoie de o schimbare a serializatorului, adaptorul catalogului, decizia regulii sau politica de recuperare.
Utilizaţi mutaţii deterministe pentru a face corpul să lucreze mai greu. Începeţi de la un dispozitiv cunoscut şi eliminaţi în mod deliberat un câmp, duplicat un ID de inventar, înlocuiţi o referinţă catalog, săriţi o versiune, reordonaţi o listă de acţiune, sau modificaţi o cantitate limită. Fiecare mutaţie ar trebui să aibă un rezultat aşteptat: migrează cu un implicit documentat, respinge cu o categorie de diagnosticare, carantină pentru recuperare, sau necesită o reparaţie de date aprobate de proprietar.
Reduceți o salvare eșuată fără a pierde bug-ul
Statele mari ale jucătorilor sunt greu de înţeles. Dacă un dispozitiv conţine sute de câmpuri şi o migraţie eşuează, un dezvoltator poate petrece ore citind date nelegate. Minimizarea contraexemplu reduce fixarea păstrând în acelaşi timp invariantul încălcat. Eliminaţi un grup de teren, rejudecaţi aceeaşi migraţie deterministă, şi păstraţi eliminarea numai atunci când eşecul încă mai are loc. Apoi colecţii de partiţii, micşorează valorile spre limite, şi reduce istoria acţiunii dacă reluarea problemelor de comportament.
Reducerea necesită reproductibilitate. În cazul în care mediul se schimbă în timpul fiecărei retry, un reductor poate produce o stare mai mică pentru o altă problemă. Păstrați un manifest de reluare cu aceste intrări și rezultatul observat. Ieșirea nu este doar un fișier mai mic; este un caz de regresie altcineva poate executa.
Dispozitivele de regresie generate ar trebui să intre pe aceeaşi cale de revizuire ca cele manuale. Oferă fiecărui dispozitiv un nume stabil, o scurtă explicaţie a eşecului, invariantul pe care îl păstrează şi o clasificare aşteptată. Un dispozitiv de regresie este valoros pentru că face o rutină de graniţă surprinzătoare anterior. Ea nu ar trebui să devină o sursă ascunsă de date jucător de producţie sau o captură-toate pentru eşecuri inexplicabile.
Pune repetiția în CI fără a face zgomot
Rulați un subset rapid reprezentativ pe fiecare schimbare relevantă: marginile actuale de migrare, stări istorice cu risc ridicat, și un set mic de mutații deterministe. Rulați întregul corp pe un loc de muncă programat, candidat de eliberare, sau schimbare care atinge serializarea, progresia, interpretarea catalogului, sincronizare nor, sau cod de salvare-format. Ciob prin fixarea familie sau margine de migrare, mai degrabă decât trimiterea fiecare test printr-o secvență lungă.
IC de ieșire ar trebui să fie concisă, dar inspectabilă. Raportați elementele de fixare ID, începe și versiunile țintă, marginea de migrare, stratul invariant, primul punct de control invalid, și o cale spre artefact sau diff. Evitați imprimarea conținut profil complet în jurnale. Atunci când un eșec este nou, păstrați informațiile minime necesare pentru a-l reproduce la nivel local; atunci când este de așteptat, înregistrați că clasificarea astfel o eliberare nu normalizează în tăcere un risc cunoscut.
Decizia de eliberare ar trebui să precizeze ce înseamnă dovezile. Trecerea testelor de migrare susțin o afirmație delimitată: corpul testat și căile declarate s-au comportat așa cum se aștepta în acest mediu. Ei nu dovedesc fiecare jucător salva, dispozitiv, sau serviciu extern se va comporta identic. Echipele încă mai au nevoie de planuri de rollback, client-suport de manipulare, și monitorizarea care respectă confidențialitatea.
Lista de verificare practică
- Păstrați un corp istoric versiune cu etichete scenarii și clasificări de confidențialitate.
- Copiați intrările înainte de migrare și păstrați hașii pentru artefactele sursă și ieșire.
- Desenează marginile de migrare sprijinite, inclusiv politica de reducere a emisiilor și respingerile explicite.
- Validarea invarianţilor structurali, preferenţiali, de domeniu şi de siguranţă după fiecare punct de control.
- Excursie dus-întors migrat ieșire prin scriitorul curent și cititor.
- Utilizați mutații deterministe pentru a testa câmpurile lipsă, înregistrările duplicate, conținutul retras și valorile limită.
- Se reduc defecțiunile reproductibile în corpurile de regresie revizuite cu manifeste de reluare.
- Rulați în mod continuu subseturi axate pe risc și întregul corp înainte de a se elibera modificări sensibile.
- Păstrați jurnalele și artefactele redactate; nu transforma CI într-o arhivă de date a jucătorului.
Întrebări frecvente
Avem nevoie de un jucător adevărat ca să testăm migraţia?
Nu. Forme istorice reale sunt utile, dar corpusul poate fi sintetic sau atent redactat. Ceea ce contează este păstrarea combinațiilor dificile de stat: conținut retras, progresie lungă, tranziții întrerupte, date opționale, și valori la limite semnificative. În cazul în care datele de producție sunt utilizate pentru a descoperi un caz de margine, obține un dispozitiv sigur care păstrează doar proprietatea în curs de testare.
Ar trebui ca fiecare versiune veche să rămână susţinută pentru totdeauna?
Nu neapărat. Suportul este un produs și o decizie operațională. Important este de a face limita explicită: care versiuni migrează, care necesită o actualizare anterioară, care sunt respinse, și modul în care jucătorul este informat. O cale accidentală nedocumentat este opțiunea cea mai puțin sigură, deoarece nu este nici susținută în mod fiabil și nici refuzată în mod clar.
Poate un test de serie înlocui teste gameplay?
Testele serializatorului stabilesc că datele pot fi citite și scrise în funcție de formele declarate. Testele Gameplay și domeniu stabilesc că starea rezultată are sens în ruleta actuală. O repetiție de migrare robustă necesită atât, cât și o revizuire a referințelor de conținut și configurare care influențează sensul valorilor salvate.
Ce este Persistium
Persistium este o familie de produse de prima fiabilitate locala in dezvoltare. Ghidul din aceasta nota este consultanta tehnica practica, nu o afirmatie ca un produs Persistium public este disponibil sau ca a diagnosticat datele reale ale clientilor. Directia Continuitatii sale exploreaza tipul de migrare explicita, reluarea, comparatie si reducerea fluxului de lucru descris mai sus.
