Biomedical Engineering Reference
In-Depth Information
must be enumerated to permit proper allocation to the
different test phases and the specific tests.
The initial analysis of the SRS involves determining
where to test a particular requirement. Where a re-
quirement is tested is often based on the capabilities of
the test fixture used in validation. Usually, most re-
quirements can be tested at the validation level. The
balance of the requirements is then tested during in-
tegration or unit testing. In general, a requirement that
has external stimulus (to the central processing unit
(CPU)) and the ability to monitor externally are done at
the validation level. Exceptions to this are conditions
that might require very specific timing, and that timing
is calculated internally to the CPU.
Requirements that are tested during integration or
unit testing are typically those that cannot be tested
sufficiently during validation testing. Testing a ''software
watchdog error'' requirement is good example of a re-
quirement tested during integration or unit testing. In
this case, the software is monitoring itself, and there is no
external means to cause the fault.
The second step of the requirements analysis phase is
to determine the best way to group the requirements into
tests. One relatively straightforward approach to doing
this is to create tests based on sections in the SRS. Typ-
ically, a section in an SRS will describe a feature almost
fully. By following the SRS format, the tests then are
developed by feature, which is a logical approach. Of
course, there will be requirements in the SRS where this
approach will not apply. In such cases, further analysis
must be done to assess whether additional tests should be
created, or whether one of these ''special'' requirements
can be allocated into those tests that follow the SRS.
As mentioned at the beginning of this section, control
procedures from the risk and hazard analysis should be
written into the SRS. If this is done, then only those risk/
hazard requirements will be analyzed and allocated to
tests just like all other requirements.
Storing the allocation matrix is a final aspect of
requirements allocation to test. It is simple enough to
keep the matrix in a spreadsheet or an electronic docu-
ment. However, it can also be stored in a database. The
advantage of storing it in a database is that a user can
track test development and also can generate numerous
reports.
There are several approaches to unit testing, such as
branch path analysis or module interface testing. In
branch-path analysis, the developer uses a development
tool to step through each path within a unit. In module-
interface testing, the developer tests the unit from
a ''black box'' perspective. Thus, the unit is only tested by
varying the inputs into the software unit.
The type of unit testing that will be required will
depend on many factors. In medical devices, the detailed
branch path analysis testing is usually done against soft-
ware units that are considered to be critical to the safety
of the patient or the user. Other, lesser critical software
units can be justifiably tested using the less thorough
module interface testing.
Integration testing
Integration testing has several definitions. The definition
covers the integration of two or more software units
together. A broader definition covers the integration of
physical subsystems (each with its own embedded soft-
ware) to ensure that they work together.
Either type of integration testing brings separately
developed entities together to ensure that they work
together. The type of testing that is usually performed at
these levels involves writing protocols to exercise the
interface.
Validation testing
Validation testing is the process of proving that the
product meets the product specification. It also can mean
going the extra step and trying to ensure that the product
does not do what it is not supposed to do. Thus, several
approaches to testing are employed to exercise the soft-
ware product. These approaches are discussed below.
Requirements-based testing
Requirements-based testing is the primary approach that
is used to validate software. Essentially, the requirements
from the SRS are analyzed and allocated to specific tests.
Different approaches to testing, such as threshold testing
or boundary testing, are used in developing these tests.
The test steps are the sequential actions that must be
taken to prove that the requirement has been met.
Threshold testing
Threshold testing is the process of proving that an event
will occur when a specified parameter exceeds a certain
value. An alarm, such as a low-battery alarm, is a good
example of this on a medical device. If the device is
running on a battery, and the voltage level in the battery
falls below a threshold level, then an alarm is enunciated.
In these types of tests, a tolerance band is placed around
the threshold level. The tolerance is determined by the
Testing phases and approaches
Unit testing
Unit testing is performed on a smallest amount of code.
What comprises a ''unit'' is often the subject of lengthy
discussion and debate. No matter how a unit is defined,
the intent of unit testing is to ensure that the lowest-level
software modules are tested.
