Testing Theory. Agenda - What will you learn today? A Software Life-cycle Model Which part will we talk about today? Theory Lecture Plan

Size: px
Start display at page:

Download "Testing Theory. Agenda - What will you learn today? A Software Life-cycle Model Which part will we talk about today? Theory Lecture Plan"

Transcription

1 heory Lecture Plan 2 esting heory Lecture 8 Software Engineering DDC88/DDC93 autumn 28 Department of Computer and Information Science Linköping University, Sweden L - Course Introduction and Overview L2 - Project Management L3 - Requirements L4 - Acceptance esting and Quality actors L5 UML L6 - Design Patterns L7 - System Design and Architecture L8 - esting heory L9 - esting in Practice L - Inspection L - Software Life Cycles and Configuration Management L2 - Software Quality Management L3 - Course Summary, Exam examples, Questions I II V A Software Life-cycle Model Which part will we talk about today? 3 Maintenance Agenda - What will you learn today? 4 Requirements System Design (Architecture, High-level Design) Validate Requirements, Verify Specification Verify System Design Acceptance est (Release ing) (Integration ing of modules) I ing Module Design (Program Design, Detailed Design) Implementation of Units (classes, procedures, functions) Verify Module Design Verify Implementation Unit ing (Integration ing of units) II V Project Management, Software Quality Assurance (SQA), Supporting ools, Education I II V I II V

2 5 riangle program (simple version) 6 triangle problem is the most widely used example in software ing literature. he program accepts three integers, a, b, and c as input. he three values are interpreted as representing the lengths of sides of a triangle. he program prints a message that states whether the triangle is scalene (oregelbunden), isosceles (likbent) or equilateral (liksidig). On a sheet of paper, write a set Student of Worksheet cases (i.e., specific sets of data) that you feel would adequately this program. est case a b c Expected output isosceles (likbent) 2???? I II V I II V esting a ballpoint pen 7 8 Does the pen write in the right color, with the right line thickness? Is the logo on the pen according to company standards? Is it safe to chew on the pen? Does the click-mechanism still work after clicks? Does it still write after a car has run over it? What is expected from this pen? Intended use!! Customer Developer Requirements definition Requirements specification unctional requirements Nonfunctional requirements Code = System Design Specification I II V I II V 2

3 Error, ault, ailure 9 ypes of aults (dep. on org. IBM, HP) Human error (Mistake, Bug) Can lead to ault (Defect, Bug) Can lead to Algorithmic: division by zero Computation & Precision: order of op Documentation: doc - code Stress/Overload: data-str size ( dimensions of tables, size of buffers) Capacity/Boundary: x devices, y parallel tasks, z interrupts iming/coordination: real-time systems hroughout/performance: speed in req. Recovery: power failure Hardware & System Software: modem Standards & Procedure: organizational standard; difficult for programmers to follow each other. ailure I II V I II V A esting Life Cycle 2 Error Requirements Specification ault Design Error ault Putting Bugs IN Development phases Coding Error ault esting Incident inding Bugs esting phase ault Classification ix ault Isolation Error ault Resolutio n Getting Bugs OU I ing I II V I II V 3

4 Unit & Integration esting 3 4 Objective: to ensure that code implemented the design properly. Component code Unit ested components Design Specification Integration Code = System Design Specification Component code Unit ested components Integrated modules I II V I II V 5 wo ypes of Oracles 6 Input est ailure? Human: an expert that can examine an input and its associated output and determine whether the program delivered the correct output for this particular input. Object Automated: a system capable of performing the above task. Output Oracle I II V I II V 4

5 Black-box esting 7 Black-box / Closed-box esting 8. Exhaustive ing 2. Equivalence class ing (Equivalence Partitioning) 3. Boundary value analysis 4. Decision table ing incorrect or missing functions interface errors performance error input output I II V I II V. Exhaustive ing 9 2. Equivalence Class esting 2 Definition: ing with every member of the input value space. Input value space: the set of all possible input values to the program. Equivalence Class (EC) ing is a technique used to reduce the number of cases to a manageable level while still maintaining reasonable coverage. Each EC consists of a set of data that is treated the same by the module or that should produce the same result. Any data value within a class is equivalent, in terms of ing, to any other value. I II V I II V 5

6 Identifying the Equivalence Classes aking each input condition (usually a sentence or phrase in the specification) and partitioning it into two or more groups: Input condition range of values x: -5 Valid equivalence class Invalid equivalence classes 2 Guidelines. If an input condition specifies a range of values; identify one valid EC and two invalid EC. 2. If an input condition specifies the number (e.g., one through 6 owners can be listed for the automobile); identify one valid EC and two invalid EC (- no owners; - more than 6 owners). 3. If an input condition specifies a set of input values and there is reason to believe that each is handled differently by the program; identify a valid EC for each and one invalid EC. 4. If an input condition specifies a must be situation (e.g., first character of the identifier must be a letter); identify one valid EC (it is a letter) and one invalid EC (it is not a letter) 5. If there is any reason to believe that elements in an EC are not handled in an identical manner by the program, split the equivalence class into smaller equivalence classes. 22 I II V I II V Identifying the est Cases 23 Equivalence partitioning 24. Assign a unique number to each EC. 2. Until all valid ECs have been covered by cases, write a new case covering as many of the uncovered valid ECs as possible. 3. Until all invalid ECs have been covered by cases, write a case that cover one, and only one, of the uncovered invalid ECs. Invalid inputs Valid inputs outputs I II V I II V 6

7 Specification: the program accepts four to eight inputs which are 5 digit integers greater than Boundary Value esting Boundary value ing focuses on the boundaries simply because that is where so many defects hide. he defects can be in the requirements or in the code. 26 he most efficient way of finding such defects, either in the requirements or the code, is through inspection (Software Inspection, Gilb and Graham s book). I II V I II V echnique 27 Boundary value analysis 28. Identify the ECs. 2. Identify the boundaries of each EC. 3. Create cases for each boundary value by choosing one point on the boundary, one point just below the boundary, and one point just above the boundary. Less than Between and More than I II V I II V 7

8 4. Decision able esting 29 echnique 3 Decision tables are an excellent tool to capture certain kinds of system requirements and to document internal system design. hey are used to record complex business rules that a system must implement. In addition, they can serve as a guide to creating cases. he general format of a decision table: Rule Rule 2 Conditions Condition- Condition-2 Condition-m Actions Action- Action-2 Action-n Rule P I II V I II V 3 echnique (cont.) 32 A decision table with don t care entry C C2 Rule Rule 2 Rules 3,4 Rule 5 Rule 6 Rules 7,8 A decision table converted to a case table: est Case est Case 2 est Case P C3 Inputs A Condition- A2 Condition-2 A3 A4 Condition-m Expected Results Action- : don t care entry. he don t care entry has two major interpretations: the condition is irrelevant, or the condition does not apply. Sometimes the n/a symbol for this latter interpretation.. Action-2 Action-n I II V I II V 8

9 est Cases for the riangle Problem 33 est Cases for the riangle Problem 34 Case ID a b c Expected output D 4 2 Not a riangle C: a < b + c? D2 C2: b < a + c? D3 C3: c < a + b? D4 C4: a = b? D5 C5: a = c? D6 C6: b = c? D7 A: Not a triangle A2: Scalene A3: Isosceles A4: Equilateral A5: Impossible D8 D9 D D I II V I II V White-box esting (Glass box ing, Open box ing, Clear box ing, Structural ing) 35 Control low Graphs 36. Control flow ing 2. Data flow ing Process blocks Decision Point Junction Point Sequence If While Until Case I II V I II V 9

10 37 Code Coverage ( coverage metrics) 38 Definition: Given a program written in an imperative programming language, its program graph is a directed graph in which nodes are statement fragments, and edges represent flow of control (a complete statement is a default statement fragment). Levels of Coverage: Statement/Line/Basic block/segment Coverage Decision (Branch) Coverage Condition Coverage Decision/Condition Coverage Path Coverage I II V I II V Statement Coverage 39 What is Wrong with Line Coverage Steve Cornett (Bullseye ing technology) 4 Begin if ( y >= ) then y = ; abs = y; end; case- (yes): input: y =? expected result:? actual result:? begin y >= no abs = y y = yes Software developers and ers commonly use line coverage because of its simplicity and availability in object code instrumentation technology. Of all the structural coverage criteria, line coverage is the weakest, indicating the fewest number of cases. Bugs can easily occur in the cases that line coverage cannot see. he most significant shortcoming of line coverage is that it fails to measure whether you simple if statements with a false decision outcome. Experts generally recommend to only use line coverage if nothing else is available. Any other measure is better. I II V I II V

11 Branch Coverage 4 Begin if ( y >= ) then y = ; abs = y; end; begin y >= no y = yes more conditions? abs = y case- (yes): input: y = expected result: actual result: case-2 (no): input: y =? expected result:? actual result:? I II V Condition Coverage 43 Decision/Condition Coverage 44 Begin if ( x < && y > 2) { z = foo (x,y); else z =fie (x,y); } end; no z=fie (x,y) x< && y>2 yes z=foo (x,y) Begin if ( x < && y > 2) { z = foo (x,y); else z =fie (x,y); } end; no z=fie (x,y) x< && y>2 yes z=foo (x,y) case- (,): input: x =?, y =? expected result:? actual result:? case-2 (,): input: x =?, y =? expected result:? actual result:? case- (,,yes): input: x =?, y =? expected result:? actual result:? case-2 (,,no): input: x =?, y =? expected result:? actual result:? I II V I II V

12 Path Coverage 45 Path with loops 46 A path is a sequence of branches, or conditions. A path corresponds to a case, or a set of inputs. In code coverage ing, branches have more importance than the blocks they connect. b a c d Bugs are often sensitive to branches and conditions. e a c,b,d d e I II V I II V Path Coverage (cont.) 47 Computation of cyclomatic complexity 48 Cyclomatic complexity has a foundation in graph theory and is computed in the following ways: All possible execution paths. Cyclomatic complexity V(G), for a flow graph, G, is defined as: Question: How do we know how many paths to look for? Answer: he computation of cyclomatic complexity V(G) = E N + 2P E: number of edges N: number of nodes P: number of disconnected parts of the graph 2. Cyclomatic complexity V(G), for a flow graph, G, with only binary decisions, is defined as: V(G) = b + b: number of binary decision I II V I II V 2

13 Examples of Graphs and calculation of McCabe s Complexity Metric 49 A. V(G) = E N + 2P 5 E=, N=, P= V= E=, N=, P= V= E=, N=, P= V= E=, N=, P= V= G E B H D C I J E =? N =? P = V(G) =? 2. V(G) = b + K L b =? M N O P V(G) =? E=, N=, P= V= Q R S I II V I II V 2. Data low esting 5 Define/Reference Anomalies 52 Data flow ing focuses on the points at which variables receive values and the points at which these values are used (or referenced). It detects improper use of data values due to coding errors. Early data flow analyses often centered on a set of faults that are known as define/reference anomalies. A variable that is defined but never used (referenced) A variable that is used but never defined A variable that is defined twice before it is used I II V I II V 3

14 53 Definitions 54 dd: defined and defined again not invalid but suspicious du: defined and used perfectly correct dk: defined and then killed not invalid but probably a programming error ud: used and defined acceptable uu: used and used again acceptable uk: used and killed acceptable kd: killed and defined acceptable ku: killed and used a serious defect kk: killed and killed probably a programming error. du-path: a definition-use path (du-path) with respect to variable v is a path in PAHS(P) such that, for some v in V, there are defined and usage nodes DE(v, m) and USE(v, n) such that m and n are initial and final nodes of the path. I II V I II V Data low Graphs 55 Hierarchy of data flow coverage metrics 56 define x ~d: the variable does not exist, then it is defined ~u: the variable does not exist, then it is used ~k: the variable does not exist, then it is killed define x All-Paths define x use x use z use y kill z define y use z kill z use x define z Variable x: define x use x use x All-DU-Paths All-Uses All C-Uses/some P-Uses All-Defs All P-Uses/some C-Uses All-P-Uses use y use z All-Edges Branch kill y define z Control flow graph annotated with define-use-kill information for x, y, z All-Nodes Statement I II V I II V 4

15 57 Integration esting 58 II. op-down 2. Bottom-up 3. Big-bang 4. Sandwich I II V I II V Unit & Integration esting 59 6 Objective: to ensure that code implemented the design properly. Component code Unit ested components Design Specification Integration Code = System Design Specification Component code Unit ested components Integrated modules I II V I II V 5

16 Components 6 62 driver A Component to be ed Boundary conditions independent paths interface... B C D E G stub stub est cases I II V I II V. op-down Bottom-up 64 B A C D B A C D E G E G I II V I II V 6

17 3. Big-bang Sandwich 66 B A C D B A C D E G E G I II V I II V V Steps unction ing / hread ing Performance ing Acceptance ing Installation ing ermination Problem I II V I II V 7

18 69 7 Objective: to ensure that the system does what the customer wants it to do. Customer Developer Component code Unit ested components Design Specification Integration Requirements definition Requirements specification unctional requirements Nonfunctional requirements Component code Unit ested components Integrated modules I II V I II V Integrated modules System functional requirements unction Acceptance Customer requirements spec. I unctioning systems Accepted system Other software requirements II Performance Installation User environment V 7 Verified validated software System In Use! unction ing/hread ing (ing one function at a time) functional requirements A function checks that the integrated system performs its function as specified in the requirement Guidelines use a team independent of the designers and programmers know the expected actions and output both valid and invalid input never modify the system just to make ing easier have stopping criteria I II V 72 8

19 Cause-and-Effect-Graph ( case generation from req.) 73 Basic cause-effect graph symbols 74 causes: inputs effects: outputs and transformations causes-and-effect graph: boolean graph reflecting causes and effects relationships is a formal language into which a natural language specification is translated a b Identity: if a then b a a b c And: if (a and b) then c b d a b c Or: if (a or b or c) then d Identity: if (not a) then b I II V I II V 75 Sample cause-effect graph 76 Specification: the character in column must be an A or a B. he character in column 2 must be a digit. In this situation, the file update is made. If the first character is incorrect, message 2 is issued. If the second character is not a digit, message 3 is issued. Intermediate node E2 Causes C: character in column is A C2: character in column is B C3: character in column 2 a digit Effects E: update made E2: message 2 is issued E3:message 3 is issued 2 E 3 E3 I II V I II V 9

20 Decision table for cause-and effect graph 77 Performance esting nonfunctional requirements 78 Cause Cause 2 Cause 3 Effect E est est 2 est 3 est 4 Stress s Volume s Configuration s Compatibility s Regression s Security s iming s Environment s Quality s Recovery s Maintenance s Documentation s Human factors s / usability s Effect E2 Effect E3 I II V I II V Acceptance esting customers, users need 79 Installation esting users site 8 Benchmark : a set of special cases Pilot : everyday working Alpha : at the developer s site, controlled environment Beta : at one or more customer site. Acceptance at developers site installation at users site, otherwise may not be needed!! Parallel : new system in parallel with previous one I II V I II V 2

21 ermination Problem How decide when to stop ing he main problem for managers! ermination takes place when resources (time & budget) are over found the seeded faults some coverage is reached 8 Summary - What have we learned today? (/2) : esting process I: Black-box esting. Exhaustive ing 2. Equivalence class ing (Equivalence Partitioning) 3. Boundary value analysis 4. Decision table ing White-box esting Control low esting. Statement/Line/Basic block/segment Coverage 2. Decision (Branch) Coverage 3. Condition Coverage 4. Decision/Condition Coverage 5. Path Coverage Data low esting 82 I II V I II V Summary - What have we learned today? (2/2) II: (Integration esting) op-down Bottom-up Big-bang Sandwich Do you want to know more about ing? ake the course on Software esting (DDC4). V: I II V I II V 2

Software Engineering Theory. Lena Buffoni (slides by Kristian Sandahl/Mariam Kamkar) Department of Computer and Information Science

Software Engineering Theory. Lena Buffoni (slides by Kristian Sandahl/Mariam Kamkar) Department of Computer and Information Science Software Engineering Theory Lena Buffoni (slides by Kristian Sandahl/Mariam Kamkar) Department of Computer and Information Science 2015-09-20 Title/Lecturer SEPTEMBER 20, 2016 2 Requirement formalization

More information

CS 4387/5387 SOFTWARE V&V LECTURE 4 BLACK-BOX TESTING

CS 4387/5387 SOFTWARE V&V LECTURE 4 BLACK-BOX TESTING 1 CS 4387/5387 SOFTWARE V&V LECTURE 4 BLACK-BOX TESTING Outline 2 Quiz Black-Box Testing Equivalence Class Testing (Equivalence Partitioning) Boundary value analysis Decision Table Testing 1 3 Quiz - 1

More information

What is Structural Testing?

What is Structural Testing? Structural Testing What is Structural Testing? Based on Source Code Examine the internal structure of the program Test cases are derived from an examination of program s logic Do not pay any attention

More information

Software Testing. 1. Testing is the process of demonstrating that errors are not present.

Software Testing. 1. Testing is the process of demonstrating that errors are not present. What is Testing? Software Testing Many people understand many definitions of testing :. Testing is the process of demonstrating that errors are not present.. The purpose of testing is to show that a program

More information

Dataflow Testing. Dataflow Testing. Dataflow Analysis. Definitions. Definitions 2. Definitions 3

Dataflow Testing. Dataflow Testing. Dataflow Analysis. Definitions. Definitions 2. Definitions 3 Dataflow Testing Dataflow Testing Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases Testing All-Paths in a control flow graph is often too timeconsuming Chapter 9

More information

Dataflow Testing. Definitions 2

Dataflow Testing. Definitions 2 Dataflow Testing Dataflow Analysis Can reveal interesting bugs Dataflow Testing Chapter 9 Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases Testing All-Paths in a

More information

Dataflow Testing. Chapter 10!

Dataflow Testing. Chapter 10! Dataflow Testing Chapter 10! Dataflow Testing Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases! Testing All-Paths in a control flow graph is often too timeconsuming!

More information

Dataflow Testing. Chapter 9!

Dataflow Testing. Chapter 9! Dataflow Testing Chapter 9! Dataflow Testing Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases! Testing All-Paths in a control flow graph is often too timeconsuming!

More information

SOFTWARE ENGINEERING IT 0301 Semester V B.Nithya,G.Lakshmi Priya Asst Professor SRM University, Kattankulathur

SOFTWARE ENGINEERING IT 0301 Semester V B.Nithya,G.Lakshmi Priya Asst Professor SRM University, Kattankulathur SOFTWARE ENGINEERING IT 0301 Semester V B.Nithya,G.Lakshmi Priya Asst Professor SRM University, Kattankulathur School of Computing, Department of IT 1 School of Computing, Department 2 SOFTWARE TESTING

More information

Introduction to Software Engineering

Introduction to Software Engineering Introduction to Software Engineering (CS350) Lecture 17 Jongmoon Baik Testing Conventional Applications 2 Testability Operability it operates cleanly Observability the results of each test case are readily

More information

1 Visible deviation from the specification or expected behavior for end-user is called: a) an error b) a fault c) a failure d) a defect e) a mistake

1 Visible deviation from the specification or expected behavior for end-user is called: a) an error b) a fault c) a failure d) a defect e) a mistake Sample ISTQB examination 1 Visible deviation from the specification or expected behavior for end-user is called: a) an error b) a fault c) a failure d) a defect e) a mistake 2 Regression testing should

More information

Testing Methods: White Box Testing II

Testing Methods: White Box Testing II Testing Methods: White Box Testing II Outline Today we continue our look at white box testing with more code coverage methods, and a data coverage method We ll look at : - code coverage testing - decision

More information

Computer Science and Software Engineering University of Wisconsin - Platteville 9-Software Testing, Verification and Validation

Computer Science and Software Engineering University of Wisconsin - Platteville 9-Software Testing, Verification and Validation Computer Science and Software Engineering University of Wisconsin - Platteville 9-Software Testing, Verification and Validation Yan Shi SE 2730 Lecture Notes Verification and Validation Verification: Are

More information

Examination Questions Time allowed: 1 hour 15 minutes

Examination Questions Time allowed: 1 hour 15 minutes Swedish Software Testing Board (SSTB) International Software Testing Qualifications Board (ISTQB) Foundation Certificate in Software Testing Practice Exam Examination Questions 2011-10-10 Time allowed:

More information

Modern Methods in Software Engineering. Testing.

Modern Methods in Software Engineering. Testing. Modern Methods in Software Engineering Testing www.imit.kth.se/courses/2g1522 Literature used Text book Chapter 11 Introduction Content Terminology Types of errors Dealing with errors Component Testing

More information

Equivalence Class Partitioning. Equivalence Partitioning. Definition and Example. Example set of classes

Equivalence Class Partitioning. Equivalence Partitioning. Definition and Example. Example set of classes Equivalence Class Partitioning Equivalence Partitioning From S. Somé, A. Williams 1 Suppose that we were going to test a method that implements the absolute value function for integers. Definition public

More information

Darshan Institute of Engineering & Technology for Diploma Studies

Darshan Institute of Engineering & Technology for Diploma Studies CODING Good software development organizations normally require their programmers to follow some welldefined and standard style of coding called coding standards. Most software development organizations

More information

Overview. State-of-the-Art. Relative cost of error correction. CS 619 Introduction to OO Design and Development. Testing.

Overview. State-of-the-Art. Relative cost of error correction. CS 619 Introduction to OO Design and Development. Testing. Overview CS 619 Introduction to OO Design and Development ing! Preliminaries! All sorts of test techniques! Comparison of test techniques! Software reliability Fall 2012! Main issues: There are a great

More information

Testing: Test design and testing process

Testing: Test design and testing process Testing: Test design and testing process Zoltán Micskei Based on István Majzik s slides Dept. of Measurement and Information Systems Budapest University of Technology and Economics Department of Measurement

More information

In this Lecture you will Learn: Testing in Software Development Process. What is Software Testing. Static Testing vs.

In this Lecture you will Learn: Testing in Software Development Process. What is Software Testing. Static Testing vs. In this Lecture you will Learn: Testing in Software Development Process Examine the verification and validation activities in software development process stage by stage Introduce some basic concepts of

More information

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification and Validation: Goals

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification and Validation: Goals Software Testing in the textbook Software Testing Chapter 8 Introduction (Verification and Validation) 8.1 Development testing 8.2 Test-driven development 8.3 Release testing 8.4 User testing 1 2 Verification

More information

Aerospace Software Engineering

Aerospace Software Engineering 16.35 Aerospace Software Engineering Verification & Validation Prof. Kristina Lundqvist Dept. of Aero/Astro, MIT Would You...... trust a completely-automated nuclear power plant?... trust a completely-automated

More information

Introduction. Easy to get started, based on description of the inputs

Introduction. Easy to get started, based on description of the inputs Introduction Testing is about choosing elements from input domain. The input domain of a program consists of all possible inputs that could be taken by the program. Easy to get started, based on description

More information

Lecture 26: Testing. Software Engineering ITCS 3155 Fall Dr. Jamie Payton

Lecture 26: Testing. Software Engineering ITCS 3155 Fall Dr. Jamie Payton Lecture 26: Testing Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Dec. 9, 2008 Verification vs validation Verification:

More information

What s Next INF 117 Project in Software Engineering

What s Next INF 117 Project in Software Engineering What s Next IN 117 Project in Software Engineering Lecture Notes - Spring Quarter, 2008 Michele Rousseau Set 8 - esting Set 8 - esting 2 Announcements k Drop Boxes We will use drop boxes for the remainder

More information

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/10/2015

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/10/2015 Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 11/10/2015 http://cs.gsu.edu/~ncasturi1 Class announcements Final Exam date - Dec 1 st. Final Presentations Dec 3 rd. And

More information

Chapter 10. Testing and Quality Assurance

Chapter 10. Testing and Quality Assurance Chapter 10 Testing and Quality Assurance Different styles of doing code review Human Reviewer Code Inspection with continuous integration infrastructure Pinger s testing set up Testing Related topics 1.

More information

Topics in Software Testing

Topics in Software Testing Dependable Software Systems Topics in Software Testing Material drawn from [Beizer, Sommerville] Software Testing Software testing is a critical element of software quality assurance and represents the

More information

Software Engineering Fall 2014

Software Engineering Fall 2014 Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 11/10/2014 Final Exam date - Dec 10 th? Class announcements Final Presentations Dec 3 rd. And Dec 8 th. Ability

More information

Software Testing. Software Testing

Software Testing. Software Testing Software Testing Software Testing Error: mistake made by the programmer/ developer Fault: a incorrect piece of code/document (i.e., bug) Failure: result of a fault Goal of software testing: Cause failures

More information

Chapter 9 Quality and Change Management

Chapter 9 Quality and Change Management MACIASZEK, L.A. (2007): Requirements Analysis and System Design, 3 rd ed. Addison Wesley, Harlow England ISBN 978-0-321-44036-5 Chapter 9 Quality and Change Management Pearson Education Limited 2007 Topics

More information

Pearson Education 2007 Chapter 9 (RASD 3/e)

Pearson Education 2007 Chapter 9 (RASD 3/e) MACIASZEK, L.A. (2007): Requirements Analysis and System Design, 3 rd ed. Addison Wesley, Harlow England ISBN 978-0-321-44036-5 Chapter 9 Quality and Change Management Pearson Education Limited 2007 Topics

More information

Facts About Testing. Cost/benefit. Reveal faults. Bottom-up. Testing takes more than 50% of the total cost of software development

Facts About Testing. Cost/benefit. Reveal faults. Bottom-up. Testing takes more than 50% of the total cost of software development Reveal faults Goals of testing Correctness Reliability Usability Robustness Performance Top-down/Bottom-up Bottom-up Lowest level modules tested first Don t depend on any other modules Driver Auxiliary

More information

Software Engineering (CSC 4350/6350) Rao Casturi

Software Engineering (CSC 4350/6350) Rao Casturi Software Engineering (CSC 4350/6350) Rao Casturi Testing Software Engineering -CSC4350/6350 - Rao Casturi 2 Testing What is testing? Process of finding the divergence between the expected behavior of the

More information

Software Testing. Lecturer: Sebastian Coope Ashton Building, Room G.18

Software Testing. Lecturer: Sebastian Coope Ashton Building, Room G.18 Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Software Testing 1 Defect Testing Defect testing involves

More information

Software Testing Interview Question and Answer

Software Testing Interview Question and Answer Software Testing Interview Question and Answer What is Software Testing? A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to

More information

Chapter 11, Testing. Using UML, Patterns, and Java. Object-Oriented Software Engineering

Chapter 11, Testing. Using UML, Patterns, and Java. Object-Oriented Software Engineering Chapter 11, Testing Using UML, Patterns, and Java Object-Oriented Software Engineering Outline Terminology Types of errors Dealing with errors Quality assurance vs Testing Component Testing! Unit testing!

More information

Software Testing. Testing: Our Experiences

Software Testing. Testing: Our Experiences Software Testing Testing: Our Experiences Test Case Software to be tested Output 1 Test Case Generation When to Stop? Test Case Software to be tested Verification Output No Enough? Test Coverage Yes A

More information

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process Verification and Validation Assuring that a software system meets a user s needs Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 19,20 Slide 1

More information

Department of Electrical & Computer Engineering, University of Calgary. B.H. Far

Department of Electrical & Computer Engineering, University of Calgary. B.H. Far SENG 421: Software Metrics Software Test Metrics (Chapter 10) Department of Electrical & Computer Engineering, University of Calgary B.H. Far (far@ucalgary.ca) http://www.enel.ucalgary.ca/people/far/lectures/seng421/10/

More information

Testing. Outline. What is this? Terminology. Erroneous State ( Error ) Algorithmic Fault

Testing. Outline. What is this? Terminology. Erroneous State ( Error ) Algorithmic Fault Outline 1 Terminology Types of errors Dealing with errors Quality assurance vs Component Unit testing Integration testing Strategy Design Patterns & testing unction testing Structure Performance testing

More information

Lecture 15 Software Testing

Lecture 15 Software Testing Lecture 15 Software Testing Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics covered

More information

Test design techniques

Test design techniques INF3121 : Software Testing 12. 02. 2015 Lecture 4 Test design techniques Lecturer: Raluca Florea INF3121/ 12.02.2015 / Raluca Florea 1 Overview 1. The test development process 2. Categories of test design

More information

Chapter 11, Testing, Part 2: Integration and System Testing

Chapter 11, Testing, Part 2: Integration and System Testing Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 11, Testing, Part 2: Integration and System Testing Overview Integration testing Big bang Bottom up Top down Sandwich System testing

More information

Quality Assurance in Software Development

Quality Assurance in Software Development Quality Assurance in Software Development Qualitätssicherung in der Softwareentwicklung A.o.Univ.-Prof. Dipl.-Ing. Dr. Bernhard Aichernig Graz University of Technology Austria Summer Term 2017 1 / 47 Agenda

More information

Chapter 11, Testing, Part 2: Integration and System Testing

Chapter 11, Testing, Part 2: Integration and System Testing Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 11, Testing, Part 2: Integration and System Testing Overview Integration testing Big bang Bottom up Top down Sandwich System testing

More information

Software Testing Fundamentals. Software Testing Techniques. Information Flow in Testing. Testing Objectives

Software Testing Fundamentals. Software Testing Techniques. Information Flow in Testing. Testing Objectives Software Testing Fundamentals Software Testing Techniques Peter Lo Software Testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding.

More information

Software Quality Assurance. David Janzen

Software Quality Assurance. David Janzen Software Quality Assurance David Janzen What is quality? Crosby: Conformance to requirements Issues: who establishes requirements? implicit requirements Juran: Fitness for intended use Issues: Who defines

More information

Terminology. There are many different types of errors and different ways how we can deal with them.

Terminology. There are many different types of errors and different ways how we can deal with them. Testing Terminology Reliability: The measure of success with which the observed behavior of a system confirms to some specification of its behavior. Failure: Any deviation of the observed behavior from

More information

UNIT 1-2 MARKS QUESTIONS WITH ANSWERS

UNIT 1-2 MARKS QUESTIONS WITH ANSWERS SUBJECT: SOFTWARE TESTING METHODOLOGIES. UNIT 1-2 MARKS QUESTIONS WITH ANSWERS 1) What is testing? What is the purpose of testing? A) TESTING: After the programs have been developed they must be tested

More information

Software Testing for Developer Development Testing. Duvan Luong, Ph.D. Operational Excellence Networks

Software Testing for Developer Development Testing. Duvan Luong, Ph.D. Operational Excellence Networks Software Testing for Developer Development Testing Duvan Luong, Ph.D. Operational Excellence Networks Contents R&D Testing Approaches Static Analysis White Box Testing Black Box Testing 4/2/2012 2 Development

More information

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK TWO MARKS UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT 1. What is software engineering? Software engineering

More information

Testing & Continuous Integration. Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/19/2010

Testing & Continuous Integration. Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/19/2010 esting & Continuous Integration Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/1/20 University of Colorado, 20 1 Goals 2 Review material from Chapter of Pilone & Miles esting

More information

Testing. Unit, integration, regression, validation, system. OO Testing techniques Application of traditional techniques to OO software

Testing. Unit, integration, regression, validation, system. OO Testing techniques Application of traditional techniques to OO software Testing Basic ideas and principles Traditional testing strategies Unit, integration, regression, validation, system OO Testing techniques Application of traditional techniques to OO software Testing-11,

More information

Chapter 11, Testing, Part 2: Integration and System Testing

Chapter 11, Testing, Part 2: Integration and System Testing Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 11, Testing, Part 2: Integration and System Testing Overview Integration testing Big bang Bottom up Top down Sandwich System testing

More information

Chapter 9. Software Testing

Chapter 9. Software Testing Chapter 9. Software Testing Table of Contents Objectives... 1 Introduction to software testing... 1 The testers... 2 The developers... 2 An independent testing team... 2 The customer... 2 Principles of

More information

Sample Exam Syllabus

Sample Exam Syllabus ISTQB Foundation Level 2011 Syllabus Version 2.9 Release Date: December 16th, 2017. Version.2.9 Page 1 of 46 Dec 16th, 2017 Copyright 2017 (hereinafter called ISTQB ). All rights reserved. The authors

More information

Topics in Data-Flow Testing

Topics in Data-Flow Testing Dependable Software Systems Topics in Data-Flow Testing Material drawn from [Beizer] Courtesy Spiros Mancoridis Data-Flow Testing Data-flow testing uses the control flowgraph to explore the unreasonable

More information

Darshan Institute of Engineering & Technology Unit : 9

Darshan Institute of Engineering & Technology Unit : 9 1) Explain software testing strategy for conventional software architecture. Draw the spiral diagram showing testing strategies with phases of software development. Software Testing: Once source code has

More information

Software Testing part II (white box) Lecturer: Giuseppe Santucci

Software Testing part II (white box) Lecturer: Giuseppe Santucci Software Testing part II (white box) Lecturer: Giuseppe Santucci 4. White box testing White-box (or Glass-box) testing: general characteristics Statement coverage Decision coverage Condition coverage Decision

More information

Software Testing. Software Testing. Theory, Practise and Reality IBM Corporation

Software Testing. Software Testing. Theory, Practise and Reality IBM Corporation Software Testing Software Testing Theory, Practise and Reality Who am I? David Vines (dvines@uk.ibm.com) Degree in Computer Science and Operational Research Joined IBM in 1984 Been involved in product

More information

Topic: Software Verification, Validation and Testing Software Engineering. Faculty of Computing Universiti Teknologi Malaysia

Topic: Software Verification, Validation and Testing Software Engineering. Faculty of Computing Universiti Teknologi Malaysia Topic: Software Verification, Validation and Testing Software Engineering Faculty of Computing Universiti Teknologi Malaysia 2016 Software Engineering 2 Recap on SDLC Phases & Artefacts Domain Analysis

More information

(See related materials in textbook.) CSE 435: Software Engineering (slides adapted from Ghezzi et al & Stirewalt

(See related materials in textbook.) CSE 435: Software Engineering (slides adapted from Ghezzi et al & Stirewalt Verification (See related materials in textbook.) Outline What are the goals of verification? What are the main approaches to verification? What kind of assurance do we get through testing? How can testing

More information

Software technology 7. Testing (2) BSc Course Dr. Katalin Balla

Software technology 7. Testing (2) BSc Course Dr. Katalin Balla Software technology 7. Testing (2) BSc Course Dr. Katalin Balla Contents Testing techniques Static testing techniques Dynamic testing Black box testing White-box testing Testing in the agile environment

More information

Software Testing. Minsoo Ryu. Hanyang University. Real-Time Computing and Communications Lab., Hanyang University

Software Testing. Minsoo Ryu. Hanyang University. Real-Time Computing and Communications Lab., Hanyang University Software Testing Minsoo Ryu Hanyang University Topics covered 1. Testing Goals and Principles 2. Testing Process 3. Testing Strategies Component testing Integration testing Validation/system testing 4.

More information

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification vs validation Verification: "Are we building the product right?. The software should

More information

MTAT : Software Testing

MTAT : Software Testing MTAT.03.159: Software Testing Lecture 02: Basic Black-Box and White-Box Testing Techniques (Textbook Ch. 4 & 5) Spring 2018 Dietmar Pfahl email: dietmar.pfahl@ut.ee Structure of Lecture 2 Black-Box vs.

More information

Test s in i g n III Week 16

Test s in i g n III Week 16 Testing III Week 16 Agenda (Lecture) White box testing Condition coverage Loop coverage Path coverage Agenda (Lab) Implementation Review of SRS/SDD documents Submit a weekly project progress report at

More information

Topics. Software Testing Test Driven Development Black Box Testing Unit Testing White Box Testing Coverage Testing Software Debugging

Topics. Software Testing Test Driven Development Black Box Testing Unit Testing White Box Testing Coverage Testing Software Debugging Supplemental Materials: Software esting CS2: Data Structures and Algorithms Colorado State University Chris Wilcox, Russ Wakefield, Wim Bohm, Dave Matthews opics Software esting est Driven Development

More information

(From Glenford Myers: The Art of Software Testing)

(From Glenford Myers: The Art of Software Testing) A Testing Exercise: (From Glenford Myers: The Art of Software Testing) A program reads three integer values from a card. The three values are interpreted as representing the lengths of the sides of a triangle.

More information

Verification and Validation

Verification and Validation Chapter 5 Verification and Validation Chapter Revision History Revision 0 Revision 1 Revision 2 Revision 3 Revision 4 original 94/03/23 by Fred Popowich modified 94/11/09 by Fred Popowich reorganization

More information

MTAT : Software Testing

MTAT : Software Testing MTAT.03.159: Software Testing Lecture 02: Basic Black-Box and White-Box Testing Techniques (Textbook Ch. 4 & 5) Spring 2018 Dietmar Pfahl email: dietmar.pfahl@ut.ee Structure of Lecture 2 Black-Box vs.

More information

10. Software Testing Fundamental Concepts

10. Software Testing Fundamental Concepts 10. Software Testing Fundamental Concepts Department of Computer Science and Engineering Hanyang University ERICA Campus 1 st Semester 2016 Testing in Object-Oriented Point of View Error Correction Cost

More information

Testing & Debugging TB-1

Testing & Debugging TB-1 Testing & Debugging TB-1 Need for Testing Software systems are inherently complex» Large systems 1 to 3 errors per 100 lines of code (LOC) Extensive verification and validiation is required to build quality

More information

Chapter 8 Software Testing. Chapter 8 Software testing

Chapter 8 Software Testing. Chapter 8 Software testing Chapter 8 Software Testing 1 Topics covered Introduction to testing Stages for testing software system are: Development testing Release testing User testing Test-driven development as interleave approach.

More information

An Introduction to Systematic Software Testing. Robert France CSU

An Introduction to Systematic Software Testing. Robert France CSU An Introduction to Systematic Software Testing Robert France CSU Why do we need to systematically test software? Poor quality products can Inconvenience direct and indirect users Result in severe financial

More information

EECS 481 Software Engineering Exam #1. You have 1 hour and 20 minutes to work on the exam.

EECS 481 Software Engineering Exam #1. You have 1 hour and 20 minutes to work on the exam. EECS 481 Software Engineering Exam #1 Write your name and UM uniqname on the exam. There are ten (10) pages in this exam (including this one) and seven (7) questions, each with multiple parts. Some questions

More information

White-Box Testing Techniques

White-Box Testing Techniques T-76.5613 Software Testing and Quality Assurance Lecture 3, 18.9.2006 White-Box Testing Techniques SoberIT Content What are white-box testing techniques Control flow testing Statement coverage Branch coverage

More information

Programming Embedded Systems

Programming Embedded Systems Programming Embedded Systems Lecture 8 Overview of software testing Wednesday Feb 8, 2012 Philipp Rümmer Uppsala University Philipp.Ruemmer@it.uu.se 1/53 Lecture outline Testing in general Unit testing

More information

Introduction To Software Testing. Brian Nielsen. Center of Embedded Software Systems Aalborg University, Denmark CSS

Introduction To Software Testing. Brian Nielsen. Center of Embedded Software Systems Aalborg University, Denmark CSS Introduction To Software Testing Brian Nielsen bnielsen@cs.aau.dk Center of Embedded Software Systems Aalborg University, Denmark CSS 1010111011010101 1011010101110111 What is testing? Testing Testing:

More information

Chapter 14 Testing Tactics

Chapter 14 Testing Tactics Chapter 14 Testing Tactics Moonzoo Kim CS Division of EECS Dept. KAIST moonzoo@cs.kaist.ac.kr http://pswlab.kaist.ac.kr/courses/cs550-07 Spring 2007 1 Overview of Ch14. Testing Tactics 14.1 Software Testing

More information

Verification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80

Verification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80 1 / 80 Verification Miaoqing Huang University of Arkansas Outline 1 Verification Overview 2 Testing Theory and Principles Theoretical Foundations of Testing Empirical Testing Principles 3 Testing in Practice

More information

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS6403 SOFTWARE ENGINEERING II year/ IV sem CSE (Regulation 2013) UNIT 1- SOFTWARE PROCESS AND PROJECT

More information

Part 5. Verification and Validation

Part 5. Verification and Validation Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this

More information

QUIZ #5 - Solutions (5pts each)

QUIZ #5 - Solutions (5pts each) CS 435 Spring 2014 SOFTWARE ENGINEERING Department of Computer Science Name QUIZ #5 - Solutions (5pts each) 1. The best reason for using Independent software test teams is that a. software developers do

More information

Bridge Course On Software Testing

Bridge Course On Software Testing G. PULLAIAH COLLEGE OF ENGINEERING AND TECHNOLOGY Accredited by NAAC with A Grade of UGC, Approved by AICTE, New Delhi Permanently Affiliated to JNTUA, Ananthapuramu (Recognized by UGC under 2(f) and 12(B)

More information

CSE 374 Programming Concepts & Tools. Hal Perkins Fall 2015 Lecture 15 Testing

CSE 374 Programming Concepts & Tools. Hal Perkins Fall 2015 Lecture 15 Testing CSE 374 Programming Concepts & Tools Hal Perkins Fall 2015 Lecture 15 Testing Where we are Some very basic software engineering topics in the midst of tools Today: testing (how, why, some terms) Later:

More information

Higher-order Testing. Stuart Anderson. Stuart Anderson Higher-order Testing c 2011

Higher-order Testing. Stuart Anderson. Stuart Anderson Higher-order Testing c 2011 Higher-order Testing Stuart Anderson Defining Higher Order Tests 1 The V-Model V-Model Stages Meyers version of the V-model has a number of stages that relate to distinct testing phases all of which are

More information

Software Testing CS 408

Software Testing CS 408 Software Testing CS 408 1/09/18 Course Webpage: http://www.cs.purdue.edu/homes/suresh/408-spring2018 1 The Course Understand testing in the context of an Agile software development methodology - Detail

More information

Decision Tables - Wikipedia Decision Table-Based Testing

Decision Tables - Wikipedia Decision Table-Based Testing Decision ables Wikipedia Decision ablebased esting Chapter A precise yet compact way to model complicated logic Associate conditions with actions to perform Can associate many independent conditions with

More information

Introduction to Dynamic Analysis

Introduction to Dynamic Analysis Introduction to Dynamic Analysis Reading assignment Gary T. Leavens, Yoonsik Cheon, "Design by Contract with JML," draft paper, http://www.eecs.ucf.edu/~leavens/jml//jmldbc.pdf G. Kudrjavets, N. Nagappan,

More information

Govt. of Karnataka, Department of Technical Education Diploma in Information Science & Engineering. Sixth Semester

Govt. of Karnataka, Department of Technical Education Diploma in Information Science & Engineering. Sixth Semester Govt. of Karnataka, Department of Technical Education Diploma in Information Science & Engineering Sixth Semester Subject: Software Testing Contact Hrs / week: 4 Total hrs: 64 Table of Contents SN Chapter

More information

Integration and Testing. Uses slides from Lethbridge & Laganiere, 2001

Integration and Testing. Uses slides from Lethbridge & Laganiere, 2001 Integration and Testing Uses slides from Lethbridge & Laganiere, 2001 Testing phases: V model Requirements Acceptance Testing Specifications System Testing Design Integration Testing Detailed Design Unit

More information

Shree.Datta Polytechnic College,Dattanagar, Shirol. Class Test- I

Shree.Datta Polytechnic College,Dattanagar, Shirol. Class Test- I Shree. Datta S.S.S.K. Charitable Trust s Shree.Datta Polytechnic College,Dattanagar, Shirol Class Test- I Course Code:CO6E Subject:-SOFTWARE TESTING Marks:-25 Semester:-VI Subject code:-12258 Date:- Institute

More information

People tell me that testing is

People tell me that testing is Software Testing Mark Micallef mark.micallef@um.edu.mt People tell me that testing is Boring Not for developers A second class activity Not necessary because they are very good coders 1 What is quality?

More information

Why testing and analysis. Software Testing. A framework for software testing. Outline. Software Qualities. Dependability Properties

Why testing and analysis. Software Testing. A framework for software testing. Outline. Software Qualities. Dependability Properties Why testing and analysis Software Testing Adapted from FSE 98 Tutorial by Michal Young and Mauro Pezze Software is never correct no matter what developing testing technique is used All software must be

More information

MTAT : Software Testing

MTAT : Software Testing MTAT.03.159: Software Testing Lecture 03: White-Box Testing (Textbook Ch. 5) Spring 2013 Dietmar Pfahl email: dietmar.pfahl@ut.ee Lecture Chapter 5 White-box testing techniques (Lab 3) Structure of Lecture

More information

Introduction and Overview

Introduction and Overview Introduction and Overview Lecture 1 Software Engineering CUGS course Spring 2011 Kristian Sandahl Department of Computer and Information Science Linköping University, Sweden @ida.liu.se Who is Kristian?

More information

It is primarily checking of the code and/or manually reviewing the code or document to find errors This type of testing can be used by the developer

It is primarily checking of the code and/or manually reviewing the code or document to find errors This type of testing can be used by the developer Static testing Static testing is a software testing method that involves examination of the program's code and its associated documentation but does not require the program be executed. Dynamic testing,

More information

EXAMINING THE CODE. 1. Examining the Design and Code 2. Formal Review: 3. Coding Standards and Guidelines: 4. Generic Code Review Checklist:

EXAMINING THE CODE. 1. Examining the Design and Code 2. Formal Review: 3. Coding Standards and Guidelines: 4. Generic Code Review Checklist: EXAMINING THE CODE CONTENTS I. Static White Box Testing II. 1. Examining the Design and Code 2. Formal Review: 3. Coding Standards and Guidelines: 4. Generic Code Review Checklist: Dynamic White Box Testing

More information