Jump to content

All-pairs testing: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m task, replaced: IEEE Trans. on Software Engineering → IEEE Transactions on Software Engineering, Transactions on Software Engineering → IEEE Transactions on Software Engineering, IEEE IEEE → IEEE
m Removed incorrect syntactic divider
Tags: Mobile edit Mobile app edit iOS app edit App section source
 
(31 intermediate revisions by 20 users not shown)
Line 1: Line 1:
In [[computer science]], '''all-pairs testing''' or '''pairwise testing''' is a [[combinatorial]] method of [[software testing]] that, for ''each pair'' of input parameters to a system (typically, a [[software]] [[algorithm]]), tests all possible discrete combinations of those parameters. Using carefully chosen [[test vector]]s, this can be done much faster than an exhaustive search of [[Software testing#Input combinations and preconditions|all combinations]] of all parameters, by "parallelizing" the tests of parameter pairs.
In [[computer science]], '''all-pairs testing''' or '''pairwise testing''' is a [[combinatorial]] method of [[software testing]] that, for ''each pair'' of input parameters to a system (typically, a [[software]] [[algorithm]]), tests all possible discrete combinations of those parameters. Using carefully chosen [[test vector]]s, this can be done much faster than an exhaustive search of [[Software testing#Input combinations and preconditions|all combinations]] of all parameters by "parallelizing" the tests of parameter pairs.<ref>{{Cite web |last=Berger |first=Bernie |date=2003 |title=Efficient Testing with All-Pairs |url=https://techwell.com/sites/default/files/articles/XDD6488filelistfilename1_0.pdf |access-date=21 November 2023 |website=[[TechWell Corporation]]}}</ref>


== Rationale ==
== Rationale ==


The most common bugs in a program are generally triggered by either a single input parameter or an interaction between pairs of parameters.<ref>{{cite book |last=Black |first=Rex |year=2007 |title=Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional |publisher=[[John Wiley & Sons|Wiley]] |location=New York |isbn=978-0-470-12790-2 |page=240}}</ref> Bugs involving interactions between three or more parameters are both progressively less common <ref>{{cite journal |last1=Kuhn |first1=D. Richard |last2=Wallace |first2=Dolores R. |last3=Gallo |first3=Albert M., Jr. |date=June 2004 |title=Software Fault Interactions and Implications for Software Testing |journal=IEEE Transactions on Software Engineering |volume=30 |issue=6 |pages=1–4 |url=http://csrc.nist.gov/staff/Kuhn/kuhn-wallace-gallo-04.pdf |format=PDF}}</ref> and also progressively more expensive to find---such testing has as its limit the testing of all possible inputs.<ref>{{cite report |last1=Kuhn |first1=D. Richard |last2=Kacker |first2=Raghu N. |author3=Yu Lei |year=October 2010 |title=Practical Combinatorial Testing. SP 800-142. |publisher=[[National Institute of Standards and Technology]] |doi=10.6028/NIST.SP.800-142}}</ref> Thus, a combinatorial technique for picking test cases like all-pairs testing is a useful cost-benefit compromise that enables a significant reduction in the number of test cases without drastically compromising functional coverage.<ref>{{cite web |date=July 18, 2008 |title=IEEE 12. Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications. |doi=10.1109/IEEESTD.2008.4578383 |pages=1–150 |url=http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4578383}}</ref>
In most cases, a single input parameter or an interaction between two parameters is what causes a program's bugs.<ref>{{cite book |last=Black |first=Rex |year=2007 |title=Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional |publisher=[[John Wiley & Sons|Wiley]] |location=New York |isbn=978-0-470-12790-2 |page=240}}</ref> Bugs involving interactions between three or more parameters are both progressively less common <ref>{{cite journal |last1=Kuhn |first1=D. Richard |last2=Wallace |first2=Dolores R. |last3=Gallo |first3=Albert M. Jr. |date=June 2004 |title=Software Fault Interactions and Implications for Software Testing |journal=IEEE Transactions on Software Engineering |volume=30 |issue=6 |pages=418–421 |url=http://csrc.nist.gov/staff/Kuhn/kuhn-wallace-gallo-04.pdf |doi=10.1109/TSE.2004.24 |s2cid=206778290 }}</ref> and also progressively more expensive to find, such testing has as its limit the testing of all possible inputs.<ref>{{cite report |last1=Kuhn |first1=D. Richard |last2=Kacker |first2=Raghu N. |author3=Yu Lei |date=October 2010 |title=Practical Combinatorial Testing. SP 800-142. |publisher=[[National Institute of Standards and Technology]] |doi=10.6028/NIST.SP.800-142|doi-access=free }}</ref> Thus, a combinatorial technique for picking test cases like all-pairs testing is a useful cost-benefit compromise that enables a significant reduction in the number of test cases without drastically compromising functional coverage.<ref>{{cite book |date=July 18, 2008 |title=IEEE 12. Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications. |journal=IEEE STD 829-2008 |doi=10.1109/IEEESTD.2008.4578383 |pages=1–150 |isbn=978-0-7381-5746-7 }}</ref>


More rigorously, if we assume that a test case has <math>N</math> parameters given in a set <math>\{ P_i\} = \{ P_1 , P_2 , ... , P_N \}</math>.
More rigorously, if we assume that a test case has <math>N</math> parameters given in a set <math>\{ P_i\} = \{ P_1 , P_2 , ... , P_N \}</math>.
Line 47: Line 47:
! Parameter name !! Value 1 !! Value 2 || Value 3 || Value 4
! Parameter name !! Value 1 !! Value 2 || Value 3 || Value 4
|-
|-
| Enabled || True || False || * || *
| Enabled || True || False || - || -
|-
|-
| Choice type || 1 || 2 || 3 || *
| Choice type || 1 || 2 || 3 || -
|-
|-
| Category || a || b || c || d
| Category || a || b || c || d
|}
|}


'Enabled', 'Choice Type' and 'Category' have a choice range of 2, 3 and 4, respectively. An exhaustive test would involve 24 tests (2 x 3 x 4). Multiplying the two largest values (3 and 4) indicates that a pair-wise tests would involve 12 tests. The pict tool generated pairwise test cases is shown below.
'Enabled', 'Choice Type' and 'Category' have a choice range of 2, 3 and 4, respectively. An exhaustive test would involve 24 tests (2 x 3 x 4). Multiplying the two largest values (3 and 4) indicates that a pair-wise tests would involve 12 tests. The pairwise test cases, generated by Microsoft's "pict" tool, are shown below.


{| class="wikitable"
{| class="wikitable sortable"
|-
|-
! Enabled !! Choice type !! Category
! Enabled !! Choice type !! Category
Line 86: Line 86:


== See also ==
== See also ==
{{portal|Software Testing}}


* [[Software testing]]
* [[Software testing]]
Line 98: Line 97:
* [http://csrc.nist.gov/acts/ Pairwise and generalized t-way combinatorial testing]
* [http://csrc.nist.gov/acts/ Pairwise and generalized t-way combinatorial testing]
* [http://msdn.microsoft.com/en-us/library/cc150619.aspx Pairwise Testing in the Real World: Practical Extensions to Test-Case Scenarios]
* [http://msdn.microsoft.com/en-us/library/cc150619.aspx Pairwise Testing in the Real World: Practical Extensions to Test-Case Scenarios]
* [https://www.pairwise.org Pairwise Testing - Combinatorial Test Case Generation]


{{Prone to spam|date=April 2015}}
{{Prone to spam|date=April 2015}}
{{Z148}}<!-- {{No more links}}
<!-- {{No more links}}


Please be cautious adding more external links.
Please be cautious adding more external links.
Line 115: Line 115:


-->
-->

{{Software testing}}


{{DEFAULTSORT:All-Pairs Testing}}
{{DEFAULTSORT:All-Pairs Testing}}

Latest revision as of 02:52, 17 August 2024

In computer science, all-pairs testing or pairwise testing is a combinatorial method of software testing that, for each pair of input parameters to a system (typically, a software algorithm), tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters by "parallelizing" the tests of parameter pairs.[1]

Rationale

[edit]

In most cases, a single input parameter or an interaction between two parameters is what causes a program's bugs.[2] Bugs involving interactions between three or more parameters are both progressively less common [3] and also progressively more expensive to find, such testing has as its limit the testing of all possible inputs.[4] Thus, a combinatorial technique for picking test cases like all-pairs testing is a useful cost-benefit compromise that enables a significant reduction in the number of test cases without drastically compromising functional coverage.[5]

More rigorously, if we assume that a test case has parameters given in a set . The range of the parameters are given by . Let's assume that . We note that the number of all possible test cases is a . Imagining that the code deals with the conditions taking only two parameters at a time, might reduce the number of needed test cases.[clarification needed]

To demonstrate, suppose there are X,Y,Z parameters. We can use a predicate of the form of order 3, which takes all 3 as input, or rather three different order 2 predicates of the form . can be written in an equivalent form of where comma denotes any combination. If the code is written as conditions taking "pairs" of parameters, then the set of choices of ranges can be a multiset[clarification needed], because there can be multiple parameters having same number of choices.

is one of the maximum of the multiset The number of pair-wise test cases on this test function would be:-

Therefore, if the and then the number of tests is typically O(nm), where n and m are the number of possibilities for each of the two parameters with the most choices, and it can be quite a lot less than the exhaustive ·

N-wise testing

[edit]

N-wise testing can be considered the generalized form of pair-wise testing.[citation needed]

The idea is to apply sorting to the set so that gets ordered too. Let the sorted set be a tuple :-

Now we can take the set and call it the pairwise testing. Generalizing further we can take the set and call it the 3-wise testing. Eventually, we can say T-wise testing.

The N-wise testing then would just be, all possible combinations from the above formula.

Example

[edit]

Consider the parameters shown in the table below.

Parameter name Value 1 Value 2 Value 3 Value 4
Enabled True False - -
Choice type 1 2 3 -
Category a b c d

'Enabled', 'Choice Type' and 'Category' have a choice range of 2, 3 and 4, respectively. An exhaustive test would involve 24 tests (2 x 3 x 4). Multiplying the two largest values (3 and 4) indicates that a pair-wise tests would involve 12 tests. The pairwise test cases, generated by Microsoft's "pict" tool, are shown below.

Enabled Choice type Category
True 3 a
True 1 d
False 1 c
False 2 d
True 2 c
False 2 a
False 1 a
False 3 b
True 2 b
True 3 d
False 3 c
True 1 b

See also

[edit]

Notes

[edit]
  1. ^ Berger, Bernie (2003). "Efficient Testing with All-Pairs" (PDF). TechWell Corporation. Retrieved 21 November 2023.
  2. ^ Black, Rex (2007). Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional. New York: Wiley. p. 240. ISBN 978-0-470-12790-2.
  3. ^ Kuhn, D. Richard; Wallace, Dolores R.; Gallo, Albert M. Jr. (June 2004). "Software Fault Interactions and Implications for Software Testing" (PDF). IEEE Transactions on Software Engineering. 30 (6): 418–421. doi:10.1109/TSE.2004.24. S2CID 206778290.
  4. ^ Kuhn, D. Richard; Kacker, Raghu N.; Yu Lei (October 2010). Practical Combinatorial Testing. SP 800-142 (Report). National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-142.
  5. ^ IEEE 12. Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications. July 18, 2008. pp. 1–150. doi:10.1109/IEEESTD.2008.4578383. ISBN 978-0-7381-5746-7. {{cite book}}: |journal= ignored (help)
[edit]