View
40
Download
0
Category
Tags:
Preview:
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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
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
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)
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 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
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 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
Software Testing Techniques
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
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)
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
Software Testing Techniques
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
Software Testing Techniques
c1 e10
c2
e100
e200
c3 e20
c4
e300
c5 e30
c6
e400e40
c7
Develop a Cause effect graph
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 StateChartMore 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 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"
Recommended