Vai al contenuto
Lingua: IT

Quali tag deve tenere uno sviluppatore per le prove?

Uno per ogni tipo che il codice dichiara di sostenere, poi uno per ogni stato che deve sopportare: vergine, formattato e vuoto, pieno, in sola lettura, protetto da password, e un tag morto apposta. L'ultimo è quello che dimostra che la verifica può ancora fallire.

Uno per ogni tipo che dichiari

Parti da quello che il codice dice di sostenere. Un adesivo di tipo 2, una scheda di tipo 4 e un tag di tipo 5 coprono le tre famiglie che la maggior parte dei progetti incontra, e la pagina dei tipi di tag dice su quale norma ciascuno si appoggia. Se l'installazione comprende schede MIFARE Classic, aggiungine una: la classe che le legge è facoltativa su Android, quindi un telefono che non ce l'ha fa parte della prova.

Poi aggiungi un secondo tag dello stesso tipo e di un chip diverso, con una memoria di dimensione diversa. È il modo meno caro di cogliere un numero di pagina fissato nel codice o una capacità data per scontata, il guasto di cui parla la pagina delle differenze fra chip.

Uno per ogni stato che devi sopportare

Un tag ha degli stati, e il codice prima o poi li incontra tutti. Vergine e non formattato, cosa che un tag nuovo a volte è, come spiega la pagina della formattazione. Formattato e vuoto, che si legge come un messaggio di lunghezza zero. Pieno, così che una scrittura che non ci sta fallisca come deve, il caso che la pagina della dimensione copre.

In sola lettura, che rifiuta la scrittura per sempre, e protetto da password, che la rifiuta finché il codice non si autentica, i due che la pagina della protezione separa. Tutti e due esistono per verificare che i tuoi percorsi di errore dicano la cosa giusta invece della stessa cosa.

Il tag che non deve mai leggersi

Tieni un tag che sia davvero morto, ed etichettalo. La pagina del tag rovinato ne dà la ragione: è l'unico modo di sapere che una verifica rileva davvero un tag guasto, e vale la pena saperlo prima di una serie di produzione invece che dopo.

Un tag lasciato in uno stato sconosciuto è il contrario: produce guasti che nessuno sa attribuire. Se lo stato non è scritto sopra, non fa parte dell'insieme.

Etichettati, annotati, conservati

Scrivi lo stato su ogni tag e tieni l'elenco dove la squadra lo può leggere, la stessa disciplina che la pagina del registro chiede a un'installazione. Anche le password stanno in quel registro, dato che un tag di prova protetto con una chiave dimenticata è un tag in sola lettura con qualche passaggio in più.

E ricorda che i tag sono metà dell'insieme. Due telefoni almeno, uno dei quali senza le classi di tecnologia facoltative, più un iPhone, dato che un messaggio che un analizzatore Android accetta lì può non fare niente, la differenza che la pagina dei record su iOS copre.

Domande frequenti

Quanti tag servono per un insieme di prova?

Meno di quanto sembri: uno per ogni tipo che dichiari, uno per ogni stato che devi sopportare, e un tag morto. Una decina copre la maggior parte dei progetti.

Perché tenere un tag morto?

Per dimostrare che la verifica può fallire. Un controllo che non ha mai rifiutato niente non è stato provato.

Mi servono tag MIFARE Classic?

Solo se la tua installazione ne ha. La classe Android che li legge è facoltativa, quindi prova anche su un telefono che non ce l'ha.

E i telefoni?

Due telefoni Android con controller diversi e un iPhone. L'insieme di tag trova i difetti di contenuto, quello di telefoni li trova di piattaforma.