Software Testing part II (white box) Lecturer: Giuseppe Santucci
|
|
- Lucinda Morrison
- 5 years ago
- Views:
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 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 informationChapter 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 informationSoftware 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 informationNo 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 informationLecture 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 informationBlack 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 informationManuel 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 informationAn 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 informationVerification 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 informationSoftware 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 informationSample 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 informationChap 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 informationChapter 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 informationQuote 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 informationIn 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 informationTesting! 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 informationTopic: 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
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 informationTopics 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 informationSoftware 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 informationChapter 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 informationIntroduction 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 information10. 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 informationSoftware 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 informationSoftware 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 informationComputer 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 informationSoftware 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 informationSoftware 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 informationSoftware 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 information1 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 informationWhite-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 informationDarshan 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 informationProgram 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 informationAgile 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 informationVerification 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 informationTesting! 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 informationProgram 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 informationProgram 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 informationSoftware 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 informationObject 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 informationCS 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 informationHuman 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 informationExamination 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 informationSoftware 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 informationSFWR 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 informationMTAT : 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 informationMTAT : 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 informationTest 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 informationhttps://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 informationLecture 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 informationSoftware 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 informationTesting. 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 informationTesting 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 informationTesting 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 informationVerification 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 informationVerification 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 informationSOFTWARE 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 informationChapter 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 informationSample 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 informationPearson 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 informationCS159. 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 informationMTAT : 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 informationIntegration 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 informationSoftware 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 informationAerospace 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 informationDarshan 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 informationSoftware 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 informationMONIKA 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 informationINTRODUCTION 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 informationTesting: 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 informationSoftware 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 informationCSE 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 informationTerminology. 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 informationSoftware 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 informationWhite-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 informationTesting 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 informationPart 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 informationIntroduction 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 informationFacts 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 informationHuman 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 informationTesting & 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 informationSample 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 informationSoftware 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 informationLECTURE 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 informationStandard 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 informationMTAT : 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 informationQUIZ #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 information7.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 informationDilbert 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 informationMTAT : 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 informationOutline. 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 informationSoftware 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 informationHCI 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 informationHCI 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 informationUnit-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 informationCS18000: 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 informationLearning 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 informationSoftware 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 informationUsing 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 informationSample 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