Editing Black-box testing

{{Short description|Method of software testing}}
{{Black-box}}

'''Black-box testing,''' sometimes referred to as '''specification-based testing''',<ref>{{cite book|author1=Jerry Gao|author2=H.-S. J. Tsao|author3=Ye Wu|title=Testing and Quality Assurance for Component-based Software|url=https://books.google.com/books?id=VoCX09hOsCoC&pg=PA170|year=2003|publisher=Artech House|isbn=978-1-58053-735-3|pages=170–}}</ref> is a method of [[software testing]] that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied virtually to every level of software testing: [[unit test|unit]], [[integration testing|integration]], [[system testing|system]] and [[acceptance test|acceptance]]. Black-box testing is also used as a method in [[penetration test]]ing, where an [[ethical hacker]] simulates an external hacking or cyber warfare attack with no knowledge of the system being attacked.

==Test procedures==
Specification-based testing aims to test the functionality of software according to the applicable requirements.<ref>{{Cite thesis |last=Laycock |first=Gilbert T. |title=The Theory and Practice of Specification Based Software Testing |degree=dissertation |publisher=Department of Computer Science, [[University of Sheffield]] |url=http://www.cs.le.ac.uk/people/glaycock/thesis.pdf |year=1993 |access-date=January 2, 2018}}</ref> This level of testing usually requires thorough [[Test case|test cases]] to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case.[[File:Blackbox3D-withGraphs.svg|thumb|upright=1.4|Example of a black box model where a certain input produces a certain output]]
Specific knowledge of the application's code, internal structure and programming knowledge in general is not required.<ref>{{cite book |author=Milind G. Limaye |title=Software Testing |url=https://books.google.com/books?id=zUm8My7SiakC&pg=PA216 |year=2009 |publisher=Tata McGraw-Hill Education |isbn=978-0-07-013990-9 |pages=216}}</ref> The tester is aware of ''what'' the software is supposed to do but is not aware of ''how'' it does it. For instance, the tester is aware that a particular input returns a certain, invariable output but is not aware of ''how'' the software produces the output in the first place.<ref name="REF1">{{cite book|title=Software Testing|last=Patton|first=Ron|publisher=Sams Publishing|year=2005|isbn=978-0672327988|edition=2nd|location=Indianapolis|url-access=registration|url=https://archive.org/details/softwaretesting0000patt}}</ref>

===Test cases===
[[Test case|Test cases]] are built around specifications and [[Software requirements|requirements]], i.e., what the application is supposed to do. Test cases are generally derived from external descriptions of the software, including specifications, requirements and design parameters. Although the tests used are primarily ''functional'' in nature, ''non-functional'' tests may also be used. The test designer selects both valid and invalid inputs and determines the correct output, often with the help of a [[test oracle]] or a previous result that is known to be good, without any knowledge of the test object's internal structure.

=== Test design techniques ===
Typical black-box test design techniques include [[decision table]] testing, [[all-pairs testing]], [[equivalence partitioning]], [[boundary value analysis]], [[cause–effect graph]], [[error guessing]], [[state transition]] testing, [[use case]] testing, [[user story]] testing, [[domain analysis]], and syntax testing.<ref>{{Cite book|title=Practical Test Design: Selection of Traditional and Automated Test Design Techniques |first1=István|last1=Forgács|first2=Attila|last2=Kovács |year=2019 |publisher=BCS Learning & Development Limited |isbn=978-1780174723}}</ref><ref name="BlackPragmatic11">{{Cite book |last=Black, R. |url=https://books.google.com/books?id=n-bTHNW97kYC&pg=PA44 |title=Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional |publisher=John Wiley & Sons |year=2011 |isbn=978-1-118-07938-6 |pages=44–6}}</ref>

== Test coverage ==
{{Redirects|Test coverage|coverage based on source code|Code coverage}}
'''Test coverage''' refers to the percentage of [[software requirements]] that are tested by black-box testing for a system or application.<ref>{{Cite tech report|number=610.12-1990|date=1990|institution=[[IEEE]]|title=IEEE Standard Glossary of Software Engineering Terminology}}</ref> This is in contrast with [[code coverage]], which examines the inner workings of a program and measures the degree to which the [[source code]] of a [[Computer program|program]] is executed when a test suite is run.<ref name=":0">{{Cite web |title=Code Coverage vs Test Coverage |url=https://www.browserstack.com/guide/code-coverage-vs-test-coverage |access-date=2024-04-13 |website=BrowserStack |language=en-US}}</ref> Measuring test coverage makes it possible to quickly detect and eliminate defects, to create a more comprehensive [[test suite]]. and to remove tests that are not relevant for the given requirements.<ref name=":0" /><ref>{{Cite web |last=Andrades |first=Geosley |date=2023-12-16 |title=Top 8 Test Coverage Techniques in Software Testing |url=https://www.accelq.com/blog/test-coverage-techniques/ |access-date=2024-04-13 |website=ACCELQ Inc |language=en-GB}}</ref>

== Effectiveness ==
Black-box testing may be necessary to assure correct functionality, but it is insufficient to guard against complex or high-risk situations.<ref>{{Cite journal |last=Bach |first=James |author-link=James Bach |date=June 1999 |title=Risk and Requirements-Based Testing |url=http://www.satisfice.com/articles/requirements_based_testing.pdf |journal=Computer |volume=32 |issue=6 |pages=113–114 |access-date=August 19, 2008}}</ref> An advantage of the black box technique is that no programming knowledge is required. Whatever biases the programmers may have had, the tester likely has a different set and may emphasize different areas of functionality. On the other hand, black-box testing has been said to be "like a walk in a dark labyrinth without a flashlight."<ref>{{Cite book |last=Savenkov |first=Roman |title=How to Become a Software Tester |publisher=Roman Savenkov Consulting |year=2008 |isbn=978-0-615-23372-7 |page=159}}</ref> Because they do not examine the source code, there are situations when a tester writes many test cases to check something that could have been tested by only one test case or leaves some parts of the program untested.

==See also==
{{div col|colwidth=20em}}
* [[ABX test]]
* [[Acceptance testing]]
* [[Blind experiment]]
* [[Boundary testing]]
* [[Fuzz testing]]
* [[Gray box testing]]
* [[Metasploit Project]]
* [[Sanity testing]]
* [[Smoke testing (software)|Smoke testing]]
* [[Software performance testing]]
* [[Software testing]]
* [[Stress testing]]
* [[Test automation]]
* [[Unit testing]]
* [[Web application security scanner]]
* [[White hat (computer security)|White hat hacker]]
* [[White-box testing]]
{{div col end}}

== References ==
{{Reflist}}

==External links==
*BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): [http://www.testingstandards.co.uk/Component%20Testing.pdf ''Standard for Software Component Testing''], Working Draft 3.4, 27. April 2001.

{{Software testing}}

{{DEFAULTSORT:Black-Box Testing}}
[[Category:Software testing]]
[[Category:Hardware testing]]