1 / 25

Software Testing: Building Test Cases

Software Testing: Building Test Cases. Topics covered. Software Testing Process Software Testability Test Cases Black box testing Search and Sort Cases Debuging the application. Dynamics of Faults. Fault Detection: “Waiting” or causing (or finding) for the error or failure to ocurr .

avonaco-williams
Télécharger la présentation

Software Testing: Building Test Cases

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. Software Testing: Building Test Cases

  2. Topics covered • Software Testing Process • Software Testability • Test Cases • Black box testing • Search and Sort Cases • Debuging the application

  3. Dynamics of Faults • Fault Detection: “Waiting” or causing (or finding) for the error or failure to ocurr. • Fault Location: Finding where the fault(s) ocurred, its causes and its consequences. • Fault Recovery: Fixing the fault and NOT causing others. • Regresion Testing: Testing the software again with the same data that caused the original fault

  4. Static and dynamic verification • Software inspections. Concerned with analysis of the static system representation to discover problems (static verification) • May be supplement by tool-based document and code analysis • Software Testing. Concerned with exercising and observing product behaviour (dynamic verification) • The system is executed with test data and its operational behaviour is observed. • Used to Detect Faults. • Software Debugging. Concerned with finding and removing the faults. • Fault Tolerance. If faults still ocurr during operation: detect, remove and recover the system from faults.

  5. The Software Testing process

  6. Software Testability The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met • Plainly speaking – how hard it is to find faults in the software • Testability is determined by two practical problems • How to provide the test values to the software • How to observe the results of test execution

  7. Observability and Controllability • Observability • Software that affects hardware devices, databases, or remote files have low observability • Controllability • Easy to control software with inputs from keyboards • Inputs from hardware sensors or distributed software is harder • Data abstraction reduces controllability and observability How easy it is to observe the behavior of a program in terms of its outputs, effects on the environment and other hardware and software components How easy it is to provide a program with the needed inputs, in terms of values, operations, and behaviors

  8. Components of a Test Case • A test case is a multipart artifact with a definite structure • Test case values • Expected results The values that directly satisfy one test requirement The result that will be produced when executing the test if the program satisfies it intended behavior

  9. Affecting Controllability and Observability • Preconditions • Postconditions • Verification Values : Values needed to see the results of the test case values • Exit Commands : Values needed to terminate the program or otherwise return it to a stable state • Executable test script Any conditions necessary for the correct execution of the software Any conditions that must be observed after executing the software A test case that is prepared in a form to be executed automatically on the test software and produce a report

  10. Algorithms to Test Search • Binary Search • Interpolation Search Sort • Heap Sort • Merge Sort.

  11. Testing the algorithms Black Box Testing. • Study the algorithms • Programming. • Pre-conditions & Post-Conditionsof each algorithm. • Develop Test Cases. • Develop Oracle. • Run the test. • Record Inputs and Outputs. • Record Invalid Outputs • If invalid Outputs or Execution Errors then: • Debug the program: Finding the fault.

  12. Test case design • Involves designing the test cases (inputs and outputs) used to test the system. • The goal of test case design is to create a set of tests that are effective in validation and defect testing. • Design approaches: • Black Box Testing: Partition testing; • White Box Testing: • Structural testing. • Criteria based on Structures.

  13. Black-box testing

  14. Equivalence partitioning Test Data Generation Random Number Generation Valid/ Invalid Output Oracle

  15. Testing guidelines • Testing guidelines are hints for the testing team to help them choose tests that will reveal defects in the system • Choose inputs that force the system to generate valid outputs; • Choose inputs that force the system to generate faults (invalid outputs); • Check if valid inputs generate invalid outputs. • Check if invalid outputs generate valid outputs. • Design inputs that cause buffers to overflow; • Repeat the same input or input series several times; • Force computation results to be too large or too small.

  16. Partition testing • Input data and output results often fall into different classes where all members of a class are related. • Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member. • Test cases should be chosen from each partition.

  17. Search routine - input partitions

  18. Sort Routine – Partitions Sequences: Array of 1,000 elements • Sort an array with all elements not sorted. • Sort an array with all elements sorted. • Sort an array with many equal elements. Oracle: • Simple: Check that first element in array is less or equal than next. • Check how many elements are not correctly sorted. • Check what input makes out to be incorrect.

  19. Testing and debugging • Defect testing and debugging are distinct processes. • Verification and validation is concerned with establishing the existence of defects in a program. • Debugging is concerned with locating and repairing these errors. • Debugging involves formulating a hypothesis about program behaviour then testing these hypotheses to find the system error.

  20. The debugging process

  21. Debugging What can debuggers do? • Run programs • Make the program stops on specified places or on specified conditions • Give information about current variables’ values, the memory and the stack • Let you examine the program execution step by step - stepping • Let you examine the change of program variables’ values - tracing ! To be able to debug your program, you must compile it with the -g option (creates the symbol table) ! CC –g my_prog

  22. GDB – Running Programs Running a program: run (or r) -- creates an inferior process that runs your program. • if there are no execution errors the program will finish and results will be displayed • in case of error, the GDB will show: - the line the program has stopped on and - a short description of what it believes has caused the error

  23. Test automation • Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs. • Systems such as Junit support the automatic execution of tests. • Most testing workbenches are open systems because testing needs are organisation-specific. • They are sometimes difficult to integrate with closed design and analysis workbenches.

  24. A testing workbench

  25. What do we need to improve testing? • Run programs

More Related