1 / 74

UNIT-IV

UNIT-IV. TESTING STRATEGIES - Prasad Mahale. A STRATEGIC APPROACH TO SOFTWARE TESTING. To perform effective testing, you should conduct effective technical reviews . By doing this, many errors will be eliminated before testing commences.

semple
Télécharger la présentation

UNIT-IV

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UNIT-IV TESTING STRATEGIES -Prasad Mahale

  2. A STRATEGIC APPROACH TO SOFTWARE TESTING • To perform effective testing, you should conduct effective technical reviews. By doing this, many errors will be eliminated before testing commences. • Testing begins at the component level and works “outward” toward the integration of the entire computer-based system.

  3. Different testing techniques are appropriate for different software engineering approaches and at different points in time. • Testing is conducted by the developer of the software and (for large projects) an independent test group. • Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.

  4. Software testing is a process, to evaluate the functionality of a software application with an intent to find whether the developed software met the specified requirements or not and to identify the defects to ensure that the product is defect free in order to produce the quality product.

  5. A STRATEGIC APPROACH TO SOFTWARE TESTING Verification and Validation • Verification: “Are we building the product right?” • Validation: “Are we building the right product?” SQA activities: • Technical reviews, quality and configuration audits, performance monitoring, simulation, feasibility study, documentation review, database review, algorithm analysis, development testing, usability testing, qualification testing, acceptance testing, and installation testing.

  6. Difference between Verification and Validation

  7. A STRATEGIC APPROACH TO SOFTWARE TESTING Software Testing Strategy—The Big Picture

  8. A STRATEGIC APPROACH TO SOFTWARE TESTING Criteria for completion of testing • One question arises : “when we done testing- how do we know that we’ve tested enough”. • Response is “You're never done testing; the burdon only shifts from you ”. • Need more rigorous criteria for determining for sufficient testing. • It is possible to develop meaningful answer for guidelines.

  9. STRATEGIC ISSUES software testing strategy will succeed when software testers: • Specify product requirements in a proven manner long before testing commences. (portability, maintainability & usability) • State testing objectives explicitly. (test effectiveness, coverage, time to failure, find and fix defects, test work hour) • Understand the users of the software and develop a profile for each user category. (that describe the interaction scenario)

  10. Develop a testing plan that emphasizes “rapid cycle testing.” • Build “robust” software that is designed to test itself. • Use effectives technical reviews as a filter prior to testing. • Conduct technical reviews to assess the test strategy and test cases themselves. (Review) • Develop a continuous improvement approach for the testing process.

  11. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE • Unit Testing • Unit testing focus on the smallest unit of software design, i.e module or software component. • Test strategy conducted on each module interface to access the flow of input and output. • The local data structure is accessible to verify integrity during execution. • Boundary conditions are tested. • In which all error handling paths are tested. • An Independent path is tested.

  12. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE • Unit Testing Unit-test considerations

  13. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE Unit-test procedures

  14. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE

  15. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE • Integration Testing 1. Top-down

  16. Top-down integration testing is an integration testing technique used in order to simulate the behavior of the lower-level modules that are not yet integrated. • Stubs are the modules that act as temporary replacement for a called module and give the same output as that of the actual product. • The replacement for the 'called' modules is known as 'Stubs' and is also used when the software needs to interact with an external system. Stub - Flow Diagram:

  17. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE 2. Bottom-up integration

  18. The order of Integration by Bottom-down approach will be: 4,2 5,2 6,3 7,3 2,1 3,1 • Each component at lower hierarchy is tested individually and then the components that rely upon these components are tested. • Bottom Up Integration - Flow Diagram

  19. Regression testing • Each time a new model is added as part of integration testing, the software testing. • This is the reexecution of subset of some subset of test that already conducted to ensure that changes never unintended changes. • By reexecuting a subset of all test cases or using automated capture/playback tools. • Additional test that focus on software function that are likely to be affected by change.

  20. Smoke testing • This is commonly used when product software is developed. • Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing. • The term ‘Smoke Testing’ is came from the hardware testing, in the hardware testing initial pass is done to check if it did not catch the fire or smoked in the initial switch on. Benefits • Integration risk is minimized • Error diagnosis and correction are simplified • Progress is easier to assess.

  21. TEST STRATEGIES FOR OBJECT-ORIENTED SOFTWARE • Unit Testing in the OO Context • Attribute and operation • X id defined for superclass and inherited by subclass. • It is equivalent of unit testing for conventional testing 2. Integration Testing in the OO Context • thread-based testing • use-based testing • dependent classes • Cluster testing (by examining CRC & object oriented relationship model)

  22. TEST STRATEGIES FOR WEBAPPS • The content model for the WebApp is reviewed to uncover errors. • The interface model is reviewed to ensure that all use cases can be accommodated. • The design model for the WebApp is reviewed to uncover navigation errors. • The user interface is tested to uncover errors in presentation and/or navigation mechanics. • Each functional component is unit tested.

  23. Navigation throughout the architecture is tested. 7. The WebApp is implemented in a variety of different environmental configurations and is tested for compatibility with each configuration. 8. Security tests are conducted in an attempt to exploit vulnerabilities in the WebApp or within its environment. • Performance tests are conducted. 10. The WebApp is tested by a controlled and monitored population of end users.

  24. VALIDATION TESTING • Validation-Test Criteria • Test that demonstrate conformity with requirements • To ensure that all fun requirements are satisfied • Characteristics are achieved • All content is accurate and properly • Configuration Review • All elements of software configuration have been properly developed, are cataloged (Audit)

  25. Alpha and Beta Testing • “test drive” to plan and systematically executed series of tests • Alpha Test : • It is always performed by the developers at the software development site. • Sometimes it is also performed by Independent Testing Team. • Alpha Testing is not open to the market and public • It is always performed in Virtual Environment. • Beta Test: • It is always performed by the customers at their own site • It is not performed by Independent Testing Team. • Beta Testing is always open to the market and public. • It is performed in Real Time Environment

  26. SYSTEM TESTING 1. Recovery Testing • Recovery Testing is the failure which is forced into an application to check how well the recover process is performed. • Recovery is ability to restart the operation after integrity of application is lost. • It is a type of non-functional testing. • How fast and better the application can recover after it has gone through any type of crash

  27. SYSTEM TESTING 2. Security Testing • That’s done to check whether the application or the product is secured or not. • It checks to see if the application is vulnerable to attacks, if anyone hack the system or login to the application without any authorization. • It is a process to determine that an information system protects data and maintains functionality as intended.

  28. SYSTEM TESTING 3. Stress Testing • Stress testing refers to a type of testing that is so harsh, it is expected to push the program to failure • Consequences of the crash, what else fails, what data are corrupted and so forth, are the results of interest for the stress tester. • Is any test that hits the program with boundaries or other extreme values • Under stress testing, various activities to overload the existing resources with excess jobs are carried out in an attempt to break the system down.

  29. SYSTEM TESTING 4. Performance Testing • Which is performed, to ascertain how the components of a system are performing, given a particular situation. • The measure, validate or verify quality attributes of the system like responsiveness, Speed, Scalability, Stability under variety of load conditions.

  30. SYSTEM TESTING 5. Deployment Testing • Deployment testing is a type of production testing which is performed after the code is deployed to check whether it is working fine in production or not .  a) Check it deploys to right folder.b) Check deploying correctness machinec) Application (that it actually works)d) Check that the changes made our present and test for any bugs.e) Performance Issues (slow, crashes etc)

  31. TESTING TACTICS

  32. SOFTWARE TESTING FUNDAMENTALS Testability. “Software testability is simply how easily [a computer program] can be tested.” The following characteristics lead to testable software. • Operability- “The better it works, the more efficiently it can be tested.”

  33. Controllability- “The better we can control the software, the more the testing can be automated and optimized.” • Decomposability- “By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting.” • Simplicity- “The less there is to test, the more quickly we can test it.” (functional simplicity, structural simplicity, code simplicity)

  34. Stability- “The fewer the changes, the fewer the disruptions to testing.” • Understandability- “The more information we have, the smarter we will test.” Test Characteristics • A good test has a high probability of finding an error. • A good test is not redundant. • A good test is not “best of breed”. • A good test should be neither too simple nor too complex.

  35. WHITE-BOX TESTING • It is also known as Code-Based Testing or Structural Testing. White box testing is the software testing method in which internal structure is being known to tester who is going to test the software. • When you completely aware of the internal structure of the code then you can run your test cases & check whether the system meet requirements mentioned in the specification document. • White box testing traditionally refers to the use of program source code as a test basis, that is, as the basis for designing tests and test cases.

  36. In the White box testing following steps are executed to test the software code: • Basically verify the security holes in the code. • Verify the broken or incomplete paths in the code. • Verify the flow of structure mention in the specification document • Verify the Expected outputs • Verify the all conditional loops in the code to check the complete functionality of the application. • Verify the line by line or Section by Section in the code & cover the 100% testing. -

  37. BASIS PATH TESTING 1. Flow Graph Notation

  38. BASIS PATH TESTING 2. Independent Program Paths • Path 1: 1-11 Path 2: 1-2-3-4-5-10-1-11 • Path 3: 1-2-3-6-8-9-10-1-11 Path 4: 1-2-3-6-7-9-10-1-11

  39. BASIS PATH TESTING Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. • The number of regions of the flow graph corresponds to the cyclomatic complexity. 2. Cyclomatic complexity V(G) for a flow graph G is defined as V(G)=E - N + 2 where E is the number of flow graph edges and N is the number of flow graph nodes. 3. Cyclomatic complexity V(G) for a flow graph G is also defined as V(G)=P + 1 where P is the number of predicate nodes contained in the flow graph G.

More Related