DETAILED DESIGN, IMPLEMENTATIONA AND TESTING

DETAILED DESIGN, IMPLEMENTATIONA AND TESTING Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

OUTLINE • The Detailed design, Implementation, and testing phase in the software development standards • The ESA standard, and the 498 Standard • Software Testing • Black Box Testing, White Box Testing • Cause-Effect graphing • Scenario-based Testing • Software Testing Documents • The IEEE 829 Standard • Software Testing Document Template

Detailed design, Implementation, and Testing • In the European Space Agency standard, the major activities in this phase include - decomposition and the specification of the low-level software modules. the low-level components specified at the architectural design are decomposed into software modules. - This is followed by software production and documentation:implementing the modules specifications into code, integrating the software components, and the testing activities

Detailed design, Implementation,and Testing in the ESA standard

Detailed Design Phase Activities • Examine the ADD and confirm that it is understandable. • Detailed Design: starts with the major components defined in the ADD, and continues to decompose them until the components can be expressed as simple modules in the selected programming languages.

Detailed Design Decomposition of low-level components - Using stepwise refinement, the low-level components specified at the architectural design are decomposed into software modules, and Library modules (language dependent Application Programming Interfaces APIs, e.g., Microsoft Foundation Classes, Java API packages for Graphical User Interfaces or GUIs, network programming, etc.)

IETM Object Model Interfaces Data Services Business Services User Services Example: Integrated Electronic Technical Manual Architecture UML Component Diagram IETM Object Model

IETM Object Model Detailed Design Class Diagram of he IETM Object Model Component Architectural-Forms id : ID 1..* 1..* cdm : NAME ref : IDREF <<Stereotype>> <<Stereotype>> IF-NODE LOOP-NODE Condition : expression 0..* 0..* InformationContent-Forms IndexDeclare [0..1] : assertion ThenSeq : NODE-SEQ ExitCond : expression ElseSeq [0..1] : NODE-SEQ IndexAlter [0..1] : assertion RepeatSeq : NODE-SEQ selectFlow() getThenSeq() Start() Eval_Condition() Update_Index() Terminate() <<Stereotype>> NODE 1 1 name : CDATA type : CDATA itemid : CDATA <<Stereotype>> preconditions [0..*] : precond 1 1 NODE-ALTS postconditions [0..*] : postcond <<Stereotype>> Contents : InformationContent-Forms Nodes : NODE NODE-SEQ 1..* 1..* 1 1 primitives [0..*] : %primitive links [0..*] : %link SeqElements : Architectural-Forms Eval_Alts() 1 1 Display() getNextElement() Set_Post_Conditions() stepBack() 1 1 Eval_Pre_Conditions() hasMoreElements() Reset() hasContents()

Detailed Design • Decomposition of low-level components (cont.) • In OOD services of relatively complex classes can be delegated to new classes using design patterns to refine the design class design • Complex operations in a class can be refined using stepwise refinements into subordinate simpler operations in the same class (Interface operations depend on private operations), or by delegating these operations to new classes using design patterns

Example: ATM StateChart The State Pattern can be used iteratively

Detailed Design: Decomposition of low-level components • Specify the detailed design of subordinate modules (e.g., class operations) and outline the module processing in a Flow Chart (or UML Activity diagrams), Program Design Language (PDL), or pseudo-code • PDLs and pseudo-code can be included later in the code as comments, easing maintenance, whereas flowcharts cannot. Flowcharts are not compatible with the stepwise refinement technique, and so PDLs and pseudo-code are to be preferred to flowcharts for detailed design. • Specify how buffers are structured (the data structures of the buffers used for inputs and outputs)

Detailed Design: Decomposition of low-level components • Defensive design • Anticipate possible problems and include defenses against them (Exception Handling) • Principles of defensive design: • mutual suspicion; Modules should be designed to handle erroneous input and error reports from other modules. • immediate detection; detect error where they occur in the lower level functions (not at the higher levels of the function call hierarchy)

Implementation, and Testing Software production phase Software production consists of • Implementing the modules specifications into code (structured Programming or object-oriented programming), • Integrating the software components and the testing activities in testing procedures of • Unit testing: testing each software unit • Integration testing: integrating and testing several units, • System testing: testing the whole system

Implementation, and Unit Testing The activities required in the MIL-STD-498 standard for the Software Implementation and Unit Testing (SWIUT) are described as follows: - Develop and document software corresponding to each software unit (CSU) of each software component (CSC) in the CSCI design - Establish test cases (in terms of inputs, expected results, and evaluation criteria), test procedures, and test data for testing the software corresponding to each software unit

Implementation, and Unit Testing • The test cases shall cover all aspects of the unit's detailed design. The developer shall record this information in the appropriate software development files (SDFs) • Test the software corresponding to each software unit. The testing shall be in accordance with the unit test cases and procedures

Implementation, and Unit Testing • Make all necessary revisions to the software, perform all necessary retesting, and update the software development files (SDFs) and other software products as needed, based on the results of unit testing • Analyze the results of unit testing and record the test and analysis results in appropriate software development files (SDFs)

Software Testing What is Software Testing? • Is the process of executing a program with an established set of test cases • A test case is a software testing document, which consists of event, action, input, output, expected result, and actual result (also defined as set of test inputs, executions, and expected results developed for a particular objective) • Test cases are designed according to well defined procedures or techniques • Testing is a bottom-up process, starts with Unit testing (testing each sw unit, Integration testing (testing several components), and System testing

Software Unit Testing Set of test cases Test Driver Module under test Data Module Stub Stub Stub

Software Unit Testing • The test driver is developed based on a design set of test cases • The driver invokes the module under test for each test case and establishes the test case data/control requirements • Stubs are sub-ordinate dummy modules that represent the modules (including global data structures) invoked (or accessed) by the module under test • They contain print and return statements

Software Testing TechniquesDesigning Test Cases • Testing techniques consist of - Black Box testing, where we focus on testing the software functional requirements, and testing the input/output interfaces Outputs Inputs Module under test Is treated as a Black Box

Software Testing Techniques • White Box Testing, where we focus on developing test cases to cover the logical paths through the code Also called Path Testing (e.g., conditional statements, loops, etc.) • Based on developing a control flow graph of the code under test to identify the set of independent paths, and produce a set of test cases to cover these paths (statement coverage, Independent path coverage)

Software Testing Techniques • Black Box Testing Techniques 1. Equivalence Partitioning Partition the input space into equivalence classes and develop a test case for each class of inputs 2. Boundary value analysis develop test cases at the boundaries of the possible input ranges (minimum and maximum values) • The above techniques are important for data processing intensive applications

Software Testing Techniques • Black Box Testing Techniques (cont.) 3. Cause-effect graphing - Used for control intensive applications, - Develops test cases to represent input events (or causes) and the corresponding actions (or effects) • This technique is used intensively in real-time systems

Software Testing Techniques • Cause-effect graphing consists of the following 4 steps 1. List and label causes (input-events) and effects (output actions) for a module 2. Draw a cause-effect graph describing the logical combinations of causes, intermediate causes and resulting effects, 3. Develop a decision table (causes vs effects) from the graph (each raw consists of a combination of causes and the resulting effects) 4. Convert each row into a test case, or a set of rows into a testing scenario

Software Testing Techniques Symbols used in the cause-effect graphs ci = ith cause, ei = ith effect ci ei ci ei Ci causes ei Ci does Not cause ei ci ei ci ei cj cj AND OR

Software Testing Techniques • Example: Control motion module in the automated train sodware project (assume the module inputs are a state variable and a control input) • List and label all Causes and all effects Causes Effects C1: Start e100: Release all Brakes C2: Idle e200: Engage_Engine C3: speed = Max_speede300: Disengage_Engine C4:Accelerating e400: Apply Ph. 1 Brakes C5: Speed > Max_speed e500: Release Ph. 1 brakes C6: Coasting e600: Apply Ph. 2 brakes C7: Speed <= Min_speed e700: Apply Safety brakes

Software Testing Techniques This List is obtained form the following STD Speed > Max_speed / Apply Ph. 1 brakes Coasting Decelerating Stop / Speed <= Min_speed/ Engage Engine Speed = Max_speed / Disengage_Engine Accelerating stopping Speed = Stopping_Speed Start / Rlease all Braks Engage Engine Idle Applying ph II

Software Testing Techniques Develop a Cause effect graph c1 e10 e100 c2 e200 c3 e20 e300 c4 e40 c5 e30 e400 c7 c6

Software Testing Techniques • Develop a Decision Table C1 C2 C3 C4 C5 C6 C7 e100 e200 e300 e400 1 1 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0 1 0 0 0 0 0 1 1 0 1 0 0 • Convert each row to a test case

The same technique can be applied to our ATM project Example State Diagram, Simplified

Example: ATM StateChart More Elaborate

Software Testing Techniques • Scenario testing: Defines a test case that combines a set of simpler test cases for testing the system behavior over a period of time • A design sequence diagram is used to define the scenario and derive the implementation of the test driver • Example: in Control Motion testing, the scanrios can be defined wit the following sequence of inputs Start,idle ; speed = max_speed, Accelerating; Speed < = Min_speed, Coasting; Stop, Accelerating; speed = stop speed; start, Idle; speed = max_speed, Accelerating; speed > Max_speed, Coasting;

Software Testing DocumentsThe IEEE 829 Standard IEEE 829 standard for Software Test Documentation provides documentation guidelines in three distinct phases of software testing • 1. Preparation Of Tests • Test Plan: Plan how the testing will proceed. • Test Design Specification: Decide what needs to be tested. • Test Case Specification: Create the tests to be run. • Test Procedure: Describe how the tests are run. • Test Item Transmittal Report: Specify the items released for testing. • 2. Running The Tests • Test Log: Record the details of tests in time order. • Test Incident Report: Record details of events that need to be investigated. • 3. Completion of Testing • Test Summary Report: Summarize and evaluate tests

Software Testing Documents • IEEE 829 - Test Design Specification (what feature do we want to test?) • Creating the test design is the first stage in developing the tests for a software testing project. It records what needs to be tested, and is derived from the documents that come into the testing stage, such as requirements and designs. It records which features of a test item are to be tested, and how a successful test of these features would be recognized. As an example lets use a Billing project from which the following testing requirements may be defined: • A normal bill can be produced. • A final bill can be produced. • The volume discount is properly calculated. • The test design does not record the values to be entered for a test, but describes the requirements for defining those values

Software Testing Documents IEEE 829 - Test Case Specification (how features will be tested?) • The test cases are produced when the test design is completed. Test cases specify for each testing requirement: • The exact input values that will be input and the values of any standing data that is required, • The exact output values and changes of value of the internal system state that are expected, • And any special steps for setting up the tests. • A feature from the Test Design may be tested in more than one Test Case, and a Test Case may test more than one feature. The aim is for a set of test cases to test each feature from the Test Design at least once. Taking the Billing project example all three requirements could be tested using two test cases: • The first test case could test both that a normal bill is produced and that a volume discount is properly calculated. • A second test case could check that a final bill is produced and a volume discount is calculated

Software Testing Documents,STD Document Template 1. BACKGROUND – This item summarizes the functions of the application system and the tests to be performed.2. INTRODUCTION- The scope of this document, referenced documents, and the organization of this document3. ASSUMPTIONS – Indicates any anticipated assumptions which will be made while testing the application.4. TEST ITEMS - List each of the items (Classes, Program Files) to be tested.5. FEATURES TO BE TESTED - List each of the features (Use-Cases, scenarios, functions, or requirements) which will be tested or demonstrated by the test.6. FEATURES NOT TO BE TESTED - Explicitly lists each feature, function, or requirement which won't be tested and why not. 7. APPROACH - Describe the data flows and test philosophy. 8. TEST CASES – Describe each test case in a subsection as shown in the next slide

Software Testing Documents,STD Document Template test case id: unique number or name test case name: previously selected test case title feature to be tested: the name of the scenario corresponding module functionality test suit id: the name of test batch id, in which batch this case is a member. Priority: the importance of this test case w.r.t functionality (high, low)test environment: required h/w and s/w to execute these test cases. Pre-condition: necessary tasks to do before starting the test execution test procedure/log: a step by step procedure to execute this test case, step no. , Action , i/p required, expected result, actual result, comment test case pass / fail criteria: when this case is "pass", when this case is "fail"

DETAILED DESIGN, IMPLEMENTATIONA AND TESTING