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

Slides:



Advertisements
Similar presentations
Software Testing Techniques
Advertisements

Software Testing. Quality is Hard to Pin Down Concise, clear definition is elusive Not easily quantifiable Many things to many people You'll know it when.
DETAILED DESIGN, IMPLEMENTATIONA AND TESTING Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
1 Integration Testing CS 4311 I. Burnstein. Practical Software Testing, Springer-Verlag, 2003.
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
IFS310: Week 3 BIS310: Structured Analysis and Design 5/4/2015 Process Modeling and Data Flow Diagrams.
Traditional Approach to Design
Chapter 10 The Traditional Approach to Design
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
Testing an individual module
The Software Development Standards Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
Traditional Approach to Requirements Data Flow Diagram (DFD)
Chapter 6: The Traditional Approach to Requirements
Systems Analysis and Design in a Changing World, Fifth Edition
Chapter 6 The Traditional Approach to Requirements
Systems Analysis and Design in a Changing World, Fifth Edition
1 Software Testing (Part-II) Lecture Software Testing Software Testing is the process of finding the bugs in a software. It helps in Verifying and.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
CMSC 345 Fall 2000 Unit Testing. The testing process.
Software Testing.
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
The Software Development Standards Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Overview of Software Testing 07/12/2013 WISTPC 2013 Peter Clarke.
4/2/03I-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Software Architecture and Design Readings: Ambler, Chap. 7 (Sections to start.
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
UML Diagrams: Sequence Diagrams The Requirements Model, and The Dynamic Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical.
Software Testing. 2 CMSC 345, Version 4/12 Topics The testing process  unit testing  integration and system testing  acceptance testing Test case planning.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
Black-box Testing.
INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES BY PRADEEP I.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
UHD::3320::CH121 DESIGN PHASE Chapter 12. UHD::3320::CH122 Design Phase Two Aspects –Actions which operate on data –Data on which actions operate Two.
1 6 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 6 The Traditional Approach to Requirements.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
Design Methods Instructor: Dr. Jerry Gao. Software Design Methods Design --> as a multistep process in which we design: a) data structureb) program structure.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Software Testing and Quality Assurance 1. What is the objectives of Software Testing?
Architectural Design Introduction Design has been described as a multistep process in which representations of data and program structure,
Theory and Practice of Software Testing
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
Chapter 1 Software Engineering Principles. Problem analysis Requirements elicitation Software specification High- and low-level design Implementation.
Dynamic Testing.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Architectural Complexity  A useful technique for assessing the overall complexity of a proposed architecture is to consider dependencies between components.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Systems Analysis and Design in a Changing World, Fourth Edition
Testing Tutorial 7.
Chapter 6 The Traditional Approach to Requirements.
How Systems are Developed
Software Testing.
Software Testing Techniques
Software Engineering (CSI 321)
Quality Management Perfectqaservices.
Chapter 13 & 14 Software Testing Strategies and Techniques
Unit Test: Functions, Procedures, Classes, and Methods as Units
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
Chapter 10 – Software Testing
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Chapter 13 & 14 Software Testing Strategies and Techniques 1 Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Presentation transcript:

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

OUTLINE 2 Detailed design, Implementation, and testing phase in the software development standards Software Testing Black Box Testing White Box Testing

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

Detailed design, Implementation, and Testing 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.) 4

Decomposition of low-level components ◦ Example: Process Pilot Request subsystem Example: Process Pilot Request subsystem Specify the detailed design of subordinate modules of Process_Pilot_Request Specify how buffers are structured (the data structures of the buffers used for inputs and outputs) 5

Detailed design, Implementation, and Testing Software production 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, integration testing, and system testing. 6

Detailed design, Implementation, and 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 7

Detailed design, Implementation, and 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 8

Detailed design, Implementation, and 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) 9

Software Testing What is Software Testing? Is the process of executing a program with an established set of test cases. Test cases are generated according to a well defined procedures or techniques. Testing is a bottom-up process, starts with unit testing, components testing, CSCI testing. 10

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

Software Testing The test driver is developed based on a 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 12

Software Testing Testing techniques consist of ◦ Black Box testing, where we focus on testing the software functional requirements, and testing the input/output interfaces 13 Inputs Outputs Module under test is treated as a Black Box

Software Testing ◦ White Box Testing, where we focus on developing test cases to cover the logical paths through the code (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 14

Software Testing 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 15

Software Testing 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 16

Software Testing 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 4. Convert each row into a test case, or a set of rows into a testing scenario 17

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

Software Testing Example: Control motion module in our project (assume the module inputs are a state variable and a control input) List and label all Causes and all effects CausesEffects C1: Start_traine100: Release all Brakes C2: Idle e200: Engage_Engine C3: speed = Max_speed e300:Disengage_Engine C4:Acceleratinge400: Apply Ph. 1 Brakes C5: Speed > Max_speede500: Release Ph. 1 brakes C6: Coastinge600: Apply Ph. 2 brakes C7: Speed <= Min_speede700: Apply Safety brakes 19

Software Testing 20 Accelerating CoastingDecelerating Idle stopping Start / RL all Br Engage Engine Speed = Max_speed / Disengage_Engine Speed > Max_speed / Apply Ph. 1 brakes Stop / Applying ph II Speed <= Min_speed/ Engage Engine This List is obtained from the following C-spec STD

Software Testing Develop a Cause-effect graph 21 c1 e10 c2 e100 e200 c3e20 c4 e300 c5e30 c6 e400 e40 c7

Software Testing Develop a Decision Table C1 C2 C3 C4 C5 C6 C7 e100 e200 e300 e Convert each row to a test case 22

Software Testing Scenario testing: A testing scenario combines a set of test cases for testing the system behavior over a period of time For example the following sample run can be used for scenario testing Start,idle ; speed = max_speed, Accelerating; Speed Max_speed, Coasting; 23