Henrik Bærbak Christensen1 Systematic Testing (Scratching the surface) The art of economic testing...

Slides:



Advertisements
Similar presentations
Testing and Inspecting to Ensure High Quality
Advertisements

Formal Methods and Testing Goal: software reliability Use software engineering methodologies to develop the code. Use formal methods during code development.
Black Box Testing Csci 565 Spring 2009.
Composition CMSC 202. Code Reuse Effective software development relies on reusing existing code. Code reuse must be more than just copying code and changing.
Types of Algorithms.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Grey Box testing Tor Stålhane. What is Grey Box testing Grey Box testing is testing done with limited knowledge of the internal of the system. Grey Box.
1 Software Engineering Lecture 11 Software Testing.
Testing in the Small (aka Unit Testing, Class Testing)
PS4: Test Driven Development Based on Test Driven Development by Example By Kent Beck.
1 CODE TESTING Principles and Alternatives. 2 Testing - Basics goal - find errors –focus is the source code (executable system) –test team wants to achieve.
DAIMI(c) Henrik Bærbak Christensen1 BlackBox Testing based on Specification.
Software Testing and Quality Assurance
Computer Science 1620 Programming & Problem Solving.
Testing an individual module
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
DAIMI(c) Henrik Bærbak Christensen1 White-box Testing Let us open the box...
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
Equivalence Class Testing
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 9 Functional Testing
1 Joe Meehean. 2 Testing is the process of executing a program with the intent of finding errors. -Glenford Myers.
1 Functional Testing Motivation Example Basic Methods Timing: 30 minutes.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
System/Software Testing
CMSC 345 Fall 2000 Unit Testing. The testing process.
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
Black-Box Testing Techniques I Software Testing Lecture 4.
Chapter 8 – Software Testing Lecture 1 1Chapter 8 Software testing The bearing of a child takes nine months, no matter how many women are assigned. Many.
CS /51 Illinois Institute of Technology CS487 Software Engineering Software Testing Techniques Mr. David A. Lash.
Agenda Introduction Overview of White-box testing Basis path testing
Black-Box Testing Techniques I
Grey Box testing Tor Stålhane. What is Grey Box testing Grey Box testing is testing done with limited knowledge of the internal of the system. Grey Box.
Testing Testing Techniques to Design Tests. Testing:Example Problem: Find a mode and its frequency given an ordered list (array) of with one or more integer.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
Black-box Testing.
Systems Life Cycle. Know the elements of the system that are created Understand the need for thorough testing Be able to describe the different tests.
(1) Unit Testing and Test Planning CS2110: SW Development Methods These slides design for use in lab. They supplement more complete slides used in lecture.
Today’s Agenda  Reminder: HW #1 Due next class  Quick Review  Input Space Partitioning Software Testing and Maintenance 1.
What is Testing? Testing is the process of finding errors in the system implementation. –The intent of testing is to find problems with the system.
UNIT 5.  The related activities of sorting, searching and merging are central to many computer applications.  Sorting and merging provide us with a.
Function Definition by Cases and Recursion Lecture 2, Programmeringsteknik del A.
Equivalence Class Testing In chapter 5, we saw that all four variations of boundary value testing are vulnerable to –gaps of untested functionality, and.
Henrik Bærbak Christensen1 Test Driven Development “TDD” Summary.
Test Case Designing UNIT - 2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test.
Theory and Practice of Software Testing
1. Black Box Testing  Black box testing is also called functional testing  Black box testing ignores the internal mechanism of a system or component.
Theory and Practice of Software Testing Chapter 14 Presman Software Testing Tactics BLACK BOX TESTING.
72 4/11/98 CSE 143 Abstract Data Types [Sections , ]
Efficiently Solving Computer Programming Problems Doncho Minkov Telerik Corporation Technical Trainer.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
1 Software Testing. 2 Equivalence Class Testing 3 The use of equivalence class testing has two motivations: –Sense of complete testing –Avoid redundancy.
Black Box Unit Testing What is black-box testing? Unit (code, module) seen as a black box No access to the internal or logical structure Determine.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Software Testing. SE, Testing, Hans van Vliet, © Nasty question  Suppose you are being asked to lead the team to test the software that controls.
1 Software Testing. 2 What is Software Testing ? Testing is a verification and validation activity that is performed by executing program code.
Dynamic Black-Box Testing Part 1 What is dynamic black-box testing? How to reduce the number of test cases using: Equivalence partitioning Boundary value.
Software Engineering (CSI 321)
Software Testing.
Equivalence partitioning
Systematic Testing (Scratching the surface)
Decision Table Testing
Software Testing.
The Joy of Breaking Code Testing Logic and Case Selection
Black Box Testing PPT Sources: Code Complete, 2nd Ed., Steve McConnell
Types of Testing Visit to more Learning Resources.
Testing Approaches.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software Engineering and Architecture
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Presentation transcript:

Henrik Bærbak Christensen1 Systematic Testing (Scratching the surface) The art of economic testing...

Henrik Bærbak Christensen2 What is reliability? If there is a defect, it may fail and is thus not reliable. Thus: –Reduce number of defects –… will reduce number of failures –… will increase reliability

Henrik Bærbak Christensen3 Discussion True? –Find example of removing a defect does not increase the system’s reliability at all –Find example of removing defect 1 increase reliability dramatically while removing defect 2 does not

Henrik Bærbak Christensen4 All defects are not equal! So – given a certain amount of time to find defects (you need to sell things to earn money!): What kind of defects should you correct to get best return on investment?

Henrik Bærbak Christensen5 Example Firefox has an enormous amount of possible configurations! Imagine testing all possible combinations! Which one would you test most thoroughly? Henrik Bærbak Christensen5

6 Testing techniques

Henrik Bærbak Christensen7 7 One viewpoint The probability of defects is a function of the code complexity. Thus we may identify three different testing approaches: –No testing. Complexity is so low that the test code will become more complex. Example: set/get methods –Explorative testing: “gut feeling”, experience. TDD relies heavily on ‘making the smart test case’ but does not dictate any method.

Henrik Bærbak Christensen8 Destructive! Testing is a destructive process!!! –In contrast to almost all other SW processes which are constructive! Human psychology –I want to be a success The brain will deliver! –(ok, X-factor shows this is not always the case…) I will prove my software works I will prove my software is really lousy

Henrik Bærbak Christensen9 Morale: When testing, reprogram your brains I am a success if I find a defect. The more I find, the better I am!

Henrik Bærbak Christensen10Henrik Bærbak Christensen10 Our focus There are a lot of different testing techniques. Types: Here – two black box techniques: –Equivalence class partitioning –Boundary value analysis

Henrik Bærbak Christensen11 Equivalence Class Partitioning

Henrik Bærbak Christensen12 Consider Math.abs(x): Absolute value of x –If x is not negative, return x. –If x is negative, return the negation of x. Will these five test cases ensure a reliable implementation?

Henrik Bærbak Christensen13 Two problems A) what is the probability that x=38 will find a defect that x=37 did not expose? B) what is the probability that there will be a defect in handling negative x?

Henrik Bærbak Christensen14 Core insight We can find a single input value that represents a large set of values!

Henrik Bærbak Christensen 15 For Math.abs ECs are subsets of the full input set EC-1 EC-2 X = - 42 | 42

Henrik Bærbak Christensen16 The argumentation The specification will force an implementation where (most likely!) all positive arguments are treated by one code fragment and all negative arguments by another. –Thus we only need two test cases: 1) one that tests the positive argument handling code 2) one that tests the negative argument handling code For 1) x=37 is just as good as x=1232, etc. Thus we simply select a representative element from each EC and generate a test case based upon it.

Note Systematic testing... does not mean –Systematically find all defects and guaranty none are left!!! does mean –Systematically derive a small set of test cases with high probability of finding many defects!!! Henrik Bærbak Christensen17

Specifically Systematic testing cannot in any way counter malicious programming –Virus, easter eggs, evil-minded programmers –(really really lousy programmers) Henrik Bærbak Christensen18

Henrik Bærbak Christensen19 A sound EC partitioning For our ECs to be sound:

Henrik Bærbak Christensen20 Exercise Coverage? Representation? EC-1 EC-2

Henrik Bærbak Christensen21 Exercise The classic blunder at exams! –Representation = two values from the same EC will result in the same behaviour in the algorithm Argue why this is completely wrong! –Consider for instance the Account class’ deposit method… account.deposit(100); account.deposit( );

Henrik Bærbak Christensen22 Documenting ECs Math.abs is simple. Thus the ECs are simple. This is often not the case! Finding ECs require deep thinking, analysis, and iteration. Document them! Equivalence class table:

Henrik Bærbak Christensen23 Invalid/Valid ECs Some input values make an algorithm give up, bail out, or compute answer immediately: –file.open(“nonexisingfile”); g.moveUnitTo([mountain]) Input values that leads to abnormal processing/giving up we classify as belonging to invalid ECs. Those input values that process normally we say belong to valid ECs. fail fast

Henrik Bærbak Christensen24 Finding the ECs Often tricky…

Henrik Bærbak Christensen25Henrik Bærbak Christensen25 Reality Example: Backgammon move validation –validity = v ( move, player, board-state, die-value ) is Red move (B1-B2) valid on this board given this die? –Problem: multiple parameters: player, move, board, die complex parameters: board state coupled parameters: die couples to move! –EC boundary is not a constant!

Henrik Bærbak Christensen26 A process To find the ECs you will need to look carefully at the specification and especially all the conditions associated. –Conditions express choices in our algorithms and therefore typically defines disjoint algorithm parts! –And as the test cases should at least run through all parts of the algorithms, it defines the boundaries for the ECs. … And consider typical programming techniques –Will a program contain if’s and while’s here? Henrik Bærbak Christensen26

Henrik Bærbak Christensen27Henrik Bærbak Christensen27 Partitioning Heuristics 1) If you have a range of values specification –make 3 ECs: [1] in rangevalid [2] above rangeinvalid [3] below rangeinvalid Ex. Standard chess notation/ is “a8” or “x17” valid positions? –Column range: a-hRow range: 1-8

Henrik Bærbak Christensen28Henrik Bærbak Christensen28 Partitioning Heuristics 2) If you have a set, S, of values specification –make |S|+1 ECs [1]..[|S|] one for each member in Svalid [|S|+1 for a value outside Sinvalid Ex. PayStation accepting coins –Set of {5, 10, 25} cents coins

Henrik Bærbak Christensen29Henrik Bærbak Christensen29 Partitioning Heuristics 3) If you have a boolean condition specification –make 2 ECs Ex. the first character must be a letter the object reference must not be null –you get it, right?

Henrik Bærbak Christensen30Henrik Bærbak Christensen30 Partitioning Heuristics 4) If you question the representation property of any EC, then repartition! –Split EC into smaller ECs Examples: shortly

Computation Heuristics Note! Not in FRS, but in a later Appendix! See weekplan Henrik Bærbak Christensen31

Computation Heuristics Example (or a strong hint ) – HotCiv attacks Implementation 1: –Value = attackStrength * dieValue; Implementation 2: –Value = attackStrength; What happens if you choose 1 as die value in all your test cases??? Using the heuristics: –ConditionValid EC Die value{1} [A], {2,3,4,5,6} [B] Henrik Bærbak Christensen32

Henrik Bærbak Christensen33 From ECs to Test cases

Henrik Bærbak Christensen34 Test case generation For disjoint ECs you simply pick an element from each EC to make a test case. Extended test case table Augmented with a column showing which ECs are covered! [2] [1]

Henrik Bærbak Christensen35 Usual case ECs are seldom disjoint – so you have to combine them to generate test cases. Ex. Chess board validation

Henrik Bærbak Christensen36 Combinatorial Explosion Umph! Combinatorial explosion of test cases . Ex. –Three independent input parameters foo(x,y,z) –Four ECs for each parameter That is: –x’s input set divided into four ECs, –y’s input set divided into four ECs, etc. Question: –How many test cases?

Henrik Bærbak Christensen37 Combinatorial Explosion Answer: 4 3 = 64 test cases… TC1: [ECx1],[ECy1],[ECz1] TC2: [ECx1],[ECy1],[ECz2] … TC4: [ECx1],[ECy1],[ECz4] … TC5: [ECx1],[ECy2],[ECz1] … TC9: [ECx1],[ECy3],[ECz1] … TC64: [ECx4],[ECy4],[ECz4]

Henrik Bærbak Christensen38 Myers Heuristics Often, generate test cases like this is better: Rule 2 Rule 1

Henrik Bærbak Christensen39 Why Rule 2? Due to masking –One correct test masks a later incorrect test Ex. Test case (‘ ‘,0) will pass which is expected –Code deemed correct, but this is a wrong conclusion! False positive

Henrik Bærbak Christensen40 Why Rule 1? You may combine as many valid ECs as possible and cover it with only a single test case until all valid ECs are exhausted… Why? Because I must assume that all elements from ECs are used to compute the final result. Any defects will thus most likely show up even if the defect only relate to one element. Ex. bankdayNumberInYear(int month, int day) –return 30*month+day

Henrik Bærbak Christensen41 The Process

Henrik Bærbak Christensen42 Revisited… 5. Review the generated test cases carefully to find what you missed – and iterate!

Henrik Bærbak Christensen43 An Example Phew – let’s see things in practice

Henrik Bærbak Christensen44Henrik Bærbak Christensen44 Example

Henrik Bærbak Christensen45 Exercise Which heuristics to use on the spec?

Henrik Bærbak Christensen46 Process step 1 Result

Henrik Bærbak Christensen47 Process step 2 Review and consider representation property?

Henrik Bærbak Christensen48 Damn – Leap years! Nice to be an astronomer What about the months? Let’s play it safe… (as before)

Henrik Bærbak Christensen49 Process step 3 Coverage?

Henrik Bærbak Christensen50 Process step 4 Generate, using Myers Conclusion: 8 test cases for a rather tricky alg.

Henrik Bærbak Christensen51 Example 2

Henrik Bærbak Christensen52 Formatting Note! Most of the conditions do not really talk about x but on the output. Remember: Conditions in the specs!!!

Henrik Bærbak Christensen53 Exercise What do we do? Range? Boolean? Set? Valid / Invalid ECs?

Henrik Bærbak Christensen54 My analysis 0.0 <= x < [1a]

Henrik Bærbak Christensen55 Test cases 0.0 <= x < [1a]

Henrik Bærbak Christensen56 Boundary value analysis

Henrik Bærbak Christensen57Henrik Bærbak Christensen57 Boundary value analysis Experience shows that test cases focusing on boundary conditions have high payoff. Some that spring into my mind are –iteration over a C array at its max size –”off by one” errors in comparisons if ( x <= MAX_SIZE ) and not if ( x < MAX_SIZE ) –null as value for a reference/pointer

Henrik Bærbak Christensen58Henrik Bærbak Christensen58 Complements EP analysis Ex. Formatting has a strong boundary between EC [1] and [1a] –0.0 (-> ‘000.00’) and (-> ‘---.--’) It is thus very interesting to test x=0.0 as boundary.

Henrik Bærbak Christensen59 Discussion

Henrik Bærbak Christensen60 A few key points

Henrik Bærbak Christensen61 Summary Equivalence Class Partitioning –EC = set of input elements where each one will show same defect as all others in the same set (representation) –Find ECs, use Myers to generate test cases. Boundary analysis –be sceptical about values at the boundaries –Especially on the boundary between valid and invalid ECs