1 / 16

Testing the Software with Blinders on

Testing the Software with Blinders on. [Reading assignment: Chapter 5, pp. 63-79]. Dynamic black-box testing. Dynamic black-box testing is testing without having an insight into the details of the underlying code. Dynamic, because the program is running

lgerard
Download Presentation

Testing the Software with Blinders on

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 the Software with Blinders on [Reading assignment: Chapter 5, pp. 63-79]

  2. Dynamic black-box testing • Dynamic black-box testing is testing without having an insight into the details of the underlying code. • Dynamic, because the program is running • Black-box, because testing is done without knowledge of how the program is implemented. • Sometimes referred to as behavioral testing. • Requires an executable program and a specification (or at least a user manual). • Test cases are formulated as a set of pairs • E.g., (input, expected output)

  3. Test Data and Test Cases • Test data: Inputs which have been devised to test the system. • Test cases: Inputs to test the system and the predicted(expected) outputs from these inputs if the system operates according to its specification.

  4. Test-to-Pass and Test-to-Fail There are two fundamental approaches to testing software: test-to-pass and test-to-fail. When you test-to-pass, you really assure only that the software minimally works. You don't push its capabilities. You don't see what you can do to break it. You treat it with kid gloves, applying the simplest and most straightforward test cases. You may be thinking that if your goal is to find bugs, why would you test-to-pass? Wouldn't you want to find bugs by any means possible? The answer is no, not initially.

  5. Figure 5.2. Use test-to-pass to reveal bugs before you test-to-fail

  6. Start defining the test cases. • Test cases are the specific inputs that you'll try and the procedures that you'll follow when you test the software. Figure 5.1

  7. Data Testing • The simplest view of software is to divide its world into two parts: the data (or its domain) and the program. • The data is the keyboard input, mouse clicks, disk files, printouts, and so on. • The program is the executable flow, transitions, logic, and computations. • A common approach to software testing is to divide up the test work along the same lines. • When you perform software testing on the data, you're checking that information the user inputs, results that he receives, and any interim results internal to the software are handled correctly.

  8. State Testing • So far what you've been testing is the data—the numbers, words, inputs, and outputs of the software. • The other side of software testing is to verify the program's logic flow through its various states. • A software state is a condition or mode that the software is currently in. Consider Figures 5.3

  9. Fig 5.3

  10. Other Black-Box Test Techniques • The remaining categories of black-box test techniques aren't standalone methods as much as they are variations of the data testing and state testing that has already been described. • If you've done thorough equivalence partitioning of your program's data, created a detailed state map, and developed test cases from these, you'll find most software bugs that a user would find. • What's left are techniques for finding the stragglers, the ones that, if they were real living bugs, might appear to have a mind of their own, going their own way. • Finding them might appear a bit subjective and not necessarily based on reason, but if you want to flush out every last bug, you'll have to be a bit creative.

  11. Black-box testing • Characteristics of Black-box testing: • Program is treated as a black box. • Implementation details do not matter. • Requires an end-user perspective. • Criteria are not precise. • Test planning can begin early.

  12. Black-box testing

  13. Equivalence Partitioning • Equivalence partitioning is the process of methodically reducing the huge (or infinite) set of possible test cases into a small, but equally effective, set of test cases.

  14. Data Testing • If you think of a program as a function, the input of the program is its domain. • Examples of program data are: • words typed into MS Word • numbers entered into Excel • picture displayed in Photoshop

  15. Boundary input data • Boundary conditions are situations at the edge of the planned operational limits of the software. • E.g., negative to zero to positive numbers, exceeding the input field length of a form, etc. • Choose input data that lie on the boundary when formulating equivalence partitions. • Test the valid data just inside the boundary • Test the last possible valid data • Test the invalid data just outside the boundary • Security flaws such as buffer overflow attacks exploit boundaries of array buffers.

  16. Example of Data Testing:Syntax Testing • System inputs must be validated. Internal and external inputs conform to formats: • Textual format of data input from users. • File formats. • Database schemata. • Data formats can be mechanically converted into many input data validation tests. • Such a conversion is easy when the input is expressed in a formal notation such as BNF (Backus-Naur Form).

More Related