Test Generation Techniques.

Added on - 21 Sep 2019

  • 2


  • 888


  • 111


  • 0


Showing pages 1 to 1 of 2 pages
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 werecombined into a single tests to prevent duplication: many control structures are executed inloops and with specific data can exercise both branches. Since testing all combinations ofinputs is not feasible (Müller et al, 2005), tests were mainly focused around the structuraltesting.Error Guessing“To test program is to try to make it fail” (Meyer, 2008) - is the principle used to specify thefirst test cases for given task. Produced tests (1 - 5, 18) are focusing on the file input andwere generated using the blackbox error guessing technique. It exploits ambiguities in thespecification and uses past experience and intuition to identify what situations may causesoftware to fail (Black, 2014). The advantages of this technique in the possibility of “thinkingout 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-designmethods (Myers 2012) was used to test to confirm that the program can handle the statedrestriction extremes (15 - 17). Though not particularly useful for this task (due to a complexunified structure), boundary value analysis is the easiest way to check the edge caseswithout reinventing the wheel.Branch and Condition/Decision TestingMajority of tests are focused around the branch testing techniques because of their ease ofimplementation (Yang, et al 2006) and effective code-line coverage. Path selection criteriafocuses on control structure: each source statement is executed at least once and all inputsare used for branching structures (Whittaker 2000). Main goal for tests was to cover all thepossible branches in the source code using as little different inputs as possible. This allowsto 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 contiguouscode, were not tested as a control structure. Generated tests were then analysed to findcovered branches later in code to prevent test duplication. Although tests are very inclusiveand the point of failure may hide other possible bugs, the disadvantage is not in the selectedtechnique but in the code structure itself. It is not split into single functions that could betested in isolation.
You’re reading a preview

To View Complete Document

Become a Desklib Library Member.
Subscribe to our plans

Unlock This Document