Please enable JavaScript.
Coggle requires JavaScript to display documents.
integration and component-basad Software Testing - Coggle Diagram
integration and component-basad Software Testing
Integration fault
Inconsistent interpretation of
parameters or values
Violations of value domains or
of capacity or size limits
Implicit assumptions on ranges of
values or sizes
Side-effects on parameters or
resources
integration problems arise when these implicit effects
of one module interfere with those of another.
Missing or misunderstood
functionality
Nonfunctional problems
Dynamic mismatches
problems may be caused by failures in machings when modules are integrated
Testing Components and Assemblies
Terminology for Components and Frameworks
Component contract or interface
Component
A software component is a reusable unit of deployment and composition that is deployed and integrated multiple times and usually by different teams
types
Components typically use persistent storage
Components may be accessed by an extensive set of communication mechanisms
Components are usually larger grain subsystems than objects
Framework
A framework is a micro-architecture or a skeleton of an application
Frameworks and design patterns
Patterns are logical design fragments
Component-based system
based system is a system built primarily
connected through a framework or ad hoc “glue code.
a software component is characterized by
contract or application program interface
API
integration testing strategies
Incremental testing is preferred, first, to provide the earliest possible feedback on integration problems
the build plan
Memory Leaks
are typical of program faults that often escape module testing
strategies for incrementally testing
structural and feature oriented
modules are constructed, assembled, and tested together in an order based on hierarchical structure in the design
Top-down and bottom-up strategies
consist in sorting modules according to the use/include relation
and in starting testing from the top or from the bottom of the hierarchy, respectively
Open Research Issues
One research thread considers how dynamic analysis of components and component-based systems in one environment can produce useful information for assessing likely suitability
System, Acceptance, and
Regression Testing
System Testing
g can be considered the culmination of integration testing
test cases can be devised during development to check for observable symptoms of failures that were not anticipated in the initial system specification
type
Test cases
derived from
architecture and design specifications
requirements specification
module specifications
Visibility
required
some details of the code, mainly interfaces
no details of the code
all the details of the code
Scaffolding
required
Potentially complex
Depends on architecture and integration order
Mostly limited to test oracles
Focus on
module integration and interaction
system functionality
behavior of individual modules
Acceptance Testing
acceptance testing is to guide a decision as to whether the product in its current state should be released
operational profile
sensitivity testing
alpha and beta test
An early version of the product
the user sample determines the operational profile
Usability
main steps
Testing early prototypes
h end users to explore their mental mode
Inspecting specifications
with usability checklists
Testing incremental releases
System and acceptance testing
exploratory testing
It consists of asking users about their approach to interactions with the system
Regression Testing
Test case prioritization orders frequency of test case execution
are based on either code or specifications
control flow
are based on the differences between the CFGs of the new and old versions of the software
data flow
reexecute test cases