Leila Naslavsky

Using scenarios to support traceability

Software traceability is a recognized challenge in software development that can be ameliorated with requirements management tools. Traceability information can be used in a number of different software engineering activities such as software change impact analysis and testing One main challenge in the automation of software testing is mapping modeling concepts to code concepts. The level of granularity and the semantics supported by available requirements management tools do not, however, fully support such mapping, or more sophisticated requirement change impact analysis. Scenarios have been used as an alternative (and sometimes complementary) way to express requirements and system behavior throughout the phases of software development. Scenarios are used with different representation and semantics across software phases, and these can be related. This paper argues for exploring scenarios as one means for tracing requirements to code, and using this information to leverage automation of activities that benefit from traceability such as change impact analysis and software testing.

Towards traceability of model-based testing artifacts

Practitioners regard software testing as the central means for ensuring that a system behaves as expected. Due to the recent widespread adoption of model-driven development (MDD), code is no longer the single source for selecting test cases. Testing against original expectations can be done with model-based testing that adopts high-level models as the basis for test generation. In addition to test generation, challenges to model-based testing include creation and maintenance of traceability information among test-related artifacts. Traceability is required to support activities such as result evaluation, regression testing and coverage analysis. MDD and model transformation solutions address the traceability problem by creating relationships among transformed artifacts throughout the transformation process. This paper proposes an approach that leverages model transformation traceability techniques to create fine-grained relationships among model-based testing artifacts. Relationships are created during the test generation process. Their fine granularity enables the support for result evaluation, coverage analysis and regression testing.

A model-based regression test selection technique

Throughout their life cycle, software artifacts are modified, and selective regression testing is used to identify the negative impact of modifications. Code-based regression test selection retests test cases sub-set that traverse code modifications. It uses recovered relationships between code parts and test cases that traverse them to locate test cases for retest when code is modified. Broad adoption of model-centric development has created opportunities for software testing. It enabled driving testing processes at higher abstraction levels and demonstrating code to model compliance by means of Model-Based Testing (MBT). Models also evolve, so an important activity of MBT is selective regression testing. It selects test cases for retest based on model modification, so it relies on relationships between model elements and test cases that traverse those elements to locate test cases for retest. We contribute an approach and prototype that during test case generation creates fine-grained traceability relationships between model elements and test cases, which are used to support model-based regression test selection.

Using traceability to support model-based regression testing

Model-driven development is leading to increased use of models in conjunction with source code in software testing. Model-based testing, however, introduces new challenges for testing activities, which include creation and maintenance of traceability information among test-related artifacts. Traceability is required to support activities such as selective regression testing. In fact, most model-based testing automated approaches often concentrate on the test generation and execution activities, while support to other activities is limited (e.g. model-based selective regression testing, coverage analysis and behavioral result evaluation) To address this problem, we propose a solution that uses model transformation to create a traceable infrastructure of test-related artifacts. We use this infrastructure to support model-based selective regression testing.

MbSRT2: Model-Based Selective Regression Testing with Traceability

Widespread adoption of model-centric development has created opportunities for software testing, with Model-Based Testing (MBT). MBT supports the generation of test cases from models and the demonstration of model and source-code compliance. Models evolve, much like source code. Thus, an important activity of MBT is selective regression testing, which selects test cases for retest based on model modifications, rather than source-code modifications. This activity explores relationships between model elements and test cases that traverse those elements to locate retest able test cases. We contribute an approach and prototype to model-based selective regression testing, whereby fine-grain traceability relationships among entities in models and test cases are persisted into a traceability infrastructure throughout the test generation process: the relationships represent reasons for test case creation and are used to select test cases for re-run. The approach builds upon existing regression test selection techniques and adopts scenarios as behavioral modeling perspective. We analyze precision, efficiency and safety of the approach through case studies and through theoretical and intuitive reasoning.

Towards leveraging model transformation to support model-based testing

The adoption of model-driven development is leading to increased use of models in conjunction with source code in software testing. Model-based testing, however, introduces new challenges for testing activities, which include creation and maintenance of traceability information among test-related artifacts. Traceability is required to support activities such as model-based result evaluation, regression testing and coverage analysis. In this paper, we present an automated approach that leverages model transformation techniques to support test generation. The test generation process includes creation of test-related models and fine-grained relationships among these models. We also motivate our approach with a simple example demonstrating support for model-based regression testing

Using model transformation to support model-based test coverage measurement

Adoption of model-driven development is leading to increased use of models jointly with source code for software testing, by means of Model-Based Testing (MBT). MBT uses models to derive concrete test cases to test code. With MBT, test adequacy criteria are described in relation to the models. They are used to evaluate reliability of derived test cases and as predictor for determining when to stop testing. Hence, when concrete test cases are executed, it is important to measure coverage achieved with regards to the model, rather than only to the code. This places new challenges for testing activities, which include creation and maintenance of relationships between model and code elements. To deal with such challenge, we propose an approach that leverages model-to-text transformation traceability techniques to create relationships required to measure model coverage achieved with test cases executions. We illustrate the approach by applying it to a small ATM example.

Toward Architecture Evaluation through Ontology-Based Requirements-Level Scenarios

A data processing system is disclosed in which a high-speed processor is added to a slow-speed processor and in which both processors have access to a first memory unit with the slow processor having access priority over the fast processor. In order to allow the fast processor to operate without losing data when a conflict occurs during a write operation, a second memory is coupled to the fast processor in which is stored all the data stored in the first memory. When the fast processor attempts to write into both memories but fails to write into the first memory due to a conflict with the slow processor, the data stored in the second memory is then transferred to the first memory subsequent to the completion of the access operation by the slow processor. This arrangement allows the fast processor to complete the write operation interrupted by the conflicts with the slow processor, thereby allowing the fast processor and the slow processor to have access to the same data. Both memories are continuously balanced by the fast processor so that each memory will contain the same data allowing both processors access to the same data.