Gray-box testing: Difference between revisions
Content deleted Content added
fixed redirect |
Importing Wikidata short description: "Software testing" |
||
| (248 intermediate revisions by 83 users not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Software testing}} |
|||
#REDIRECT [[Software_testing#Grey_Box_Testing]] |
|||
{{Use dmy dates|date=September 2021}} |
|||
{{Black-box}} |
|||
'''Gray-box testing''' (International English spelling: '''grey-box testing''') is a combination of [[white-box testing]] and [[black-box testing]]. The aim of this testing is to search for the defects, if any, due to improper structure or improper usage of applications.<ref>{{Cite web | url=http://research.microsoft.com/pubs/81199/p1-kicillof.pdf |title = Microsoft Research – Emerging Technology, Computer, and Software Research}}</ref><ref>{{Cite web |url=http://eastwest.inf.brad.ac.uk/document/publication/Doungsa-ard-IWS06%20.pdf |title=Archived copy |access-date=17 October 2011 |archive-url=https://web.archive.org/web/20120329214234/http://eastwest.inf.brad.ac.uk/document/publication/Doungsa-ard-IWS06%20.pdf |archive-date=29 March 2012 |url-status=dead }}</ref> |
|||
==Overview== |
|||
A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester has access to the internal structure of the application. A gray-box tester partially knows the internal structure, which includes access to the documentation of internal data structures as well as the algorithms used.<ref>{{cite web |url=http://softwaretestingfundamentals.com/gray-box-testing |title=Gray Box Testing |publisher=Software Testing Fundamentals |date=4 November 2011 |access-date=19 January 2012 |archive-date=16 November 2021 |archive-url=https://web.archive.org/web/20211116044449/https://softwaretestingfundamentals.com/gray-box-testing/ |url-status=dead }}</ref> |
|||
Gray-box testers require both high-level and detailed documents describing the application, which they collect in order to define test cases.<ref>{{cite web|url=http://www.geekinterview.com/question_details/35806 |title=Example of grey box testing with definition |publisher=Geekinterview.com |access-date=19 January 2012}}</ref> |
|||
==Need for gray-box testing== |
|||
Gray-box testing is beneficial because it takes the straightforward technique of black-box testing and combines it with the code-targeted systems in white-box testing. |
|||
Gray-box testing is based on requirement test case generation because it presents all the conditions before the program is tested by using the assertion method. A requirement [[Software requirements specification|specification language]] is used to make it easy to understand the requirements and verify its correctness.<ref name="cgsec">{{cite web |author=Jake Rogers |url=https://www.cgsec.co.uk/2016/08/09/common-questions-regarding-grey-box-testing/ |title=Common Questions Regarding Grey-Box Testing |publisher=cgsec.co.uk |date=8 August 2016 |access-date=8 August 2016 }}{{Dead link|date=March 2023 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> |
|||
==Gray-box testing assumptions for object-oriented software== |
|||
Object-oriented software consists primarily of objects; where objects are single indivisible units having executable code and/or data. Some assumptions are stated below which are needed for the application of use gray-box testing. |
|||
* Activation of Methods<ref>{{cite web |url=http://pascal-central.com/OOE-stds.html#sect-6.5.8.2 |title=Object-Oriented Extensions to Pascal |publisher=Pascal-central.com |access-date=19 January 2012 |archive-date=5 June 2021 |archive-url=https://web.archive.org/web/20210605064414/http://pascal-central.com/OOE-stds.html#sect-6.5.8.2 |url-status=dead }}</ref> |
|||
* State Reporting in Class Under Test (CUT). |
|||
* Report Testing is inherent in Class Under Test.<ref name="cgsec"/> |
|||
==Examples== |
|||
*[[Architectural model]] |
|||
* [[Unified Modeling Language]] - UML Design Model |
|||
* [[Finite-state machine]] - State Model.<ref>{{cite book|last=Patton|first=Ron|title=Software Testing|date=26 July 2005|publisher=Sams|isbn=978-0-672-32798-8|page=[https://archive.org/details/softwaretesting0000patt/page/2 2]|url=https://archive.org/details/softwaretesting0000patt/page/2|url-access=registration}}</ref><ref>{{Cite web |url=http://www.site.uottawa.ca/~ssome/Cours/SEG3203/gboxtesting.pdf |title=Archived copy |access-date=17 October 2011 |archive-url=https://web.archive.org/web/20120403002944/http://www.site.uottawa.ca/~ssome/Cours/SEG3203/gboxtesting.pdf |archive-date=3 April 2012 |url-status=dead }}</ref> |
|||
==Techniques== |
|||
[[Cem Kaner]] defines "gray-box testing as involving inputs and outputs, but test design is educated by information about the code or the program operation of a kind that would normally be out of view of the tester".<ref>{{cite book |last=Nguyen |first=Hung Q |date=2001 |title=Testing Applications on the Web: Test Planning for Internet-Based Systems |publisher=John Wiley & Sons |isbn=9780471437642}}</ref> Gray-box testing techniques are: |
|||
*Matrix Testing: states the status report of the project. |
|||
* [[Regression testing]]: it implies rerunning of the test cases if new changes are made. |
|||
*Pattern Testing: verify the good application for its design or architecture and patterns. |
|||
*[[Orthogonal array testing]]: used as subset of all possible combination.<ref>{{cite web|url=http://extremesoftwaretesting.com/Articles/WorldofGrayBoxTesting.html |title=Explore the World of Gray Box Testing |publisher=Extremesoftwaretesting.com |access-date=19 January 2012}}</ref> |
|||
==Effects== |
|||
===Positive Effects=== |
|||
*Offers combined benefits: As Gray-box testing is combination of white-box and black-box testing, it serves advantages from both the testings. |
|||
*Non Intrusive: It is based on functional specification, architectural view whereas not on source code or binaries which makes it invasive too. |
|||
*Intelligent Test Authoring: Gray-box tester handles intelligent test scenario, for example, data type handling, communication protocol, [[exception handling]]. |
|||
*Unbiased Testing: In spite of all above advantages and functionalities, Gray-box testing maintains boundary for testing between tester and developer.<ref name="crosschecknet1">{{cite web |url=http://www.crosschecknet.com/soa_testing_black_white_gray_box.php |title=SOA Testing Tools for Black, White and Gray Box SOA Testing Techniques |publisher=Crosschecknet.com |access-date=19 January 2012 |archive-url=https://web.archive.org/web/20181001010542/http://www.crosschecknet.com/soa_testing_black_white_gray_box.php |archive-date=1 October 2018 |url-status=dead }}</ref> |
|||
===Negative Effects=== |
|||
*Partial code coverage: In gray-box testing, source code or binaries are missing because of limited access to internal or structure of the applications which results in limited access for code path traversal. |
|||
*Defect Identification: In distributed applications, it is difficult to associate defect identification. Still, Gray-box testing is a boon to find how appropriate these systems throw exceptions and how fine are these exceptions handled in distributed systems having web services environment.<ref name="crosschecknet1"/><ref>{{Cite web | url=http://www.sfisaca.org/events/conference04/presentations/E33-Gray-Box-Testing.pdf | title=E33 Gray Box Testing.PDF}}</ref> |
|||
==Applications== |
|||
*Gray-box testing is well suited for web applications. Web applications have distributed network or systems; due to absence of source code or binaries it is not possible to use white-box testing. Black-box testing is also not used due to just contract between customer and developer, so it is more efficient to use gray-box testing as significant information is available in [[Web Services Description Language]] (WSDL).<ref>{{cite web|last=Ramdeo |first=Anand |url=http://www.testinggeek.com/gray-box-testing |title=Gray Box Testing - Software |publisher=Testing Geek |date=5 May 2011 |access-date=19 January 2012}}</ref> |
|||
*Gray-box testing is suited for functional or business domain testing. Functional testing is done basically a test of user interactions with may be external systems. Gray-box testing is well-suited for functional testing due to its characteristics; it also helps to confirm that software meets the requirements defined for the software.<ref>{{cite book|last=Bach|first=James|title=Lessons Learned in Software Testing|date=31 December 2001 |publisher=Wiley Computer Publishing|isbn=978-0-471-08112-8 |url=https://www.amazon.com/exec/obidos/ASIN/0471081124/softwarqaandtest}}</ref><ref>{{cite book|last=Falk|first=Jack|title=Testing Computer Software, 2nd Edition|date=12 April 1999 |publisher=Wiley Computer Publishing|isbn=978-0-471-35846-6 |url=https://www.amazon.com/exec/obidos/ASIN/0471358460/softwarqaandtest}}</ref><ref>http://legacy.cleanscape.net/docs_lib/paper_graybox.pdf {{Bare URL PDF|date=March 2022}}</ref><ref>{{cite journal |journal=IBM Systems Journal |volume=47 |issue=3 |pages=457–472 |doi=10.1147/sj.473.0457 |date=6 April 2010 |last1=Li |first1=Z. J. |title=Business-process-driven gray-box SOA testing |last2=Tan |first2=H. F. |last3=Liu |first3=H. H. |last4=Zhu |first4=J. |last5=Mitsumori |first5=N. M. }}</ref> |
|||
==Future scope== |
|||
The distributed nature of [[Web service]]s allows gray-box testing to detect defects within a [[service-oriented architecture]] (SOA). As we know, white-box testing is not suitable for Web services as it deals directly with the internal structures. White-box testing can be used for state art methods; for example, message mutation which generates the automatic tests for large arrays to help exception handling states, flow without source code or binaries. Such a strategy is useful to push gray-box testing nearer to the outcomes of white-box testing. |
|||
==See also== |
|||
* [[Grey box model]] |
|||
==References== |
|||
{{Reflist}} |
|||
{{Software testing}} |
|||
[[Category:Hardware testing]] |
|||
[[Category:Software testing]] |
|||
Latest revision as of 22:35, 28 November 2024
| Black box systems | |
|---|---|
 | |
| System | |
| Black box, Oracle machine | |
| Methods and techniques | |
| Black-box testing, Blackboxing | |
| Related techniques | |
| Feed forward, Obfuscation, Pattern recognition, White box, White-box testing, Gray-box testing, System identification | |
| Fundamentals | |
| A priori information, Control systems, Open systems, Operations research, Thermodynamic systems | |
Gray-box testing (International English spelling: grey-box testing) is a combination of white-box testing and black-box testing. The aim of this testing is to search for the defects, if any, due to improper structure or improper usage of applications.[1][2]
Overview
[edit]A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester has access to the internal structure of the application. A gray-box tester partially knows the internal structure, which includes access to the documentation of internal data structures as well as the algorithms used.[3]
Gray-box testers require both high-level and detailed documents describing the application, which they collect in order to define test cases.[4]
Need for gray-box testing
[edit]Gray-box testing is beneficial because it takes the straightforward technique of black-box testing and combines it with the code-targeted systems in white-box testing.
Gray-box testing is based on requirement test case generation because it presents all the conditions before the program is tested by using the assertion method. A requirement specification language is used to make it easy to understand the requirements and verify its correctness.[5]
Gray-box testing assumptions for object-oriented software
[edit]Object-oriented software consists primarily of objects; where objects are single indivisible units having executable code and/or data. Some assumptions are stated below which are needed for the application of use gray-box testing.
- Activation of Methods[6]
- State Reporting in Class Under Test (CUT).
- Report Testing is inherent in Class Under Test.[5]
Examples
[edit]- Architectural model
- Unified Modeling Language - UML Design Model
- Finite-state machine - State Model.[7][8]
Techniques
[edit]Cem Kaner defines "gray-box testing as involving inputs and outputs, but test design is educated by information about the code or the program operation of a kind that would normally be out of view of the tester".[9] Gray-box testing techniques are:
- Matrix Testing: states the status report of the project.
- Regression testing: it implies rerunning of the test cases if new changes are made.
- Pattern Testing: verify the good application for its design or architecture and patterns.
- Orthogonal array testing: used as subset of all possible combination.[10]
Effects
[edit]Positive Effects
[edit]- Offers combined benefits: As Gray-box testing is combination of white-box and black-box testing, it serves advantages from both the testings.
- Non Intrusive: It is based on functional specification, architectural view whereas not on source code or binaries which makes it invasive too.
- Intelligent Test Authoring: Gray-box tester handles intelligent test scenario, for example, data type handling, communication protocol, exception handling.
- Unbiased Testing: In spite of all above advantages and functionalities, Gray-box testing maintains boundary for testing between tester and developer.[11]
Negative Effects
[edit]- Partial code coverage: In gray-box testing, source code or binaries are missing because of limited access to internal or structure of the applications which results in limited access for code path traversal.
- Defect Identification: In distributed applications, it is difficult to associate defect identification. Still, Gray-box testing is a boon to find how appropriate these systems throw exceptions and how fine are these exceptions handled in distributed systems having web services environment.[11][12]
Applications
[edit]- Gray-box testing is well suited for web applications. Web applications have distributed network or systems; due to absence of source code or binaries it is not possible to use white-box testing. Black-box testing is also not used due to just contract between customer and developer, so it is more efficient to use gray-box testing as significant information is available in Web Services Description Language (WSDL).[13]
- Gray-box testing is suited for functional or business domain testing. Functional testing is done basically a test of user interactions with may be external systems. Gray-box testing is well-suited for functional testing due to its characteristics; it also helps to confirm that software meets the requirements defined for the software.[14][15][16][17]
Future scope
[edit]The distributed nature of Web services allows gray-box testing to detect defects within a service-oriented architecture (SOA). As we know, white-box testing is not suitable for Web services as it deals directly with the internal structures. White-box testing can be used for state art methods; for example, message mutation which generates the automatic tests for large arrays to help exception handling states, flow without source code or binaries. Such a strategy is useful to push gray-box testing nearer to the outcomes of white-box testing.
See also
[edit]References
[edit]- ^ "Microsoft Research – Emerging Technology, Computer, and Software Research" (PDF).
- ^ "Archived copy" (PDF). Archived from the original (PDF) on 29 March 2012. Retrieved 17 October 2011.
{{cite web}}: CS1 maint: archived copy as title (link) - ^ "Gray Box Testing". Software Testing Fundamentals. 4 November 2011. Archived from the original on 16 November 2021. Retrieved 19 January 2012.
- ^ "Example of grey box testing with definition". Geekinterview.com. Retrieved 19 January 2012.
- ^ a b Jake Rogers (8 August 2016). "Common Questions Regarding Grey-Box Testing". cgsec.co.uk. Retrieved 8 August 2016.[permanent dead link]
- ^ "Object-Oriented Extensions to Pascal". Pascal-central.com. Archived from the original on 5 June 2021. Retrieved 19 January 2012.
- ^ Patton, Ron (26 July 2005). Software Testing. Sams. p. 2. ISBN 978-0-672-32798-8.
- ^ "Archived copy" (PDF). Archived from the original (PDF) on 3 April 2012. Retrieved 17 October 2011.
{{cite web}}: CS1 maint: archived copy as title (link) - ^ Nguyen, Hung Q (2001). Testing Applications on the Web: Test Planning for Internet-Based Systems. John Wiley & Sons. ISBN 9780471437642.
- ^ "Explore the World of Gray Box Testing". Extremesoftwaretesting.com. Retrieved 19 January 2012.
- ^ a b "SOA Testing Tools for Black, White and Gray Box SOA Testing Techniques". Crosschecknet.com. Archived from the original on 1 October 2018. Retrieved 19 January 2012.
- ^ "E33 Gray Box Testing.PDF" (PDF).
- ^ Ramdeo, Anand (5 May 2011). "Gray Box Testing - Software". Testing Geek. Retrieved 19 January 2012.
- ^ Bach, James (31 December 2001). Lessons Learned in Software Testing. Wiley Computer Publishing. ISBN 978-0-471-08112-8.
- ^ Falk, Jack (12 April 1999). Testing Computer Software, 2nd Edition. Wiley Computer Publishing. ISBN 978-0-471-35846-6.
- ^ http://legacy.cleanscape.net/docs_lib/paper_graybox.pdf [bare URL PDF]
- ^ Li, Z. J.; Tan, H. F.; Liu, H. H.; Zhu, J.; Mitsumori, N. M. (6 April 2010). "Business-process-driven gray-box SOA testing". IBM Systems Journal. 47 (3): 457–472. doi:10.1147/sj.473.0457.