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