@phdthesis{Reuys2006, title = {Anforderungsbasierte Ableitung von Systemtestfall-Szenarien in der Software-Produktlinien-Entwicklung}, author = {Andreas Reuys}, publisher = {Logos Berlin}, year = 2006, url = {http://www.amazon.de/gp/redirect.html%3FASIN=383251435X%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/383251435X%253FSubscriptionId=13CT5CVB80YFWJEPWS02}, ean = {9783832514358}, asin = {383251435X}, isbn = {383251435X}, description = {MR: Die Referenzarbeit für auf ScenTED basierende Forschung.}, abstract = {Kurzbeschreibung Ziel der Einführung von Software-Produktlinien in einer industriellen Software-Entwicklung ist die Reduzierung der Entwicklungszeit und u2013kosten bei gleichzeitiger Steigerung der Qualität gegenüber der Einzelsystem-Entwicklung. Neben konstruktiven Entwicklungsphasen müssen in der Produktlinien-Entwicklung Maßnahmen zur Qualitätssicherung durchgeführt werden. Der Systemtest ist Bestandteil der analytischen Qualitätssicherungsmaßnahmen. Eine Aufgabe des Systemtests ist die Überprüfung der richtigen Umsetzung der funktionalen Anforderungen eines Systems. Dazu werden System-Testfälle aus den spezifizierten funktionalen Anforderungen abgeleitet. Die Anwendung existierender Test-Techniken, -Methoden und -Verfahren aus der Einzelsystem-Entwicklung ist durch die Konzepte der Produktlinien-Entwicklung, der Trennung von Domänen- und Applikations-Entwicklung sowie Variabilität, problematisch. Es ist ein effizientes Verfahren entwickelt worden, das den Systemtest in der Software-Produktlinien-Entwicklung unterstützt. An das Verfahren wurden die folgenden Anforderungen gestellt: Um einen geringen Aufwand bei dem Systemtest zu haben, soll die Wiederverwendung von Testfällen unterstützt werden. Die Wiederverwendung kann nur erfolgen, wenn die Nachvollziehbarkeit zwischen Anforderungen und Testfällen aufgezeichnet wurde. Durch wiederverwendete Anforderungen in Applikationen der Produktlinie können die wiederzuverwendenden Testfälle ermittelt werden. Zusätzlich soll eine frühe Validierung während des Domänen-Tests unterstützt werden, um Fehler frühzeitig zu ermitteln. Die Umsetzung der Anforderungen erfolgt im ScenTED-Verfahren (Scenario-based TEst case Derivarion) durch die folgenden Kernideen: - Erstellung von Testfällen mit Variabilität im Domänen-Test: Es wurden unterschiedliche Strategien zum Test in der Produktlinien-Entwicklung beurteilt. Es wurde eine Strategie umgesetzt, in der Testfälle für Gemeinsamkeiten und für die Varianten der Produktlinie ermittelt werden. Die Testfälle mit Variabilität enthalten die Ausprägungen der Varianten und können deshalb mit geringen Anpassungen beim Testen von Applikationen der Produktlinie verwendet werden. - Ableitung der Testfälle aus Domänen-Use-Cases und Szenarien: Die Ableitung der Testfälle erfolgt aus den Anforderungen. Die Anforderungen liegen als Domänen-Use-Cases und dazu gehörigen Szenarien vor. Diese Typen von Anforderungen sind eine gute Grundlage zur Ermittlung der Testfälle, da sie Abläufe beschreiben, die einem Systemtest sehr ähnlich sind. - Umsetzung eines Modell-basierten Vorgehens: Modell-basierte Vorgehen sind in der Einzelsystem-Entwicklung bekannt. Sie haben einige Vorteile, wie z.B. nachvollziehbare Mengen von Testfällen und Überprüfung der Anforderungen durch die Erstellung des Test-Modells. Als Test-Modell wurde ein Aktivitätsmodell verwendet, welches um Variabilität erweitert wurde. Zur Unterstützung des ScenTED-Vorgehens sind zwei Prototypen implementiert worden. Der erste Prototyp realisiert die Erstellung eines Test-Modells für den Domänen-Test. Der zweite Prototyp nimmt dieses Test-Modell als Eingabe, um daraus Testfall-Szenarien im Domänen-Test zu ermitteln. Das Verfahren wurde in zwei Fallstudien angewendet. Zum einen wurde eine imaginäre Produktlinie getestet. Zum anderen wurde das ScenTED-Verfahren erfolgreich in einer Kooperation mit der Firma Siemens AG in einer realen Entwicklung genutzt, um den Systemtest einer Software-Produktlinie zu unterstützen. Es ist einmal eine kleine Menge von Testfall-Szenarien ermittelt worden. Diese Testfall-Szenarien wurden zum Test von drei Applikationen der Produktlinie herangezogen. Die Testfälle wurden systematisch wiederverwendet, was den Aufwand zur Ermittlung der Testfälle reduzieren soll. }, biburl = {http://www.bibsonomy.org/bibtex/24336a1857dfafb495786b25d49c7600f/ist_spl}, keywords = {requirements testing scenario ScenTED line based product software} } @article{Tevanlinna2004, title = {Product family testing: a survey}, address = {New York, NY, USA}, author = {Antti Tevanlinna and Juha Taina and Raine Kauppinen}, journal = {SIGSOFT Softw. Eng. Notes}, note = {MR: ein guter Überblick über SPL-Testing bis 2004}, number = 2, pages = {12--12}, publisher = {ACM}, volume = 29, year = 2004, url = {http://portal.acm.org/citation.cfm?id=979766}, issn = {0163-5948}, doi = {http://doi.acm.org/10.1145/979743.979766}, description = {Product family testing}, abstract = {In this paper we discuss the current state of product family testing. Testing, unlike other areas of software development, has received only little attention in this context despite the problems directly rising from scale, reuse and variability. We present the current approaches to product family testing methodology and processes. We also evaluate the current state-of-the-art in product family testing and highlight problems that need to be addressed in the future.}, biburl = {http://www.bibsonomy.org/bibtex/2823e900bcd466d99b6d9aedff92da714/ist_spl}, keywords = {product testing line} } @techreport{McGregor2001, title = {Testing a Software Product Line}, author = {John D. McGregor}, note = {MR: beschäftigt sich eher mit den organisatorischen Aspekten}, number = {CMU/SEI-2001-TR-022}, year = 2001, abstract = {A suitably organized and executed test process can contribute to the success of a product line organization. Testing is used to identify defects during construction and to assure that completed products possess the qualities specified for the products. Test-related activities are organized into a test process that is designed to take advantage of the economies of scope and scale that are present in a product line organization. These activities are sequenced and scheduled so that a test activity occurs immediately following the construction activity whose output the test is intended to validate. This report expands on the testing practice area described by Clements and Northrop. Test-related activities that can be used to form the test process for a product line organization are described. Product line organizations face unique challenges in testing. This report describes techniques and activities for meeting those challenges.}, biburl = {http://www.bibsonomy.org/bibtex/2aec593ff707ee5e036253d36633a414e/ist_spl}, keywords = {product testing line} } @article{Pohl2006, title = {Software product line testing}, address = {New York, NY, USA}, author = {Klaus Pohl and Andreas Metzger}, journal = {Commun. ACM}, number = 12, pages = {78--81}, publisher = {ACM}, volume = 49, year = 2006, url = {http://portal.acm.org/citation.cfm?id=1183236.1183271&coll=Portal&dl=GUIDE&CFID=76494643&CFTOKEN=68898243}, issn = {0001-0782}, doi = {http://doi.acm.org/10.1145/1183236.1183271}, description = {Software product line testing}, abstract = {Exploring principles and potential solutions.}, biburl = {http://www.bibsonomy.org/bibtex/2d98a11b8a2cfb061f5eeea8f84b44ff3/ist_spl}, keywords = {product line testing ScenTED} } @inproceedings{Hartmann2000, title = {UML-Based integration testing}, address = {New York, NY, USA}, author = {Jean Hartmann and Claudio Imoberdorf and Michael Meisinger}, booktitle = {ISSTA '00: Proceedings of the 2000 ACM SIGSOFT international symposium on Software testing and analysis}, note = {MR: Es konzentriert sich auf dem Integrationstest. Es gibt aber sehr viele Parallelen zu den späteren Systemtest-Techniken von Hartmann et.al.}, pages = {60--70}, publisher = {ACM}, year = 2000, url = {http://portal.acm.org/citation.cfm?doid=347324.348872}, location = {Portland, Oregon, United States}, isbn = {1-58113-266-2}, doi = {http://doi.acm.org/10.1145/347324.348872}, description = {UML-Based integration testing}, abstract = {Increasing numbers of software developers are using the Unified Modeling Language (UML) and associated visual modeling tools as a basis for the design and implementation of their distributed, component-based applications. At the same time, it is necessary to test these components, especially during unit and integration testing.At Siemens Corporate Research, we have addressed the issue of testing components by integrating test generation and test execution technology with commercial UML modeling tools such as Rational Rose; the goal being a design-based testing environment. In order to generate test cases automatically, developers first define the dynamic behavior of their components via UML Statecharts, specify the interactions amongst them and finally annotate them with test requirements. Test cases are then derived from these annotated Statecharts using our test generation engine and executed with the help of our test execution tool. The latter tool was developed specifically for interfacing to components based on COM/DCOM and CORBA middleware.In this paper, we present our approach to modeling components and their interactions, describe how test cases are derived from these component models and then executed to verify their conformant behavior. We outline the implementation strategy of our TnT environment and use it to evaluate our approach by means of a simple example.}, biburl = {http://www.bibsonomy.org/bibtex/2d91d30d66138ff7df38d62421fb8d32c/ist_spl}, keywords = {testing statecharts category-partition UML TDE/UML integration} } @inproceedings{Chen2005, title = {Identification of Categories and Choices in Activity Diagrams}, address = {Washington, DC, USA}, author = {T. Y. Chen and Sau-Fun Tang and Pak-Lok Poon and T. H. Tse}, booktitle = {QSIC '05: Proceedings of the Fifth International Conference on Quality Software}, pages = {55--63}, publisher = {IEEE Computer Society}, year = 2005, url = {http://portal.acm.org/citation.cfm?id=1110491&dl=&coll=}, isbn = {0-7695-2472-9}, doi = {http://dx.doi.org/10.1109/QSIC.2005.36}, description = {Identification of Categories and Choices in Activity Diagrams}, abstract = {The choice relation framework (CHOC' LATE) provides a systematic skeleton for constructing test cases from specifications. An early stage of the framework is to identify a set of categories and choices from the speci- fication, which is not a trivial task when this document is largely informal and complex. Despite the difficulty, the identification task is very important because the quality of the identified categories and choices will affect the comprehensiveness of the test cases and, hence, the chance of revealing software faults. This paper alleviates the problem by introducing a technique for identifying categories and choices from the activity diagrams in the specification. This technique also helps determine the relations between some pair of choices in the choice relation table - an essential step of CHOC' LATE for the subsequent generation of test cases.}, biburl = {http://www.bibsonomy.org/bibtex/235bf31ceea5f91ddbed0348764e22e59/ist_spl}, keywords = {classification-tree-method specification-based category-partition diagrams test activity testing} } @inproceedings{Wang2004, title = {Generating Test Cases from UML Activity Diagram based on Gray-Box Method}, address = {Washington, DC, USA}, author = {Wang Linzhang and Yuan Jiesong and Yu Xiaofeng and Hu Jun and Li Xuandong and Zheng Guoliang}, booktitle = {APSEC '04: Proceedings of the 11th Asia-Pacific Software Engineering Conference}, pages = {284--291}, publisher = {IEEE Computer Society}, year = 2004, url = {http://portal.acm.org/citation.cfm?id=1032630.1032732}, isbn = {0-7695-2245-9}, doi = {http://dx.doi.org/10.1109/APSEC.2004.55}, description = {Generating Test Cases from UML Activity Diagram based on Gray-Box Method}, abstract = {Test case generation is the most important part of the testing efforts, the automation of specification based test case generation needs formal or semi-formal specifications. As a semi-formal modelling language, UML is widely used to describe analysis and design specifications by both academia and industry, thus UML models become the sources of test generation naturally. Test cases are usually generated from the requirement or the code while the design is seldom concerned, this paper proposes an approach to generate test cases directly from UML activity diagram using gray-box method, where the design is reused to avoid the cost of test model creation. In this approach, test scenarios are directly derived from the activity diagram modelling an operation. Then all the information for test case generation, i.e. input/output sequence and parameters, the constraint conditions and expected object method sequence, is extracted from each test scenario. At last, the possible values of all the input/output parameters could be generated by applying category-partition method, and test suite could be systematically generated to find the inconsistency between the implementation and the design. A prototype tool named UMLTGF has been developed to support the above process.}, biburl = {http://www.bibsonomy.org/bibtex/21b3b853c356f30b69b0e73bae873f883/ist_spl}, keywords = {testing test UML activity gray-box generation diagram} } @book{Baker2007, title = {Model-Driven Testing: Using the UML Testing Profile}, author = {Paul Baker and Zhen Ru Dai and Jens Grabowski and Øystein Haugen and Ina Schieferdecker and Clay Williams}, edition = 1, note = {Volltext vorhanden unter: http://dx.doi.org/10.1007/978-3-540-72563-3 MR: Befasst sich mit funktionalem Black-Box-Testing (also spezifikationsbasiert oder MBT), wobei das Funktionale bezieht sich auf das korrekte funktionale Verhalten des SUT. Es beschreibt wie aus Verhaltensspezifikationen, wie UML state/activity/interaction/...-Diagrammen die Test-/Testfallspezifikationen in Form von ähnlichen Diagrammen abgeleitet werden können. Es gibt aber keine ausdrücklichen Vorschriften für die Automatisierung der Testfallgenerierung. Es kann außer für den Systemtest auch für jede andere Testphase eingesetzt werden. Für IST-SPL ist vor allem die UML-Modellierung von Testdaten interessant mit data pools, data partitions, data selectors (Kapitel 7: Data-Driven Testing). Auch deren Anwendung mit Black-Box-Techniken wurde dort kurz erwähnt. }, publisher = {Springer, Berlin}, year = 2007, url = {http://dx.doi.org/10.1007/978-3-540-72563-3}, ean = {9783540725626}, asin = {3540725628}, isbn = {3540725628}, dewey = {005}, biburl = {http://www.bibsonomy.org/bibtex/2b61e66cc642ea87d1b58da45e6175ac3/ist_spl}, keywords = {testing UML MBT U2TP profile driven model} } @article{Edwards2000, title = {Black-box testing using flowgraphs: an experimental assessment of effectiveness and automation potential}, author = {Stephen H. Edwards}, journal = {Software Testing, Verification and Reliability}, month = {January}, note = {MR: Aus dem Text: Testing 'to contract' is at the heart of specification based testing. Es wird gezeigt wie ein Anzatz von [Zweben1992] (der leider nicht auffindbar ist) sich praktisch umsetzen lässt. Dabei spielen die Contracts für die Generierung der Test(ein/aus)gabedaten grundlegende Rolle. Die getesteten Komponenten werden als Flowgraphs dargestellt, womit sie große Analogie zu Aktivitätsdiagrammen besitzen. Obwohl noch Probleme bei der Auswahl der Testdaten (infeasable paths) existieren, wurde gezeigt, dass dieser Ansatz großen Potential besitzt. Für das Experiment wurde Fehlerinjektionsmethoden angewendet (Mutation).}, number = 4, pages = {249--262}, volume = 10, year = 2001, url = {http://dx.doi.org/10.1002/1099-1689(200012)10:4\%3C249::AID-STVR215\%3E3.0.CO;2-C}, id = {88926}, issn = {1099-1689}, priority = {2}, at = {2005-02-07 17:23:44}, doi = {10.1002/1099-1689(200012)10:4<249::AID-STVR215>3.0.CO;2-C}, abstract = {A black-box testing strategy based on Zweben et al.'s specification-based test data adequacy criteria is explored. The approach focuses on generating a flowgraph from a component's specification and applying analogues of white-box strategies to it. An experimental assessment of the fault-detecting ability of test sets generated using this approach was performed for three of Zweben et al.'s criteria using mutation analysis. By using precondition, postcondition and invariant checking wrappers around the component under test, fault detection ratios competitive with white-box techniques were achieved. Experience with a prototype test set generator used in the experiment suggests that practical automation may be feasible.}, biburl = {http://www.bibsonomy.org/bibtex/2a45a856d10b02b17f280190fcd86e042/ist_spl}, keywords = {path fault-injection automated black-box flowgraph sensitization testing specification-based oracle testdata contracts} } @book{Gross2004, title = {Component-Based Software Testing with UML}, author = {Hans-Gerhard Gross}, edition = 1, note = {MR: am meisten interessant ist der Kapitel: Model-Based Testing with UML und dadrin der Abschnitt über das Testen mit Aktivitätsdiagrammen (in Bezug auf ScenTED)}, publisher = {Springer}, year = 2004, url = {http://www.amazon.com/Component-Based-Software-Testing-Hans-Gerhard-Gross/dp/354020864X%3FSubscriptionId%3D13CT5CVB80YFWJEPWS02%26tag%3Dws%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D354020864X}, ean = {9783540208648}, asin = {354020864X}, isbn = {354020864X}, dewey = {005.14}, description = {Amazon.com: Component-Based Software Testing with UML: Hans-Gerhard Gross: Books}, abstract = {Review Component-based software development regards software construction in terms of conventional engineering disciplines where the assembly of systems from readily-available prefabricated parts is the norm. Because both component-based systems themselves and the stakeholders in component-based development projects are different from traditional software systems, component-based testing also needs to deviate from traditional software testing approaches. Gross first describes the specific challenges related to component-based testing like the lack of internal knowledge of a component or the usage of a component in diverse contexts. He argues that only built-in contract testing, a test organization for component-based applications founded on building test artifacts directly into components, can prevent catastrophic failures like the one that caused the now famous ARIANE 5 crash in 1996. Since building testing into components has implications for component development, built-in contract testing is integrated with and made to complement a model-driven development method. Here UML models are used to derive the testing architecture for an application, the testing interfaces and the component testers. The method also provides a process and guidelines for modeling and developing these artifacts. This book is the first comprehensive treatment of the intricacies of testing component-based software systems. With its strong modeling background, it appeals to researchers and graduate students specializing in component-based software engineering. Professionals architecting and developing component-based systems will profit from the UML-based methodology and the implementation hints based on the XUnit and JUnit frameworks.}, biburl = {http://www.bibsonomy.org/bibtex/2f279f8b0b4981974f0151393e8db9c17/ist_spl}, keywords = {assertions activity testing diagrams contracts MBT UML} } @inproceedings{Mishra2006, title = {Specification Based Software Product Line Testing: A Case Study}, author = {Satish Mishra}, booktitle = { CS&P 2006 - Concurrency, Specification and Programming}, editor = {Roman Redziejowski Ludwik Czaja and Holger Schlingloff}, note = {MR: Es wird gezeigt, dass bei SPLs, die mit formalen Spezifikationen (hier CSP-CASL) beschrieben sind, die Testfälle, Testeingaben und erwartete Ergebnisse automatisch generiert werden können. Die Wiederverwendung der Tests beschränkt sich im Paper auf SPLs von speziellen Art, bei denen die Varianten nur erweitert werden können und somit andere Varianten und den gemeinsamen Teil vollständig involvieren.}, year = 2006, url = {http://www2.informatik.hu-berlin.de/~hs/Aktivitaeten/2006_CSP/}, abstract = {In this paper, we describe an approach of software product line testing which is based on formal specifications of the desired properties. In a software product line, common behaviours are maintained at subsequent levels of the product development. Commonalities among products arise from the reuse of parts of the software. It is unclear, however, in which way test cases for one product can be reused for subsequent enhancements. In this paper we approach this problem by specification based testing. We start the software quality assurance process by formally specifying the system in the process algebraic specification language CSP-CASL [1] for the description of system properties. After that we establish an enhancement relation between specifications in a software product line development. This enhancement relation conceptually forms the basis of reusability of test suites among different implementations in a product line development.}, biburl = {http://www.bibsonomy.org/bibtex/2d75bfa54d7c45c6a6ffba04b75938005/ist_spl}, keywords = {testing testdata product software oracle specification algebraic automated line CSP specification-based} } @inproceedings{Uzuncaova2007, title = {A specification-based approach to testing software product lines}, address = {New York, NY, USA}, author = {Engin Uzuncaova and Daniel Garcia and Sarfraz Khurshid and Don S. Batory}, booktitle = {ESEC-FSE '07: Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering}, editor = {Ivica Crnkovic and Antonia Bertolino}, note = {ST: Die Spezifikation der Produktlinie liegt in einer formalen Beschreibung vor (LTL) Es wird ein Modelchecking-Verfahren durchgefuehrt um zu beweisen, dass die Spezifikation gilt. Fazit: Keine explizite Ableitung von Testdaten, die Spezifikation muss formal vorliegen. MR: Anhand von formalen Alloy-Spezifikationen von Invarianten und Constraints kann der Alloy Analyzer (SAT solver) automatisch alle passenden Testdaten generieren. Nachteile: Die erwarteten Ergebnisse werden nicht betrachtet (oder?). Die Spezifikation wird als Annotationen in den Code eingebracht (hier als moderner Ansatz angesehen ähnlich JML). An der Wiederverwendung wird erst gearbeitet. }, pages = {525--528}, publisher = {ACM}, year = 2007, url = {http://doi.acm.org/10.1145/1287624.1287701}, bibdate = {2007-10-23}, bibsource = {DBLP, http://dblp.uni-trier.de/db/conf/sigsoft/fse2007.html#UzuncaovaGKB07}, isbn = {978-1-59593-811-4}, description = {Computer Science Bibliography Collection}, abstract = {This paper presents a specification-based approach for sys- tematic testing of products from a software product line. Our approach uses specifications given as formulas in Alloy, a first-order logic based on relations. Alloy formulas can be checked for satisfiability using the Alloy Analyzer. The fully automatic analyzer, given an Alloy formula and a scope, i.e., a bound on the universe of discourse, searches for an in- stance, i.e., a valuation to the relations in the formula such that it evaluates to true. The analyzer translates an Alloy formula (for the given scope) to a propositional formula and finds an instance using an off-the-shelf SAT solver. The use of an enumerating solver enables systematic test generation. We have developed a prototype based on the AHEAD theory. The prototype uses the recently developed Kodkod model finding engine of the Alloy Analyzer. We illustrate our approach using a data structure product line.}, biburl = {http://www.bibsonomy.org/bibtex/2295b43ca71fb9d71fe69cb755c7ae30d/ist_spl}, keywords = {testdata product generation specification-based line GenVoca testing AHEAD Alloy} } @inproceedings{Balcer1989, title = {Automatic Generation of Test Scripts from Formal Test Specifications}, author = {Marc J. Balcer and William M. Hasling and Thomas J. Ostrand}, booktitle = {Symposium on Testing, Analysis, and Verification}, note = {MR: Formalismen zu der Category-Partition-Methode mittels TSL}, pages = {210-218}, year = 1989, ee = {http://doi.acm.org/10.1145/75308.75332}, bibsource = {DBLP, http://dblp.uni-trier.de}, description = {DBLP Record 'conf/issta/BalcerHO89'}, abstract = {TSL is a language for writing formal test spec@ations of the functions of a sofhyare system. The test specifications are compiled into executable test scripts that establish test environments, assign values to input variables, peflorm necessary setup and cleanup operations, run the test cases, and check the correctness of test results. TSL is a working system that has been used to test commercial software in a production}, biburl = {http://www.bibsonomy.org/bibtex/20c549af374d78951b97b7695cd847f7d/ist_spl}, keywords = {testing category-partition TSL} } @inproceedings{Ammann1994, title = {Using Formal Methods to Derive Test Frames in Category-Partition Testing}, address = {Gaithersburg, MD}, author = {Paul Ammann and Jeff Offutt}, booktitle = {Compass'94: 9th Annual Conference on Computer Assurance}, pages = {69--80}, publisher = {National Institute of Standards and Technology}, year = 1994, url = {citeseer.ist.psu.edu/ammann94using.html}, description = {Using Formal Methods To Derive Test Frames In Category-Partition Testing - Ammann, Offutt (ResearchIndex)}, biburl = {http://www.bibsonomy.org/bibtex/2e44d557afd9ec9c11e099f5c65a872b0/ist_spl}, keywords = {testing category-partition ADT Domain-Partitioning Z TSL} } @article{paradkar97specificationbased, title = {Specification-Based Testing Using Cause-Effect Graphs}, author = {Amit M. Paradkar and Kuo-Chung Tai and Mladen A. Vouk}, journal = {Annals of Software Engineering}, pages = {133-157}, volume = 4, year = 1997, url = {citeseer.ist.psu.edu/paradkar97specificationbased.html}, description = {Specification-Based Testing Using Cause-Effect Graphs - Paradkar, Tai, Vouk (ResearchIndex)}, biburl = {http://www.bibsonomy.org/bibtex/2130c0297f41500c8dbc5951681aa8484/ist_spl}, keywords = {testing specification-based predicate graphs cause-effect} } @article{Offutt1999b, title = {Generating test data from SOFL specifications}, author = {A. Jefferson Offutt and Shaoying Liu}, journal = {Journal of Systems and Software}, month = {#dec#}, note = {MR: Habe mir mehr von dem Paper erhofft. Nur auf der Unit-Test-Ebene wird es mehr konkreter, wobei die DNF mit einer natürlichen Semantik ersetzbar wäre. Für Systemtest wird (mutierte) Category-Partition auf S-Modules(ähnlich Use-Cases) vorgeschlagen und für die Integrationstests Branch-Coverage-Criterion auf CDFD (ähnlich Aktivitätsdiagramme).}, number = 1, pages = {49--62}, volume = 49, year = 1999, url = {http://www.sciencedirect.com/science/article/B6V0N-3Y9RCX5-6/1/c5ebc39ab8c82a84f7b908a815ef77ec}, description = {ScienceDirect - Journal of Systems and Software : Generating test data from SOFL specifications1}, abstract = {Software testing can only be formalized and quantified when a solid basis for test generation can be defined. Tests are commonly generated from the source code, control flow graphs, design representations, and specifications/requirements. Formal specifications represent a significant opportunity for testing because they precisely describe functions the software is supposed to provide in a form that can be easily manipulated. This paper presents a new method for generating tests from formal specifications. This method is comprehensive in specification coverage, applies at several levels of abstraction, and can be highly automated. The paper applies the method to SOFL specifications, describes the technique, and demonstrates the application on a case study. A preliminary evaluation using a code-level coverage criterion (mutation testing), indicates that the method can result in very effective tests.}, biburl = {http://www.bibsonomy.org/bibtex/2a12220ece974926b9d8cbf38202cad69/ist_spl}, keywords = {integration SOFL testing activity diagrams category-partition specification-based systemtest TSL} } @inproceedings{Offutt1999, title = {Generating Tests from {UML} Specifications}, author = {Jeff Offutt and Aynur Abdurazik}, booktitle = {{UML}'99 - The Unified Modeling Language. Beyond the Standard. Second International Conference, Fort Collins, {CO}, {USA}, October 28-30. 1999, Proceedings}, editor = {Robert France and Bernhard Rumpe}, note = {MR: Die 'Transition Table' aus UML-Statechart-Werkzeugen wird eingelesen und entsprechend definierten Coverage-Criteria werden daraus Testfälle generiert. Ein weiterer Algo. kümmert sich um die Test Data indem die Werte generiert werden, die zum erreichen von bestimmten Zuständen notwendig sind. Es gibt keine konkrete Aussage über erwartete Testergebnisse. Den Algorithmen kann man aber vorsichtig ableiten, dass mit Test Data auch die erwarteten Ergebnisse gemeint sind.}, pages = {416--429}, publisher = {Springer}, volume = 1723, year = 1999, url = {citeseer.ist.psu.edu/article/offutt99generating.html}, description = {Generating Tests from UML Specifications - Offutt, Abdurazik (ResearchIndex)}, abstract = {Although most industry testing of complex software is conducted at the system level, most formal research has focused on the unit level.Asaresult,mostsystemlevel testing techniques are only described informally. This paper presents a novel technique that adapts pre-de#ned state-based speci#cation test data generation criteria to generate test cases from UML statecharts. UML statecharts provide a solid basis for test generation in a form that can be easily manipulated. This technique...}, biburl = {http://www.bibsonomy.org/bibtex/2db9b7ace10d2745034396bdd4bf3259f/ist_spl}, keywords = {OCL systemtest UML testing generation testdata statecharts specification-based} } @book{Binder1999, title = {Testing Object Oriented Systems: Models, Patterns and Tools}, author = {Robert Binder}, edition = {Revised.}, note = {MR: [Santos-Neto2007] referenzieren es im Zusammenhang mit test oracle generation: "This is the hardest and the most expensive MBT requirement." Enthält 16 micro-patterns for test oracles. Interessant: Round-trip Scenario Test (ähnlich zu ScenTED, wobei Daten berücksichtigt werden).}, publisher = {Addison Wesley}, year = 1999, url = {http://www.amazon.de/gp/redirect.html%3FASIN=0201809389%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/0201809389%253FSubscriptionId=13CT5CVB80YFWJEPWS02}, ean = {9780201809381}, asin = {0201809389}, isbn = {0201809389}, dewey = {005.117}, abstract = {Test Engineering Testing Object-Oriented Systems takes software/systems engineering approach to test design and test automation. It is a comprehensive guide to testing object-oriented systems, organized as a desk reference. It starts with basic testing concepts and then shows what is unique about testing object-oriented software. Test models based on state machines, combinational logic, and the UML provide a systematic and practical foundation. Over sixty patterns present concepts and techniques for test design and test automation. Pattern-Based Test Design The book introduces the test design pattern. This new pattern template focuses explicitly on the key dimensions of test design: When is a particular test strategy appropriate? What kind of bugs will it find? How do you develop a test suite -- how should the implementation under test be modeled, and how are test cases produced from the model and its oracle? What kind of test automation works best? What are the testing entry and exit criteria? What are its advantages and disadvantages? Who has used this pattern? The book presents 37 test design patterns based on this template. They cover testing of methods, classes/clusters, subsystems, reusable components, frameworks, and systems. They address responsibility-based testing, integration testing, and regression testing at all these scopes. Seventeen design patterns for test automation support test tool development, and 16 micro-patterns for test oracles show how to produce expected results. }, biburl = {http://www.bibsonomy.org/bibtex/2710185c6fc22c2378c71418131ae7f48/ist_spl}, keywords = {oriented oracle fundamentals testing object} } @book{Beizer1995, title = {Black-Box Testing: Techniques for Functional Testing of Software and Systems}, author = {Boris Beizer}, edition = 1, note = {MR: referenziert aus Binder1999 (u.a. im Hinblick auf data flow testing strategies)}, publisher = {Verlag John Wiley & Sons, Inc}, year = 1995, url = {http://www.amazon.de/gp/redirect.html%3FASIN=0471120944%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/Black-Box-Testing-Techniques-Functional-Software/dp/0471120944%253FSubscriptionId=13CT5CVB80YFWJEPWS02}, ean = {9780471120940}, asin = {0471120944}, isbn = {0471120944}, dewey = {005.14}, description = {Amazon.de: Black-Box Testing: Techniques for Functional Testing of Software and Systems: Boris Beizer: Englische Bücher}, abstract = {Book Description An expert in the software testing field, Beizer uses a range of examples testing IRS tax forms and their corresponding off-the-shelf tax preparation packages to demonstrate how a wealth of accepted and proven black box testing techniques can be used to validate the requirements of the forms as they relate to software. All methods are thoroughly introduced and tests are designed, modeled, and debugged for readers. Includes numerous self-evaluation quizzes and tax forms. Synopsis From a leading expositor of testing methods, a practical, comprehensive, hands-on guide to the state-of-the-art black-box testing techniques This book fills a long-standing need in the software and general systems development communities to make the essential aspects of black-box testing available in one comprehensive work. Written by one of the world's most respected figures in the field of testing, it is both a valuable working resource for independent testers and programmers and an excellent practical introduction for students. Dr. Boris Beizer clearly explains the principles behind behavioral testing in general and behind the most important black-box testing techniques in use today, which involve testing a system based on its desired behavior or function and for conformance to its specifications. Then, with fully worked examples, he leads you step-by-step from specifications to finished test cases. Complete coverage of all important test techniques including those that apply to object-oriented software Up-to-date including the most recent breakthroughs in domain testing that now make this technique available to the working tester with no tools needed beyond a calculator or spreadsheet Examples based on the popular off-the-shelf tax preparation packages let you try the techniques on your favorite tax software Includes all necessary IRS tax forms Self-evaluation quizzes help you evaluate your understanding of the material }, biburl = {http://www.bibsonomy.org/bibtex/2ed27c814801f39fa05296c28b63a2554/ist_spl}, keywords = {functional testing black-box} } @article{Bertolino1994, title = {Automatic Generation of Path Covers Based on the Control Flow Analysis of Computer Programs}, address = {Piscataway, NJ, USA}, author = {Antonia Bertolino and Martina Marr\'{e}}, journal = {IEEE Trans. Softw. Eng.}, note = {MR: Bei ScenTED wird dieses Verfahren zur Ableitung von Testfall-Scenarien angewendet.}, number = 12, pages = {885--899}, publisher = {IEEE Press}, volume = 20, year = 1994, url = {http://portal.acm.org/citation.cfm?id=203102.203103}, issn = {0098-5589}, doi = {http://dx.doi.org/10.1109/32.368137}, description = {Automatic Generation of Path Covers Based on the Control Flow Analysis of Computer Programs}, abstract = {Branch testing a program involves generating a set of paths that will cover every arc in the program flowgraph, called a path cover, and finding a set of program inputs that will execute every path in the path cover. This paper presents a generalized algorithm that finds a path cover for a given program flowgraph. The analysis is conducted on a reduced flowgraph, called a ddgraph, and uses graph theoretic principles differently than previous approaches. In particular, the relations of dominance and implication which form two trees of the arcs of the ddgraph are exploited. These relations make it possible to identify a subset of ddgraph arcs, called unconstrained arcs, having the property that a set of paths exercising all the unconstrained arcs also cover all the arcs in the ddgraph. In fact, the algorithm has been designed to cover all the unconstrained arcs of a given ddgraph: the paths are derived one at a time, each path covering at least one as yet uncovered unconstrained arc. The greatest merits of the algorithm are its simplicity and its flexibility. It consists in just visiting recursively in combination the dominator and the implied trees, and is flexible in the sense that it can derive a path cover to satisfy different requirements, according to the strategy adopted for the selection of the unconstrained arc to be covered at each recursive iteration. This feature of the algorithm can be employed to address the problem of infeasible paths, by adopting the most suitable selection strategy for the problem at hand. Embedding of the algorithm into a software analysis and testing tool is recommended.}, biburl = {http://www.bibsonomy.org/bibtex/2392b8b21a4c41e09b286cca9eaa18752/ist_spl}, keywords = {testing path ddgraph ScenTED automated diagrams cover activity} }