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.)

Example: Integrated Electronic Technical Manual Architecture

Data Access

IETM Electronic Display System (EDS)

IETM Data User Interface

Business Services User ServicesData Services

IETM Object Model IETM Object

Model Interfaces

UML Component Diagram

Detailed Design Class Diagram of he IETM Object Model Component

IETM Object Model

NODE-ALTS

Nodes : NODE

Eval_Alts()

<<Stereotype>>

NODE

name : CDATAtype : CDATAitemid : CDATApreconditions [0..*] : precondpostconditions [0..*] : postcondContents : InformationContent-Formsprimitives [0..*] : %primitivelinks [0..*] : %link

Display()Set_Post_Conditions()Eval_Pre_Conditions()hasContents()

<<Stereotype>>

1 1..*1 1..*

InformationContent-Forms

1

0..*

1

0..*LOOP-NODE

IndexDeclare [0..1] : assertionExitCond : expressionIndexAlter [0..1] : assertionRepeatSeq : NODE-SEQ

Start()Eval_Condition()Update_Index()Terminate()

<<Stereotype>>

Architectural-Forms

id : IDcdm : NAMEref : IDREF

IF-NODE

Condition : expressionThenSeq : NODE-SEQElseSeq [0..1] : NODE-SEQ

selectFlow()getThenSeq()

<<Stereotype>>

NODE-SEQ

SeqElements : Architectural-Forms

getNextElement()

<<Stereotype>>

1

1

1

1

1

1..*

1

1..*

stepBack()hasMoreElements()Reset()

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 StateChartThe State Pattern canbe 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


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


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

Stub Stub StubDataModule

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

Inputs Outputs

Module under testIs 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)


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 analysisdevelop test cases at the boundaries of the possible input ranges (minimum and maximum values)

The above techniques are important for data processing intensive applications


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 module2. 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


Symbols used in the cause-effect graphsci = ith cause, ei = ith effect

ci ei ci ei

Ci causes ei Ci does Not cause ei

ci ei

cjOR

ci ei

cj AND


Example: Control motion module in the automated train sodware project (assume the module inputs are a state variable and a control input)

1. List and label all Causes and all effectsCauses Effects

C1: Start e100: Release all BrakesC2: Idle e200: Engage_Engine

C3: speed = Max_speed e300: Disengage_EngineC4:Accelerating e400: Apply Ph. 1 BrakesC5: Speed > Max_speed e500: Release Ph. 1 brakesC6: Coasting e600: Apply Ph. 2 brakesC7: Speed <= Min_speed e700: Apply Safety brakes


Accelerating

Coasting Decelerating

Idle

stopping

Start / Rlease all Braks Engage Engine

Speed = Max_speed /Disengage_Engine

Speed > Max_speed /Apply Ph. 1 brakes

This List is obtained form the following STD

Stop /

Applying ph II

Speed <=Min_speed/EngageEngine

Speed = Stopping_Speed


c1 e10

c2

e100

e200

c3 e20

c4

e300

c5 e30

c6

e400e40

c7

Develop a Cause effect graph


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 StateChartMore Elaborate


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 StandardIEEE 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 DocumentsIEEE 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 document 3. 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 Templatetest 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

Documents

Transcript of DETAILED DESIGN, IMPLEMENTATIONA AND TESTING