Model-Based Built-In Tests

Groß, Hans-Gerhard; Schieferdecker, Ina; Din, George

doi:10.1016/j.entcs.2004.12.001

Cited by 11 publications

(4 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Summing up we can say that [2,3,8,11,33,35,36,50,56,62,68,77,78,88,93,95,97] use coverage criteria for the appropriate domain, [38,39,43] use metrics, [34,53] do monitoring of the testing progress, [57,63,74,81] combine different models or other data like usage profiles for doing the assessment of the test process, and [24,73] provide useful information, i.e. suggestions for the best integration order strategy for the tester.…”

Section: Assessment Type (Rq2)mentioning

confidence: 99%

Software paradigms, assessment types and non-functional requirements in model-based integration testing

Häser

Felderer

Breu

2014

Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

Context:In modern systems, like cyber-physical systems, where software and physical services are interacting, safety, security or performance play an important role. In order to guarantee the correct interoperability of such systems, with respect to functional and non-functional requirements, integration testing is an effective measure to achieve this. Model-based testing moreover not only enables early definition and validation, but also test automation. This makes it a good choice to overcome urgent challenges of integration testing. Objective: Many publications on model-based integration testing (MBIT) approaches can be found. Nevertheless, a study giving a systematic overview on the underlying software paradigms, measures for guiding the integration testing process as well as non-functional requirements they are suitable for, is missing. The aim of this paper is to find and synthesize the relevant primary studies to gain a comprehensive understanding of the current state of model-based integration testing. Method: For synthesizing the relevant studies, we conducted a systematic literature review (SLR) according to the guidelines of Kitchenham. Results: The systematic search and selection retrieved 83 relevant studies from which data has been extracted. Our review identified three assessment criteria for guiding the testing process, namely static metrics, dynamic metrics and stochastic &random. In addition it shows that just a small fraction considers non-functional requirements. Most approaches are for component-oriented systems. Conclusion: Results from the SLR show that there are two major research gaps. First, there is an accumulated need for approaches in the MBIT field that support non-functional requirements, as they are gaining importance. Second, means for steering the integration testing process, especially together with automation, need to evolve.

show abstract

Section: Assessment Type (Rq2)mentioning

confidence: 99%

Software paradigms, assessment types and non-functional requirements in model-based integration testing

Häser

Felderer

Breu

2014

Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

show abstract

“…There are works focusing on improving simulation testing [24]- [26] and model-driven performance testing [27]. An idea borrowed from the computer hardware industry [28], the builtin test enabled components [29]- [31], is to have a functionally separate maintenance mode to provide access to Built-In Tests (BITs). Using test-wrappers is another common approach that works along with the BIT approach to envelop the software component in a single or multi-layer software wrapper that is transparent to both the component being tested and its peers in the environment.…”

Section: Introductionmentioning

confidence: 99%

“…According to our experience of working with robots in the service robot industry, community-driven models with a special focus on Component-Based Software Development (CBSD) works best for the development of the robotic software component. Although there exist several Model-Based Engineering (MDE) approaches for software development in general [31], [33]- [37], approaches with a special focus on the robotic industry are essential for the growth of the robotics industry (Multi-annual roadmap [38], the European SPARC Robotics [39] initiative). One such effort towards creating an ecosystem for model-driven and component-based development of robotic software is the EU H2020 RobMoSys: Composable Models and Software for Robotics [40], [41] project.…”

Section: Introductionmentioning

confidence: 99%

SmartTS: A Component-Based and Model-Driven Approach to Software Testing in Robotic Software Ecosystem

Nagrath¹,

Schlegel²

2021

IJACSA

View full text Add to dashboard Cite

Validating the behaviour of commercial off-theshelf components and of interactions between them is a complex, and often a manual task. Treated like any other software product, a software component for a robot system is often tested only by the component developer. Test sets and results are often not available to the system builder, who may need to verify functional and non-functional claims made by the component. Availability of test records is key in establishing compliance and thus selection of the most suitable components for system composition. To provide empirically verifiable test records consistent with a component's claims would greatly improve the overall safety and dependability of robotic software systems in open-ended environments. Additionally, a test and validation suite for a system built from the model package of that system empirically codifies its behavioural claims. In this paper, we present the "SmartTS methodology": A component-based and model-driven approach to generate modelbound test-suites for software components and systems. SmartTS methodology and tooling are not restricted to the robotics domain. The core contribution of SmartTS is support for test and validation suites derived from the model packages of components and systems. The test-suites in SmartTS are tightly bound to an application domain's data and service models as defined in the RobMoSys (EU H2020 project) compliant SmartMDSD toolchain. SmartTS does not break component encapsulation for system builders while providing them complete access to the way that component is tested and simulated.

show abstract

“…It is also possible to write or generate the tests in a notation dedicated to testing, such as TTCN-3 or the UML Testing Profile, and then have a generic tester component read these specifications and run the tests [12].…”

Section: The Atlas Frameworkmentioning

confidence: 99%

Architecture support for runtime integration and verification of component-based Systems of Systems

González

Piel

Groß

2008

2008 23rd IEEE/ACM International Conference on Automated Software Engineering - Workshops

Self Cite

View full text Add to dashboard Cite

Model-Based Built-In Tests

Cited by 11 publications

References 7 publications

Software paradigms, assessment types and non-functional requirements in model-based integration testing

Software paradigms, assessment types and non-functional requirements in model-based integration testing

SmartTS: A Component-Based and Model-Driven Approach to Software Testing in Robotic Software Ecosystem

Architecture support for runtime integration and verification of component-based Systems of Systems

Contact Info

Product

Resources

About