Black Box And White Box Comparison Computer Science Essay Example

to determine which technique is appropriate for testing at different stages of software testing. While white box testing is suitable for unit level testing, black box testing is preferred for integration or system level testing. Hence, relying solely on white box or black box testing is inadequate in detecting all software bugs.

The paper discusses the significance of both black box testing and white box testing in software testing and bug identification. The structure of the paper is as follows: Section 2 provides a comprehensive explanation of black box testing. Section 3 elaborates on the white box testing method used in software projects. Section 4 compares the approaches of both black box and white box testing. Lastly, Section 5 presents concluding remarks for the paper.

BLACK BOX TESTING

"Black box testing treats the system as a black-box, so it doesn't explicitly use knowledge of the internal structure or code." Therefore, black box testing is performed by giving inputs and getting the expected output. It verifies the correctness of the software's behavior and is referred to as behavior coverage. The focus is on the functionality of the system. The requirements for black box testing include software requirements, executable program, and its data. These requirements are usually met during the middle phase of the development lifecycle when large pieces of code begin to operate together.

Black box testing is conducted when the source code is not available. Once programming is finished, the code is packaged into larger components. These components are compiled, linked, or bound to showcase the collective execution behavior of the code with its inputs and outputs. A diagram of Black box testing is provided below. Developers primarily

concentrate on positive testing to validate the expected behavior of the code. Testers enhance black box testing by conducting both positive and negative testing as they understand that most defects are discovered through unexpected behavior. The following are the techniques utilized in Black box testing.

Equivalence class technique

In the equivalence class technique, the software data is divided into partitions and test cases are generated from these partitions. This ensures that the test cases cover the partitioned data. According to this method, only one test case is needed for each partition to verify the program's behavior. By using the equivalence class technique, the number of test cases can be reduced because multiple test cases within a partition will not uncover any new faults. The recommended black box approach for selecting equivalence class values includes choosing values from the beginning, middle, and end of the data range. To better understand this technique, let's consider an example.

Assuming a security system needs to validate 5000 logon IDs during production. The tester has two options for validation: either validating each logon ID individually or selecting a sample from three categories of IDs (clerks, supervisors, and managers). In this case, selecting 50 logon IDs from each category will be sufficient for validation.

During validation, if any of the 50 logon IDs for a given category is not accepted, the sample size of logon IDs for that category is increased and testing continues. If the initial samples of 150 IDs for all three categories are accepted, the desired test results are achieved using only 3% of the possible test data.

Boundary Value Analysis technique

This technique extends the analysis of the beginning and ending input value

possibilities of an equivalence class. Functional errors in input and output data occur around these boundaries. The analysis begins by identifying the smallest value increment within a specific equivalence class, known as the boundary value epsilon.

It is used to calculate +/- value around the beginning and ending values in an equivalence class. If we take the above example then the boundary value for each category would be 49, 50, 51 for 50 value and 149, 150, 151 for 150 equivalence value. Equivalence classes remain smaller even by the addition of boundary test values.

Expected result coverage Technique

The expected result coverage technique focus on output test values for related input values.

In order to achieve the desired outcomes, it is important to identify the business rules specified in the application requirement. If there is a difference between the expected and actual results for a particular input combination, further analysis should be conducted to determine if the discrepancy is due to inadequate test design, unclear or ambiguous rules, or a program error.

Error Guessing

This technique involves the Tester making educated guesses about potential bugs or errors. The Tester relies on past experience to test the application and creates test cases to verify different tasks.

There is no specific tool used for this technique.

Here are the advantages to black box testing:

Ease of Use

Black Box testing is not involved in the inner functionality of the application so it is easy for the tester to create test cases by simply working through the application. Black box testers don't need high skills in programming rather low skilled persons can do black box testing.

Quicker Test Case Development

Test cases can be developed quickly because testers only concern

themselves with the user interface. There is no need to identify the internal paths that may be involved in a specific process.

The tester will cover the UI paths that a user may take so it makes quicker test development.

Simplicity

Using black box testing even complex applications can be tested, that focuses on valid and invalid inputs and ensuring that the correct out puts are received.

Issues of Black box testing

The Followings are the few issues of black box testing approach.

Fragility

User interface interaction makes script fragile. The reason is because the UI may not be rendered constantly from time to time on different platforms. Unless the tool is capable dealing with difference in UI rendering, it is likely that test cases will fail to execute properly.

[2]
Lack of introspection
Black box testing lacks the ability to inspect an application's internal logic, unlike white box testing. Consequently, it is unable to provide comprehensive testing for an application.
Failure reason
Furthermore, black box testing fails to identify the root cause of a failure and does not reveal what triggers system failures. Therefore, pure black box testing does not guarantee complete coverage of the tested component.

WHITE BOX TESTING

White box testing involves testing the inner logic of a program using test cases constructed from the program's source code. It is based on knowledge of how the system is implemented. White box testing analyzes data flow, control flow, information flow, coding practices, exception and error handling to test both intended and unintended system behavior [1]. Access to the source code is required for white box testing. While white box testing can be performed at any stage in the development life cycle,

it is typically done during unit level testing.

The initial phase of white box testing involves studying design documents and source code in order to understand how to ensure software security. The subsequent step is to formulate tests that expose vulnerabilities in the software. Lastly, testers must possess knowledge of techniques and tools utilized in white box testing to effectively perform the tests. Typically, white box testing is conducted by developers as an extension of the code debugging process.

Developers typically concentrate on ensuring the code functions properly, which means they tend to debug only the code they are certain works correctly. Software testers enhance the developer's debugging effort by assisting them in planning and debugging a larger portion of the code than usual. The more thorough the testing coverage in terms of logic during debugging, the fewer defects will be identified later on through other forms of testing. The sooner these defects are detected, the less costly they are to fix. According to research, there is currently no white box approach that guarantees 100% logic test coverage for all scenarios. [3] Below is a diagram illustrating white box testing.

White Box Testing Techniques:

White box testing is concerned with verifying the accuracy of the software's statements, code paths, conditions, loops, and data flow. The prerequisites for white box testing include software requirements, use cases, the executable program, its data, and its source code. Below are the techniques employed in white box testing.

Statement Coverage Technique

This technique concentrates on determining the percentage of executed source code lines in a program. For instance, if a program has 5,000 lines of source

code and you can ascertain that you have executed 4,537 lines either manually or with a tool, then you have achieved 90.7% statement coverage. It is hypothesized that higher source code test coverage leads to fewer defects discovered later on.

The main point is that new, unexecuted code lines are a potential problem in production. It is not a matter of "if" they will cause issues, but rather "when".

The branch coverage technique

focuses on determining the percentage of executed branch logic in a program. For example, if there are 1,500 branch points and we determine that 1,145 branches have been executed (counting true and false branches separately), we have achieved 76.3% branch point coverage. This issue often occurs in untested error recovery logic, where unexecuted branches and statements coincide.

Testing simple condition branches before the compound condition branches requires less initial test actions. The developer must select a test value that will result in a true branch and any test value that will result in a false branch, just two test values for each branch.

Compound Condition Coverage Technique

This technique expands the branch coverage technique to include branches with compound conditions, which consist of combinations of Boolean operators AND, OR, and NOT, along with pairs of parentheses, potentially nested. The challenge in this technique is to identify all combinations of test values that will evaluate to true and false for every simple condition and every Boolean combination of simple conditions.

Path Coverage Technique

This technique focuses on determining what percentage of source code paths in a program have been completely traversed. “A source code path is the sequence of

program statements from the first executable statement through a series of arithmetic, replacement input/out, branch, and looping statements to a return/stop/end/exit statement.” [3] If there are 943 different paths through a program and we can manually or with a tool determine that we have executed 766 of them, then we have achieved 81% path coverage.

The main idea is that having higher test coverage of paths will result in fewer defects being found later.

The Loop Coverage Technique

This technique focuses on determining the percentage of source code loop that has been completely cycled in a program. Programming languages have various types of loops such as DO, FOR, WHILE, and UNTIL. Some loops are created using IF statements and subsequent returns to these statements. The objective of loop testing is to navigate the program through the loop zero times, once, n/2 times (where n is the terminal loop value), n times, and n+1 times. Testing the loop once, n/2 times, and n times validates the expected loop response at the beginning, middle, and end of the longest loop.

The zero-time and n+1 time loop tests for unexpected and inappropriate looping conditions. Advantages of White Box Testing Here is the list of the few common advantages of white box testing. Introspection "Introspection is the ability to look inside the application and tester can identify objects programmatically." [2] It is helpful when UI changes frequently or the UI yet not known, It allows testing to proceed. In some situations it decreases the fragility of the test script provided the names of an object do not change.

Stability
White box testing offers increased stability and reusability of test cases, as long as the objects

that make up an application do not change.

Thoroughness
White box testing is a highly useful technique for ensuring thorough testing of every path and internal interaction in an application. Testers can achieve a high level of coverage in their testing.

Issues with White box testing

The issues with white box testing are as follows:

Complexity:
White box testing requires testers to have detailed knowledge of the application's programming in order to develop effective test cases. As it involves understanding the internal logic of the application's code, this complexity calls for highly skilled testers.

Fragility Despite overcoming the issue of application changes breaking test scripts through introspection, it is common for object names to change during product development. Test scripts for white box testing are tightly tied to the underlying code of an application, which means that code changes often lead to script breaks. As a result, there is a high degree of script maintenance involved in the testing process.
Integration White box testing tools are highly integrated and usually only provide support for a single platform, typically Windows. Companies that have applications running on other platforms need either different tools or manual testing.

COMPARING BLACK BOX AND WHITE BOX TESTING FEATURES

Black box testing is based on requirements and is therefore referred to as behavioral or functional testing technique. On the other hand, white box testing is based on the internal logic and structure of the project, also known as structural testing.

Black box testing focuses on creating test data based on the software's requirements, without considering the software's structure or implementation. It is typically used in integration or system levels, where it executes a system using input data and output results, without looking

into the source code. On the other hand, white box testing derives tests from the structure of the tested object and is based on the actual implementation. White box testing is used for logical and analytic tests at the unit test level. A black box tester does not require strong programming skills and does not have a strong connection to the code being tested, while a white box tester needs programming skills to identify and test all paths through the software.

Black box testing allows test cases to be designed once functional specifications are complete, while white box testing allows test cases to be designed as the program code is developed. A black box tester verifies contradictions between the actual system and the specifications, while a white box tester selects test case inputs to cover paths through the code and determine appropriate output, revealing any hidden errors. Black box testing emphasizes results and user experience, whereas white box testing focuses on internal workings and ensuring efficient application functionality. While white box testing can be time-consuming for the entire system, it directly identifies more software bugs.

When conducting black box testing, it is necessary to use inputs from a large sample space in order to uncover expected results. There are certain bugs that cannot be detected solely through black box or white box testing. Black box testing presents difficulties in identifying all possible inputs within the time constraints of testing, resulting in slow and challenging test case writing. On the other hand, white box testing cannot perform exhaustive testing on every loop path within a program, making it impossible for large systems. In black box testing, some sections

of code may remain unreached without extraordinary measures, while white box testing does not guarantee that all program functionality has been implemented. To achieve comprehensive test coverage, it is necessary to combine both black box and white box testing techniques, as they offer various advantages in application testing.

CONCLUSION

The conclusion can be drawn after discussing that black box testing ensures the functionality of the software and adherence to user requirements. It is a cost-effective option and can be conducted by individuals with less technical knowledge. However, black box testing lacks comprehensive system testing. In contrast, white box testing examines the internal structure, loops, conditions, and logic of the code to verify its functionality. It is an expensive method performed by skilled individuals. Nevertheless, as software size increases, it becomes challenging to thoroughly assess all parts of the source code during integration or system-level testing.

When it comes to testing methods, both white box testing and black box testing have their advantages and disadvantages for specific levels of testing. Relying on just one testing approach cannot ensure bug-free software. In conclusion, a comprehensive testing of the system can be achieved by combining both techniques for software testing. White box testing, when used alongside black box testing, can enhance the overall effectiveness of the tests.