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

Size: px
Start display at page:

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

Transcription

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

2 4. White box testing White-box (or Glass-box) testing: general characteristics Statement coverage Decision coverage Condition coverage Decision and condition coverage Coverage of a linearly independent set of paths 2

3 Also called White-box testing: general characteristics Glass-box testing Structural testing (compared to functional) Exploits the control structure, that means the control or flow graph of programs in order to design test cases 3

4 White-box testing: general characteristics cont.d Allows to test parts of the program With black-box is not possible Allows to cover systematically every part of the program Often errors are found in special cases 4

5 Types of white-box tests

6 Statement coverage It is the easiest criterion for a reasonable whitebox test Necessary but not sufficient Goal To identify a set of test cases sufficient to exercise all statements at least once 6

7 Statement coverage cont.d Java example: A /*A*/ float x = InOut.readFloat(), y = InOut.readFloat(); /*B*/ if (x!= 0) /*C*/ y = y+10; /*D*/ y = y/x; /*E*/ System.out.println(x + ' ' + y); x == 0 B D C x!= 0 The test case {x!= 0; y = any} Covers the statements Control flow graph for the example E Do you see any problem? 7

8 Statement coverage cont.d Possible problem Even in a case of a program without iterations, the execution of every statement does not guarantee that all possible paths are exercised Possible negative consequence: In previous java example program the error of division by 0 is not identified (statement D) 8

9 Decision coverage Properly includes statement coverage Vice versa does not hold Focuses on all possible decisions in a program Decisions are in statements if, switch, while, for, do Goal To identify a set of test cases sufficient for guaranteeing that each decision will have value true at least once and value false at least once 9

10 Java example: Decision coverage cont.d /*A*/ float x = InOut.readFloat(), y = InOut.readFloat(); /*B*/ if (x!= 0) /*C*/ y += 10; /*D*/ y = y/x; /*E*/ System.out.println(x + ' ' + y); A B x!= 0 Test cases 1. {x=20; y=30} 2. {x=0; y=30} x == 0 D C Cover decisions hence statements The second case identifies the error of division by zero in statement D E 10

11 Decision coverage cont.d Possible problem If decisions are composed of several conditions (AND, OR), decision coverage can be not sufficient Java example: /*A*/ float z = InOut.readFloat(), w = InOut.readFloat(); t = InOut.readFloat(); /*B*/ if (z == 0 w > 0) /*C*/ w = w/z; /*D*/ else w = w + 2/t; /*E*/ System.out.println(z+' '+w+' '+t); What is the problem here? 11

12 Decision coverage cont.d Test cases: {t = 0; z= 5 ; w= 5} decision TRUE {t = 0; z= 5 ; w= -5} decision FALSE Cover decisions The risk of division by zero in D is identified (thanks to t = 0 that is not due to decision coverage strategy!!!! ) The risk of division by zero in C is not identified (z!=0) We need a criterion that considers the decision s conditions (i.e., the atomic Boolean expression components) (z == 0 w > 0) 12

13 Condition coverage Does not properly include decision coverage It is not properly included by decision coverage Focus on all possible conditions in a program Conditions are the components of Boolean expressions Goal: To identify a set of test cases sufficient for guaranteeing that every condition (atomic Boolean expression) included in the program s decisions have value true at least once and value false at least once 13

14 Condition coverage cont.d Java example: /*A*/ float z = InOut.readFloat(), w = InOut.readFloat(); t = InOut.readFloat(); /*B*/ if (z == 0 w > 0) /*C*/ w = w/z; /*D*/ else w = w + 2/t; /*E*/ System.out.println(z+' '+w+' '+t); Test cases {t=0;z=0;w= 5} 1 st condition=t, 2 nd condition=f {t=0;z=5;w= 5} 1 st condition=f, 2 nd condition=t Cover conditions What problem do such case tests make emerge? 14

15 Condition coverage Test cases {t=0;z=0;w=-5} 1 st condition=t, 2 nd condition=f {t=0;z=5;w= 5} 1 st condition=f, 2 nd condition=t Covers conditions The risk of division by zero in C is identified The risk of division by zero in D is not identified as D is never exercised Decision is always true 15

16 Decision and condition coverage Properly includes Decision coverage And, as a consequence, statements coverage Condition coverage Goal To identify a set of test cases sufficient for guaranteeing that Each decision is true at least once and false at least once All conditions composing decisions is true at least once and false at least once 16

17 Decision and condition coverage /*A*/ float z = InOut.readFloat(), w = InOut.readFloat(); t = InOut.readFloat(); /*B*/ if (z == 0 w > 0) /*C*/ w = w/z; /*D*/ else w = w + 2/t; /*E*/ System.out.println(z+' '+w+' '+t); cont.d Test cases {t=0;z=0;w=5} 1 st condition=t, 2 nd condition=t, decision=t {t=0;z=5;w= 5} 1 st condition=f, 2 nd condition=f, decision=f Cover decisions and conditions and identify both division by zero in statements C and D (thanks to t = 0 that is not due to decision and condition coverage strategy!!!! ) 17

18 Summary of test cases so far Test case t z w cond. 1 cond. 2 decis. Finds error in C? Finds error in D? C T T T yes no C F T T no no C T F T yes no C F F F no yes 18

19 Decision and condition coverage Coverage criterion Associated test cases Finds error in C? Finds error in D? Decision C2 + C4 no yes Condition C2 + C3 yes no Decision and condition C1 + C4, or C2 + C3 + C4 yes yes Which one is the best? 19

20 Methodological issue There are different combination of test cases that guarantee decision and condition coverage but it is not always trivial to find one We need a simple and effective method for identifying test cases that cover both decisions and conditions 20

21 Control flow graph s paths coverage Based on Criteria of decision and condition coverage Program s control flow graph Goal To provide a simple method for guaranteeing decision and condition coverage 21

22 Control flow graph Predicate nodes node D A B C edges while (A) { if (B) { C } else { D } E } F; E F region Example: V(G) = = 3 V(G) = 3 Cyclomatic number V(G) = E N + 2 (E = number of edges, N = number of nodes) V(G) = R (R = number of regions) 22

23 Control flow graph until Sequence of statements Simple if while case What about the for statement? It must be simulated through a while 23

24 Control flow graph without conditions /*A*/ float z = InOut.readFloat(), w = InOut.readFloat(); t = InOut.readFloat(); /*B*/ if (z == 0 w > 0) /*C*/ w = w/z; /*D*/ else w = w + 2/t; /*E*/ System.out.println(z+' '+w+' '+t); False D E A B True C The control flow graph should be more detailed 24

25 Control flow graph with complex if (a b) x; else y; decisions if (a && b) x; else y; a==f a a==t a==t a a==f b==f b b==t b==t b b==f y x x y

26 Control flow graph for the program /*A*/ float z = InOut.readFloat(), w = InOut.readFloat(); t = InOut.readFloat(); /*B*/ if (z == 0 w > 0) /*C*/ w = w/z; /*D*/ else w = w + 2/t; /*E*/ System.out.println(z+' '+w+' '+t); False D A B True C A!= 0 z <= 0 w > 0 D C == 0 E Control flow graph Without conditions E Control flow graph with conditions 26

27 Control flow graph, conditions and decisions Boolean values ( true and false ) associated with conditions and decisions have corresponding edges To design a set of test cases such that all edges of the control flow graph are traversed implies condition and decision coverage 27

28 Paths of the control flow graph The set of test cases corresponds to a set of paths such that every edge is traversed at least once The number of paths sufficient for covering all arcs is always equal or less than the cyclomatic complexity 28

29 For the previous example /*A*/ float z = InOut.readFloat(), w = InOut.readFloat(); t = InOut.readFloat(); /*B*/ if (z == 0 w > 0) /*C*/ w = w/z; /*D*/ else w = w + 2/t; /*E*/ System.out.println(z+' '+w+' '+t); A!= 0 z <= 0 w > 0 D C == 0 Three test cases C2. {t=0; z=5; w= 5} C3. {t=0; z=0; w= 5} C4. {t=0; z=5; w= 5} Cover all edges, hence decisions and conditions E V=7 6+2=3 The three paths 1. A z w C E (C2) 2. A z C E (C3) 3. A z w D E (C4) 29

30 How to choose paths Pragmatic rule Experiments show that the the number of errors increases with increasing of the cyclomatic complexity Choose a number of paths equal to the cyclomatic complexity You have a correlation between number of test cases and code complexity Which paths? 30

31 Linearly independent paths: Basis Path Testing A good criterion for choosing paths is based on the concept of linear independency A maximal set of linearly independent paths is called a basis It is NOT unique A basis contains a number of paths equal to the cyclomatic complexity Intuitively, every path in the control graph can be obtained as a linear combination of paths of a basis By choosing a basis, a certain extent of reliability is guaranteed with respect of combinations of errors that hide each other 31

32 Example of paths 7 A 1 B 2 3 D C 4 5 E 6 while (A) { if (B) { C } else { D } E } F; Paths. A F. A B D E A F. A B C E A F F Arcs/paths The matrix rank is 3 (the maximum) { } is a basis Note that A B D E A B C E A F covers all edges BUT 32

33 Remarks Every path corresponds to a binary row vector (0/1) Vice versa does not hold A matrix representing paths has maximum 2 E distinct rows (E = n of edges) McCabe has proved that for each graph G: 1. The matrix rank cannot be greater than V(G) (cyclomatic complexity) 2. There exists always a matrix made of paths with rank equal to V(G) A basis is any set of paths (rows) with maximum rank Note: MacCabe s result is purely topological: /*B*/ if(5>7) /*C*/ i=9; It is not possible to traverse Edge B-C In other cases is necessary to re-iterate the cycles in order to traverse all edges 7 A 1 B 2 3 D C 4 5 E F 6 33

34 Edges traversable only by iterations /*A*/ int z = ; int t=0; /*B*/ while (t<100) /*C*/ if (t > 20) /*D*/ t=t+90; /*E*/ else t= t+z*z; /*F*/ System.out.println(t); A B F C D Require at least one iteration in order to be traversed {z=10} A B C E K B F {z= 5} A B C E K B C D K B F t>20 D t<100 C E B t<=20 t>=100 So A B F A B C D K B F are not traversable K Fake node F 34

35 Additional considerations Paths coverage method does not consider explicitly loops iterations In some cases it is necessary to perform iterations in order to traverse all edges It might be interesting to consider some iterations in any case but the number of test cases increases exponentially It is important to decide the type of iterations 35

36 Pragmatic choices for loops To limit the number of iterations to n It is called loop coverage To execute only certain loops To limit the number of paths to be traversed based on weighted edges and function to be maximized Probability of execution Resources occupancy To limit the number of paths by identifying the paths that define and use program variables (Data Flow testing) Definition of a variable value Use of such value in a test 36

37 Data Flow Testing B... A int x,y,a,b; B scanf( %d %d,&x, &y); C a=x; D b=y E while (a!=b) F if(a>b) G a=a b; H else b=b a; I printf( %d,a);... a!=b F a>b G C D E a<=b H a==b I For x and y it is not needed to execute the loop (loop coverage = 0) For the definition of a and b the loop has to be iterated once (loop coverage = 1) For the definition and usage of a and b the loop has to be iterated twice (loop coverage = 2) 37

38 5. Testing strategies Testing and development process Verification vs. Validation The V-model Test levels Test types Maintenance testing 38

39 Testing and development process 1 The adopted life cycle has a big impact on the testing that is carried out: testing does not exist in isolation Test activities are highly related to software development activities The way testing is organized must fit the development life cycle or it will fail to deliver its benefit If a fully documented software development life cycle is required, the testing must be fully documented 39

40 Verification vs. Validation In every development life cycle, a part of testing is focused on verification testing and a part is focused on validation testing Verification: Evaluation of a work product, component or system to determine whether it meets the requirements set Answers the question: Is the deliverable built according to the specification? Validation: Evaluation of a work product, component or system to determine whether it meets the user needs and requirements Answers the question: Does the deliverable fit for purpose, e.g., does it provide a solution to the problem? 40

41 Good practices for testing Good testing practices apply to any life cycle model For every development activity there is a corresponding testing activity Each test level has test objectives specific to that level The analysis and design of tests for a given test level should begin during the corresponding development activity Testers should be involved in reviewing documents as soon as drafts are available in the development cycle 41

42 V-model The V-model was developed to address some of the problems experienced using the traditional waterfall approach Defects were being found too late in the life cycle, as testing was not started until the end of the project The V-model provides guidance to begin testing as early as possible in the life cycle 42

43 V-model Activities performed with the user Design Review Planning Testing Requirements Analysis Requirements Review Acceptance test Planning Acceptance Testing System Design Design Review Functional test Planning System Testing Architecture Design Architecture Review Integration test Planning Integration Testing Module Design Module Review Unit test Planning Unit Testing Internal activities Coding 03Test.43

44 Four test levels 1. Unit testing Searches for defects in and verifies the functioning of software components e.g. modules, programs, objects, classes etc., that are separately testable 2. Integration testing Tests interfaces between components, interactions to different parts of a system such as an operating system, file system and hardware or interfaces between systems 3. System testing Concerned with the behavior of the whole system/product as defined by the scope of a development project or product The main focus of system testing is verification against specified requirements 4. Acceptance testing validation testing with respect to user needs, requirements, and business processes conducted to determine whether or not to accept the system 44

45 1: Unit testing Also known as component, module, and program testing Searches for defects in, and verifies the functioning of software e.g. modules, programs, objects, classes, etc. that are separately testable Can be done in isolation from the rest of the system Stubs and drivers are used to replace the missing software and simulate the interface between the software components in a simple manner 45

46 Stub and Driver A stub is called from the software component to be tested A driver calls a component to be tested A A Driver B Stub B 46

47 1: Unit testing (cont.) Typically occurs with access to the code being tested Can be supported by the development environment such as a unit test framework or debugging tool See for example JUnit ( Usually involves the programmer who wrote the code Defects are fixed as soon as they are found, without formally recording the incidents found 47

48 Junit (annotation based) 48

49 Junit assertions 49

50 Junit test case public void testclassx_methody(){ ClassX a = new ClassX(); assertequals(4, a.methody(3, 1)); } 50

51 Test-driven development To prepare and automate test cases before coding Highly iterative Based on cycles of developing test cases, then building and integrating small pieces of code, and executing the component tests until they pass Used in Extreme Programming 51

52 2: Integration testing Focus: interfaces among components Interactions with different parts of a system an operating system, file system and hardware Interfaces between systems Within the NASA Apollo project, interface errors were the 75% of all errors! 52

53 Different levels of integration testing Component integration testing Testing the interactions among software components and is done after unit testing System integration testing Tests the interactions between different systems and may be done after system testing In this case, the developing organization may control only one side of the interface, so changes may be destabilizing Worst case: a series of systems that run on different platforms The greater the scope of integration, the more difficult it becomes to isolate failures to a specific interface 53

54 Two extreme approaches Big-bang integration testing All components or systems are integrated simultaneously After that everything is tested as a whole Advantage: everything is finished before integration testing starts Disadvantage: time-consuming and difficult to trace the cause of failures with this late integration Incremental integration testing All programs are integrated one by one A test is carried out after each step Advantage: defects are found early in a smaller assembly when it is relatively easy to detect the cause Disadvantage: it can be time-consuming since stubs and drivers have to be developed and used in the test 54

55 Incremental testing approaches Top-down Testing takes place from top to bottom, following the control flow or architectural structure e.g., starting from the GUI or the main menu Components or systems are substituted by stubs Bottom-up Testing takes place from the bottom of the control flow upwards Components or systems are substituted by drivers Functional incremental Integration and testing takes place on the basis of the functions or functionality, as documented in the functional specification 55

56 Example of top-down approach A B C D Stub E Stub F G Stub H 56

57 Example of bottom-up approach Driver A Driver B C Driver D E F G H 57

58 3: System testing Is concerned with the behavior of the whole system/product It may include tests based on Risks and/or requirements specification Business processes Use cases, or other high level descriptions of system behavior Interactions with the operating system and system resources Is most often the final test on behalf of development Should investigate both functional and non-functional requirements of the system System testing requires a controlled test environment with regard to control of the software versions (configuration management) The test environment should correspond to the final target or production environment as much as possible 58

59 4: Acceptance testing It comes after the system testing Responsibility of the user or customer Answer questions: Can the system be released? What, if any, are the outstanding (business) risks? Has development met its obligations? Executed in a test environment that is representative of the production environment Focused on a validation type of testing It is not necessarily the final level of testing E.g. a large-scale system integration test may come after the acceptance of a system 59

60 Test types: target of testing Test types are a means of clearly defining the objective of a certain test level for a program or project A test type is focused on a particular test objective For example Testing of a function to be performed by the component or system A non- functional quality characteristic, such as reliability or usability The structure or architecture of the component or system Testing changes, confirming that defects have been fixed (confirmation testing, or re-testing) and looking for unintended changes (regression testing) Depending on its objectives, testing will be organized differently 60

61 ISO quality characteristics ISO (ex 9126) defines eight quality characteristics and the subdivision of each quality characteristic into a number of sub-characteristics 1. Portability 2. Maintainability 3. Security 4. Reliability 5. Functional suitability 6. Performance efficiency 7. Compatibility 8. Usability ISO

62 Functional testing The function of a system (or component) is what it does This is typically described in a requirements specification, a functional specification, or in use cases It is difficult to test against undocumented and implicit requirements some functions that are assumed to be provided Functional tests are based on functions described in documents or understood by the testers Functional tests may be performed at all test levels e.g. test for components may be based on a component specification Functional testing considers the specified behavior and is often also referred to as black-box testing Even if black-box testing includes also non-functional testing 62

63 Functionality testing based on ISO Functions are those that satisfy stated or implied needs The objective is to guarantee the existence of a set of functions and their specified properties Functional suitability Completeness Correctness Appropriateness 63

64 Functionality testing based on ISO (ex 9126) functional suitability: degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions functional completeness: degree to which the set of functions covers all the specified tasks and user objectives functional correctness: degree to which a product or system provides the correct results with the needed degree of precision functional appropriateness: degree to which the functions facilitate the accomplishment of specified tasks and objectives 64

65 Non-functional testing Quality characteristics or non- functional attributes of the system How well or how fast something is done We need to measure on a scale of measurement E.g., time to respond Non-functional testing is performed at all test levels 65

66 Non-functional testing based on ISO Portability Maintainability Security Reliability Performance efficiency Compatibility Usability 66

67 Structural testing Is often referred to as white-box or glass-box because we are interested in what is happening inside the box It can occur at any test level It tends to be mostly applied at unit and integration testing and generally is less likely at higher test levels (e.g., acceptance testing) Good tool support to measure code coverage At component level, and to a lesser extent at (component) integration testing Code coverage: the percentage of executable elements, e.g., statements or decision outcomes that have been exercised 67

68 Confirmation and regression testing Testing of changes If you have made a change to the software, the way it functions, the way it performs (or both) and its structure have changed We look at the specific types of tests relating to changes, even though they may include all of the other test types 68

69 Confirmation testing (re-testing) A test run on a code that has been changed in order to fix a defect The test is the same that was run before and that causes the defect to emerge The test is executed in order to confirm that the defect has been fixed It is important to ensure that the test is executed in exactly the same way as it was the first time Using the same inputs, data and environment 69

70 Confirmation testing: question If the test now passes does this mean that the software is now correct? We now know that at least one part of the software is correct Where the defect was The fix may have introduced or uncovered a different defect elsewhere in the software The way to detect these unexpected side-effects of fixes is to do regression testing 70

71 Regression testing Involves executing (all) test cases that have been executed before The intent is checking that the system has not regressed It does not now have more defects in it as a result of some changes It is common for organizations to have what is usually called a regression test suite or regression test pack They are designed to collectively exercise most functions in a system (but not test each one in detail) It is appropriate to have a regression test suite at every level of testing All of the test cases in a regression test suite would be executed every time a new version of software is produced and this makes them ideal candidates for automation Maintenance of a regression test suite should be carried out so it evolves over time in line with the software 71

72 Maintenance testing Once deployed, a system is often in service for years or even decades During this time the system and its operational environment is often corrected, changed or extended Testing that is executed during this life cycle phase is called maintenance testing Note that maintenance testing is different from maintainability testing, which defines how easy it is to maintain the system 72

73 Maintenance testing Usually maintenance testing will consist of two parts 1. Testing the changes 2. Regression tests to show that the rest of the system has not been affected by the maintenance work 73

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

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

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

No Source Code. EEC 521: Software Engineering. Specification-Based Testing. Advantages

No Source Code. EEC 521: Software Engineering. Specification-Based Testing. Advantages No Source Code : Software Testing Black-Box Testing Test-Driven Development No access to source code So test cases don t worry about structure Emphasis is only on ensuring that the contract is met Specification-Based

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

Black Box Testing. EEC 521: Software Engineering. Specification-Based Testing. No Source Code. Software Testing

Black Box Testing. EEC 521: Software Engineering. Specification-Based Testing. No Source Code. Software Testing Black Box Testing EEC 521: Software Engineering Software Testing Black-Box Testing Test-Driven Development Also known as specification-based testing Tester has access only to running code and the specification

More information

Manuel Oriol, CHCRC-C, Software Testing ABB

Manuel Oriol, CHCRC-C, Software Testing ABB Manuel Oriol, CHCRC-C, 08.11.2017 Software Testing Slide 1 About me 1998 2004 2005 2008 2011 Slide 2 Introduction Why do we test? Did you have to deal with testing in the past? Slide 3 Ariane 5 http://www.youtube.com/watch?v=kyurqduyepi

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

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

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

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

Chap 2. Introduction to Software Testing

Chap 2. Introduction to Software Testing Chap 2. Introduction to Software Testing 2.1 Software Testing Concepts and Processes 2.2 Test Management 1 2.1 Software Testing Concepts and Processes 1. Introduction 2. Testing Dimensions 3. Test Concepts

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

Quote by Bruce Sterling, from: A Software Testing Primer, Nick Jenkins

Quote by Bruce Sterling, from: A Software Testing Primer, Nick Jenkins Software Testing Why Test? Quote by Bruce Sterling, from: A Software Testing Primer, Nick Jenkins https://www.typemock.com/software-bugs-infographic A bug found at design time costs ten times less to fix

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

Testing! The material for this lecture is drawn, in part, from! The Practice of Programming (Kernighan & Pike) Chapter 6!

Testing! The material for this lecture is drawn, in part, from! The Practice of Programming (Kernighan & Pike) Chapter 6! Testing The material for this lecture is drawn, in part, from The Practice of Programming (Kernighan & Pike) Chapter 6 1 Goals of this Lecture Help you learn about: Internal testing External testing General

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

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 Testing TEST CASE SELECTION AND ADEQUECY TEST EXECUTION

Software Testing TEST CASE SELECTION AND ADEQUECY TEST EXECUTION Software Testing TEST CASE SELECTION AND ADEQUECY TEST EXECUTION Overview, Test specification and cases, Adequacy criteria, comparing criteria, Overview of test execution, From test case specification

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

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

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

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

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

Software Testing Prof. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur. Lecture 13 Path Testing

Software Testing Prof. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur. Lecture 13 Path Testing Software Testing Prof. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture 13 Path Testing Welcome to this session and we will discuss about path

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 Test. Levels of test. Types of test. Regression test The JUnit tool for unit testing Java programs. System test Integration test Unit test

Software Test. Levels of test. Types of test. Regression test The JUnit tool for unit testing Java programs. System test Integration test Unit test Levels of test System test Integration test Unit test Types of test Black box White box Software Test Regression test The JUnit tool for unit testing Java programs OOP: Software Test 1 Introduction Sofware

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

White-Box Testing Techniques III

White-Box Testing Techniques III White-Box Testing Techniques III Software Testing and Verification Lecture 9 Prepared by Stephen M. Thebaut, Ph.D. University of Florida White-Box Testing Topics Logic coverage (lecture I) Dataflow coverage

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

Program Verification! Goals of this Lecture! Words from the Wise! Testing!

Program Verification! Goals of this Lecture! Words from the Wise! Testing! Words from the Wise Testing On two occasions I have been asked [by members of Parliament], Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out? I am not able rightly

More information

Agile Software Development. Lecture 7: Software Testing

Agile Software Development. Lecture 7: Software Testing Agile Software Development Lecture 7: Software Testing Mahmoud El-Gayyar elgayyar@ci.suez.edu.eg Slides are a modified version of the slides by Prof. Kenneth M. Anderson Outline Testing Terminology Types

More information

Verification Black-box Testing & Testing in the Large

Verification Black-box Testing & Testing in the Large 1 / 18 Verification & Miaoqing Huang University of Arkansas Spring 2010 2 / 18 Outline 1 2 Testing Boundary Conditions 3 Module Testing Integration Testing 3 / 18 Outline 1 2 Testing Boundary Conditions

More information

Testing! The material for this lecture is drawn, in part, from! The Practice of Programming (Kernighan & Pike) Chapter 6!

Testing! The material for this lecture is drawn, in part, from! The Practice of Programming (Kernighan & Pike) Chapter 6! Testing The material for this lecture is drawn, in part, from The Practice of Programming (Kernighan & Pike) Chapter 6 1 Words from the Wise On two occasions I have been asked [by members of Parliament],

More information

Program Analysis. Program Analysis

Program Analysis. Program Analysis Program Analysis Class #4 Program Analysis Dynamic Analysis 1 Static VS Dynamic Analysis Static analysis operates on a model of the SW (without executing it) If successful, produces definitive information

More information

Program Correctness and Efficiency. Chapter 2

Program Correctness and Efficiency. Chapter 2 Program Correctness and Efficiency Chapter 2 Chapter Objectives To understand the differences between the three categories of program errors To understand the effect of an uncaught exception and why you

More information

Software Engineering 2 A practical course in software engineering. Ekkart Kindler

Software Engineering 2 A practical course in software engineering. Ekkart Kindler Software Engineering 2 A practical course in software engineering Quality Management Main Message Planning phase Definition phase Design phase Implem. phase Acceptance phase Mainten. phase 3 1. Overview

More information

Object Oriented Software Design - I

Object Oriented Software Design - I Object Oriented Software Design - I Unit Testing Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa November 28, 2011 G. Lipari (Scuola Superiore Sant Anna) Unit Testing November

More information

CS 520 Theory and Practice of Software Engineering Fall 2018

CS 520 Theory and Practice of Software Engineering Fall 2018 Today CS 52 Theory and Practice of Software Engineering Fall 218 Software testing October 11, 218 Introduction to software testing Blackbox vs. whitebox testing Unit testing (vs. integration vs. system

More information

Human Computer Interaction Lecture 14. HCI in Software Process. HCI in the software process

Human Computer Interaction Lecture 14. HCI in Software Process. HCI in the software process Human Computer Interaction Lecture 14 HCI in Software Process HCI in the software process Software engineering and the design process for interactive systems Usability engineering Iterative design and

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

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

SFWR ENG 3S03: Software Testing

SFWR ENG 3S03: Software Testing (Slide 1 of 52) Dr. Ridha Khedri Department of Computing and Software, McMaster University Canada L8S 4L7, Hamilton, Ontario Acknowledgments: Material based on [?] Techniques (Slide 2 of 52) 1 2 3 4 Empirical

More information

MTAT : Software Testing

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

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

https://www.lri.fr/ linaye/gl.html

https://www.lri.fr/ linaye/gl.html Software Engineering https://www.lri.fr/ linaye/gl.html lina.ye@centralesupelec.fr Sequence 3, 2017-2018 1/61 Software Engineering Plan 1 2 3 4 5 2/61 Software Engineering Software Testing 3/61 Software

More information

Lecture 20: SW Testing Presented by: Mohammad El-Ramly, PhD

Lecture 20: SW Testing Presented by: Mohammad El-Ramly, PhD Cairo University Faculty of Computers and Information CS251 Software Engineering Lecture 20: SW Testing Presented by: Mohammad El-Ramly, PhD http://www.acadox.com/join/75udwt Outline Definition of Software

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

Testing. ECE/CS 5780/6780: Embedded System Design. Why is testing so hard? Why do testing?

Testing. ECE/CS 5780/6780: Embedded System Design. Why is testing so hard? Why do testing? Testing ECE/CS 5780/6780: Embedded System Design Scott R. Little Lecture 24: Introduction to Software Testing and Verification What is software testing? Running a program in order to find bugs (faults,

More information

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

Testing Theory. Agenda - What will you learn today? A Software Life-cycle Model Which part will we talk about today? Theory Lecture Plan 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

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

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

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

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

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

Sample Exam. Certified Tester Foundation Level

Sample Exam. Certified Tester Foundation Level Sample Exam Certified Tester Foundation Level Answer Table ASTQB Created - 2018 American Stware Testing Qualifications Board Copyright Notice This document may be copied in its entirety, or extracts made,

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

CS159. Nathan Sprague. September 30, 2015

CS159. Nathan Sprague. September 30, 2015 CS159 Nathan Sprague September 30, 2015 Testing Happens at Multiple Levels Unit Testing - Test individual classes in isolation. Focus is on making sure that each method works according to specification.

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

Integration Testing Qualidade de Software 2

Integration Testing Qualidade de Software 2 Integration Testing Integration Testing Software systems are built with components that must interoperate Primary purpose: To reveal component interoperability faults so that testing at system scope may

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

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

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 Strategies. Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only

Software Testing Strategies. Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only Chapter 22 Software Testing Strategies Slide Set to accompany Software Engineering: A Practitioner s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright 1996, 2001, 2005, 2009, 2014

More information

MONIKA HEINER.

MONIKA HEINER. LESSON 1 testing, intro 1 / 25 SOFTWARE TESTING - STATE OF THE ART, METHODS, AND LIMITATIONS MONIKA HEINER monika.heiner@b-tu.de http://www.informatik.tu-cottbus.de PRELIMINARIES testing, intro 2 / 25

More information

INTRODUCTION TO SOFTWARE ENGINEERING

INTRODUCTION TO SOFTWARE ENGINEERING INTRODUCTION TO SOFTWARE ENGINEERING Structural Testing d_sinnig@cs.concordia.ca Department for Computer Science and Software Engineering Introduction Testing is simple all a tester needs to do is find

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

Software Testing Prof. Meenakshi D Souza Department of Computer Science and Engineering International Institute of Information Technology, Bangalore

Software Testing Prof. Meenakshi D Souza Department of Computer Science and Engineering International Institute of Information Technology, Bangalore Software Testing Prof. Meenakshi D Souza Department of Computer Science and Engineering International Institute of Information Technology, Bangalore Lecture 04 Software Test Automation: JUnit as an example

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

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

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

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

Testing Objectives. Successful testing: discovers previously unknown errors

Testing Objectives. Successful testing: discovers previously unknown errors Testing Objectives Informal view: Testing: a process of executing software with the intent of finding errors Good testing: a high probability of finding as-yetundiscovered errors Successful testing: discovers

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

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

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

Human Computer Interaction Lecture 06 [ HCI in Software Process ] HCI in the software process

Human Computer Interaction Lecture 06 [ HCI in Software Process ] HCI in the software process Human Computer Interaction Lecture 06 [ HCI in Software Process ] Imran Ihsan Assistant Professor www.imranihsan.com aucs.imranihsan.com HCI06 - HCI in Software Process 1 HCI in the software process Software

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

Sample Exam ISTQB Advanced Test Analyst Answer Rationale. Prepared By

Sample Exam ISTQB Advanced Test Analyst Answer Rationale. Prepared By Sample Exam ISTQB Advanced Test Analyst Answer Rationale Prepared By Released March 2016 TTA-1.3.1 (K2) Summarize the generic risk factors that the Technical Test Analyst typically needs to consider #1

More information

Software Engineering: Theory and Practice. Verification by Testing. Test Case Design. Tom Verhoeff

Software Engineering: Theory and Practice. Verification by Testing. Test Case Design. Tom Verhoeff Software Engineering: Theory and Practice Verification by Testing Test Case Design Tom Verhoeff Eindhoven University of Technology Department of Mathematics & Computer Science Software Engineering & Technology

More information

LECTURE 11 TEST DESIGN TECHNIQUES IV

LECTURE 11 TEST DESIGN TECHNIQUES IV Code Coverage Testing 1. Statement coverage testing 2. Branch coverage testing 3. Conditional coverage testing LECTURE 11 TEST DESIGN TECHNIQUES IV Code Complexity Testing 1. Cyclomatic Complexity s V

More information

Standard Glossary of Terms used in Software Testing. Version 3.2. Advanced Test Automation - Engineer Terms

Standard Glossary of Terms used in Software Testing. Version 3.2. Advanced Test Automation - Engineer Terms Standard Glossary of Terms used in Software Testing Version 3.2 International Software Testing Qualifications Board Copyright Notice This document may be copied in its entirety, or extracts made, if the

More information

MTAT : Software Testing

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

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

7.0 Test Design Techniques & Dynamic Testing

7.0 Test Design Techniques & Dynamic Testing 7.0 Test Design Techniques & Dynamic Testing Test Design Techniques 7.1 The Test Development Process 7.2 Categories of Test Design Techniques 7.3 Specification based or Black Box Techniques 7.4 Structure

More information

Dilbert Scott Adams. CSc 233 Spring 2012

Dilbert Scott Adams. CSc 233 Spring 2012 Dilbert Scott Adams CSc 233 Spring 2012 Dilbert Scott Adams CSc 233 Spring 2012 2 Dilbert Scott Adams CSc 233 Spring 2012 3 prerequisites CSc 233 Spring 2012 I thought we had agreed long ago that the Department

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

Outline. software testing: search bugs black-box and white-box testing static and dynamic testing

Outline. software testing: search bugs black-box and white-box testing static and dynamic testing Outline 1 Verification Techniques software testing: search bugs black-box and white-box testing static and dynamic testing 2 Programming by Contract assert statements in Python using preconditions and

More information

Software Testing and Maintenance

Software Testing and Maintenance Software Testing and Maintenance Testing Strategies Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal structure/ design/ implementation of the item

More information

HCI in the software process

HCI in the software process chapter 6 HCI in the software process HCI in the software process Software engineering and the process for interactive systems Usability engineering Iterative and prototyping Design rationale the software

More information

HCI in the software. chapter 6. HCI in the software process. The waterfall model. the software lifecycle

HCI in the software. chapter 6. HCI in the software process. The waterfall model. the software lifecycle HCI in the software process chapter 6 HCI in the software process Software engineering and the process for interactive systems Usability engineering Iterative and prototyping Design rationale the software

More information

Unit-3 Software Design (Lecture Notes)

Unit-3 Software Design (Lecture Notes) Unit-3 Software Design (Lecture Notes) Prepared by Jay Nanavati, Assistant Professor, SEMCOM Topics Software Design - Introduction Design Principles Module Level concepts Overview of Structured design

More information

CS18000: Programming I

CS18000: Programming I CS18000: Programming I Testing Basics 19 April 2010 Prof. Chris Clifton Testing Programs Your programs are getting large and more complex How do you make sure they work? 1. Reason about the program Think

More information

Learning outcomes. Systems Engineering. Debugging Process. Debugging Process. Review

Learning outcomes. Systems Engineering. Debugging Process. Debugging Process. Review Systems Engineering Lecture 9 System Verification II Dr. Joanna Bryson Dr. Leon Watts University of Bath Department of Computer Science 1 Learning outcomes After both lectures and doing the reading, you

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

Using the code to measure test adequacy (and derive test cases) Structural Testing

Using the code to measure test adequacy (and derive test cases) Structural Testing Using the code to measure test adequacy (and derive test cases) Structural Testing Objectives To describe a second approach to testing which is geared to find program defects To explain the use of program

More information

Sample Question Paper. Software Testing (ETIT 414)

Sample Question Paper. Software Testing (ETIT 414) Sample Question Paper Software Testing (ETIT 414) Q 1 i) What is functional testing? This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type

More information