Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > T&M

The need for software component testing

Posted: 29 Jul 2009     Print Version  Bookmark and Share

Keywords:software  component test  embedded system test 

While testing is most often regarded as a detective measure of quality, it is closely related to preventive and corrective measures. In practice, software developers usually find it more productive to enact testing and debugging together, usually as an interactive process.

This article addresses the need for the software component testing in embedded systems because software now makes up 90 per cent of the value of the embedded system devices. More so, the software architecture of the embedded system devices, in most cases, is componentised in nature.

Further to add, at the system level, embedded system devices are extremely hard to test and the defects detected are more complicated to debug and fix at the system level.

Hence, if the software part is tested first by implementing component testing, the software components are ensured to be with minimal defects or with no critical defects when the system testing phase begins.

To settle on a common set of concepts, let�s start with some definitions:

Embedded system—It�s difficult and highly controversial to give a precise definition of embedded system. So, here are some examples. Embedded systems are in every �intelligent� device that is infiltrating our daily lives: the cell phone in your pocket and the entire wireless infrastructure behind it; the Palm Pilot on your desk; the Internet router your e-mails are channeled through; your bigscreen home theatre system; the air traffic control station as well as the delayed aircraft it is monitoring.

Software component—This is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

Software component testing—Component testing is the act of subdividing an object-oriented software system into units of particular granularity, applying stimuli to the component�s interface and validating the correct responses to those stimuli, in the form of either a state change or reaction in the component, or elsewhere in the system.

Before discussing the relevance of software component testing in embedded systems, let us discuss the high level features that the software component architectures offer. The features of software component architectures are the following: organised; loosely coupled; support event bus model; maintainable; reusable; and extensible.

All of these features make software component architectures an ideal place for software development in embedded system devices. Having said that, it is imperative that the testing of such software that conforms to a componentised architecture should take the advantage of its architectural benefits to test early and test efficiently.

To illustrate briefly the need for doing software component testing in embedded systems, let us consider the following scenario: Let us assume that there is an embedded system device under development, which follows a componentised architecture. The software development is in iterative fashion. The classes that make up a software component are unit-tested while development during the same iteration and system tested at the end of the iteration.

The system test defects of the earlier iteration are fixed in the next adjacent iteration(s). This development model seems to work just as defined because it follows an iterative and incremental approach. However, there is one basic flaw with this approach.

image name

Figure 1: Unlike system tests, the software component tests don�t just rely on the System Requirement Specification (SRS) and/or use cases as the input.

The flaw is that the defects induced during iteration are fixed in the next adjacent iteration(s). This is termed as a flaw because it is the number of defects found and the criticality of the defects detected in the earlier iteration that defines the amount of time it would take to fix those defects in the next adjacent iteration(s). This causes an undue delay in the software development. Such a delay is hard to predict and difficult to plan.

This flaw can be overcome by doing software component testing as and when the software components are developed. The software components are tested in isolation and also in conjunction with other components, as integration tests.

As seen from the �V� development paradigm in Figure 1, unlike system tests, the software component tests don�t just rely on the system requirement specification (SRS) and/or use cases as the input.

image name

Figure 2: After the individual classes that make up a component are unit tested and after the unit tests are successful, the SW Component test stage begins.

The inputs required for the software component tests are:

� SRS—To understand the basic functionality of the software components;
� Software design document—To understand how many software components exist in the system and how they collaborate with each other as a system;
� Software realisation—In terms of sequence diagrams to understand the sequence of messages and/or events through which the components collaborate with each other for a given functionality. Software component tests are just a replica of these sequence diagrams from the functionality verification perspective.

1 • 2 • 3 Next Page Last Page

Comment on "The need for software component test..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top