White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing). In white-box testing, an internal perspective of the system is used to design test cases. The tester chooses inputs to exercise paths through the code and determine the expected outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT). White-box testing can be applied at the unit, integration and system levels of the software testing process. Although traditional testers tended to think of white-box testing as being done at the unit level, it is used for integration and system testing more frequently today. 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 has the potential to miss unimplemented parts of the specification or missing requirements. Where white-box testing is design-driven, that is, driven exclusively by agreed specifications of how each component of software is required to behave (as in DO-178C and ISO 26262 processes), white-box test techniques can accomplish assessment for unimplemented or missing requirements. White-box test design techniques include the following code coverage criteria: Control flow testing Data flow testing Branch testing Statement coverage Decision coverage Modified condition/decision coverage Prime path testing Path testing White-box testing is a method of testing the application at the level of the source code. These test cases are derived through the use of the design techniques mentioned above: control flow testing, data flow testing, branch testing, path testing, statement coverage and decision coverage as well as modified condition/decision coverage. White-box testing is the use of these techniques as guidelines to create an error-free environment by examining all code.

About this result
This page is automatically generated and may contain information that is not correct, complete, up-to-date, or relevant to your search query. The same applies to every other page on this website. Please make sure to verify the information with EPFL's official sources.
Related lectures (25)
External Libraries and Doxygen
Covers compilation, linking, external libraries, Doxygen documentation, and Google Test for C++ unit testing.
Mini-Tests Guidelines
Covers mini-test guidelines and the concept of moment of inertia for various shapes, including practical demonstrations on gyroscopic forces.
Unit Testing in Java: Arrays
Discusses unit testing for Java arrays and methods to find min, average, and sort.
Show more
Related publications (47)

To Infinity, and Beyond (Coverage)

Ahmad Hazimeh

The pursuit of software security and reliability hinges on the identification and elimination of software vulnerabilities, a challenge compounded by the vast and evolving complexity of modern systems. Fuzzing has emerged as an indispensable technique for b ...
EPFL2024

Uniaxial fiber reinforced DEA fabrication

Julian Asboth

Dielectric Elastomer Actuators (DEA) are devices designed to convert electric energy into mechanical work. However, the current actuator design will expand when actuated while muscles contract. Fiber reinforcement may allow for anisotropic movement, which ...
2023

DatAFLow: Toward a Data-Flow-Guided Fuzzer

Mathias Josef Payer

Coverage-guided greybox fuzzers rely on control-flow coverage feedback to explore a target program and uncover bugs. Compared to control-flow coverage, data-flow coverage offers a more fine-grained approximation of program behavior. Data-flow coverage capt ...
2023
Show more
Related concepts (1)
Software testing
Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to: analyzing the product requirements for completeness and correctness in various contexts like industry perspective, business perspective, feasibility and viability of implementation, usability, performance, security, infrastructure considerations, etc.

Graph Chatbot

Chat with Graph Search

Ask any question about EPFL courses, lectures, exercises, research, news, etc. or try the example questions below.

DISCLAIMER: The Graph Chatbot is not programmed to provide explicit or categorical answers to your questions. Rather, it transforms your questions into API requests that are distributed across the various IT services officially administered by EPFL. Its purpose is solely to collect and recommend relevant references to content that you can explore to help you answer your questions.