No abstract

No abstract

Improved test case prioritization means that software developers can detect and fix more software faults sooner than usual. But is there one "best" prioritization algorithm? Or do different kinds of projects deserve special kinds of prioritization? To answer these questions, this paper applies nine prioritization schemes to 31 projects that range from (a) highly rated open-source Github projects to (b) computational science software to (c) a closed-source project. We find that prioritization approaches that work best for open-source projects are can work worst for the closed-source project (and vice versa). From these experiments, we conclude that (a) it is ill-advised to always apply one prioritization scheme to all projects since (b) prioritization requires tuning to different project types.Index Terms-software testing, regression testing, test case prioritization, open-source software ! BACKGROUND DefinitionsThis paper shows that the "best" prioritization differs between closed-source proprietary projects and open-source projects. These projects can be distinguished as follows:• Open-source projects are developed and distributed for free redistribution, possibility for modifications, and with full access to the source code [7], [8]. • Closed-source projects are proprietary software, developed with authorized users with private modification, republishing under a permission agreement [9]. As to the sites where we collect data: • Github is a hosting company for software development version control. Free GitHub accounts are commonly used to host open-source projects. As of January 2020, GitHub reports having over 40 million users and more than 100 million repositories (including at least 28 million public repositories), making it the largest host of source code in the world. • TravisTorrent is a public data set containing vanilla API data (build information), the build log analysis (tests information), plus repository and commit data [10].

No abstract

How to make software analytics simpler and faster? One method is to match the complexity of analysis to the intrinsic complexity of the data being explored. For example, hyperparameter optimizers find the control settings for data miners that improve for improving the predictions generated via software analytics. Sometimes, very fast hyperparameter optimization can be achieved by just DODGE-ing away from things tried before. But when is it wise to use DODGE and when must we use more complex (and much slower) optimizers? To answer this, we applied hyperparameter optimization to 120 SE data sets that explored bad smell detection, predicting Github issue close time, bug report analysis, defect prediction, and dozens of other non-SE problems. We find that DODGE works best for data sets with low "intrinsic dimensionality" (µ D ≈ 3) and very poorly for higher-dimensional data (µ D > 8). Nearly all the SE data seen here was intrinsically low-dimensional, indicating that DODGE is applicable for many SE analytics tasks.