| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\openup_basic\guidances\guidelines\test_ideas.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: test_ideas.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_0jzlsMlgEdmt3adZL5Dmdw CRC: 1652868117 -->Test Ideas<!-- END:presentationName,_0jzlsMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_0jzlsMlgEdmt3adZL5Dmdw CRC: 2113250201 -->This guideline identifies common faults and mistakes done when developing software. It shows how to create test ideas from method calls, and from boolean and relational expressions.<!-- END:briefDescription,_0jzlsMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,_y3rxsMM3EdmSIPI87WLu3g CRC: 2458895332 --><h3> |
| Introduction |
| </h3> |
| <p> |
| Test ideas are used to generate tests. Test ideas can come from many different sources. In general, they can |
| be derived in different ways depending on the given development domain, the kind of application being developed, and |
| the sophistication of the testers. Although test ideas are derived in many different ways, there are some useful |
| categories for generating them. This guideline will describe some of these categories as well as some general |
| heuristics for creating good test ideas. |
| </p> |
| <h4> |
| Test Ideas and Functions |
| </h4> |
| <p> |
| Below are some test ideas to calculate the square root: |
| </p> |
| <ol> |
| <li> |
| A number that's barely less than zero as input |
| </li> |
| <li> |
| Zero as the input |
| </li> |
| <li> |
| Number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?) |
| </li> |
| <li> |
| Print to a LaserJet IIIp |
| </li> |
| <li> |
| Test with database full |
| </li> |
| </ol> |
| <p> |
| The first 3 test ideas validate input while the last 2 address environmental issues. Even though these |
| statements are very incomplete they ensure that an idea is not forgotten. |
| </p> |
| <h4> |
| Test Ideas and Boundaries |
| </h4> |
| <p> |
| Test ideas are often based on fault models. Consider boundaries. It's safe to assume the square root function can |
| be implemented something like this:<br /> |
| double sqrt(double x) {<br /> |
| if (x < 0)<br /> |
| // signal error<br /> |
| ...<br /> |
| It's also plausible that the < will be incorrectly typed as <=. People often make that kind of mistake, so it's |
| worth checking. The fault cannot be detected with X having the value 2, because both the incorrect expression (x<=0) |
| and the correct expression (x<0) will take the same branch of the if statement. Similarly, giving X the value -5 |
| cannot find the fault. The only way to find it is to give X the value 0, which justifies the second test idea. |
| </p> |
| <h4> |
| Test Idea and Methods |
| </h4> |
| <p> |
| Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either |
| obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is |
| found.<br /> |
| int Collection.find(String string, Boolean ignoreCase); |
| </p> |
| <p> |
| Here are some test ideas for this method, each of which could be implemented as a test. |
| </p> |
| <ol> |
| <li> |
| Match found in the first position |
| </li> |
| <li> |
| Match found in the last position |
| </li> |
| <li> |
| No match found |
| </li> |
| <li> |
| Two or more matches found in the collection |
| </li> |
| <li> |
| Case is ignored; match found, but it wouldn't match if case was obeyed |
| </li> |
| <li> |
| Case is obeyed; an exact match is found |
| </li> |
| <li> |
| Case is obeyed; a string that would have matched if case were ignored is skipped |
| </li> |
| </ol> |
| <p> |
| However, different test ideas can be combined into a single test; for example, the following test satisfies test ideas |
| 2, 6, and 7: |
| </p> |
| <p> |
| <strong>Setup:</strong> Collection initialized to ["dawn", "Dawn"]<br /> |
| <strong>Invocation:</strong> Collection.find("Dawn", false)<br /> |
| <strong>Expected result:</strong> Return value is 1 (it would be 0 if "dawn" were not skipped) |
| </p> |
| <h4> |
| Test Idea Simplicity and Complexity |
| </h4> |
| <p> |
| Making test ideas nonspecific makes them easier to combine.<br /> |
| Creating many several small tests that satisfy a few test ideas makes it simpler to: |
| </p> |
| <ul> |
| <li> |
| "Copy and Tweak" the tests to meet other test idea |
| </li> |
| <li> |
| Easy of debugging - if you have test that covers 2 test ideas then you know the fault is one or two area, but if |
| the test covers 7 test ideas you will spend more time debugging the issue. |
| </li> |
| </ul> |
| <p> |
| If the test ideas list were complete, with a test idea for every fault in the program, it wouldn't matter how you wrote |
| the tests. But the list is always missing some test ideas that could find bugs. Smaller more complex tests increase the |
| chance the test will satisfy a test idea that you didn't know you needed. |
| </p> |
| <h4> |
| Complex Tests |
| </h4> |
| <p> |
| Sometimes when you're creating more complex tests, new test ideas come to mind. However, there are reasons for not |
| creating complex tests. |
| </p> |
| <ul> |
| <li> |
| Complex test are more difficult to debug because they usually cover multiple test ideas |
| </li> |
| <li> |
| Complex tests are more difficult to understand and maintain. The intent of the test is less obvious. |
| </li> |
| <li> |
| Complex tests are more difficult to create. |
| </li> |
| </ul> |
| <p> |
| Constructing a test that satisfies five test ideas often takes more time than constructing five tests that each |
| satisfies one. Moreover, it's easier to make mistakes - to think you're satisfying all five when you're only satisfying |
| four.<br /> |
| In practice, find a reasonable balance between complexity and simplicity.<br /> |
| </p><!-- END:mainDescription,_y3rxsMM3EdmSIPI87WLu3g --> |
| </body> |
| </html> |