Testing Team exercise Have each team member contribute answers: –Do you test your code? If no, why not? If yes: When? How? How often? –What is your team’s.

Slides:



Advertisements
Similar presentations
1 Integration Testing CS 4311 I. Burnstein. Practical Software Testing, Springer-Verlag, 2003.
Advertisements

Testing and Quality Assurance
System/Software Testing Error detection and removal determine level of reliability well-planned procedure - Test Cases done by independent quality assurance.
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
Black box testing  Black box tests focus on the input/output behavior of the component  Black-box tests do not deal with the internal aspects of the.
April 1, R McFadyen1 A Traditional Software Development Process Unit test Integration test System test Detailed design Architectural design.
Software testing.
Chapter 9 Testing the System, part 2. Testing  Unit testing White (glass) box Code walkthroughs and inspections  Integration testing Bottom-up Top-down.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
System Testing CS 414 – Software Engineering I Don Bagert January 21, 2003.
Software Testing. “Software and Cathedrals are much the same: First we build them, then we pray!!!” -Sam Redwine, Jr.
Chapter 18 Testing Conventional Applications
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.
- Testing programs to establish the presence of system defects -
Outline Types of errors Component Testing Testing Strategy
Chapter 11: Testing The dynamic verification of the behavior of a program on a finite set of test cases, suitable selected from the usually infinite execution.
Software Testing & Strategies
BY RAJESWARI S SOFTWARE TESTING. INTRODUCTION Software testing is the process of testing the software product. Effective software testing will contribute.
Chapter 13 & 14 Software Testing Strategies and Techniques
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
System/Software Testing
Software Testing. Introduction Testing is often left to the end of the project which is generally not a good idea. Testing should be conducted throughout.
Implementation & Integration Phase Implementation, then integration: Implementation, then integration:  Each module is implemented by member of programmer.
Objectives Understand the basic concepts and definitions relating to testing, like error, fault, failure, test case, test suite, test harness. Explore.
Object-Oriented Software Engineering, Ch. 9
CMSC 345 Fall 2000 Unit Testing. The testing process.
Testing phases. Test data Inputs which have been devised to test the system Test cases Inputs to test the system and the predicted outputs from these.
Chapter 12: Software Testing Omar Meqdadi SE 273 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Prof. Mohamed Batouche Software Testing.
Overview of Software Testing 07/12/2013 WISTPC 2013 Peter Clarke.
Introduction to Software Testing
Lecture 11 Testing and Debugging SFDV Principles of Information Systems.
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
Software Testing Testing types Testing strategy Testing principles.
Software Testing The process of operating a system or component under specified conditions, observing and recording the results, and making an evaluation.
Software Testing. 2 CMSC 345, Version 4/12 Topics The testing process  unit testing  integration and system testing  acceptance testing Test case planning.
Software Testing Yonsei University 2 nd Semester, 2014 Woo-Cheol Kim.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
TESTING LEVELS Unit Testing Integration Testing System Testing Acceptance Testing.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects.
Chapter 8 Lecture 1 Software Testing. Program testing Testing is intended to show that a program does what it is intended to do and to discover program.
LECTURE 19 23/11/15 Software Quality and Testing.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
1 CSE 403 Testing Reading: Code Complete, Ch. 22 (McConnell) Object-Oriented Software Engineering, Ch. 9 (B. Bruegge, A. Dutoit) These lecture slides are.
CS451 Lecture 10: Software Testing Yugi Lee STB #555 (816)
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Presentations next week. Presentation stuff again. Finish Testing. Lots more jargon!
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Workshop on Integrating Software Testing into Programming Courses (WISTPC14:2) Friday July 18, 2014 Introduction to Software Testing.
Chapter 12: Software Testing Omar Meqdadi SE 273 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 9, Testing.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
System Testing 12/09. Hierarchy of Testing Testing Program Testing Top Down Bottom Up Integration TestingUnit Testing System Testing Big Bang Sandwich.
CS 325: Software Engineering February 16, 2016 Designing a Design Class Diagram Design Class Diagrams DCD: Restaurant Example DCD: ATM Example Software.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
SOFTWARE TESTING. SOFTWARE Software is not the collection of programs but also all associated documentation and configuration data which is need to make.
Software Testing Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
Defect testing Testing programs to establish the presence of system defects.
Software Testing Strategies for building test group
Rekayasa Perangkat Lunak Part-13
Software Testing Techniques
Chapter 8 – Software Testing
LECTURE 8: Software Testing
Chapter 13 & 14 Software Testing Strategies and Techniques
Lecture 09:Software Testing
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Chapter 11: Integration- and System Testing
Chapter 13 & 14 Software Testing Strategies and Techniques 1 Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Presentation transcript:

Testing Team exercise Have each team member contribute answers: –Do you test your code? If no, why not? If yes: When? How? How often? –What is your team’s test plan? You have one, right? :-)

Some TLAs (Three Letter Acronyms) SQA –Software Quality Assurance many different activities (including good communication, good design, etc) V&V –Verification and Validation Part of SQA Verification: are we building the product right? Validation: are we building the right product? Fault detection –Reviews: Walkthroughs and Inspections –Testing Debugging –what you do once you’ve established that there is a bug

Types of testing Unit testing Integration testing Functional testing Acceptance testing Pilot testing Performance testing Installation testing Usability testing

Who does the testing? Developers Testers Customers

Unit tests Written by developers Tests individual components In TDD (another TLA) unit tests are written before code Automated test frameworks –JUnit –CPPUnit –etc.

Integration testing Testing of components when brought together Different strategies: –big bang: test all components together at once –bottom-up: test layer by layer, from bottom up –top-down: test layer by layer, from top (UI) down Unintegrated components are simulated by stubs during integration testing

Functional testing A whole-system test Also called “requirements testing” Uncovers differences between use-case model and observed system behavior

Acceptance testing Benchmark testing –testing against a specific set of test cases Competitor testing –evaluation wrt competitor product Shadow testing –evaluation wrt legacy system

Pilot testing Field testing –alpha test: system is tested by users in development environment –beta test: system is tested by users in the deployment environment

Performance testing Stress testing – simultaneous requests Volume – large amounts of data Security testing – is it secure? Timing tests – are timing constraints violated? Recover tests – can system recover from errors?

Installation testing Testing of system in deployment environment (after beta test)

Usability testing Is user interface acceptable to users?

Random testing Series of studies done by B. Miller and colleagues First study: Unix utilities (50-85 utilities, depending on OS version, 6 versions) Second study: Unix utilities and X- Windows applications Third study: Windows NT applications

Results How many utilities/applications crashed or hung on random input?

Results How many utilities/applications crashed or hung on random input? first study 25%-33% second study –utilities 40% –applications 25%

Window NT study Similar study for Windows NT, using software/utilities from different vendors (Microsoft, Adobe, Command Software Systems, Qualcomm, Aladdin, Ghostgum, Free Software Foundation, Sun, Netscape, Jasc, Van Dyke, MIT Kerberos Group, Nullsoft, Ipswitch, Metrowerks) 23 applications

Results How many utilities/applications crashed or hung on random input?

Results How many utilities/applications crashed or hung on random input? 21% of applications crashed (valid keyboard/mouse events) Additional 24% hung (valid keyboard/mouse events) 100% crashed or hung with random input streams

Blackbox vs. whitebox testing Blackbox testing considers only input- output behavior of a component. Blackbox testing tests functionality. Whitebox testing considers the internal structure of components. Whitebox testing tests “structural and dynamic aspects of the component” [Bruegge & Dutoit, “Object-Oriented Software Engieering”, p. 448]

Equivalence testing Blackbox technique Partition inputs into equivalence classes. A representative from each equivalence class is used for each test. Assumption: all members of equivalence class will behave the same. [Bruegge & Dutoit, “Object-Oriented Software Engieering”, p. 453]

Example Calendar Month equivalence classes –months with 30 days –months with 31 days –months with 28 or 29 days –Invalid inputs: month 12 Year equivalence classes –non-leap years –leap years –Invalid inputs: year < 0 If method depends on both month and year, we have 2*3=6 equivalence classes. [Bruegge & Dutoit, “Object-Oriented Software Engieering”, p. 454]

Example Calendar Month equivalence classes –months with 30 days –months with 31 days –months with 28 or 29 days –Invalid inputs: month 12 Year equivalence classes –non-leap years –leap years –Invalid inputs: year < 0 If method depends on both month and year, we have 2*3=6 equivalence classes (My question: why not 4*3=12?) [Bruegge & Dutoit, “Object-Oriented Software Engieering”, p. 454]

Boundary testing Test boundaries of equivalence classes In example, February yields many boundary cases. Leap years are years divisible by 4, unless divisible by 100, unless divisible by 400. –leap years divisible by 400 (e.g. Feb 2, 2000) –non-leap years divisible by 100 (e.g. Feb 2, 1900) [Bruegge & Dutoit, “Object-Oriented Software Engieering”, p. 454]

Path testing Whitebox testing Ensure that all paths through the code are exercised Start with a flow graph (a graph whose nodes are executable blocks of code and whose edges represent flow of control) Test cases must cover each edge in graph Minimum number of test cases required is the number of independent paths in graph, which is # edges - # nodes + 2 Can work off of activity diagram [Bruegge & Dutoit, “Object-Oriented Software Engieering”, p. 456]

State-based testing Whitebox testing Ensures that state transitions of system work as expected Works off of statechart diagram [Bruegge & Dutoit, “Object-Oriented Software Engieering”, p. 459]

Unit Testing Example In this exercise we will develop a simple class (RationalNumber) in a TDD fashion.

Properties A rational number is of the form n/d, where n is an integer, and d is an integer except zero. Rational numbers can be added, multiplied, tested for equality. Each rational number has an additive inverse (its negative) and a multiplicative inverse (its reciprocal).

Rational class Will provide public constructor: public Rational(int numerator, int denominator); Will provide public methods: public Rational add(Rational r); public Rational negative(); public Rational multiply(Rational r); public Rational reciprocal(); public boolean equals(Object obj);

Exercise structure Break into 6 groups Each group identifies tests to perform on their operation (construction, addition, negative, multiplication, reciprocal, equals) I will write the tests, then we will write the code