Informatics 43 – April 28, 2016.

Slides:



Advertisements
Similar presentations
การทดสอบโปรแกรม กระบวนการในการทดสอบ
Advertisements

Testing and Quality Assurance
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Introduction to Software Engineering Lecture 11 André van der Hoek.
Software Architecture Prof.Dr.ir. F. Gielen
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
Informatics 43 – May 7, Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases  No.
Informatics 43 – May 12, Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases 
Informatics 43 – May 5, Restatement of goals Want to verify software’s correctness  Need to test  Need to decide on test cases  No set of test.
1 CODE TESTING Principles and Alternatives. 2 Testing - Basics goal - find errors –focus is the source code (executable system) –test team wants to achieve.
Informatics 43 – April 30, What is a test case? An input to a system, and the correct output. An “input” may be complex. Example: – What is an input.
16/27/2015 3:38 AM6/27/2015 3:38 AM6/27/2015 3:38 AMTesting and Debugging Testing The process of verifying the software performs to the specifications.
Testing an individual module
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Outline Types of errors Component Testing Testing Strategy
Software Testing Prasad G.
Types and Techniques of Software Testing
Issues on Software Testing for Safety-Critical Real-Time Automation Systems Shahdat Hossain Troy Mockenhaupt.
BY RAJESWARI S SOFTWARE TESTING. INTRODUCTION Software testing is the process of testing the software product. Effective software testing will contribute.
1 Functional Testing Motivation Example Basic Methods Timing: 30 minutes.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
BY: GARIMA GUPTA MCA FINAL YEAR WHAT IS SOFTWARE TESTING ? SOFTWARE TESTING IS THE PROCESS OF EXECUTING PROGRAMS OR SYSTEM WITH THE INTENT.
System/Software Testing
CMSC 345 Fall 2000 Unit Testing. The testing process.
1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing.
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
Software Testing The process of operating a system or component under specified conditions, observing and recording the results, and making an evaluation.
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.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
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.
SOFTWARE TESTING. INTRODUCTION Testing forms the first step in determining the errors in a program. It is the major quality control measure used during.
Test Case Designing UNIT - 2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Dynamic Testing.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
Week 6 MondayTuesdayWednesdayThursdayFriday Testing III Reading due Group meetings Testing IVSection ZFR due ZFR demos Progress report due Readings out.
Informatics 43 – May 3, Restatement of goals Want to verify software’s correctness  Need to test  Need to decide on test cases  No set of test.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
ANOOP GANGWAR 5 TH SEM SOFTWARE TESTING MASTER OF COMPUTER APPLICATION-V Sem.
Informatics 43 – May 5, Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases  No.
Test Plans Test Driven Development – Unit test plan first Code coverage Automated Regression built as you go Debug is easier Serves as system doc – Still.
Software Testing. Software Quality Assurance Overarching term Time consuming (40% to 90% of dev effort) Includes –Verification: Building the product right,
Dr. Rozmie Razif bin Othman
SaralTA Batch-07 Software Testing Presented By - Chittaranjan M.
Software Testing Strategies for building test group
Software Testing.
Informatics 43 – May 10, 2016.
John D. McGregor Session 9 Testing Vocabulary
Chapter 9, Testing.
SUCHITA M.DAKI TYIT(sem v)
Software engineering – 1
Chapter 13 & 14 Software Testing Strategies and Techniques
John D. McGregor Session 9 Testing Vocabulary
Testing Approaches.
Informatics 43 – May 3, 2016.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
John D. McGregor Session 9 Testing Vocabulary
Introduction to Software Testing
Lecture 09:Software Testing
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
CS240: Advanced Programming Concepts
Chapter 10 – 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.
CS410 – Software Engineering Lecture #11: Testing II
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software Testing.
Software Testing Strategies
08120: Programming 2: SoftwareTesting and Debugging
Chapter 13 & 14 Software Testing Strategies and Techniques 1 Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Presentation transcript:

Informatics 43 – April 28, 2016

What is testing? Running some code. Determining if the output is correct.

What is a test case? An input to a system, and the correct output. An “input” may be complex. Example: What is an input to WebReg, when you enroll in a class? What is the correct output?

Where do test cases come from, Mommy?

Goals for selecting test cases -- 100% Confidence in module being tested Number of test cases with correct outputs – not well chosen -- 100% Confidence in module being tested Number of test cases with correct outputs – well chosen “A well-chosen set of test cases means more confidence, sooner.”

More goals for selecting test cases Detect defects Locate defects Qualities Accurate Complete thorough Repeatable Systematic

Levels and types of testing Unit / component Integration testing System testing (same as integration testing, with entire codebase) Acceptance Volume / stress Regression

Restatement of goals Want to verify software’s correctness  Need to test  Need to decide on test cases  No set of test cases is sufficient

Restatement of goals Want to verify software’s correctness  Need to test  Need to decide on test cases  No set of test cases is sufficient What is a systematic approach to the selection of test cases that will lead to accurate, thorough, repeatable identification of bugs?

Approaches to test case selection “White box” – or structural Test cases based on the structure of the code Can be partially automated “Thorough”ness measured against code qualities “Black box” – or specification based Test cases based on specifications Requires “formal” specs to automate “Thorough”ness measured against either the set of functionalities, or the set of inputs

White box example What test cases are required to make sure every line of code is executed at least once? to make sure every branch is taken at least once? to make sure that all possible error conditions are encountered? a  17 read b from textbox if b is not numeric do error routine if a < b while a < b-3 a  a / (b–50) print a, b

White box example What test cases are required to make sure every line of code is executed at least once? “Code coverage” to make sure every branch is taken at least once? “Branch coverage” to make sure that all possible error conditions are encountered? a  17 read b from textbox if b is not numeric do error routine if a < b while a < b-3 a  a / (b–50) print a, b

Black box example From the (eventual) Requirements Specification: “A substitute teacher who is nearest to the school is selected, all other factors being equal.” What test cases are required to make sure the user interface actually updates internal data stores? determine if a sub’s location is correctly used when determining the substitute’s distance to a school? verify that invalid inputs are rejected?

The Testing Process Model Decide what to test. Select a test case input, with input I. Determine the expected output E. Run the system with the test case input I. Capture the actual output A. Compare E and A. Different? Inform programmer Loop back to 1 or 2, if time permits.

Back to Black box test case selection Based on specifications, not source code. How to select inputs for test cases? Typical values Boundary values Extreme values Special cases Invalid values Values you suspect might cause a failure Environmental factors, such as date, type of user This is all pretty haphazard.

Back to Black box test case selection Equivalence Class Partitioning – a systematic approach. Identify the set of all possible inputs (to what is being tested). Identify a basis for subdividing the set of inputs. stated requirements size, order, structure your smarts Use this basis to divide the set of all possible inputs into subsets (domain into subdomains). From each subset/subdomain, select a representative to be a test case input.

Back to Black box test case selection An example: The QuizAverage function: Input: a list of numbers Output: a single number which is the average of the numbers on the input list, not counting the lowest number on the list.