Software Testing Techniques PDF

# Software Testing Techniques ## What is Software Testing? - Testing is the process of exercising a program with the specific intent of finding **errors** prior to delivery to the end user. ## Software Development Process A diagram of a software development process is shown. - The diagram shows...

# Software Testing Techniques ## What is Software Testing? - Testing is the process of exercising a program with the specific intent of finding **errors** prior to delivery to the end user. ## Software Development Process A diagram of a software development process is shown. - The diagram shows an abstract concept being converted into a tangible product, the CD icon. - There is an arrow from the thought bubble to the triangle labeled “**Testing**.” - Below the triangle is the caption “Tries hard to demolish the software.” ## Developer Mindset - The developer must discard the preconceived idea that his software is always correct. ## Objectives of Software Testing - Uncovering different cases of errors - Needing minimum effort and time - Showing that software functions work according to specification. > It **cannot** show absence of errors or defects. > It can **only** show that errors are present. ## General Testing Principles - **Customer** thinks - most serious defect is not meeting his requirements - All tests should reflect customer requirements - Tests should be planned long before testing begins - The "**pareto**" principle applies to software testing - Exhaustive testing is not possible - To be most effective, testing should be conducted by a third party > 80% of errors originate from 20% of a program > Too many paths in a normal -size program ## Who Tests The Software? A diagram shows a developer and an independent tester, each in front of a computer. The caption below each image describes their role in testing the software. - **Developer:** - Understands the system - Will test "gently" - Is driven by "delivery" - **Independent Tester:** - Must learn about the system - Will attempt to break it - Is driven by quality ## What is a Good Test? - Has a high probability of finding an error - It **must** not be redundant. Every test **must** have a different purpose. - It **should** neither be too simple nor too complex. ## What Testing Shows - There is a visual representation of a staircase. > - The steps are labeled with what testing shows: > - errors > - requirements conformance > - performance > - an indication of quality ## Testability - **Operability** - it operates cleanly - **Observability** - the results of each test case are readily observed. - **Controllability** - the degree to which testing can be automated and optimized. - **Decomposability** - testing can be targeted. - **Simplicity** - reduce complex architecture and logic to simplify tests - **Stability** - few changes are requested during testing. - **Understandability** - of the design ## Test Case Design - Design of test cases is as challenging as designing the software itself. - A rich variety of test case design methods have evolved. - Methods provide a systematic approach to testing. - Methods provide a mechanism for that ensures the completeness of tests and high likelihood of finding an error. ## Software Testing Methods (Strategies) A diagram shows two triangular shapes, one is black and one is white, touching at their bases. The shape is placed on a purple oval. - The **white** triangle is labeled “white-box methods.” - The **black** triangle is labeled “black-box methods.” - The purple oval is labeled “Methods Strategies.” ## Index - **Black Box Testing**(Functional testing) - Equivalence Partitioning - Boundary Value Analysis - Cause Effect Graphing - **White Box Testing**(Structural testing) - Coverage Testing - Statement Coverage - Branch And Decision Coverage - Path Coverage - Comparison of black box and white box testing ## Blackbox Testing - In Black Box Testing, we just focus on **inputs** and **outputs** of the software system without bothering about internal knowledge of the software program. > A diagram shows a box labeled “BLACK BOX TESTING.” > - The box contains the label “Executable Program” > - An arrow points to the box from the left that is labeled “Input.” > - An arrow points from the box to the right that is labeled “Output.” > [Figure of Blackbox Testing] - The above Black Box executable program can be any software system you want to test. ## Blackbox Testing: Criteria - By applying black-box techniques, you derive a set of test cases that satisfy the following criteria: - test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing, and - test cases that tell you something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand. ## Blackbox Testing: Techniques / Methods - **Equivalence partitioning**: It is a software test design technique that involves dividing input values into valid and invalid partitions and selecting representative values from each partition as test data. - **Boundary Value Analysis**: It is a software test design technique that involves the determination of boundaries for input values and selecting values that are at the boundaries and just inside/ outside of the boundaries as test data. - **Cause effect graphing**: It is a software test design technique that involves identifying the cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph, and generating test cases accordingly. ## White Box Testing - Close examination of procedural detail. - Logical paths through the software are tested by providing test cases that exercise specific sets of conditions and/or loops. - Status of the program is examined at **various** points to determine if the actual status matches the expected status. ## Does White Box Testing Lead to 100% Correct Program? > The answer is: **No** - It is not possible to exhaustively test every program path because the number of paths is simply too large. ## Exhaustive Testing - There are $10^{14}$ possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! > A diagram shows a flowchart with several boxes and diamonds. > - The boxes are labeled with blue text and the diamonds are labeled with yellow text. > - An arrow points in a loop, labeled “loop<20X” > - Another arrow points up and to the right, labeled “14” ## Selective Testing > A diagram shows a flowchart with several boxes and diamonds. > - The boxes are labeled with blue text and the diamonds are labeled with yellow text. > - An arrow points in a loop, labeled “loop<20X” - [An arrow points to a path in the diagram labeled] “Selected path." ## Black Box Testing - Know the specific function that the program is designed to perform. - Test that each function is fully operational. - Search for more errors in the functions. - These tests are conducted at the software interface. - Whether input is properly accepted and output is correctly produced. - Integrity of external information (database) is maintained. - Examines fundamental aspects of the system with little regard to internal logical structure. ## Blackbox Testing and Whitebox Testing - The attributes of both black-box and white-box testing can be combined to provide an approach that validates the software interface and selectively ensures that the internal workings of the software are correct. > A diagram shows a stack of three black blocks and three white blocks, alternating colors. ## White Box Testing - It is also known as "Glass Box Testing" - Uses the **control structure** of the procedural design to derive test cases. > A diagram shows a box labeled “Glass Box.” > - Inside the box is the following code: ``` If a = b then do c else do v ``` ## White Box Testing: Benefits - Guarantees that all independent paths within a module have been exercised at least once. - Exercise all logical decisions on their true and false sides. - Exercise all loops at their boundaries and within their operational bounds. - Exercise internal data structures to ensure their validity. ## Why Need White-Box Testing? - Logic errors occur more frequently in the less probable paths of execution. - Everyday processing tends to be well understood while "special case" processing tends to fall into cracks. - We often believe that a logical path is not likely to be executed when, in fact, it may be executed on a regular basis. - Typos are random. It is as likely that a type will exist on an obscure logical path as on a mainstream path. ## White-Box Testing > A diagram shows a person with a magnifying glass looking at a flowchart. > - The flowchart shows several boxes and diamonds. > - The boxes are labeled with blue text and the diamonds are labeled with yellow text. - ... our goal is to ensure that all statements and conditions have been executed at least once... ## Basis Path Testing - It is a white-box testing technique. - Proposed by Tom Macabe - Derives a logical complexity measure. - Test cases derived to exercise the basis set are guaranteed to execute every statement in the **program at least once** during testing. - Uses **flow-graph notation**. - Each structured construct has a corresponding flow graph symbol. ## Thank You! An image shows an envelope with a white card inside. > The card says “Thank you…”