<?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:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-c7t_eJuo1g5hpWTYTCItig"
    name="equivalence_class_analysis,1.8491691792142673E-308" guid="-c7t_eJuo1g5hpWTYTCItig">
  <mainDescription>&lt;a id=&quot;XE_runtime_observation_amp;_analysis__concept&quot; name=&quot;XE_runtime_observation_&amp;amp;_analysis__concept&quot;>&lt;/a> &#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Introduction&quot; name=&quot;Introduction&quot;>Introduction&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Except for the most trivial of software applications, it is generally considered impossible to test all the input&#xD;
    combinations logically feasible for a software system. Therefore, selecting a good subset that has the highest&#xD;
    probability of finding the most errors, is a worthwhile and important task for testers to undertake.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Testing based on equivalence class analysis (synonyms: &lt;i>equivalence partitioning&lt;/i>, &lt;i>domain analysis&lt;/i>) is a&#xD;
    form of black-box test analysis that attempts to reduce the total number of potential tests to a minimal set of tests&#xD;
    that will uncover as many errors as possible [&lt;a href=&quot;../../process/referenc.htm#MYE79&quot;>MYE79&lt;/a>]. It is a method&#xD;
    that partitions the set of inputs and outputs into a finite number of &lt;i>&lt;a href=&quot;./../../../glossary/glossary.htm#equivalence_class&quot;>equivalence classes&lt;/a>&lt;/i> that enable the selection of a&#xD;
    representative test value for each class. The test that results from the representative value for a class is said to be&#xD;
    &quot;equivalent&quot; to the other values in the same class. If no errors were found in the test of the representative value, it&#xD;
    is reasoned that all the other &quot;equivalent&quot; values wouldn't identify any errors either.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The power of Equivalence Classes lies in their ability to guide the tester using a sampling strategy to reduce the&#xD;
    combinatorial explosion of potentially necessary tests. The technique provides a logical bases by which a subset of the&#xD;
    total conceivable number of tests can be selected. Here are some categories of problem areas for large numbers of tests&#xD;
    that can be benefit from the consideration of equivalence classes:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Combinations of independent variables&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Dependent variables based on hierarchical relationship&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Dependent variables based on temporal relationship&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Clustered relationships based on market exemplars&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Complex relationships that can be modeled&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Strategies&quot; name=&quot;Strategies&quot;>Strategies&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    There are different strategies and techniques that can be used in equivalence partition testing. Here are some&#xD;
    examples:&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;EquivalenceClassPartition&quot; name=&quot;EquivalenceClassPartition&quot;>Equivalence Class Partition&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Equivalence partition theory as proposed by Glenford Myers [&lt;a href=&quot;../../process/referenc.htm#MYE79&quot;>MYE79&lt;/a>].&#xD;
    attempts to reduce the total number of test cases necessary by partitioning the input conditions into a finite number&#xD;
    of equivalence classes. Two types of equivalence classes are classified: the set of valid inputs to the program is&#xD;
    regarded as the &lt;i>valid equivalence class&lt;/i>, and all other inputs are included in the &lt;i>invalid equivalence&#xD;
    class&lt;/i>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Here are a set of guidelines to identify equivalence classes:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        If an input condition specifies a range of values (such as, program &quot;accepts values from 10 to 100&quot;), then one&#xD;
        valid equivalence class (from 10 to 100) and two invalid equivalence classes are identified (less than 10 and&#xD;
        greater than 100).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If an input condition specifies a set of values (such as, &quot;cloth can be many colors: RED, WHITE, BLACK, GREEN,&#xD;
        BROWN &quot;), then one valid equivalence class (the valid values) and one invalid equivalence class (all the other&#xD;
        invalid values) are identified. Each value of the valid equivalence class should be handled distinctly.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If the input condition is specified as a &quot;must be&quot; situation (such as, &quot;the input string must be upper case&quot;), then&#xD;
        one valid equivalence class (uppercase characters) and one invalid equivalence (all the other input except&#xD;
        uppercase characters) class are identified.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Everything finished &quot;long&quot; before the task is done is an equivalence class. Everything done within some short time&#xD;
        interval before the program is finished is another class. Everything done just before program starts another&#xD;
        operation is another class.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If a program is specified to work with memory size from 64M to 256M. Then this size range is an equivalence class.&#xD;
        Any other memory size, which is greater than 256M or less than 64M, can be accepted.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The partition of output event lies in the inputs of the program. Even though different input equivalence classes&#xD;
        could have same type of output event, you should still treat the input equivalence classes distinctly.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;BoundaryValueAnalysis&quot; name=&quot;BoundaryValueAnalysis&quot;>Boundary Value Analysis&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    In each of the equivalence classes, the boundary conditions are considered to have a higher rate of success identifying&#xD;
    resulting failures than non-boundary conditions. Boundary conditions are the values at, immediately above or below the&#xD;
    boundary or &quot;edges&quot; of each equivalence classes.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Tests that result from boundary conditions make use of values at the minimum (min), just above minimum (min+), just&#xD;
    below the maximum (max-), and the maximum (max) of the range that needs be tested. When testing boundary values,&#xD;
    testers choose a few test cases for each equivalence class. For the relatively small sample of tests the likelihood of&#xD;
    failure discovery is high. The Tester is given some relief from the burden of testing a huge population of cases in an&#xD;
    equivalent class of values that are unlikely to produce large differences in testing results.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Some recommendations when choosing boundary values:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        For a floating variable, if the valid condition of it is from &lt;code>-1.0&lt;/code> to &lt;code>1.0&lt;/code>, test&#xD;
        &lt;code>-1.0&lt;/code>, &lt;code>1.0&lt;/code>, &lt;code>-1.001&lt;/code> and &lt;code>1.001&lt;/code>.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        For an integer, if the valid range of input is &lt;code>10&lt;/code> to &lt;code>100&lt;/code>, test &lt;code>9&lt;/code>,&#xD;
        &lt;code>10&lt;/code>, &lt;code>100&lt;/code>, &lt;code>101&lt;/code>.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If a program expects an uppercase letter, test the boundary A and Z. Test &lt;code>@&lt;/code> and &lt;code>[&lt;/code> too,&#xD;
        because in ASCII code, &lt;code>@&lt;/code> is just below A and &lt;code>[&lt;/code> is just beyond the Z.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If the input or output of a program is an ordered set, pay attention on the first and the last element of the set.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If the sum of the inputs must be a specific number (&lt;code>n&lt;/code>), test the program where the sum is&#xD;
        &lt;code>n-1&lt;/code>, &lt;code>n&lt;/code>, or &lt;code>n+1&lt;/code>.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If the program accepts a list, test values in the list. All the other values are invalid.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When reading from or writing to a file, check the first and last characters in the file.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The smallest denomination of money is one cent or equivalent. If the program accepts a specific range, from a to b,&#xD;
        test a &lt;code>-0.01&lt;/code> and b &lt;code>+0.01&lt;/code>.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        For a variable with multiple ranges, each range is an equivalence class. If the sub-ranges are not overlapped, test&#xD;
        the values on the boundaries, beyond the upper boundary, and below the lower boundary.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;SpecialValues&quot; name=&quot;SpecialValues&quot;>Special Values&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    After attempting the two previous boundary analysis strategies, an experienced tester will observe the program inputs&#xD;
    to discovery any &quot;special value&quot; cases, which are again potentially rich sources for uncovering software failures. Here&#xD;
    are some examples:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        For an integer type, zero should always be tested if it is in the valid equivalence class.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When testing time (hour, minute and second), 59 and 0 should always be tested as the upper and lower bound for each&#xD;
        field, no matter what constraint the input variable has. Thus, except the boundary values of the input, -1, 0, 59&#xD;
        and 60 should always be test cases.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When testing date (year, month and day), several test cases, such as number of days in a specific month, the number&#xD;
        of days in February in leap year, the number of days in the non-leap year, should be involved.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;CategoryPartition&quot; name=&quot;CategoryPartition&quot;>&quot;Category-Partition&quot; Method&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    &lt;a href=&quot;#OstrandBalcer&quot;>Ostrand and Balcer&lt;/a> [16] developed a partition method that helps testers to analyze the&#xD;
    system specification, write test scripts, and manage them. Different from common strategies that mostly focuses on the&#xD;
    code, their method is based on the specification and design information too.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The main benefit of this method is its ability to expose errors before the code has been written because the input&#xD;
    source is the specification and the tests result from the analysis of that specification. Faults in the specifications&#xD;
    will be discovered early, often well before they are implemented in code.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The strategy for the &quot;category-partition&quot; method follows:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Analyze the specification: decompose the system functionality into functional units, which can be tested&#xD;
        independently both by specification and implementation.&lt;br />&#xD;
         From there;&lt;br />&#xD;
        &lt;br />&#xD;
         &#xD;
        &lt;ol>&#xD;
            &lt;li>&#xD;
                Identify the parameters and the environment conditions that will influence the function's execution.&#xD;
                Parameters are the inputs of the function unit. Environment conditions are the system states, which will&#xD;
                effect the execution of the function unit.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                Identify the characteristics of the parameters and the environment conditions.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                Classify the characteristics into categories, which effect the behavior of the system.&lt;br />&#xD;
                &lt;br />&#xD;
            &lt;/li>&#xD;
        &lt;/ol>Ambiguous, contradictory, and missing descriptions of behavior will be discovered in this stage.&lt;br />&#xD;
        &lt;br />&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Partition the categories into choices: Choices are the different possible situations that might occur and not be&#xD;
        expected. They represent the same type of information in a category.&lt;br />&#xD;
        &lt;br />&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Determine the relations and the constraints among choices. The choices in different categories influence with each&#xD;
        other, which also have an influence of building the test suite. Constraints are added to eliminate the&#xD;
        contradiction of between choices of different parameters and environments.&lt;br />&#xD;
        &lt;br />&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Design test cases according to the categories, choices and constraint information. If a choice causes an error,&#xD;
        don't combine it with other choices to create the test case. If a choice can be &quot;adequately&quot; tested by one single&#xD;
        test, it is either the representative of the choice or a special value.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;FurtherReading&quot; name=&quot;FurtherReading&quot;>Further Reading and References&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Glenford J. Myers, The Art of Software Testing, John Wiley &amp;amp; Sons, Inc., New York, 1979.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        White L. J. and Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software&#xD;
        Engineering, Vol. SE-6, No. 3, 1980.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Lori A. Clarke, Johnhette Hassell, and Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on&#xD;
        Software Engineering, 8-4, 1992.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Steven J. Zeil, Faten H. Afifi and Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction&#xD;
        on Software Engineering and Methodology, 1-4, 1992.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering&#xD;
        and Methodology, 3-3, 1994.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Martin R. Woodward and Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal&#xD;
        triangle, ACM Press New York, NY, 2000.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software&#xD;
        Engineering, 71-16, 2000.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Cem Kaner, James Bach, and Bret Pettichord, Lessons learned in Software Testing, John Wiley &amp;amp; Sons, Inc., New&#xD;
        York, 2002.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Andy Podgurski and Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special&#xD;
        Interest Group on Software Engineering, 18-5, 1993.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Debra J. Richardson and Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM&#xD;
        Special Interest Group on Software Engineering, 1981.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Lori A. Clarke, Johnette Hassell, and Debra J Richardson, A system to generate test data and symbolically execute&#xD;
        programs, IEEE Transaction on Software Engineering, SE-2, 1976.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley &amp;amp; Sons,&#xD;
        Inc., 1995.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Steven J. Zeil, Faten H. Afifi and Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM&#xD;
        Transaction on Software Engineering and Methodology, 1-4, 1992.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a id=&quot;OstrandBalcer&quot; name=&quot;OstrandBalcer&quot;>Thomas J. Ostrand and Marc J. Balcer&lt;/a>, The Category-Partition method&#xD;
        for specifying and generating functional tests, Communications of ACM 31, 1988.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Cem Kaner, Jack Falk and Hung Quoc Nguyen, Testing Computer Software, John Wiley &amp;amp; Sons, Inc., 1999.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    &amp;nbsp;&#xD;
&lt;/p>&lt;br />&#xD;
&lt;br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>