Scribd
Upload
40 views

9010 Testing

Testing is done at various levels including unit, integration, system, and acceptance testing. Unit testing checks individual code modules in isolation and is done by programmers. Integration testing checks interactions between code modules. System testing verifies overall system functionality and performance. Acceptance testing is done by users to check that requirements are met. Regression testing checks for new issues caused by code changes.

Uploaded by

Shefali Mittal
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
40 views

9010 Testing

Testing is done at various levels including unit, integration, system, and acceptance testing. Unit testing checks individual code modules in isolation and is done by programmers. Integration testing checks interactions between code modules. System testing verifies overall system functionality and performance. Acceptance testing is done by users to check that requirements are met. Regression testing checks for new issues caused by code changes.

Uploaded by

Shefali Mittal
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 23

Software Testing

Testing
One of the practical methods commonly used to detect the presence of errors (failures) in a computer program is to test it for a set of inputs.
The output is correct?
I1, I2, I3, , In,
Our program Expected results =? Obtained results

Inputs

- No code inspection - No model checking 2 - No debugging

- No code analysis - No bug fixing

Testing: four main questions


At which level conduct the testing?
Unit Integration System

How to choose inputs?


using the specifications/use cases/requirements using the code

How to identify the expected output?

Test oracles
When we can stop the testing activity

How good test cases are?

Objectives of testing
Executing a program with the intent of finding an error. To check if the system meets the requirements and be executed successfully in the Intended environment. To check if the system is Fit for purpose. To check if the system does what it is expected to do.

Objective of a Software Tester


Find bugs as early as possible and make sure they get fixed. To understand the application well. Study the functionality in detail to find where the bugs are likely to occur. Study the code to ensure that each and every line of code is tested. Create test cases in such a way that testing is done to uncover the hidden bugs and also ensure that the software is usable and reliable

VERIFICATION & VALIDATION


Verification - typically involves reviews and meeting to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meeting.

Validation - typically involves actual testing and takes place after verifications are completed. Validation and Verification process continue in a cycle till the software becomes defects free.

Testing Levels

Unit testing Integration testing System testing Acceptance testing

Unit testing
The most micro scale of testing. Tests done on particular functions or code modules. Requires knowledge of the internal program design and code. Done by Programmers (not by testers).

Unit testing
Objectives To test the function of a program or unit of code such as a program or module To test internal logic To verify internal design To test path & conditions coverage To test exception conditions & error handling When After modules are coded Input Internal Application Design Master Test Plan Unit Test Plan Output Unit Test Report

Integration Testing

Testing of combined parts of an application to determine their functional correctness.


Parts can be code modules individual applications client/server applications on a network.

Types of Integration Testing


Big Bang testing
Top Down Integration testing Bottom Up Integration testing

Integration testing Objectives

To technically verify proper interfacing between modules, and within sub-systems After modules are unit tested

When

Input

Internal & External Application Design Master Test Plan Integration Test Plan
Integration Test report

Output

Big Bang Integration


Non-incremental strategy
Unit test each module in isolation Integrate as a whole
main

test main
C

test A
F

test C

test B test D

test main, A, B, C D, E, F

test E

test F

Big Bang Integration


Advantages
Convenient for small systems

Disadvantages
Integration testing can only begin when all modules are ready Fault localization difficult Easy to miss interface faults

Top-down Integration
Incremental strategy 1. Start by including highest level modules in test set. All other modules replaced by stubs or mock objects. 2. Integrate (i.e. replace stub by real module) modules called by called by modules in test set. 3. Repeat until all modules in test set. main
A B C

test main

test main, A, B,C

test main, A, B, C D, E, F

Top-down Integration
Advantages Fault localization easier Few or no drivers needed Different order of testing/implementation possible Major design flaws found first in logic modules on top of the hierarchy Disadvantages Need lot of stubs / mock objects

Bottom-up Integration
Incremental strategy
Test low-level modules Modules calling them until highest level module
main

test D
C

test D,E,A

test E
F

test B
test C,F

test main, A, B, C D, E, F

test F

Bottom-up Integration
Advantages Fault localization easier (than big-bang) No need for stubs / fewer mock objects Logic modules tested thoroughly Testing can be in parallel with implementation Disadvantages Need drivers High-level modules (that relate to the solution logic) tested in the last (and least)

Stub and Driver


Stub means a Dummy model of a particular module. Suppose we have to test the interface between 2 modules A and B and we have developed only module A while Module B is yet in development stage. So in such case we can not test module A but, if we prepare a dummy module, having similar features like B then using that we can test module A. Our main aim in this is to test Module A & not Module B so that we can save time otherwise we have to wait till the module B is actually developed. Hence this dummy module B is called as Stub. Now module B cannot send/receive data from module A directly/automatically so, in such case we have to transfer data from one module to another module by some external features. This external feature used is called Driver.

System Testing
Objectives

To verify that the system components perform control functions To perform inter-system test To demonstrate that the system performs both functionally and operationally as specified To perform appropriate types of tests relating to Transaction Flow, Installation, Reliability, Regression etc.

When Input

After Integration Testing

Output

Detailed Requirements & External Application Design Master Test Plan System Test Plan System Test Report

Acceptance Testing Objectives When Input


Output

To verify that the system meets the user requirements After System Testing Business Needs & Detailed Requirements Master Test Plan User Acceptance Test Plan User Acceptance Test report

Types of Acceptance Testing


Alpha Testing: done at developers site. Beta Testing: done at users site.

Regression Testing
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them. The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults. One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.

You might also like