Pith. sign in

REVIEW 4 major objections 5 minor 35 references

Empirically Evaluating the Use of Bytecode for Diversity-Based Test Case Prioritisation

T0 review · 4 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that using test bytecode instead of test source text for diversity-based test prioritisation improves fault detection while cutting computation time, and that filtering routine instructions preserves or improves those…

desk verdict Bytecode representation for TCP is new and the efficiency gains are credible, but the real-fault analysis counts error-revealing tests as faults and the abstract overstates the mixed significance. read the letter →

arxiv 2504.12790 v1 pith:DEECLZXZ submitted 2025-04-17 cs.SE

Islam T. Elgendy , Robert M. Hierons , Phil McMinn This is my paper · ORCID
classification cs.SE
keywords testcaseprioritisationdiversity-basedtestingbytecodetextualdiversityfilteringLevenshteindistanceregressionstaticanalysis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper introduces bytecode as the diversity artefact for test case prioritisation, replacing the test source text that previous static approaches compare. On seven Java projects covering 97 versions, it reports that bytecode-based prioritisation finds more faults earlier than text-based prioritisation, with median APFD gains of 2.3% to 7.8% depending on the algorithm. The bigger payoff is speed: preparation time drops by 124 to 2798 times in a similarity-matrix method and by 2.5 to 17.9 times in the FAST method. Filtering bytecode down to constant pushes, field accesses, and method calls makes the method up to four times faster still while keeping or improving fault detection. The practical consequence is that static prioritisation, which needs no coverage instrumentation, becomes feasible for large regression suites.

What carries the argument

The central object is the bytecode of each compiled test method, obtained with a bytecode-reading library and compared with the same distance metrics used for text: Levenshtein distance for the pairwise similarity matrix in Ledru-TCP, and hexadecimal bytecode fed into MinHash and locality-sensitive hashing signatures in FAST-TCP. The second mechanism is the filter, which keeps only instructions that push constants onto the stack, access fields, or invoke methods while discarding stack loads and stores, variable operations, and returns. That filter carries the argument because it shrinks each test's representation, concentrating similarity on the test's substantive actions and turning bytecode's compactness into both a large speed gain and, in the Ledru variant, a small effectiveness gain over full bytecode.

What would settle it

Run Ledru-Bytecode-Filter and FAST-Bytecode-Filter on held-out Java projects with real faults, using only the paper's filter, and compare median APFD to their text-based counterparts; if the APFD advantage shrinks or reverses on several projects, the filter is project-specific rather than a general property of bytecode.

Watch

Extended reading notes

Core claim

The paper's central claim is that a test's compiled bytecode carries enough execution-relevant information for diversity-based prioritisation, without the comments, variable names, and formatting that inflate and distort textual similarity. Implementing Ledru-TCP and FAST-TCP over text, full bytecode, and filtered bytecode, the authors find that bytecode versions achieve higher median APFD (89.9 versus 87.6 for Ledru, and 93.2 versus 85.4 for FAST), and that FAST-Bytecode finds real faults after a median of 32 tests compared to 125 for FAST-Text. Filtering bytecode to instructions that push constants, access fields, or invoke methods raises Ledru's median APFD to 92.1 and makes it 455 to 2798 times faster than text, while FAST-Bytecode-Filter stays 5.1% above text in APFD and is 4 to 17.9 times faster. Coverage-based dynamic TCP still beats bytecode TCP by 2.8% to 3.5% in APFD, but bytecode TCP is 6.5 to 8.3 times faster and avoids program instrumentation.

Load-bearing premise

The load-bearing premise is that similarity over bytecode, and specifically over the authors' hand-picked filtered instruction set, tracks how differently tests exercise the program at least as well as similarity over test text; if that premise fails on other projects, the effectiveness gains will not generalise.

Editorial extensions

If this is right

  • Large regression suites can use static prioritisation without coverage instrumentation at a small fraction of the previous computation cost.
  • Text-based Ledru-TCP becomes impractical at scale, while bytecode versions make full pairwise similarity feasible even for suites of tens of thousands of tests.
  • Filtering gives practitioners a tuning knob: dropping mechanical instructions can sacrifice little or no effectiveness while multiplying speed.
  • Bytecode TCP remains less effective than coverage-based TCP, so projects with existing coverage pipelines may keep dynamic methods, but bytecode offers a cheaper fallback when coverage data is unavailable.
  • Because the bytecode artefact is independent of the prioritisation algorithm, the benefit is likely to carry over to other similarity-based TCP methods beyond the two studied.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • My inference: the specific filter set, chosen by the authors on the same seven projects used for evaluation, is plausible but under-tested; a transfer experiment on new projects would show whether the filter is a general principle or an artefact of the chosen subjects.
  • My inference: bytecode's advantage probably grows with suite size and with the presence of automatically generated tests, which tend to add textual repetition without adding behavioural diversity; a size-stratified replication could quantify this.
  • My inference: normalising bytecode to remove compiler-version differences could close part of the remaining gap to coverage-based TCP, because raw bytecode still carries some implementation artefacts unrelated to test behaviour.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper introduces bytecode of test cases as a diversity artefact for static test case prioritisation, arguing that bytecode is more compact and execution-focused than test text. It instantiates Ledru-TCP and FAST-TCP over textual, full-bytecode, and filtered-bytecode representations, and compares them with two coverage-based greedy techniques. The study uses seven Defects4J projects (97 versions), mutation-based APFD, real-fault detection positions, and wall-clock runtimes. The headline findings are that bytecode diversity improves APFD by 2.3--7.8% over text, is 2--3 orders of magnitude faster for Ledru-TCP and 2.5--6 times faster for FAST-TCP, and that filtering bytecode instructions yields further speedups while maintaining effectiveness.

Significance. If the real-fault analysis is repaired, the paper makes a useful contribution to diversity-based TCP: it is, to my knowledge, the first study of bytecode as a diversity artefact, and the reported runtime gains are large and practically relevant. The authors validate their Ledru-TCP implementation against the original case studies and reuse the FAST replication package, and they provide a replication package of their own; these are concrete strengths. The effectiveness advantage is more modest than the abstract suggests, because the Ledru-Bytecode APFD gain is not statistically significant and the FAST filtering gain on real faults is also not significant.

major comments (4)
  1. [§4.3, Table 1; §4.4.1 and §4.4.3] Table 1 reports 107 real faults for 97 Defects4J versions, which is arithmetically impossible because Defects4J versions are single-fault subjects (the project totals are Cli 5, Compress 7, Csv 10, Jsoup 16, Lang 15, Math 42, Time 2, summing to 97). The likely explanation is that the '#Real Faults' column counts error-revealing tests rather than distinct faults, since Section 4.4.1 says the tool records 'all the error-revealing tests' and Section 4.2 defines a fault-revealing test as failing on the buggy version and passing on the fixed version. If so, Tables 3 and 6 aggregate the position of every error-revealing test as if each were a separate fault, whereas the fault-level detection position should be the earliest position among those tests for each version. This can inflate the sample, shift medians, and distort p-values, so the real-fault claims (e.g., FAST-Bytecode 3.9x better, filtering 'doubled real fault detection') need to be recomputed at fault level or explicitly re-scoped. If the column is merely mislabelled, the table and all dependent conclusions must be corrected.
  2. [Abstract; §5.1, Table 2] The abstract's claim that 'bytecode diversity improves fault detection by 2.3–7.8% over text-based TCP' is not supported for Ledru-Bytecode: Table 2 gives p=0.453 and A12=0.53 for Ledru-Bytecode versus Ledru-Text, and Table 3 shows Ledru-Bytecode's median real-fault detection position (124) is worse than Ledru-Text's (110). Only the FAST-Bytecode APFD gain is statistically significant (p=0.000, A12=0.67). The RQ1 conclusion should distinguish the significant FAST result from the non-significant Ledru result, and the abstract should not present the 2.3–7.8% range as a uniform improvement.
  3. [Abstract; §5.2, Table 3] The claim that filtering bytecode 'doubled real fault detection' compared with text is not statistically significant: Table 3 reports p=0.297 and A12=0.46 for FAST-Bytecode-Filter versus FAST-Text. The body of Section 5.2 includes this caveat, but the abstract and the RQ2 conclusion present the point estimate without it. Please carry the uncertainty into the abstract and conclusions, or restrict the claim to the APFD results where the comparisons are significant.
  4. [§3.2, §4.3, §5.2] The bytecode filter set (constant pushes, field accesses, method invocations) is an author-design choice rather than a derived or independently validated artifact, and it is evaluated only on the seven projects that were selected because JaCoCo and PIT ran without issues. The external-validity discussion acknowledges this, but the RQ2 conclusion that filtering 'maintains effectiveness' should be scoped to the selected projects rather than stated as a general property of the filtered instruction set.
minor comments (5)
  1. [§5.3, Table 6] The caption of Table 6 says 'APFDs for FAST-bytecode TCP and coverage-based TCP', but the table reports real-fault detection positions; the caption should be corrected.
  2. [§5.3] The sentence 'there is a medium effect size in favour of bytecode diversity' is inconsistent with the direction of the result, since coverage-based TCP has the lower (better) median detection position; the effect is in favour of coverage-based TCP.
  3. [§4.4.3, Tables 2–6] Multiple pairwise comparisons are made across Tables 2, 3, 5, and 6 without correction for multiple testing. This should at least be noted, because borderline p-values such as Ledru-Bytecode-Filter's APFD p=0.040 would not survive a simple Bonferroni correction.
  4. [§4.2, Table 4] The runtime comparison in RQ3 compares FAST-Bytecode's total time (preparation plus prioritisation) with coverage-based approaches' prioritisation-only time. Section 4.2 justifies excluding coverage preparation time, but the asymmetry of the comparison should also be noted at the point where 'up to 6.5 times faster' is stated.
  5. [§7] There is a typo in 'stubborn mutants (those hardest to detec/t/kill)' where 'detect' is split by a slash; this should be cleaned up.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the study is an empirical comparison against external baselines, and no prediction is equivalent to a fitted input or self-cited result.

full rationale

The paper makes no derivation chain in which an output is defined in terms of an input, or in which a fitted parameter is renamed as a prediction. RQ1, RQ2, and RQ3 are empirical comparisons of bytecode-based TCP against external baselines: Ledru-Text and FAST-Text use the authors' own implementations of published algorithms, and the coverage-based greedy approaches are implemented from Rothermel et al. The bytecode and filtered-bytecode representations are constructed from the test cases independently of the evaluation metrics (APFD, real-fault position, and runtime), and no parameter is fitted to the outcome. The filter instruction set in Section 3.2 is an author design choice described by intuition ('instructions ... better reflect the test’s intent and logic'); the paper does not report tuning it on the evaluation data, so the effectiveness results are a claim subject to empirical validation rather than a tautology. The self-citations to Elgendy et al. [6, 8] justify the choice of Levenshtein distance as a string metric; those citations do not assert or imply the bytecode results, and the conclusions would not be forced by removing them. The validation of the Ledru and FAST implementations against external case studies and replication packages is independent support, not circular self-support. The Table 1 discrepancy between 97 Defects4J versions and 107 reported 'Real Faults' is a potential data-integrity concern about how error-revealing tests were counted, but it is not a circular-reasoning step: the APFD and fault-position formulas are defined independently of the bytecode artefact, and the claimed gains are empirical observations that could be wrong without being circular. Therefore no specific circular step can be quoted or exhibited, and the appropriate score is 0.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The empirical claims rest on a small number of domain assumptions and one ad hoc design choice, the filter set. No free parameters are fitted to maximise APFD, but the filter set and distance metric are author-selected configurations that all results depend on. No new ontological entities are introduced; bytecode is an existing representation and the filter is a selection over existing instructions.

free parameters (2)
  • Bytecode filter instruction set = iconst, getfield, putfield, invokevirtual, invokestatic
    Hand-selected in Section 3.2 as the instructions that reflect test intent. All filtered-bytecode effectiveness and efficiency results depend on this choice; it is not derived from theory or searched over.
  • Levenshtein distance as similarity metric = N/A (metric choice)
    Chosen because prior work recommends it for string data. It is applied unchanged to text and bytecode, so it is not fitted to the outcome, but it is a methodological parameter that affects all similarity measurements.
assumptions (4)
  • domain assumption Dissimilar tests are more likely to exercise different system parts and uncover more faults.
    Inherited from diversity-based testing literature, stated in the introduction and Section 2.2; the entire prioritisation strategy rests on it.
  • domain assumption Bytecode is a condensed form of source code that strips comments, whitespace, and variable names while retaining execution-critical details, without hindering fault detection.
    Stated as a hypothesis in Sections 2.3, 3.1, and 3.2. The validity of bytecode diversity depends on this equivalence of information content.
  • ad hoc to paper Instructions that push constants, access fields, or invoke methods best capture test logic, while load and store instructions are mechanical noise.
    Section 3.2 proposes this filter without a systematic search or formal justification; all filtered-bytecode results depend on it.
  • domain assumption The seven Defects4J projects where JaCoCo and PIT ran without issues are representative of Java regression testing settings.
    Section 4.3 excludes projects where tooling failed; the external-validity conclusions assume the remaining subjects are representative.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Empirically Evaluating the Use of Bytecode for Diversity-Based Test Case Prioritisation." pith.science (2026). https://pith.science/paper/DEECLZXZ

@misc{pith2026250412790,
  author       = {Pith},
  title        = {Pith review of: Empirically Evaluating the Use of Bytecode for Diversity-Based Test Case Prioritisation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DEECLZXZ}},
  note         = {Machine review of arXiv:2504.12790}
}
read the original abstract

Regression testing assures software correctness after changes but is resource-intensive. Test Case Prioritisation (TCP) mitigates this by ordering tests to maximise early fault detection. Diversity-based TCP prioritises dissimilar tests, assuming they exercise different system parts and uncover more faults. Traditional static diversity-based TCP approaches (i.e., methods that utilise the dissimilarity of tests), like the state-of-the-art FAST approach, rely on textual diversity from test source code, which is effective but inefficient due to its relative verbosity and redundancies affecting similarity calculations. This paper is the first to study bytecode as the basis of diversity in TCP, leveraging its compactness for improved efficiency and accuracy. An empirical study on seven Defects4J projects shows that bytecode diversity improves fault detection by 2.3-7.8% over text-based TCP. It is also 2-3 orders of magnitude faster in one TCP approach and 2.5-6 times faster in FAST-based TCP. Filtering specific bytecode instructions improves efficiency up to fourfold while maintaining effectiveness, making bytecode diversity a superior static approach.

Figures

Figures reproduced from arXiv: 2504.12790 by the authors.

Figure 1
Figure 1. TCP process diagram A well-known metric to evaluate TCP approaches is the Average Percentage of Faults Detected (APFD). The faults can be real faults or mutants. It is calculated using the following equation: APFD = 1 − TF1 + TF2 + · · · + TFm 𝑛𝑚 + 1 2𝑛 (1) where 𝑛 is the number of tests in the test suite, 𝑚 is the number of killable faults, and TFi is the position of the first test case that detects the fault 𝑖. 2.… view at source ↗
Figure 2
Figure 2. An example of four test cases from the Math project, [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. The human-readable and the Hexadecimal formats [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: The preparation times in seconds for all static TCP approaches [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

35 extracted references · 20 canonical work pages

  1. [1]

    Altiero, A

    F. Altiero, A. Corazza, S. Di Martino, A. Peron, and L. Libero Lucio Starace. 2024. Regression test prioritization leveraging source code similarity with tree kernels. Journal of Software: Evolution and Process (2024), e2653. https://doi.org/10.1002/ smr.2653

    work page 2024

  2. [2]

    Arafeen and H

    Md J. Arafeen and H. Do. 2013. Test case prioritization using requirements-based clustering. In Proceedings of the International Conference on Software Testing, Validation and Verification (ICST). 312–321. https://doi.org/10.1109/ICST.2013.12

    work page doi:10.1109/icst.2013.12 2013

  3. [3]

    Coles, T

    H. Coles, T. Laurent, C. Henard, M. Papadakis, and A. Ventresque. 2016. PIT: A practical mutation testing tool for java. In Proceedings of the International Symposium on Software Testing and Analysis (ISSTA). 449–452. https://doi.org/ 10.1145/2931037.2948707

    arXiv 2016

  4. [4]

    A. Dann, B. Hermann, and E. Bodden. 2019. SootDiff: bytecode comparison across different Java compilers. In Proceedings of the International Workshop on State Of the Art in Program Analysis. 14–19. https://doi.org/10.1145/3315568.3329966

    arXiv 2019

  5. [5]

    Elbaum, A

    S. Elbaum, A. Malishevsky, and G. Rothermel. 2001. Incorporating varying test costs and fault severities into test case prioritization. In Proceedings of the International Conference on Software Engineering (ICSE) . 329–338. https://doi.or g/10.1109/ICSE.2001.919106

    arXiv 2001

  6. [6]

    Elgendy, R

    I. Elgendy, R. Hierons, and P. McMinn. 2024. Evaluating string distance metrics for reducing automatically generated test suites. In Proceedings of the International Conference on Automation of Software Test (AST) . 171–181. https://doi.org/10.1 145/3644032.3644455

    arXiv 2024

  7. [7]

    Elgendy, R

    I. Elgendy, R. Hierons, and P. McMinn. 2025. Replication Package for Empirically Evaluating the Use of Bytecode for Diversity-Based Test Case Prioritisation. https://github.com/islamelgendy/Replication-Package-Evaluating-Bytecode- Diversity. [Online; accessed 25-March-2025]. Bytecode Diversity for TCP

    work page 2025

  8. [8]

    Elgendy, R

    I. Elgendy, R. Hierons, and P. McMinn. 2025. A Systematic Mapping Study of the Metrics, Uses and Subjects of Diversity-Based Testing Techniques. Software Testing, Verification and Reliability 35, 2 (2025), e1914. https://doi.org/10.1002/st vr.1914

    work page doi:10.1002/st 2025

Show all 35 references
  1. [9]

    B. Eric, L. Romain, and C. Thierry. 2002. ASM: A code manipulation tool for the Java virtual machine. Available: https://asm.ow2.io

    2002

  2. [10]

    Fraser and A

    G. Fraser and A. Arcuri. 2011. Evosuite: automatic test suite generation for object-oriented software. In Proceedings of the SIGSOFT symposium and the European conference on Foundations of software engineering . 416–419. https: //doi.org/10.1145/2025113.2025179

    2011

  3. [11]

    Mäntylä, M

    A Haghighatkhah, M. Mäntylä, M. Oivo, and P. Kuvaja. 2018. Test case prioritization using test similarities. In Proceedings of the International Con- ference on Product-Focused Software Process Improvement (PROFES) . 243–259. https://doi.org/10.1007/978-3-030-03673-7_18

    2018 doi

  4. [12]

    Haghighatkhah, M

    A. Haghighatkhah, M. Mäntylä, M. Oivo, and P. Kuvaja. 2018. Test prioritization in continuous integration environments. Journal of Systems and Software 146 (2018), 80–98. https://doi.org/10.1016/j.jss.2018.08.061

    2018 doi

  5. [13]

    Hemmati, Z

    H. Hemmati, Z. Fang, and M. V Mantyla. 2015. Prioritizing manual test cases in traditional and rapid release environments. In Proceedings of the International Conference on Software Testing, Verification and Validation (ICST). 1–10. https: //doi.org/10.1109/ICST.2015.7102602

    2015

  6. [14]

    Henard, M

    C. Henard, M. Papadakis, M. Harman, Y. Jia, and Y. Le Traon. 2016. Comparing white-box and black-box test prioritization. In Proceedings of the International Conference on Software Engineering. 523–534. https://doi.org/10.1145/2884781.28 84791

    2016 doi

  7. [15]

    Huang, Y

    R. Huang, Y. Zhou, W. Zong, D. Towey, and J. Chen. 2017. An empirical compari- son of similarity measures for abstract test case prioritization. In Proceedings of the Annual Computer Software and Applications Conference (COMPSAC) , Vol. 1. 3–12

    2017

  8. [16]

    JaCoCo. 2025. JaCoCo Implementation Design. http://www.jacoco.org/jacoco/tr unk/doc/implementation.html. [Last accessed: 25-March-2025]

    2025

  9. [17]

    R. Just, D. Jalali, and M. D Ernst. 2014. Defects4J: A database of existing faults to enable controlled testing studies for Java programs. In Proceedings of the International Symposium on Software Testing and Analysis (ISSTA). 437–440. https: //doi.org/10.1145/2610384.2628055

    2014

  10. [18]

    Khatibsyarbini, M A

    M. Khatibsyarbini, M A. Isa, D. NA Jawawi, and R. Tumeng. 2018. Test case prioritization approaches in regression testing: A systematic literature review. Information and Software Technology 93 (2018), 74–93. https://doi.org/10.1016/j. infsof.2017.08.014

    2018 doi

  11. [19]

    Khojah, C

    R. Khojah, C. H. Chao, and d F G Oliveira Neto. 2023. Evaluating the trade-offs of text-based diversity in test prioritisation. In Proceedings of the International Conference on Automation of Software Test (AST) . 168–178. https://doi.org/10.1 109/AST58925.2023.00021

    2023

  12. [20]

    J-M Kim and A. Porter. 2002. A history-based test prioritization technique for regression testing in resource constrained environments. In Proceedings of the International Conference on Software Engineering (ICSE) . 119–129. https: //doi.org/10.1145/581339.581357

    2002

  13. [21]

    Ledru, A

    Y. Ledru, A. Petrenko, S. Boroday, and N. Mandran. 2012. Prioritizing test cases with string distances. Automated Software Engineering 19, 1 (2012), 65–95. https://doi.org/10.1007/s10515-011-0093-0

    2012 doi

  14. [22]

    V. I. Levenshtein. 1966. Binary codes capable of correcting deletions, insertions, and reversals. 10, 8 (1966), 707–710

    1966

  15. [23]

    Y. Lou, J. Chen, L. Zhang, and D. Hao. 2019. A survey on regression test-case prioritization. In Advances in Computers. Vol. 113. 1–46. https://doi.org/10.1016/ bs.adcom.2018.10.001

    2019

  16. [24]

    Miranda, E

    B. Miranda, E. Cruciani, R. Verdecchia, and A. Bertolino. 2018. FAST approaches to scalable similarity-based test case prioritization. InProceedings of the International Conference on Software Engineering (ICSE) . 222–232. https://doi.org/10.1145/31 80155.3180210

    2018

  17. [25]

    Miranda, E

    B. Miranda, E. Cruciani, R. Verdecchia, and A. Bertolino. 2025. FAST replication package. https://github.com/icse18-FAST/FAST. [Last accessed: 25-March-2025]

    2025

  18. [26]

    T. B. Noor and H. Hemmati. 2015. A similarity-based approach for test case prioritization using historical failure data. In Proceedings of the International Symposium on Software Reliability Engineering (ISSRE) . 58–68. https://doi.org/10 .1109/ISSRE.2015.7381799

    2015

  19. [27]

    Pacheco and M

    C. Pacheco and M. D Ernst. 2007. Randoop: Feedback-directed random test- ing for Java. In Proceedings of the Companion to the SIGPLAN Conference on Object-Oriented Programming Systems and Applications Companion (OOPSLA Companion). 815–816. https://doi.org/10.1145/1297846.1297902

    2007

  20. [28]

    Rothermel, R

    G. Rothermel, R. H. Untch, C. Chu, and M. J. Harrold. 1999. Test case prioritization: An empirical study. In Proceedings of the International Conference on Software Maintenance (ICSM). 179–188. https://doi.org/10.1109/ICSM.1999.792604

    1999

  21. [29]

    Rothermel, R

    G. Rothermel, R. H. Untch, C. Chu, and M. J. Harrold. 2001. Prioritizing test cases for regression testing. IEEE Transactions on Software Engineering 27, 10 (2001), 929–948. https://doi.org/10.1109/32.962562

    2001 doi

  22. [30]

    Schott, S

    S. Schott, S. E. Ponta, W. Fischer, J. Klauke, and E. Bodden. 2024. Java Bytecode Normalization for Code Similarity Analysis. In European Conference on Object- Oriented Programming (ECOOP), Vol. 313. 37:1–37:29. https://doi.org/10.4230/LI PIcs.ECOOP.2024.37

    2024 doi

  23. [31]

    Srikanth, L

    H. Srikanth, L. Williams, and J. Osborne. 2005. System test case prioritization of new and regression test cases. In International Symposium on Empirical Software Engineering. 10–pp. https://doi.org/10.1109/ISESE.2005.1541815

    2005

  24. [32]

    Vargha and H

    A. Vargha and H. D Delaney. 2000. A critique and improvement of the CL common language effect size statistics of McGraw and Wong. Journal of Educational and Behavioral Statistics 25, 2 (2000), 101–132. https://doi.org/10.3102/107699860250 02101

    2000 doi

  25. [33]

    R. Wang, S. Jiang, and D. Chen. 2015. Similarity-based regression test case prioriti- zation. In Proceedings of the International Conference on Software Engineering and Knowledge Engineering (SEKE). 358–363. https://doi.org/10.18293/seke2015-115

    2015 doi

  26. [34]

    K. Wu, C. Fang, Z. Chen, and Z. Zhao. 2012. Test case prioritization incor- porating ordered sequence of program elements. In Proceedings of the Inter- national Workshop on Automation of Software Test (AST) . 124–130. https: //doi.org/10.1109/IWAST.2012.6228980

    2012

  27. [35]

    Yoo and M

    S. Yoo and M. Harman. 2010. Regression testing minimization, selection and prioritization: A survey. Software testing, verification and reliability 22, 2 (2010), 67–120. https://doi.org/10.1002/stvr.430

    2010 doi

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.