| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.2.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="_y3rxsMM3EdmSIPI87WLu3g" |
| name="test_ideas,_0jzlsMlgEdmt3adZL5Dmdw" guid="_y3rxsMM3EdmSIPI87WLu3g" changeDate="2006-09-29T09:37:59.292-0700" |
| version="1.0.0"> |
| <mainDescription><h3>
 |
| Introduction
 |
| </h3>
 |
| <p>
 |
| Test ideas are used to generate tests.&nbsp;Test ideas can come from many different sources.&nbsp;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.&nbsp;Although test ideas are derived in many different ways, there are some useful
 |
| categories for generating them.&nbsp;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&nbsp;3 test ideas validate input while the last 2 address environmental issues.&nbsp; 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.&nbsp; Consider boundaries. It's safe to assume the square root function can
 |
| be implemented something like this:<br />
 |
| double sqrt(double x) {<br />
 |
| &nbsp;&nbsp;&nbsp; if (x &lt; 0)<br />
 |
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // signal error<br />
 |
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br />
 |
| It's also plausible that the &lt; will be incorrectly typed as &lt;=. 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&lt;=0)
 |
| and the correct expression (x&lt;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.&nbsp;
 |
| </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.&nbsp;
 |
| </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></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
