Ask a question to Desklib · AI bot


Test Generation Techniques for Desklib Online Library

Added on -2019-09-21

This article discusses the testing techniques used in Desklib Online Library, including error guessing, boundary analysis, and branch and condition/decision testing. The tests produced with these techniques were combined to prevent duplication and focused mainly on structural testing. The article also highlights some assumptions and errors found in the prototype pseudocode.
| 2 pages
| 888 words

Trusted by 2+ million users,
1000+ happy students everyday

Test Generation TechniquesTesting techniques are either functional (blackbox) or structural, and both types were used inthis assignment. Tests produced with different techniques that use the same data were combined into a single tests to prevent duplication: many control structures are executed in loops and with specific data can exercise both branches. Since testing all combinations of inputs is not feasible (Müller et al, 2005), tests were mainly focused around the structural testing.Error Guessing“To test program is to try to make it fail” (Meyer, 2008) - is the principle used to specify the first test cases for given task. Produced tests (1 - 5, 18) are focusing on the file input and were generated using the blackbox error guessing technique. It exploits ambiguities in the specification and uses past experience and intuition to identify what situations may cause software to fail (Black, 2014). The advantages of this technique in the possibility of “thinking out of the box” situations which may not be considered in other techniques (Kuckis 2013).Boundary AnalysisBoundary value analysis (blackbox), which is one of the most useful test-case-design methods (Myers 2012) was used to test to confirm that the program can handle the stated restriction extremes (15 - 17). Though not particularly useful for this task (due to a complex unified structure), boundary value analysis is the easiest way to check the edge cases without reinventing the wheel.Branch and Condition/Decision TestingMajority of tests are focused around the branch testing techniques because of their ease of implementation (Yang, et al 2006) and effective code-line coverage. Path selection criteria focuses on control structure: each source statement is executed at least once and all inputs are used for branching structures (Whittaker 2000). Main goal for tests was to cover all the possible branches in the source code using as little different inputs as possible. This allows to keep the testing suite short and to the point, find more errors with less tests.Every test (5 - 14) was produced by following the code to the first branch and applying eitherbranch or condition/decision technique to make sure all condition and decisions are tested. Simple loops (lines 54 - 56) that could be (dynamically/runtime) unfolded into contiguous code, were not tested as a control structure. Generated tests were then analysed to find covered branches later in code to prevent test duplication. Although tests are very inclusive and the point of failure may hide other possible bugs, the disadvantage is not in the selected technique but in the code structure itself. It is not split into single functions that could be tested in isolation.

Found this document preview useful?

You are reading a preview
Upload your documents to download
Become a Desklib member to get accesss

Students who viewed this