Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Software Engineering
MCA-303

Mayank Gupta(Student of MCA)
ABES Engineering College, Ghaziabad
Software Testing
Software testing is the process of testing the
software product.
Effective software testing is the delive...
Testing Objectives
In an excellent book on software testing, Glen
Myers states a number of rules that can serve well
as te...
•
Software testing is process of executing
software in a controlled manner.
•
The objective of testing is to show
incorrec...
The goal of testing is to find bugs and fixed them
as early as possible. But testing is potentially
endless process.
We ca...
Test case

Test case is a set of test data and test programs
(test scripts) and their expected results. A test
case valida...
Test suite

Test suite is a collection of test scenarios and / or
test cases that are related or that may cooperate
with e...
Test Scenario
Test scenario is set of test cases that ensure that
the business process flows are tested from end to
end .
...
Testing Principles
• All tests should be traceable to customer requirements.
• Tests should be planned long before testing...
Manual Testing
Test case generation with using
paper
Automation Testing
WINRUNNER
QTP
LOAD RUNNER
SELINIUM
etc.

Pen and
Test Case generation Format-1
Test
Cas
e ID

Descriptio
n/ function

Test
Prerequisit
e

I/O
Action

Expected
Values

Test...
WHITE-BOX TESTING
White-box testing, sometimes called glass-box
testing, is a test case design method that uses the
contro...
WHITE-BOX TESTING
Using white-box testing methods, the software
engineer can derive test cases that
(1) Guarantee that all...
Boundary value analysis
It is a test case design technique
complements equivalence partitioning.

that

Rather than select...
Guidelines for BVA are similar in many respects
to those provided for equivalence partitioning:
1. If an input condition s...
3. Apply guidelines 1 and 2 to output
conditions.
For example, assume that a temperature vs.
pressure table is required as...
Testing Strategies
Software Testing Steps
Unit testing
Unit testing focuses verification effort on the
smallest unit of software design—the software
component or mo...
Unit testing
The relative complexity of tests and uncovered
errors is limited by the constrained scope
established for uni...
Unit testing
Unit testing is the first level of dynamic testing and is
first the responsibility of developers and then tha...
User Acceptance Testing
User Acceptance testing occurs just before the
software is released to the customer.
The end-users...
When custom software is built for one customer,
a series of acceptance tests are conducted to
enable the customer to valid...
Integration Testing
Integration testing is a systematic technique for
constructing the program structure while at the
same...
Top-Down Integration
Top-down integration testing is an incremental
approach to construction of program structure.
Modules...
The Integration process is performed in a
series of five steps:
1.The main control module is used as a test
driver and stu...
3.Tests are conducted as each component is
integrated.
4.On completion of each set of tests, stub is
replaced with the rea...
Bottom-Up Integration
Bottom-up integration testing begins construction
and testing with atomic modules (i.e. components a...
A Bottom-up integration strategy
implemented with the following steps

may

be

1. Low level components are combined into ...
Performance testing
It is designed to test the run-time performance of
software within the context of an integrated system...
The Designing Process
Performance tests are often coupled with stress
testing and usually require both hardware and
software instrumentation.
Th...
Regression Testing
Each time a new module is added as part of
integration testing, the software changes.
New data flow pat...
Regression testing is the activity that helps to
ensure that changes (due to testing or for other
reasons) do not introduc...
The regression test suite (the subset of tests to
be executed) contains three different
classes of test cases:
• A represe...
As integration testing proceeds, the number of
regression tests can grow quite large.
Therefore, the regression test suite...
Smoke testing is an integration testing approach
that is commonly used when “shrink wrapped”
software products are being d...
1. Software components that have been
translated into code are integrated into a “build.”
A build includes all data files,...
3. The build is integrated with other builds and the
entire product (in its current form) is smoke tested
daily. The integ...
Smoke testing
The smoke test should exercise the entire
system from end to end.
It does not have to be exhaustive, but it
...
Black-box testing
Black-box testing, also called behavioral testing,
focuses on the functional requirements of the
softwar...
Black-box testing attempts to find errors in the
following categories:
(1)Incorrect or missing functions,
(2)interface err...
Black-box testing purposely disregards control
structure, attention is focused on the information
domain.
Tests are design...
• How are the boundaries of a data class
isolated?
• What data rates and data volume can the
system tolerate?
• What effec...
Black box is a test design method. Black box
testing treats the system as a "black-box", so it
doesn't explicitly use Know...
Some people like to call black box testing as
behavioral, functional, opaque-box, and closedbox.
While the term black box ...
Advantages of Black Box Testing
• Tester can be non-technical.
• This testing is most likely to find those bugs as
the use...
Disadvantages of Black Box Testing
• Chances of having repetition of tests that are
already done by programmer.
• The test...
Black-Box Testing
•
•
•
•
•

Graph-Based Testing Methods
Equivalence Partitioning
Boundary Value Analysis
Comparison Testi...
White Box testing
•Basic Path Testing
•Flow Graph Notation
•Cyclomatic Complexity
•Graph Matrices
•Control Structure Testi...
Structure
approach

of
[

testing
Functional Testing
{User Interface Testing,
Validation testing, functionality testing}

...
Alpha Testing
A software prototype stage when
software is first available for run.

the

Here the software has the core fu...
Aim
•is to identify any serious errors
•to judge if the indented functionalities are implemented
•to provide to the custom...
– Client uses the software at the
developer’s environment.
– Software used in a controlled
setting, with the developer
alw...
Alpha testing is simulated or actual operational testing
by potential users/customers or an independent test
team at the d...
Beta Testing
The Beta testing is conducted at one or more customer
sites by the end-user of the software.
The beta test is...
Beta Testing Objectives
Evaluate software technical content
Evaluate software ease of use
Evaluate user documentation draf...
Beta Testing

– Conducted at client’s
(developer is not present)

environment

– Software gets a realistic workout in targ...
• Beta testing comes after alpha testing. Versions
of the software, known as beta versions, are
released to a limited audi...
• Beta Tests are conducted by the customers /
end users at their sites.
• Unlike alpha testing, developer is not present
h...
software testing
Upcoming SlideShare
Loading in …5
×

software testing

1,700 views

Published on

Published in: Technology, Education
  • Be the first to comment

software testing

  1. 1. Software Engineering MCA-303 Mayank Gupta(Student of MCA) ABES Engineering College, Ghaziabad
  2. 2. Software Testing Software testing is the process of testing the software product. Effective software testing is the delivery of higher quality software products , more satisfied users, lower maintenance costs, more accurate and reliable results. However, ineffective testing will lead to opposite results, low quality products, unhappy users, increased maintenance cost s, unreliable and in accurate results.
  3. 3. Testing Objectives In an excellent book on software testing, Glen Myers states a number of rules that can serve well as testing objectives: 1.Testing is a process of executing a program with the intent of finding an error. 2. A good test case is one that has a high probability of finding an as-yet-undiscovered error. 3. A successful test is one that uncovers an as-yetundiscovered error.
  4. 4. • Software testing is process of executing software in a controlled manner. • The objective of testing is to show incorrectness and testing is considered to success when error is detected (Myers 1979). • Software testing involves operation of a system or application under controlled conditions and evaluating results. • The controlled condition should include both normal and abnormal conditions.
  5. 5. The goal of testing is to find bugs and fixed them as early as possible. But testing is potentially endless process. We cannot test till all the defects are unearthed and removed -- it is simply impossible and expensive. At some point, we have to stop testing and ship the software.
  6. 6. Test case Test case is a set of test data and test programs (test scripts) and their expected results. A test case validates one or more system requirements and generates a pass or fail.
  7. 7. Test suite Test suite is a collection of test scenarios and / or test cases that are related or that may cooperate with each other. In other words Test suit contains set of test cases ,which are both related or unrelated
  8. 8. Test Scenario Test scenario is set of test cases that ensure that the business process flows are tested from end to end . They may be independent tests or a series of tests that follow each other , each dependent on the output of the previous one . The terms “ test scenario “ and test case” are often synonymously.
  9. 9. Testing Principles • All tests should be traceable to customer requirements. • Tests should be planned long before testing begins. • Testing should begin “in the small” and progress toward testing “in the large.” • Exhaustive testing is not possible. • To be most effective, testing should be conducted by an independent third party.
  10. 10. Manual Testing Test case generation with using paper Automation Testing WINRUNNER QTP LOAD RUNNER SELINIUM etc. Pen and
  11. 11. Test Case generation Format-1 Test Cas e ID Descriptio n/ function Test Prerequisit e I/O Action Expected Values Test Case generation Format-1 Test Case No. Test Case Procedure purpose Expected Result ID which can What to test be referred to in other documents like ‘Traceability Matrix’, Root Cause Analysis of Defects etc. What should What actually happen happened? This column can be omitted when Defect Recording Tool is used. How to test Actual result
  12. 12. WHITE-BOX TESTING White-box testing, sometimes called glass-box testing, is a test case design method that uses the control structure of the procedural design to derive test cases. White box testing is based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths and conditions.
  13. 13. WHITE-BOX TESTING Using white-box testing methods, the software engineer can derive test cases that (1) Guarantee that all independent paths within a module have been exercised at least once, (2) exercise all logical decisions on their true and false sides, (3) execute all loops at their boundaries and within their operational bounds, and (4) exercise internal data structures to ensure their validity.
  14. 14. Boundary value analysis It is a test case design technique complements equivalence partitioning. that Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the "edges" of the class. Rather than focusing only on input conditions, BVA derives test cases from the output domain as well
  15. 15. Guidelines for BVA are similar in many respects to those provided for equivalence partitioning: 1. If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b and just above and just below a and b. 2. If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below minimum and maximum are also tested.
  16. 16. 3. Apply guidelines 1 and 2 to output conditions. For example, assume that a temperature vs. pressure table is required as output from an engineering analysis program. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries. 4. If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary.
  17. 17. Testing Strategies
  18. 18. Software Testing Steps
  19. 19. Unit testing Unit testing focuses verification effort on the smallest unit of software design—the software component or module. Using the component-level design description as a guide, important control paths are tested to uncover errors within the boundary of the module.
  20. 20. Unit testing The relative complexity of tests and uncovered errors is limited by the constrained scope established for unit testing. The unit test is white-box oriented, and the step can be conducted in parallel for multiple components.
  21. 21. Unit testing Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineer . Unit testing is performed after the expected test results are met or differences are explainable/acceptable.
  22. 22. User Acceptance Testing User Acceptance testing occurs just before the software is released to the customer. The end-users along with the developers perform the User Acceptance Testing with a certain set of test cases and typical scenarios.
  23. 23. When custom software is built for one customer, a series of acceptance tests are conducted to enable the customer to validate all requirements. Conducted by the enduser rather than software engineers, an acceptance test can range from an informal "test drive" to a planned and systematically executed series of tests. In fact, acceptance testing can be conducted over a period of weeks or months, thereby uncovering cumulative errors that might degrade the system over time.
  24. 24. Integration Testing Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure that has been dictated by design. Usually, the following methods of Integration testing are followed: 1. Top-down Integration approach. 2. Bottom-up Integration approach.
  25. 25. Top-Down Integration Top-down integration testing is an incremental approach to construction of program structure. Modules are integrated by moving downward through the control hierarchy, beginning with the main control module. Modules subordinate to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.
  26. 26. The Integration process is performed in a series of five steps: 1.The main control module is used as a test driver and stubs are substituted for all components directly subordinate to the main control module. 2.Depending on the integration approach selected subordinate stubs are replaced one at a time with actual components.
  27. 27. 3.Tests are conducted as each component is integrated. 4.On completion of each set of tests, stub is replaced with the real component. 5.Regression testing may be conducted to ensure that new errors have not been introduced.
  28. 28. Bottom-Up Integration Bottom-up integration testing begins construction and testing with atomic modules (i.e. components at the lowest levels in the program structure). Because components are integrated from the bottom up, processing required for components subordinate to a given level is always available and the need for stubs is eliminated.
  29. 29. A Bottom-up integration strategy implemented with the following steps may be 1. Low level components are combined into clusters that perform a specific software sub function. 2. A driver is written to coordinate test case input and output. 3. The cluster is tested.
  30. 30. Performance testing It is designed to test the run-time performance of software within the context of an integrated system. Performance testing occurs throughout all steps in the testing process. Even at the unit level, the performance of an individual module may be assessed as white-box tests are conducted. However, it is not until all system elements are fully integrated that the true performance of a system can be ascertained.
  31. 31. The Designing Process
  32. 32. Performance tests are often coupled with stress testing and usually require both hardware and software instrumentation. That is, it is often necessary to measure resource utilization (e.g., processor cycles) in an exacting fashion. External instrumentation can monitor execution intervals, log events (e.g., interrupts) as they occur, and sample machine states on a regular basis. By incrementing a system, the tester can uncover situations that lead to degradation and possible system failure.
  33. 33. Regression Testing Each time a new module is added as part of integration testing, the software changes. New data flow paths are established, new I/O may occur, and new control logic is invoked. These changes may cause problems with functions that previously worked flawlessly. In the context of an integration test strategy, regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.
  34. 34. Regression testing is the activity that helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors. Regression testing may be conducted manually, by re-executing a subset of all test cases or using automated capture/playback tools. Capture/playback tools enable the software engineer to capture test cases and results for subsequent playback and comparison
  35. 35. The regression test suite (the subset of tests to be executed) contains three different classes of test cases: • A representative sample of tests that will exercise all software functions. • Additional tests that focus on software functions that are likely to be affected by the change. • Tests that focus on the software components that have been changed.
  36. 36. As integration testing proceeds, the number of regression tests can grow quite large. Therefore, the regression test suite should be designed to include only those tests that address one or more classes of errors in each of the major program functions. It is impractical and inefficient to re-execute every test for every program function once a change has occurred.
  37. 37. Smoke testing is an integration testing approach that is commonly used when “shrink wrapped” software products are being developed. It is designed as a pacing mechanism for timecritical projects, allowing the software team to assess its project on a frequent basis. In essence, the smoke testing approach encompasses the following activities:
  38. 38. 1. Software components that have been translated into code are integrated into a “build.” A build includes all data files, libraries, reusable modules, and engineered components that are required to implement one or more product functions. 2. A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule.
  39. 39. 3. The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.
  40. 40. Smoke testing The smoke test should exercise the entire system from end to end. It does not have to be exhaustive, but it should be capable of exposing major problems. The smoke test should be thorough enough that if the build passes, you can assume that it is stable enough to be tested more thoroughly.
  41. 41. Black-box testing Black-box testing, also called behavioral testing, focuses on the functional requirements of the software. That is, black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Black-box testing is not an alternative to whitebox techniques. Rather, it is a complementary approach that is likely to uncover a different class of errors than white-box methods.
  42. 42. Black-box testing attempts to find errors in the following categories: (1)Incorrect or missing functions, (2)interface errors, (3)errors in data structures or external data base access, (4) behavior or performance errors, and (5) initialization and termination errors.
  43. 43. Black-box testing purposely disregards control structure, attention is focused on the information domain. Tests are designed to answer the following questions: • How is functional validity tested? • How is system behavior and performance tested? • What classes of input will make good test cases?
  44. 44. • How are the boundaries of a data class isolated? • What data rates and data volume can the system tolerate? • What effect will specific combinations of data have on system operation?
  45. 45. Black box is a test design method. Black box testing treats the system as a "black-box", so it doesn't explicitly use Knowledge of the internal structure. Or in other words the Test engineer need not know the internal working of the “Black box”. It focuses on the functionality part of the module.
  46. 46. Some people like to call black box testing as behavioral, functional, opaque-box, and closedbox. While the term black box is most popularly use, many people prefer the terms "behavioral" and "structural" for black box and white box respectively. Behavioral test design is slightly different from black-box test design because the use of internal knowledge isn't strictly forbidden, but it's still discouraged.
  47. 47. Advantages of Black Box Testing • Tester can be non-technical. • This testing is most likely to find those bugs as the user would find. • Testing helps to identify the vagueness and contradiction in functional specifications. • Test cases can be designed as soon as the functional specifications are complete
  48. 48. Disadvantages of Black Box Testing • Chances of having repetition of tests that are already done by programmer. • The test inputs needs to be from large sample space. • It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult Chances of having unidentified paths during this testing
  49. 49. Black-Box Testing • • • • • Graph-Based Testing Methods Equivalence Partitioning Boundary Value Analysis Comparison Testing Orthogonal Array Testing
  50. 50. White Box testing •Basic Path Testing •Flow Graph Notation •Cyclomatic Complexity •Graph Matrices •Control Structure Testing Condition Testing Data Flow Testing •Loop Testing Simple Loops Nested Loops Concatenated Loops Unstructured Loops •Data Structure
  51. 51. Structure approach of [ testing Functional Testing {User Interface Testing, Validation testing, functionality testing} ] [ Integration {Intra-Modular Testing, Application and System Testing, Integration Testing} ], [ Performance Testing {Load Testing, Stress Testing, Volume Testing, Stability Testing} ], [ System Testing {Usability Testing, Accessibility Testing, Compatibility Testing, Portability Testing, Localization Testing, Security Testing (Web, Window)} ]
  52. 52. Alpha Testing A software prototype stage when software is first available for run. the Here the software has the core functionalities in it but complete functionality is not aimed at. It would be able to accept inputs and give outputs. Usually the most used functionalities (parts of code) are developed more. The test is conducted at the developer’s site only.
  53. 53. Aim •is to identify any serious errors •to judge if the indented functionalities are implemented •to provide to the customer the feel of the software
  54. 54. – Client uses the software at the developer’s environment. – Software used in a controlled setting, with the developer always ready to fix bugs.
  55. 55. Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing. Alpha Tests are conducted at the developer’s site by some potential customers. These tests are conducted in a controlled environment. Alpha testing may be started when formal testing process is near completion.
  56. 56. Beta Testing The Beta testing is conducted at one or more customer sites by the end-user of the software. The beta test is a live application of the software in an environment that cannot be controlled by the developer.
  57. 57. Beta Testing Objectives Evaluate software technical content Evaluate software ease of use Evaluate user documentation draft Identify errors Report errors/findings
  58. 58. Beta Testing – Conducted at client’s (developer is not present) environment – Software gets a realistic workout in target environment
  59. 59. • Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. • The software is released to groups of people so that further testing can ensure the product has few faults or bugs. • Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.
  60. 60. • Beta Tests are conducted by the customers / end users at their sites. • Unlike alpha testing, developer is not present here. • Beta testing is conducted in a real environment that cannot be controlled by the developer

×