Scribd
Upload
47 views12 pages

Lecture 3 (Online) : Presented By: Naseem Us Sehar

The document discusses test cases and testing methods. It defines test cases as pairs of inputs and expected outcomes. It distinguishes between stateless and state-oriented systems and how their test cases differ. The document also discusses test oracles, the concept of complete testing being impossible, different levels of testing, regression testing, sources of information for test selection, and white-box and black-box testing methods.

Uploaded by

Action Movies
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
47 views12 pages

Lecture 3 (Online) : Presented By: Naseem Us Sehar

The document discusses test cases and testing methods. It defines test cases as pairs of inputs and expected outcomes. It distinguishes between stateless and state-oriented systems and how their test cases differ. The document also discusses test oracles, the concept of complete testing being impossible, different levels of testing, regression testing, sources of information for test selection, and white-box and black-box testing methods.

Uploaded by

Action Movies
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Lecture 3 (online)

Presented by:
Naseem us Sehar
Test Case
• Test Case is a simple pair of
<input, expected outcome>
• State-less systems: A compiler is a stateless system
• Test cases are very simple
• Outcome depends solely on the current input
• State-oriented: ATM is a state oriented system
• Test cases are not that simple. A test case may consist of a sequences of
<input, expected outcome>
• The outcome depends both on the current state of the system and the current
input
• ATM example:
• < check balance, $500.00 >,
• < withdraw, “amount?” >,
• < $200.00, “$200.00” >,
• < check balance, $300.00 >
Expected Outcome
• An outcome of program execution may include
• Value produced by the program
• State Change
• A sequence of values which must be interpreted together for the outcome to
be valid

• A test oracle is a mechanism that verifies the correctness of program


outputs
• Generate expected results for the test inputs
• Compare the expected results with the actual results of execution of the IUT
The Concept of Complete Testing
• Complete or exhaustive testing means
“There are no undisclosed faults at the end of test phase”

• Complete testing is near impossible for most of the system


• The domain of possible inputs of a program is too large
• Valid inputs
• Invalid inputs
• The design issues may be too complex to completely test
• It may not be possible to create all possible execution environments
of the system
The Central Issue in Testing

Divide the input domain D into D1 and D2


Select a subset D1 of D to test program P
It is possible that D1 exercise only a part P1 of P
Testing Activities

• Identify the objective to be tested


• Select inputs
• Compute the expected outcome
• Set up the execution environment of the program
• Execute the program
• Analyze the test results
Testing Level
• Unit testing
• Individual program units, such as procedure, methods in isolation
• Integration testing
• Modules are assembled to construct larger subsystem and tested
• System testing
• Includes wide spectrum of testing such as functionality, and load
• Acceptance testing
• Customer’s expectations from the system
• Two types of acceptance testing
• UAT
• BAT
• UAT: System satisfies the contractual acceptance criteria
• BAT: System will eventually pass the user acceptance test
Testing levels (classical V model)
Regression Testing

• New test cases are not designed


• Test are selected, prioritized and executed
• To ensure that nothing is broken in the new
version of the software
Source of Information for Test Selection
• Requirement and Functional Specifications
• Source Code
• Input and output Domain
• Operational Profile
• Fault Model
• Error Guessing
• Fault Seeding
• Mutation Analysis
White-box Testing
• White-box testing a.k.a. structural testing
• Examines source code with focus on:
• Control flow
• Data flow
• Control flow refers to flow of control from one instruction to another
• Data flow refers to propagation of values from one variable or constant to
another variable
• It is applied to individual units of a program
• Software developers perform structural testing on the individual program
units they write
Black-box Testing
• Black-box testing a.k.a. functional testing
• Examines the program that is accessible from outside
• Applies the input to a program and observe the externally visible
outcome
• It is applied to both an entire program as well as to individual program
units
• It is performed at the external interface level of a system
• It is conducted by a separate software quality assurance group

You might also like