Changes between Initial Version and Version 1 of RegressionTestResearch

Feb 13, 2012 3:43:02 AM (12 years ago)

Adding regression test improvement pages


  • RegressionTestResearch

    v1 v1  
     1= Isolation of flaky tests and further plans =
     3== Flakies ==
     4Flaky tests are a nightmare for systematic analysis and enhancement of the regression tests. In many cases it was nearly impossible to make reasonable conclusions about the test results, only by tedious manual analysis. The goal of this project is to systematically assess how flaky the tests are. Can we safely isolate a set of test cases that are usualy flakes and that are never? If yes, we could create a more intelligent test sets that are consistent, hence more predictable.
     5Currently we are working on:
     6 * Randomize the order of test execution and observe the differences in the results
     7 * Execute all tests indivodually and see the differences to the batch execution
     9== Other research ideas: ==
     10 * Adding static code metrics and code warnings to EWS
     11 * Analyze what are the ‘good’ tests (which often fail). Employ different methods to analyze the relationship between the failing test cases and any available data of code coverage, code metrics, etc.
     12 * Research on moving the test coverage measurement and selection to class level.
     13 * Research on prioritization based on execution times.
     14 * Research on code complexity, prioritization of tests based on complexity. Code complexity is traditionally highly related to the optimal number of test cases, thus it is possibly a good basis of test prioritization.
     15 * Change impact analysis as a service to developers. This will enable developers to check the impact of their modifications, review impacted elements and possibly eliminate bugs before the patch lands in the repository.
     16 * Branch level coverage. A fine-grained coverage measurement that reflects to the internal structure of the methods. Branch level coverage measurement is more reliable than method level coverage, but it is also more sophisticated to implement.
     17 * Bugzilla analysis. The bug database could be processed and searched for some relevant information that could aid the impact analysis and defect analysis tasks.
     18 * Research on test creation. A tool that could give at least a hint on how to test a specific piece of code would be very helpful to the developers when developing new test cases.
     19 * Research on Static Analysis Results. Research and experiments can be conducted to investigate the relationship between the code complexity and test results, or the effect of moving the analysis to class level, etc. Main tasks: investigate relationship between code complexity and test results using statistical analysis, investigate the effect of using class level information instead of method level information on test case selection.
     20 * Monitoring of code and test quality attributes using a persistence database.