What makes one software architecture more testable than another?

Path coverage technology in software architecture is a structural testing method that involves using the architecture elements to attempt to find every possible executable path. In this paper we present an approach together with an experimental tool for qualifying tests. Firstly, this method describes software architecture with linear temporal logic specification, secondly, transform the architecture specification to architecture interface connectivity graph (ICG) to indicate the computation of the single component and the transfer, thirdly, based on ICG path coverage criteria and path coverage generation algorithm, generate tested path. This approach is implemented in the LTL Tool. Finally, the criteria is assessed, the assessing result provide a theoretical basis for applying the criteria.

show abstract

“…We only present here those test paths presented in [4,5] which can be applied at ICG graph in table Ⅰ, Ⅱ . …”

Section: A Path Coverage and Testing Criteriamentioning

confidence: 99%

Investigating Subsumption Relationship on Path Coverage Criteria for Software Architecture Testing

Lun

Chi

2010

2010 International Conference on Computational Intelligence and Software Engineering

View full text Add to dashboard Cite

show abstract

“…Lakos [27] discusses the effect of system structure on testability and describes a related metric on system level. The relationship between software architecture and testing has been explored in [12]. The SEI provides a set of general-scenariogeneration tables for testability and discusses architectural tactics for testability [4].…”

Section: Related Workmentioning

confidence: 99%

Making testing product lines more efficient by improving the testability of product line architectures

Kolb

Muthig

2006

Proceedings of the ISSTA 2006 Workshop on Role of Software Architecture for Testing and Analysis

View full text Add to dashboard Cite

Product line engineering is a recent approach to software development that has shown to enable organizations to achieve significant reductions in development and maintenance cost as well as time-to-market of increasingly complex software systems. Yet, the testing process has not kept up with these reductions and the relative cost for testing product lines is actually becoming higher than in traditional single system development. Also, testing often cannot keep pace with accelerated development in product line engineering due to technical and organizational issues. This paper advocates that testing of product lines can be made more efficient and effective by considering testability already during architectural design. It explores the relationship between testability and product line architecture and discusses the importance of high testability for reducing product line testing effort and achieving required coverage criteria. The paper also outlines a systematic approach that will support product line organizations in improving and evaluating testability of product lines at the architectural level

show abstract

“…The rule-based approach described accommodates a wider range of state-transition formalisms than the execution semantics of the inframodel controlled through a limited set of parameters, described in [PY96] Software testing expends as much as 50% of software development costs and comprises up to 50% of development time, yet most of the research in software architectures marginalizes the importance of testing in relation to architectural design decisions. [ER96c] stated the belief that testing has a dual role in software architectures: defect prevention and defect detection. How effectively testing fulfills its roles is dependent on three criteria: matching of software architecture to test strategy, the ability to detect certain fault types given a specific test strategy, and the interaction of software architecture, test strategies, and fault detection.…”

Section: Concurrency Analysismentioning

confidence: 99%

Research in Advanced Environments

Taylor¹,

Richardson²,

Selby³

et al. 2001

Self Cite

View full text Add to dashboard Cite

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of informetion, including suggestions for reducing this burden, ObjectiveThe fundamental objective of Arcadia was to develop technically rich solutions across the breadth of the problem (developer support, product architectures, tool technologies) that are technically compatible, functionally comprehensive, and mutually reinforcing.Active process support was developed to help human developers, including non-technical managers, coordinate their activities while integrating commercial project planning tools. Analysis and testing tools were developed to provide high assurance in software, through provision of pre-run-time analyses, test case development, test result checking, and test process management tools. Powerful program analysis tools were developed which enable early detection of subtle coordination errors in concurrent systems composed of heterogeneous parts. Evolvable software architectures, first in the domain of user interface software, were developed to enable a more component-based software economy. World-Wide-Web and hypermedia technology were developed to foster easy information access, connections between software artifacts, and human understanding of complex systems. ApproachProcedurally, the Arcadia project's approach was one of iteration, prototyping, and integration. Emphasis was placed on identification of principles that transcend idiosyncratic implementations. The integrating environment conceptual architecture was based on a set of coherent principles iteratively refined through experience with the prototype component implementations. Specific technology transition efforts with various consumers were used to validate the technology in actual practice situations. Separate technologies were first prototyped, then pair-wise integrations performed, then multi-way integrations.The work in distributed, team-oriented software development was focused on determining effective ways of explicitly describing team-based activities, determining which parts of those activities could best be supported by automated tools, and technologies were developed to perform that automation. A critical aspect of this work was developing an effective basis for management of projects over the net; consequently, a distributed architecture implemented in Java was adopted. In a nutshell, this was research targeted at the intersection of software process research and computer-supported cooperative work (CSCW)/Groupware research. Specific technical innovation came from support for non-technical users, techniques supporting two-way integration with commercial project planning and communication tools, and support for reuse and adaptation of process fragments.

show abstract

What makes one software architecture more testable than another?

Cited by 12 publications

References 8 publications

Investigating Subsumption Relationship on Path Coverage Criteria for Software Architecture Testing

Investigating Subsumption Relationship on Path Coverage Criteria for Software Architecture Testing

Making testing product lines more efficient by improving the testability of product line architectures

Research in Advanced Environments

Contact Info

Product

Resources

About