1 / 8

Schach - Chapter 6 Page 121

Testing & Quality Assurance. T esting is a technical investigation process intended to reveal quality-related information about software. T he standard progression of software testing:. U nit T esting Programmers test the minimal software components (i.e., classes and modules).

treva
Télécharger la présentation

Schach - Chapter 6 Page 121

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. Testing & Quality Assurance Testing is a technical investigation process intended to reveal quality-related information about software The standard progression of software testing: Unit Testing Programmers test the minimal software components (i.e., classes and modules) Integration Testing Expose the defects in the interfaces between integrated modules Validation Testing Ensure that the implemented software meets customer requirements System Testing Determine whether the software will work as desired when installed Acceptance Testing The client tests the delivered software to decide whether it is in an acceptable form Schach - Chapter 6 Page 121

  2. Unit Testing To facilitate the diagnosis of problems within a module, it is usually necessary to isolate that module Place the module or class being tested in an artificial environment that allows you to focus upon its performance. A dummy driver program merely accepts test case data and passes it to the module being tested. Stub programs are used to replace modules that are called by the module being tested. The module being tested. Schach - Chapter 6 Page 122

  3. Integration Testing While individual modules might pass their unit tests, they might not work correctly when integrated together Integration Alternatives: • Big Bang: Test all modules simultaneously ({A, B, C, D, E, F, G, H}) • Fine for small, well-structured systems, but locating bugs may be tough • Top-Down: Incrementally test from the driver down ({A} with stubs for {B,C,D}, then {A, B, C, D} with stubs for {E, F, G, H}, then {A, B, C, D, E, F, G, H}) • Helps localize bugs, but deep nodes are tested last, hurting performance • Bottom-Up: Incrementally test starting at primitive modules ({E}, {F}, {G}, {H}, each with a dummy driver for {C}, then {B}, {C, E, F, G, H}, {D}, each with a dummy driver for {A}, then {A, B, C, D, E, F, G, H}) • Early validation of performance-critical modules, but overall validation is delayed Schach - Chapter 6 Page 123

  4. Validation Testing Rather than testing the internal code, at some point the overall functionality of the software needs to be tested White-box testing is performed by programmers who utilize their skills to examine all of the paths through the software to diagnose internal problems. Black-box testing, on the other hand, takes an external perspective, with the test designer selecting valid and invalid input and examining the corresponding output for accuracy. Schach - Chapter 6 Page 124

  5. System Testing After the software has been fully integrated, its compliance with its specified requirements must be tested Recovery testing is used to determine how well software can recover from crashes, hardware failures, etc. Security testing is used to determine how well software is protected from outside penetration Stress testing is used to determine how well software deals with extreme demands on its resources (e.g., memory, processing) Performance testing is used to determine the speed with which software deals with various workloads Schach - Chapter 6 Page 125

  6. Acceptance Testing In preparation for the software’s actual release, early versions may be provided to clients for testing Alpha testing is performed by clients on iterations of the software to which new features are still being added Beta testing is performed at a stage when all primary features have been added, but active debugging is still taking place Schach - Chapter 6 Page 126

  7. Regression Testing When features are added or altered, the changes might cause previously working code to fail Common methods of regression testing include re-running previously run tests and checking whether previously fixed bugs have reemerged Schach - Chapter 6 Page 127

  8. Designing Test Cases The conditions that a tester will use to determine if a system meets certain requirements must be well designed Test cases need identification parameters: • an identifier and version number, for future reference’s sake • a title and description, making the test case’s purpose and scope obvious • the name of the test designer who is responsible for its development • an identification of the system’s requirement being addressed Test cases require activity parameters: • required hardware/software configurations • initialization actions needed prior to the test • step-by-step actions taken during the test • finalization actions needed after the test Test cases require results parameters: • expected results specifications • actual results specifications Schach - Chapter 6 Page 128

More Related