Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Software testing
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==== White-box testing ==== {{Main|White-box testing}} [[File:White Box Testing Approach.png|alt=White Box Testing Diagram|thumb|White box testing diagram]] White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) verifies the internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing, an internal perspective of the system (the source code), as well as programming skills are used to design test cases. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs.<ref name="LimayeSoftware09" /><ref name="SalehSoftware09" /> This is analogous to testing nodes in a circuit, e.g., [[in-circuit test]]ing (ICT). While white-box testing can be applied at the [[unit testing|unit]], [[integration testing|integration]], and [[system testing|system]] levels of the software testing process, it is usually done at the unit level.<ref name="AmmannIntro16" /> It can test paths within a unit, paths between units during integration, and between subsystems during a systemโlevel test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements. Techniques used in white-box testing include:<ref name="SalehSoftware09" /><ref name="EverettSoftware07">{{Cite book |last1=Everatt, G.D. |title=Software Testing: Testing Across the Entire Software Development Life Cycle |last2=McLeod Jr., R. |publisher=John Wiley & Sons |year=2007 |isbn=978-0-470-14634-7 |pages=99โ121 |chapter=Chapter 7: Functional Testing}}</ref> * [[API testing]] โ testing of the application using public and private [[application programming interfaces|APIs]] (application programming interfaces) * [[Code coverage]] โ creating tests to satisfy some criteria of code coverage (for example, the test designer can create tests to cause all statements in the program to be executed at least once) * [[Fault injection]] methods โ intentionally introducing faults to gauge the efficacy of testing strategies * [[Mutation testing]] methods * [[Static testing]] methods Code coverage tools can evaluate the completeness of a test suite that was created with any method, including black-box testing. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important [[function points]] have been tested.<ref name="CornettCode96">{{Cite web |last=Cornett |first=Steve |date=c. 1996 |title=Code Coverage Analysis |url=https://www.bullseye.com/coverage.html#intro |access-date=November 21, 2017 |publisher=Bullseye Testing Technology |at=Introduction}}</ref> Code coverage as a [[software metric]] can be reported as a percentage for:<ref name="LimayeSoftware09" /><ref name="CornettCode96" /><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> :* ''Function coverage'', which reports on functions executed :* ''Statement coverage'', which reports on the number of lines executed to complete the test :* ''Decision coverage'', which reports on whether both the True and the False branch of a given test has been executed 100% statement coverage ensures that all code paths or branches (in terms of [[control flow]]) are executed at least once. This is helpful in ensuring correct functionality, but not sufficient since the same code may process different inputs correctly or incorrectly.<ref>As a simple example, the [[C (programming language)|C]] function <syntaxhighlight lang="C" inline>int f(int x){return x*x-6*x+8;}</syntaxhighlight> consists of only one statement. All tests against a specification <syntaxhighlight lang="C" inline>f(x)>=0</syntaxhighlight> will succeed, except if <syntaxhighlight lang="C" inline>x=3</syntaxhighlight> happens to be chosen.</ref>
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Software testing
(section)
Add topic