UCTSystem is a prototype tool designed to perform automatic test generation from UML requirements. It uses UML use cases enhenced with contracts (i.e. precondition and postconditions) to build an execution model allowing all valid sequences of use cases. Using this execution model and several test criteria, it generates test objectives as sequence of use cases to exerce. It includes both criteria for functional testing and a criterion for robusness testing. Those test objectives are then mapped into test cases using test templates.
The article illustrates a formal method of deriving functional test cases from use cases, including how to create a use case, derive all scenarios, and create reasonable test cases, as well as use IBM® Rational® RequisitePro for traceability from use cases to scenarios and test cases.
ObjectGen is a tool for generating test objectives from use cases. ValueGen is a tool for generating operational variables and combination of values from use cases. Although ValueGen needs the artefacts generated by ObjectGen, both tools are independent.
C. Nebut, F. Fleurey, Y. Traon, and J. Jézéquel. ISSRE '03: Proceedings of the 14th International Symposium on Software Reliability Engineering, page 85. Washington, DC, USA, IEEE Computer Society, (2003)
B. Regnell, K. Kimbler, and A. Wesslen. RE '95: Proceedings of the Second IEEE International Symposium on Requirements Engineering, page 40. Washington, DC, USA, IEEE Computer Society, (1995)
A. Braganca, and R. Machado. SPLC '07: Proceedings of the 11th International Software Product Line Conference, page 3--12. Washington, DC, USA, IEEE Computer Society, (2007)
S. Pickin, C. Jard, Y. Traon, T. Jéron, J. Jézéquel, and A. Guennec. FORTE, page 97-113. (2002)MR: Mittels UMLAUT wird die UML-Spezifikation in ein IOLTS überführt und durch das Testsynthesis-Tool TGV werden Testfälle abgeleitet.
Auf diesem Ansatz baut auch der Ansatz von Nebut im SPL-Umfeld Nebut2002Nebut2003Nebut2006..
J. Hartmann, M. Vieira, and A. Ruder. Proceedings of the International Workshop on Software Product Line Testing (SPLiT 2004), page 58--65. Boston, MA, (August 2004)
P. Carpenter. Ada Lett., XIX (3):
23--29(1999)ST: Vorgehensweise: Das Paper ordnet den Vorgang, wie man sicherheitskritische Anforderungen verifizieren kann, in einen Software Life-Cycle ein. Use-Cases werden mit Parametern für Daten versehen. Die Eingabedaten werden mit Hilfe eines Tools generiert per üblicher Ä-Klassenanalyse.
Eignung: Es ist nichts über die Testgüte zu finden (Abdeckungskriterium etc.). Außerdem wird kein Testmodell o.ä. erwähnt, welches alternative Ausführungspfade des Use Cases repräsentiert..
B. Hasling, H. Goetz, and K. Beetz. Software Testing, Verification, and Validation, 2008 1st International Conference on, (April 2008)ST: Vorgehensweise:
In diesem Paper wird eine Testtechnik für den Systemtest beschrieben, die von Siemens im medizinischen Bereich angewendet wurde. Aus einem Use Case Modell, dessen Szenarien durch Aktivitätsdiagramme und Sequenzdiagramme beschrieben werden und Äquivalenzklassen für die erforderlichen Testdaten, können Testfälle generiert werden. Dazu wird das Tool TDE/UML benutzt, welche in vorhergehenden Ansätzen entwickelt wurde. Neu an dieser Technik zu den vorher entwickelten Techniken ist die Verbindung des Requirements-Prozesses mit dem Testprozess durch die Benutzung von Use-Cases, die schon im RE erstellt werden.
Eignung:
Vom Prinzip her ist die Vorgehensweise vergleichbar mit der Idee in ScenTEDTDG, da auf den gleichen Modellen gearbeitet wird und Äquivalenzklassen für die Testdatengewinnung herangezogen werden. Variabilität fehlt, da es ein Einzelsystemansatz ist..
A. Carniello, M. Jino, and M. Chaim. Journal of Computer Science & Technology, (2005)ST: Vorgehensweise:
Die Technik arbeitet mit einem Test-kriterium, welches auf Basis der Struktur von Use-Cases entwickelt wird. Die Struktur bildet sich durch Assoziationen, Include- und Extend Beziehungen. Testkriterien sind die Auführung von Use Cases mit allen include und extend Beziehungen, oder die Kombination von extend Beziehungen. Die Rechtfertigung nach dieser Technik vorzugehen liegt darin, das bei dieser Technik mehr Fehler gefunden werden können als bei einem reinen funktionalen Test.
Eignung:
Nach dem Lesen stellte sich heraus, dass keine Flussdiagramme für den Kontrollfluss der Use-Cases verwendet werden sondern nur die Struktur der Use Cases. Daher ist der Ansatz eher ungeeignet..