Software Testing of NoTA DIP
Implementation
2009-09-23
•
Flander, Ardites and Symbio Group merged
and as a result Symbio was established
Software Testing of NoTA DIP
Implementation
Ville Kankainen symbio.com 2009-10-01
Agenda
•
Device Interconnet Protocol (DIP) stack
•
Testing DIP implementation
•
General•
Low level•
High level•
Test applications•
Conclusions
•
Questions, feedback
Device Interconnect Protocol
stack (DIP)
Tester Application Device A ref H_IN ref L_IN up L_IN down L_IN down ref L_IN upDevice Interconnect Protocol
stack (DIP)
•
H_IN (High interconnect)• Provides user API, to discover, to access and to communicate
between processes (Nodes)
Tester Application Tester Service Device A ref L_IN up L_IN down L_IN down ref L_IN up ref H_IN ref H_IN
Device Interconnect Protocol
stack (DIP)
•
H_IN (High interconnect)• Provides user API, to discover, to access and to communicate
between processes (Nodes)
•
L_IN (Low interconnect)• Up and Down parts
• L_INup is responsible of managing
connections Tester Application Device A ref H_IN ref L_IN up L_IN down L_IN down ref L_IN up
Device Interconnect Protocol
stack (DIP)
•
H_IN (High interconnect)• Provides user API, to discover, to access and to communicate
between process (Nodes)
•
L_IN (Low interconnect)• Up and Down parts
• L_INup is responsible of managing
connections
• L_INdown is responsible of
providing connections over target bearer technology Tester Application Tester Service Device A ref H_IN ref L_IN up L_IN down L_IN down ref H_IN ref L_IN up
Testing DIP implementation
•
Testing is divided into two parts
• System testing of L_INdown through L_INdown interface
Tester Application Device A ref H_IN ref L_IN up L_IN down L_IN down ref L_IN up
Testing DIP implementation
•
Testing is divided into two parts
• System testing of L_INdown through L_INdown interface • System testing of DIP through
H_IF API interface
• (dependency on L_INdown) Tester Application Tester Service Device A ref H_IN ref L_IN up L_IN down L_IN down ref H_IN ref L_IN up
Testing DIP implementation
•
Testing is divided into two parts
• System testing of L_INdown through L_INdown interface • System testing of DIP through
H_IF API interface
•
Same test applications can be
utilitilized again
Tester Application Device A ref H_IN ref L_IN up L_IN down L_IN down ref L_IN upTesting DIP implementation
•
Testing is divided into two parts
• System testing of L_INdown through L_INdown interface • System testing of DIP through
H_IF API interface
•
Same test applications can be
utilized again
•
Testing is modularized for easy
verification for each component
Tester Application Tester Service Device A ref H_IN ref L_IN up L_IN down L_IN down ref H_IN ref L_IN up
Tester Application Device A ref H_IN ref L_IN up L_IN down L_IN down ref L_IN up
•
Test is executed on L_INdown levelTesting of DIP
Testing of DIP
(l_down_IF)
•
Test is executed on L_INdown level•
Tests are run by LD_TESTER• Scene discovery
• Address resolution
• Socket connection creation
• Socket features and speed
Device A
LD_TESTER client
L_IN down
L_IN down
Testing of DIP
(l_down_IF)
•
Test is executed on L_INdown level•
Tests are run by LD_TESTER• Scene discovery
• Address resolution
• Socket connection creation
• Socket features and speed
•
Made with C language to supportDevice A
LD_TESTER client
L_IN down
Testing of DIP
(l_down_IF)
•
Test is executed on L_INdown level•
Tests are run by LD_TESTER• Scene discovery
• Address resolution
• Socket connection creation
• Socket features and speed
•
Made with C language to support variety of platforms•
Requires two devices having the same L_INdown implemented onDevice A Device B LD_TESTER client L_IN down L_IN down LD_TESTER server
Testing of DIP
(l_down_IF)
•
L_IN down is now trusted to beworking and it can be used to verify rest of the stack
Device A
LD_TESTER client
L_IN down
Testing of DIP
(H_IF 1/4) loopback
•
Communication between local processes through H_IF•
Local communication is provided by• Single process implementation
• Daemon implementation
• (Kernel – userspace implementation)
•
Ensures that the target service can be tested on target hardware• H_IN interface available during
Test A Tester Service Device A ref H_IN ref L_IN up L_IN down L_IN down ref H_IN ref L_IN up Test S
Testing of DIP
(H_IF 2/4) two stacks, one process
•
Two full stacks in one process•
Testing of full stacks in target hardware without implementing L_INdown•
Testing of NoTA approach in target hardware•
Done with the single processTester Application Process A ref H_IN ref L_IN up Single process L_IN down ref L_IN up
Testing of DIP
(H_IF 3/4) two stacks, two devices
•
Tests the integration of DIP
stacks in both devices
•
Ensures compatibility between
devices
•
Connected through target
L_INdown technology
Tester Application Tester Service Device A ref H_IN ref L_IN up L_IN down L_IN down ref H_IN ref L_IN upTesting of DIP
(H_IF 4/4) testing non-reference stack
•
Non-reference stack is required for the most optimal way to use the platform• Reference stack is using too much system resources (e.g. threads, memory)
• Reference stack has ”unnecessary” features and stack can be reduced for particular purpose
•
Non-reference stack is verified against reference stack using reference testcases• Reference stack is also verified against
Tester Application Device A ref H_IN ref L_IN up L_IN down L_IN down Vendor’s H_IN + L_INup
Testing of DIP
(H_IF test applications)
•
H_IN Reference test applications• Service registeration
• Service discovery
• Service access
• Connection throughput and roundtrip
• Stress testing
•
Service specific test application
•
Model based test applications
Tester Application Tester Service Device A ref H_IN ref L_IN up L_IN down L_IN down Vendor’s H_IN + L_INup
Testing of DIP
(H_IF) conclusions
•
Stacks are verified within different combinations of network•
Different HW combinationscan be verified with reference and non-refetence stacks•
Test applications can be reused in all of the combinations•
Test applications to particularTester Application Device A ref H_IN ref L_IN up L_IN down L_IN down Vendor’s H_IN + L_INup
