May08-21 Model-Based Software Development Kevin Korslund Daniel De Graaf Cory Kleinheksel Benjamin Miller Client – Rockwell Collins Faculty Advisor – Dr. Suraj Kothari

May08-21 Model-Based Software Development  Component-level Testing  System Testing  User Testing

May08-21 Model-Based Software Development Component-Level Testing  White-box unit testing of each class and method Boundary-value tests every method and verifies results Tests at the class level and lower Tests relationships between classes with mock objects  All tests must pass or test suite will fail If any test does not pass, the bug will be recorded using Bugzilla  Test suite will run all unit tests automatically, and be run as part of a standard software build

May08-21 Model-Based Software Development Component-Level Testing  Unit tests use JUnit framework  Class relationships are tested using EasyMock mock object framework  Tests are run from within the Eclipse environment A special Eclipse Plug-in test launcher starts a new Eclipse environment and runs tests The test runner creates the Eclipse CDT project under test and copies relevant files in for the current test

May08-21 Model-Based Software Development Component-Level Testing  Results About 15% complete Tests cover all found bugs to verify they will not happen again Creation of bug reports in Bugzilla  Analysis JUnit test runner outputs total number of tests and number of passing tests Analyze percentage of passing tests 100% of tests pass right now

May08-21 Model-Based Software Development Component-Level Testing  Conclusion Areas of code that pass tests match expected component behavior Additional Component-level testing is required

May08-21 Model-Based Software Development System-level Testing  Subsystems to test Parser Matcher Connector Splitter Outputter

May08-21 Model-Based Software Development System-level Testing - Metrics  Parser CommentedStatement lists  Matcher BlockPieces  BlockConnector Block list

May08-21 Model-Based Software Development System-level Testing - Metrics  ModelSplitter System  MdlOutput “.mdl” file output

May08-21 Model-Based Software Development System-level Testing - Procedure  Subsystem output is not serializable Cannot directly save stage outputs for later use in comparisons Means subsystems cannot be tested individually  Instead, save enough information from each output to be able to verify correctness Saved information is compared after each stage using JUnit while running the system as a whole

May08-21 Model-Based Software Development System-level Testing - Analysis  Junit will fail on the first subsystem that fails To test subsystems that follow a failed subsystem, we can revert the code for that subsystem to a known good state  On failure, JUnit will report the point of failure We can then use the Eclipse debugger to investigate the problem

May08-21 Model-Based Software Development User Testing  Alpha tests Executed daily during implementation Advisor and Graduate Students also involved in Alpha test phase  Beta tests Executed during project demonstration for Rockwell Collins Client

May08-21 Model-Based Software Development User Testing  The operational Eclipse Plug-in will be tested by: Execution of Eclipse plug-in on C files Examine model outputted Expect model to be similar or match the model the C file was created from

May08-21 Model-Based Software Development User Testing  Test Method Design models to exercise various and specific areas of the plug-in and requirements Generate C files using Real-time Workshop Execution of Eclipse plug-in on C files  Equipment Real-time Workshop Eclipse

May08-21 Model-Based Software Development User Testing  Results Outputted model from Eclipse plug-in Creation of bug reports in Bugzilla  Analysis Manual comparison of original model to outputted model  Conclusions Based on bugs found and Analysis phase

May08-21 Model-Based Software Development  Component-level Testing  System Testing  User Testing