La specifica è importante - questa affermazione è chiaro a tutti. Un prodotto largamente utilizzato, la tecnologia o la lingua senza una specifica è inutile. Una specifica senza testsuite è pericoloso. Un testsuite senza markup e le prove è impossibile. Questo processo è abbastanza complessa. Tuttavia ci sono modi per semplificare la fase di marcatura.
Per quanto riguarda Java Language Specification (JLS) e (JVM) che sono scritte in FrameMaker. In seguito di specifica è esportato in html e pdf. Il markup è incorporato in versione html. La mia opinione è che le informazioni di markup deve essere posizionato in (o connesso con) il testo d'origine. Nel nostro caso è documento FrameMaker. Non sono sicuro che questo è possibile a tutti, ma la mia ipotesi è. In caso contrario, FrameMaker forse non è la soluzione migliore. Come risultato abbiamo notevolmente ridurre la quantità di tempo e lo sforzo necessari per il trasferimento di markup vecchi e marcare il nuovo testo. Inoltre durante la stesura della prossima revisione della specifica l'autore insieme al gruppo TCK dovrebbe markup tutti chenged e nuove affermazioni. Direi che il modo migliore è quando la scrittura e le specifiche tecniche dei processi di markup sono fatti allo stesso tempo. E 'ragionevole per l'autore a sottolineare gli sviluppatori di test che le dichiarazioni devono essere testati.
La più semplice definizione di metadati è che si tratta di dati sui dati. I metadati possono essere molto utili. Per quanto riguarda il markup c'era qualche metadati incorporati: id, piccola descrizione di affermazione, link al test. Durante il trasferimento markup mi sono reso conto che più i metadati sarebbe molto utile. Nella nuova versione della specifica c'erano vari tipi di asserzioni:
di età: testo non modificato, le prove non hanno bisogno di eventuali modifiche;
oldToBeChanged: testo cambiato, le prove hanno bisogno di essere cambiato;
nuovo: totalmente nuovo testo, nuove prove necessarie;
newWritten: nuovo testo, ma i test già esistenti (perché il processo di sviluppo di test iniziata non appena il progetto di spec era disponibile);
newWrittenToBeChanged: nuovo testo, le prove esistono, spec progetto modificato, in modo i test devono essere cambiate o prove esistenti non sono sufficienti.
L'aggiunta di questo tipo di dati al markup semplificherebbe notevolmente il lavoro futuro - lo sviluppo di test. Perché solo guardando una affermazione in quella specifica può facilmente dire se sono necessari più test o di più dovrebbe essere aggiornato.
Con il dato architettura markup è stato deciso di utilizzare l'attributo title nel tag href-bis (la seconda ancora). Quindi il codice sarà simile:
<a name=assertionID> <! - descrizione shord come commento html -> affermazione dichiarazione qui <a href="path src="pics/assert.gif"> a title=assertType> ID test" prova che è la stessa affermazione ID </ a>
L'attributo title possono essere visualizzati in un browser come un suggerimento.
L'intero processo di creazione di un codice e lo sviluppo di test molto tempo. E quando sembra che il lavoro è fatto, una nuova versione della specifica viene rilasciato. Cosa succede dopo? Naturalmente vi è la necessità di una nuova versione della suite di test. Nuovi test deve essere scritta e quelle vecchie aggiornati o addirittura eliminato.
Il modo migliore per iniziare è fare la marcatura. Questo compito può essere suddiviso in due attività:
trasferimento dal vecchio codice spec precedente alla nuova specifica (questo è necessario perché molte prove sono già state scritte, esse sono legati a specifiche id, il riutilizzo di tutti i test possibili è una buona idea);
markup affermazioni nuovi e aggiornati.
Trasferire il codice è abbastanza semplice per farlo a mano:
Trovare il tag di marcatura nelle specifiche del vecchio.
Trovare il posto migliore per inserire il tag nella nuova versione di spec.
Inserire il tag.
Se ci sono solo 10 affermazioni - questo lavoro è un pezzo di torta. Ma se ce ne sono migliaia, è un lavoro duro che dovrebbe essere automatizzati. La parte più difficile è trovare una nuova sede adeguata per i tag di marcatura. E 'difficile solo perché la specifica è stata modificata. Per JLS2 per il processo di migrazione JLS3 alrorithm flollowing è stato utilizzato:
Ogni affermazione è arrotondata con ancore html. Entrambi dovrebbero essere trasferiti utilizzando l'algoritmo del genere.
Hin 1T: se alcuni tag viene trasferita, c'è una grande possibilità, che il tag successivo in spec vecchio sarà posizionato dopo quello che viene trasferito.
Suggerimento 2: algoritmo dovrebbe verificare che la seconda ancora deve essere posizionato dopo il primo e non troppo lontano da essa.
Consulta il testo prima e dopo il tag nella vecchia spec. Trova nella nuova specifica. Se uno di loro non è stato cambiato - la risposta è stata trovata. di solito la lunghezza dovrebbe essere di 1-2 sentances, almeno 60 caratteri. Se sentances nessuno o più trovati - saltare questo passaggio.
Provate a fare lo stesso come in (1), ma rimuovere tutti i tag html da vicino il testo che circonda la tag. Se nessuno trovati - saltare questo passaggio.
Prova il adotta algoritmo, che cerca di trovare il testo simile nelle specifiche del nuovo. un. passi Usa (1) e (2), ma desrease la lunghezza del testo di ricerca in un ciclo fino a quando il sentance si trova o la lunghezza è troppo breve. Il lavoro pratico ha dimostrato che questo numero non dovrebbe essere inferiore a 20. b. Se i passaggi (1) e (2), o (3 bis) ha trovato diverse sentances aumentare la lunghezza del testo per la ricerca fino a quando il testo si trova nella nuova specifica o il limite superiore (Fe 140 caratteri) è raggiunto. Utilizzare i parametri per trovare il migliore testo di corrispondenza.
Adottare algoritmo potrebbe essere utilizzato sia con ignorando tag html e di trarne vantaggio. Algoritmo è valido per le specifiche scritte in formato testo, HTML o XML.
Questo algoritmo è stato implementato in JLS2-> strumento JLS3 trasferimento markup. L'84% dei marcatori sono stati trasferiti automaticamente. Il resto di loro sono state effettuate manualmente.
La specifica è importante - questa affermazione è chiaro a tutti. Un prodotto largamente utilizzato, la tecnologia o la lingua senza una specifica è inutile. Una specifica senza testsuite è pericoloso. Un testsuite senza markup e le prove è impossibile. Questo processo è abbastanza complessa. Tuttavia ci sono modi per semplificare la fase di marcatura. 
