Spezifikation ist wichtig - diese Aussage ist für alle klar. Eine weit verbreitete Produkt, Technik oder Sprache, ohne eine Spezifikation ist nutzlos. Eine Spezifikation, die ohne eine Testsuite ist gefährlich. A Testsuite ohne Auszeichnungen und Tests ist unmöglich. Dieser Prozess ist recht komplex. Es gibt jedoch Möglichkeiten, um das Markup der Bühne zu vereinfachen.
Wie bei Java Language Specification (JLS) und (JVM) sind sie in FrameMaker geschrieben. Danach ist die spec HTML und PDF exportiert. Das Markup in HTML-Version integriert. Meine Meinung ist, dass Markup Informationen sollten in platziert werden (oder in Verbindung mit) die Herkunft Text. In unserem Fall ist es FrameMaker-Dokument. Ich bin mir nicht sicher, dass dies überhaupt möglich ist, aber ich schätze es ist. Wenn nicht, vielleicht FrameMaker ist nicht die beste Lösung. Als Ergebnis haben wir erheblich reduzieren wird die Menge an Zeit und Aufwand für die Übertragung von alten Markup und Kennzeichnung neuer Text erforderlich. Außerdem während des Schreibens der nächsten Revision der Spezifikation der Autor zusammen mit TCK-Team sollte alle Markup gewechselt wei lsie und neue Behauptungen. Ich würde sagen, der beste Weg ist, wenn die spec schriftlich und Markup-Prozesse zur gleichen Zeit fertig sind. Es ist für den Autor darauf hinweisen, was der Test-Entwickler Aussagen geprüft werden sollten vernünftig.
Die einfachste Definition von Metadaten ist, dass sie Daten über Daten ist. Metadata sehr nützlich sein könnte. Als für das Markup gab es einige Metadaten eingebettet: id, kleine Beschreibung der Behauptung, Link zu testen. Während der Übertragung Markup Ich erkannte, dass mehr Metadaten wäre sehr hilfreich. In der neuen Version der Spezifikation gab es mehrere Arten von Aussagen:
alt: nicht verändert Text, tun Tests benötigen keine Veränderungen;
oldToBeChanged: Text verändert, Tests machen müssen geändert werden;
neu: total neuen Text, neue Prüfungen erforderlich sind;
newWritten: neuen Text, Tests, sondern bereits vorhanden (weil die Entwicklung von Tests Prozess begann, sobald der Entwurf der Spezifikation zur Verfügung stand);
newWrittenToBeChanged: neuen Text gibt es Tests, Entwurf spec verändert, so dass die Tests müssen geändert werden oder die vorhandenen Tests sind nicht genug.
Addiert man diese Art von Daten an das Markup erheblich vereinfachen würden die Zukunft der Arbeit - die Entwicklung von Tests. Denn nur durch das Betrachten einer Behauptung in der spec kann man leicht sagen, ob weitere Tests erforderlich sind, oder mehrere aktualisiert werden soll.
Mit den gegebenen Markup-Architektur ist, wurde beschlossen,) nutzen das title-Attribut in einem href-tag (der zweite Anker. Also das Markup aussehen würde:
<a name=assertionID> <! - shord Beschreibung als HTML-Kommentar -> Assertion hier <img src="pics/assert.gif"> <a href="path zu test" title=assertType> Test-ID, das ist das gleiche wie Behauptung ID </ a>
Das title-Attribut kann in einem Browser als Hinweis angesehen werden.
Der gesamte Prozess der Schaffung einer Markup und der Entwicklung von Tests ist zeitaufwändig. Und wenn es scheint, dass die Arbeit getan ist, eine neue Version der Spezifikation ist freigegeben. Was passiert als nächstes? Natürlich besteht die Notwendigkeit einer neuen Version des Test-Suite. Neue Tests müssen geschrieben werden und die alten aktualisiert oder sogar gestrichen.
Der beste Weg zu beginnen ist, das Markup zu tun. Diese Aufgabe kann in zwei Teilaufgaben unterteilt werden:
Transfer alten Markup aus früheren spec auf die neue Spezifikation (dies ist nötig, weil viele Tests bereits geschrieben wurden, sind sie zu spec-ID verknüpft ist, alle möglichen Tests Wiederverwendung ist eine gute Idee);
Markup neue und aktualisierte Behauptungen.
Übertragen der Markup ist einfach genug, um es von Hand machen:
Finden Sie die Markup-Tag in der alten spec.
Finden Sie den besten Platz zum Einfügen des Tags in der neuen Version des spec.
Stecken Sie den Tag.
Wenn es nur 10 Behauptungen sind - dieses Werk ist ein Stück Kuchen. Aber es gibt Tausende, wenn es ein harter Job, dass automatisiert werden soll. Der schwierigste Teil ist, eine neue geeignete Stelle für Markup-Tags finden. Es ist schwer, nur weil die Spezifikation geändert wurde. Für JLS2 zu JLS3 Migrationsprozess der flollowing alrorithm verwendet wurde:
Jede Behauptung ist mit HTML Anker abgerundet. Beide sollten mit solchen Algorithmus übertragen werden.
Hin 1t: Wenn einige tag übertragen wird, gibt es eine große Möglichkeit, dass nächsten Tag im alten spec wird nach der einen, die übertragen wird positioniert werden.
Tipp 2: Algorithmus sollte überprüfen, ob die zweite Anker sollte nach dem ersten Teil und nicht allzu weit davon entfernt positioniert werden.
Schauen Sie sich den Text vor und nach tag in alten spec. Finden Sie es in den neuen spec. Wenn einer von ihnen wurde nicht verändert - die Antwort ist gefunden. Die Länge sollte in der Regel 1-2 sentances werden, mindestens 60 Zeichen lang sein. Wenn keine oder mehrere sentances gefunden - diesen Schritt überspringen.
Versuchen Sie, die gleiche wie zu tun in (1), sondern entfernen Sie alle HTML-Tags aus dem Text, der in der Nähe von dem Tag umgibt. Wenn keiner gefunden - diesen Schritt überspringen.
Probieren Sie den Algorithmus zu erlassen, die zu ähnlichen Text in der neuen Spezifikation zu finden versucht. ein. Verwenden Sie die Schritte (1) und (2), aber desrease die Länge der Benutzer Text in einer Schleife, bis die Sentance gefunden wird oder die Länge zu kurz ist. Die praktische Arbeit hat gezeigt, dass diese Zahl sollte nicht kleiner als 20 sein. b. Wenn die Schritte (1) und (2), oder (3a) fand mehrere sentances Erhöhung der Länge des Textes bis zur Volltextsuche ist in der neuen Spezifikation entsprechen, oder die obere Grenze (zB 140 Zeichen) erreicht ist gefunden. Verwenden Sie Hinweise zu den am besten passenden Text zu finden.
Adopt-Algorithmus kann sowohl mit HTML-Tags ignoriert und unter Ausnutzung von ihnen verwendet werden. Algorithmus gilt für Angaben im Klartext geschrieben, HTML oder XML.
Dieser Algorithmus wurde in JLS2-> JLS3 Markup Transfer Tool implementiert. 84% der Markup-Tags wurden automatisch übertragen. Der Rest von ihnen wurden manuell durchgeführt.
Spezifikation ist wichtig - diese Aussage ist für alle klar. Eine weit verbreitete Produkt, Technik oder Sprache, ohne eine Spezifikation ist nutzlos. Eine Spezifikation, die ohne eine Testsuite ist gefährlich. A Testsuite ohne Auszeichnungen und Tests ist unmöglich. Dieser Prozess ist recht komplex. Es gibt jedoch Möglichkeiten, um das Markup der Bühne zu vereinfachen. 
