Slicing tool/JaBUTi

De Software testing
Ir para: navegação, pesquisa

Facts

  • The JaBUTi slicing tool is available through the Tools ! Slicing Tool menu option. <bib>vincenzi-etal:2003, 28</bib>
  • The slicing tool implements only a simple heuristic based on control-flow information. <bib>vincenzi-etal:2003, 28</bib>
  • By changing to the slicing tool, the tester has to choose, among the test cases, the ones that cause the fault and the ones that do not reveal the fault. Based on the execution path of the failed and succeed test cases, the tool highlights the part of the code more probable to contain the fault. <bib>vincenzi-etal:2003, 28</bib>
  • JaBUTi uses a simple dynamic slice criterion, based on control-flow information, to identify a subset of statements more probable to contain the fault. The idea is (1) to compute the failed set FS of BG nodes (the execution path) of a failed test case, which includes all statements executed by the failed test case, (2) to compute the succeed set SS of BG nodes considering succeed test case(es), and (3) to calculate the difference and the intersection of these sets to prioritize the statements executed by the failed test case. Using such an approach, instead of the complete set of BG nodes N (which represents all statements of a method), the tester has only to consider the subset of BG nodes present in FS, since the other BG nodes contains the statements not executed by the failed test case and cannot contain the fault. Moreover, considering the subset of nodes executed by the succeed test cases, the most probably location of the fault is in the statements executed by the failed test case but not executed by the succeed test cases, i.e., the subset FS \ SS. Thus, such a subset of statements has a highest priority and should be analyzed first. If the fault is not located on this subset, due to data dependence that can lead to a data-flow dependent fault, the tester has to analyze the other statements executed by both the failed and by the succeed test cases, i.e., the subset FS \ SS. In this way, we can provide an incremental search for the fault, trying to reduce the time and the cost to locate the fault in a program. <bib>vincenzi-etal:2003, 28</bib>
  • It is important to select successful test cases that execute the related functionalities of the program as the ones executed by the failure test case. In this way, the difference between the two sets FS and SS will result in subset with a few BG nodes, reducing the number of statements that have to be analyzed first. <bib>vincenzi-etal:2003, 28</bib>
  • After having observed the failed test case execution path, the tester can enable one or more additional succeed test cases (Figure 32(b)), such that the tool can identify, among the statements executed any the failed test case, the dice more probable to contain the fault (statements only executed by the failed test case) and the ones less probable (the ones executed for both the failed and the succeed test cases). The rationale of such an approach is that, in theory, the fault is more probable to be located at the statements executed only by the failed test case. Although, it can happen that the fault is localized in other than the red statements, but the red points can be used at least as a good starting point, trying to reduce the search space for fault localization. Once the fault is located and corrected, the testing activity is restarted by creating a new project to revalidate the corrected program. In this case, previous test sets can be used to revalidate the behavior of the new program and also to check if new faults were not introduced by the changes. <bib>vincenzi-etal:2003, 28-29</bib>