Un rilascio è una maglia, non un numero di versione
Un giocatore può aprire un vecchio cliente mentre un servizio è già cambiato. Un catalogo di contenuti può aggiornare davanti al cliente che comprende un nuovo articolo. Un rollout di configurazione può raggiungere una regione prima dell'altra. Un backend può accettare sia forme di richiesta vecchie che nuove per un po ', quindi ritirare un adattatore. 42” nasconde le relazioni più probabili rompere in condizioni reali di rollout.
Inizia con la denominazione delle dimensioni della versione separatamente. Al minimo, registra la creazione del client, la revisione del backend o del servizio, la versione del protocollo, lo schema o la versione di salvataggio, la versione del catalogo dei contenuti, la versione di configurazione e lo stato di migrazione.
La domanda utile non è “did the newest client pass?” È “quale combinazione può coesistere, cosa deve fare ogni combinazione e quali combinazioni sono proibite?” Una politica di compatibilità trasforma quella domanda in uno spazio di prova limitato.
Scrivere vincoli di compatibilità in entrambe le direzioni
Compatibilità è spesso asimmetrica. Un nuovo backend può accettare richieste da un vecchio cliente, mentre un vecchio backend non può capire un nuovo cliente. Un nuovo cliente può leggere un vecchio salvataggio dopo la migrazione, mentre un vecchio cliente non deve riaprire la versione migrata.
Scrivere ogni vincolo come una relazione con un comportamento atteso. Ad esempio: cliente 5 può autenticarsi contro il servizio 7 attraverso il protocollo 2; cliente 4 può leggere il catalogo 10 solo quando gli elementi del tipo X sono esclusi; salvare lo schema 3 può migrare a 5 attraverso bordi supportati; configurazione 12 non deve abilitare una funzione per i clienti sotto la costruzione 6. Includere una disposizione per le combinazioni non supportate: bloccare prima della mutazione, servire una rappresentazione compatibile, percorso ad un aggiornamento richiesto, o tenere il cambiamento fino a quando i vecchi scarichi coorte.
Non fare affidamento sul confronto della versione da solo. Un numero più alto non dimostra che esiste una capacità, e un numero più vecchio non dimostra che una caratteristica è assente. Utilizzare la capacità di negoziazione o metadati di compatibilità esplicita dove pratico. I metadati stesso ha bisogno di test; una bandiera mancante non dovrebbe significare accidentalmente “sicuro di procedere”.
Generare una matrice orientata al rischio
Il prodotto cartesiano completo può essere enorme. Quattro build del client, tre servizi, quattro versioni dei contenuti e cinque stati di configurazione producono già 240 combinazioni, prima ancora di considerare la piattaforma e lo stato di migrazione. Testare ogni tupla possibile può richiedere più tempo del ciclo di rilascio e non rilevare comunque il limite rilevante. Generare invece una matrice focalizzata sui rischi a partire dai vincoli e dall’impatto delle modifiche.
Aggiungi combinazioni che attraversano un campo di protocollo modificato, il bordo di migrazione, la regola di interpretazione del contenuto, il percorso di diritto, o la bandiera della caratteristica. Includere almeno un percorso a forma di rollback: un client o un servizio di ritorno a uno stato compatibile precedente dopo che il nuovo stato ha osservato i dati.
La generazione di combinazioni a coppie può aiutare a coprire le interazioni, ma non deve sostituire il giudizio. Alcuni errori richiedono che tre o quattro dimensioni si combinino: un vecchio client, un nuovo catalogo, un salvataggio migrato e un flag di configurazione potrebbero essere sicuri in ogni coppia ma non validi tutti insieme. Aggiungere test di scenario specifici per questi rischi del prodotto. La matrice deve poter essere esaminata dalle persone che conoscono le funzionalità, non solo da un generatore di test.
Test vecchi e nuovi clienti che vivono insieme
Simula un vecchio client che crea o modifica lo stato mentre un nuovo client lo legge, quindi invertisce l'ordine. Ricollegamenti di prova, sessioni contemporaneamente, download di aggiornamento interrotti e un utente che riprende su un altro dispositivo. Per ogni percorso, identificare quale lato possiede un'interpretazione autorevole. Un client non deve inventare un nuovo valore di campo che il servizio tratta in seguito come attendibile solo perché entrambi sono stati aggiornati in un test locale.
Le modifiche del protocollo meritano adattatori espliciti. Quando un campo viene rinominato, digitato allargato o diviso in più valori, testare la vecchia rappresentazione, la nuova rappresentazione e qualsiasi strato di traduzione. Una traduzione deve conservare il significato documentato o rifiutare la richiesta prima di una mutazione non sicura. Un server che restituisce un default plausibile ma sbagliato può essere più pericoloso di una chiara incompatibilità perché diffonde la corruzione silenziosa.
Se una vecchia struttura non può continuare in modo sicuro, il percorso di aggiornamento dovrebbe apparire prima di un'azione di stato, non dopo una transazione fallita. Se una funzione è nascosta da vecchie costruzioni, confermare che rimane nascosto nei menu, nei link profondi, nei punti di entrata push-like e nelle sessioni ripristinate.
Trattare contenuti e configurazione come dipendenze eseguibili
I cataloghi dei contenuti e la configurazione remota sono spesso considerati dati operativi anziché codice. In un sistema in esercizio sono dipendenze eseguibili, perché modificano il significato degli identificatori, le funzionalità visualizzate e le regole applicate. Testare un nuovo catalogo con client vecchi e nuovi. Testare una cache di configurazione obsoleta con un nuovo servizio. Testare un flag di funzionalità che abilita un percorso di codice prima che siano presenti i contenuti necessari. Testare il ripristino di una versione precedente dei contenuti dopo che alcuni giocatori hanno acquisito riferimenti al nuovo record.
Usare contratti dei contenuti con versioni definite. Una voce del catalogo deve dichiarare i campi e le capacità necessari per visualizzarla o eseguirla. Un pacchetto di configurazione deve indicare gli intervalli di versioni del client o del servizio previsti. Se un record dipende da una capacità non disponibile, scegliere un comportamento sicuro: nasconderlo, usare un’alternativa documentata, rimandarne l’attivazione o interrompere il rilascio. Non usare un valore predefinito generico che assegni accidentalmente un oggetto, aggiri un controllo dei diritti di accesso o modifichi la progressione.
Per lo stato salvato, distinguere la migrazione schematica dalla migrazione semantica. Un cambiamento schema può aggiungere un campo con un default. Un cambiamento semantico può ritirare un articolo, dividere una ricerca, o modificare una regola di economia. Quest'ultimo ha bisogno di invarianti di dominio e decisioni di recupero, non solo un test di deserializzazione.
Prove rollback prima che il rilascio necessiti
Chiedi se un vecchio cliente può leggere lo stato scritto dal nuovo cliente, se un vecchio servizio può interpretare nuove richieste, se i record di contenuti richiedono un nuovo renderr, e se una migrazione ha attraversato un limite di sola andata. Alcuni cambiamenti sono solo in avanti. Ciò può essere accettabile quando dichiarato, ma cambia il piano di rilascio: utilizzare una coorte in fase, una finestra di compatibilità, una politica di backup o snapshot, e un percorso di supporto invece di ritorno istantaneo.
Avviare sul vecchio set compatibile, avanzare un componente, fare un cambiamento di stato rappresentativo, quindi spostare un componente selezionato indietro. Assert lo stato previsto: compatibilità continua, sicurezza di sola lettura, rifiuto controllato, o recupero pianificato. Il risultato dovrebbe nominare quello che è stato eseguito e quello che è stato simulato.
Tenere l'uscita di decisione breve e concreto. Il record di rilascio può dichiarare: gamme di compatibilità supportate, scenari eseguiti, noti rischi ineseguiti, cambiamenti che sono solo in avanti, cancelli rollout, e condizioni per arrestare.
Shard le prove in CI
Eseguire un piccolo fumo di compatibilità impostato su ogni cambiamento che tocca contratti condivisi. Eseguire shard espansi quando client, protocollo, salvare, contenuto, configurazione o modifiche del codice rollout. Shard per la famiglia scenario piuttosto che da combinazioni casuali: autenticazione e ripristino di sessione, acquisto e diritto, migrazione e stato salvato, rendering dei contenuti, comportamento con funzionalità-gated e rollback.
Il rapporto CI dovrebbe conservare il tuple sotto test e la classificazione dei risultati. Includere la costruzione del client, la revisione del servizio, il protocollo, il contenuto e le versioni di configurazione, l'identificazione o scenario ID, il tipo di ambiente, e la prima regola di compatibilità fallita. Evitare di dumping account o stato del giocatore. Quando uno scenario è simulato, etichettarlo.
Verificare questi rapporti con i proprietari di rilascio prima di ampliare un rollout; prove di compatibilità è un ingresso di decisione, non un cruscotto decorativo.
Tenere l'ambiente deterministico ancora, ridurre le dimensioni mantenendo il fallimento della compatibilità e memorizzare lo scenario minimo risultante come un caso di regressione. Questo rende la matrice più preziosa nel tempo invece di diventare costantemente una collezione rumorosa di incidenti storici.
Controllo pratico
- Nome client, servizio, protocollo, schema, contenuto, configurazione e dimensioni di migrazione separatamente.
- Scrivi relazioni di compatibilità supportate, tradotte e proibite con il comportamento atteso.
- Include scenari più vecchi, più recenti, di transizione e rollback.
- Aggiungere test multidimensionali denominati in cui la copertura in coppia è insufficiente.
- Testare vecchi e nuovi clienti creando, leggendo e riprendendo lo stato attraverso lo stesso limite di servizio.
- Tratta il catalogo e le modifiche di configurazione come dipendenze di compatibilità eseguibili.
- Dichiarare le migrazioni solo in avanti e fornire un piano di rollout o recupero in fase.
- Registra se le prove sono simulate, eseguibili localmente, sabbiose o verificate esternamente.
- Conservare il tuple di fallimento minimo come uno scenario di regressione recensione.
Domande frequenti
È abbastanza test di coppia per la compatibilità di rilascio?
La copertura a coppie è un modo utile per ridurre una grande matrice, ma non può dimostrare tutti i vincoli multidimensionali. Utilizzare per una copertura di interazione ampia, quindi aggiungere scenari espliciti per combinazioni ad alto rischio come lo stato migrato più nuovi contenuti più un vecchio cliente, o un rollback dopo che un cancello di configurazione è cambiato.
Quando dovrebbe essere bloccato un vecchio cliente?
Bloccalo prima della mutazione quando non può interpretare in modo sicuro i contenuti richiesti, soddisfare un contratto di protocollo, o leggere il limite di stato attuale. Un chiaro requisito di aggiornamento è più sicuro che continuare con un default che cambia significato. La politica esatta è specifica del prodotto, ma la condizione e il comportamento di interfaccia utente devono essere testati insieme.
Può una bandiera caratteristica risolvere la compatibilità da sola?
No. Un flag può controllare l’esposizione di una funzionalità, ma non può rendere sicuro un protocollo, uno schema o un record di contenuti incompatibile. Testare gli stati del flag nella cache e aggiornati, la sua dipendenza dalle capacità del client e ciò che accade se cambia durante una sessione attiva.
Cosa significa questo su Persistium?
Persistium è una famiglia di prodotti locali-prima affidabilità in fase di sviluppo. Questo articolo descrive un approccio di test-design, non un'affermazione che un prodotto rilasciato genera automaticamente ogni matrice o fornisce gestione del rilascio ospitato.
