Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
144
datasets available to search
ShareScore release 0.9.0
Dataset results
144 results for “Test generation”
Exploring the Interaction of Code Coverage and Non-Coverage Objectives in Search-Based Test Generation
<p>Data Package for "Exploring the Interaction of Code Coverage and Non-Coverage Objectives in Search-Based Test Generation"</p> <p>This package contains data generated as part of our experiments on EvoSuite and Defects4J.</p> <p>This paper is currently under submission.</p> <p>This package contains experimental data and the algorithms that generated them in folder "framework\test\". Specifically, in the folder "framework\test\Experiments", the data folders contain the suites generated by each technique for each project and fault ID. </p> <p>If you have questions, please contact Afonso Fontes at afonsohfontes@gmail.com.</p>
Replication package of "Higher Fault Detection Through Novel Density Estimators in Unit Test Generation"
<p>Replication package for the paper "Higher Fault Detection Through Novel Density Estimators in Unit Test Generation" accepted at the Symposium on Search-based Software Engineering (SSBSE) 2024.</p> <p> </p> <p> </p>
Adaptive Parameter Control for Search-Based Unit Test Generation — Replication Package
<h1>Running the experiments</h1> <p>Prerequisites for running the experiments:</p> <ul> <li><a href="https://www.docker.com/" target="_blank" rel="noopener">Docker</a></li> <li><a href="https://python-poetry.org/" target="_blank" rel="noopener">Poetry</a></li> </ul> <p>Steps to run the experiments:</p> <ol> <li>Download the experiment zip file you wish to run (<code>single_parameter_experiment.zip</code> or <code>multi_parameter_experiment.zip</code>).</li> <li>Un-zip the file.</li> <li>Open a terminal and navigate to the unzipped folder (e.g. <code>cd single_parameter_experiment</code>).</li> <li>Run <code>poetry install --only main</code> to install all dependencies.</li> <li>To run the experiment, run <code>poetry run python run_experiment.py</code>.</li> <li>All results can be found in the folder <code>data/</code>.</li> </ol> <p>The modules used for the experiment are defined in the file <code>experiment_modules.py</code> and to see the experiment configuration, look in <code>run_experiment.py</code>.</p> <p><strong>Warning</strong>: the experiments take several weeks to run on a single machine, therefore it is advisable to split the experiments based on modules and run them in parallel.</p> <h1>Running the analysis</h1> <p>Prerequisites for running the analysis:</p> <ul> <li><a href="https://conda.io/projects/conda/en/latest/user-guide/getting-started.html" target="_blank" rel="noopener">Conda</a></li> </ul> <p>Steps to run the analysis:</p> <ol> <li>Download the analysis zip file (<code>analysis-adaptive-parameter-control.zip</code>).</li> <li>Un-zip the file.</li> <li>Open a terminal and navigate to the unzipped folder (e.g. <code>cd analysis-adaptive-parameter-control</code>).</li> <li>Run the following command to install the conda environment and all dependencies: <code>conda env create -f environment.yml</code></li> <li>If you want to re-run the Bayesian models locally on your machine, follow the <strong>optional</strong> step below, otherwise download and unzip the trace data from the replication package, i.e., <code>Trace data single.zip</code> and <code>Trace data multi.zip</code>. </li> <li>Place the <code>.nc</code> files in the corresponding folder: <code>analysis-adaptive-parameter-control/single_parameter/</code> or <code>analysis-adaptive-parameter-control/multi_parameter/</code>. <ol> <li>E.g. the <code>coverage_rate_model_single_parameter.nc</code> goes in the <code>single_parameter</code> folder, while the <code>coverage_rate_model_multi_parameter.nc</code> goes in the <code>multi_parameter</code> folder.</li> </ol> </li> <li>Navigate to the notebooks folder (<code>Notebooks/</code>).</li> <li>Open a notebook of choice (<code>coverage_rate_multi_parameter.ipynb</code>, <code>coverage_rate_single_parameter.ipynb</code>, <code>final_coverage_multi_parameter.ipynb</code>, <code>final_coverage_single_parameter.ipynb</code>, <code>overhead_model_multi_parameter.ipynb</code>, or <code>overhead_model_single_parameter.ipynb</code>).</li> <li>Navigate to the section called "Data analysis" and run all cells in order.</li> </ol> <h3>(Optional) Running the Bayesian models locally before the analysis.</h3> <ol> <li>Navigate to the notebooks folder (<code>Notebooks/</code>).</li> <li>Open a notebook of choice (<code>coverage_rate_multi_parameter.ipynb</code>, <code>coverage_rate_single_parameter.ipynb</code>, <code>final_coverage_multi_parameter.ipynb</code>, <code>final_coverage_single_parameter.ipynb</code>, <code>overhead_model_multi_parameter.ipynb</code>, or <code>overhead_model_single_parameter.ipynb</code>).</li> <li>Navigate to the section called "Model specification" and run the three notebook cells.</li> </ol> <p><strong>Warning</strong>: this will take a long time, if you don't have the time, use the following alternative instead</p> <h1>Data</h1> <p>The data from when we ran the experiments is available in the <code>Single data.zip</code> and <code>Multi data.zip</code> files.</p> <p>The structure of these are the following:</p> <ul> <li>There are folders for each module the experiment was run on, further divided into each unique run. All these folders include: <ul> <li>Coverage reports.</li> <li>Complete logs for the unique run.</li> <li>A timeline over controlled parameter values during the test generation process.</li> <li>The complete Pynguin configuration for the run.</li> <li>The generated test suite.</li> </ul> </li> <li>There is one <code>statistics.csv</code> file containing some information about each run and their branch coverage timelines.</li> </ul> <h1>Running the parameter assignment analysis</h1> <p>Prerequisites for running the parameter assignment analysis:</p> <ul> <li><a href="https://conda.io/projects/conda/en/latest/user-guide/getting-started.html" target="_blank" rel="noopener">Conda</a></li> </ul> <p>Steps to run the parameter assignment analysis:</p> <ol> <li>Download the analysis zip file (<code>parameter-assignment.zip</code>).</li> <li>Un-zip the file.</li> <li>Open a terminal and navigate to the unzipped folder (e.g. <code>cd parameter-assignment</code>).</li> <li>Run the following command to install the conda environment and all dependencies: <code>conda env create -f environment.yml</code></li> <li>Navigate to the notebooks folder (<code>Notebooks/</code>).</li> <li>Open the notebook <code>parameter_assignment_analysis.ipynb</code>.</li> <li>Run all cells in order.</li> </ol>
Search-Based Test Data Generation for SQL Queries: Appendix
<p>The appendix of our ICSE 2018 paper "Search-Based Test Data Generation for SQL Queries: Appendix".</p> <p>The appendix contains:</p> <ul> <li>The queries from the three open source systems we used in the evaluation of our tool (the industry software system is not part of this appendix, due to privacy reasons)</li> <li>The results of our evaluation.</li> <li>The source code of the tool. Most recent version can be found at https://github.com/SERG-Delft/evosql.</li> <li>The results of the tuning procedure we conducted before running the final evaluation.</li> </ul>
Classifying Generated White-Box Tests: An Exploratory Study
<p>The data and analysis scripts for our paper entitled Classifying Generated White-Box Tests: An Exploratory Study</p>
Enhanced Synthetic Texas 2,000 bus (ACTIVSg2000) test case w/synthesized dynamic parameters of wind generation and protective devices
<p>Enhanced Synthetic Texas 2,000 bus (ACTIVSg2000) test case w/synthesized dynamic parameters of wind generation and protective devices<br> Compatible with PowerWorld v21, adapted from ACTIVSg2000.pwb (<a href="https://electricgrids.engr.tamu.edu/electric-grid-test-cases/activsg2000/">https://electricgrids.engr.tamu.edu/electric-grid-test-cases/activsg2000/</a>)<br> <br> Used as a test case for the paper: `Electrical Grid Resilience Metric with Uncertainty.' Power Systems Computation Conference, under review. </p> <p>Wind Dynamic Parameters:<br> Machine models:<br> -REGC_A: Renewable Energy Generator/Converter.</p> <p> Machine governors:<br> -WTGT_A: Wind Turbine Generator Drive-train Model.</p> <p> Machine excitation system:<br> -REEC_A: Renewable Energy Electrical Control Model.</p> <p>Protective relays:<br> -DLSH: Rate of Frequency Load Shedding Model (used on all loads in network).<br> -LVSH: Undervoltage Load Shedding Model (used on all loads in network).<br> -TIOCR1: Time inverse overcurrent relay (used on all lines in network).<br> -FRQTPAT: Under frequency generator trip relay (used on all machines).<br> -LHVRT: Low/High Voltage Ride through Generator Protection (used on all machines).</p> <p> </p> <p>This research was completed by Idaho National Laboratory with funding<br> from the U.S. Department of Energy Wind Energy Technologies Office. Idaho National Laboratory is operated<br> by Battelle Energy Alliance under contract No. DE AC07-05ID14517.</p>
Supplementary data for "Enhancing Resource-based Test Case Generation For RESTful APIs with SQL Handling"
<p>Supplement to: <em>Enhancing Resource-based Test Case Generation For RESTful APIs with SQL Handling</em></p> <p>In this repository, we provide <em>tests</em> and their <em>coverage reports</em> (conducted by Intellij coverage reports) that are used in the Discussion section of the paper.</p>
SEED-G: Simulated EEG Data Generator for testing connectivity algorithms
<p>SEED-G toolbox was developed in MATLAB environment (tested on version R2017a and R2020b) and released on the GitHub page <a href="https://github.com/aanzolin/SEED-G-toolbox">https://github.com/aanzolin/SEED-G-toolbox</a> (accessed date 12 April 2021). It is organized in the following subfolders:</p> <ul> <li> <p><strong>main</strong>: it is the core of the toolbox and contains all the functions for the generation of EEG data according to a predefined ground-truth network.</p> </li> <li> <p><strong>dependencies</strong>: containing parts of other toolboxes required to successfully run SEED-G functions. The links to the full packages can be found in the documentation on the GitHub page. The additional packages are Brain Connectivity Toolbox (BCT) [<a href="https://www.mdpi.com/1424-8220/21/11/3632/htm#B40-sensors-21-03632">40</a>], FieldTrip [<a href="https://www.mdpi.com/1424-8220/21/11/3632/htm#B41-sensors-21-03632">41</a>], Multivariate Granger Causality Toolbox (MVGC) [<a href="https://www.mdpi.com/1424-8220/21/11/3632/htm#B24-sensors-21-03632">24</a>], and AsympPDC Package (PDC_AsympSt) [<a href="https://www.mdpi.com/1424-8220/21/11/3632/htm#B42-sensors-21-03632">42</a>,<a href="https://www.mdpi.com/1424-8220/21/11/3632/htm#B43-sensors-21-03632">43</a>]. Additionally, the implemented forward model is solved according to the New York Head (NYH) model, whose parameters are contained in the structure available on the ICBM-NY platform [<a href="https://www.mdpi.com/1424-8220/21/11/3632/htm#B28-sensors-21-03632">28</a>].</p> </li> <li> <p><strong>real data</strong>: containing real EEG data acquired from one healthy subject during resting state at scalp level (‘EEG_real_sources.mat’) and its reconstructed version in source domain (‘sLOR_cortical_sources.mat’). These signals can be employed to extract the AR components to be included in the model to generate data with the same spectral properties of the real ones.</p> </li> <li> <p><strong>demo</strong>: containing examples of MATLAB scripts to be used to learn the different functionalities of the toolbox. For example, the code ‘run_generation.m’ allows to specify the directory containing the real sources and each specific input of the function ‘simulatedData_generation.m’.</p> </li> <li> <p><strong>auxiliary functions</strong>: containing either original MATLAB functions or modified version of free available functions.</p> </li> </ul>
Test Suites from Test-Generation Tools (Test-Comp 2023)
<p><strong>Test-Comp 2023</strong></p> <p><strong>Test Suites</strong></p> <p>This file describes the contents of an archive of the 5th Competition on Software Testing (Test-Comp 2023). <a href="https://test-comp.sosy-lab.org/2023/">https://test-comp.sosy-lab.org/2023/</a></p> <p>The competition was organized by Dirk Beyer, LMU Munich, Germany. More information is available in the following article: Dirk Beyer. <em>Software Testing: 5th Comparative Evaluation: Test-Comp 2023.</em> In Proceedings of the 26th International Conference on Fundamental Approaches to Software Engineering (FASE 2023, Paris, April 22 - 27), 2023. Springer.</p> <p>Copyright (C) Dirk Beyer <a href="https://www.sosy-lab.org/people/beyer/">https://www.sosy-lab.org/people/beyer/</a></p> <p>SPDX-License-Identifier: CC-BY-4.0 <a href="https://spdx.org/licenses/CC-BY-4.0.html">https://spdx.org/licenses/CC-BY-4.0.html</a></p> <p><strong>Contents</strong></p> <ul> <li><code>LICENSE.txt</code>: specifies the license</li> <li><code>README.txt</code>: this file</li> <li><code>witnessFileByHash/</code>: This directory contains test suites (witnesses for coverage). Each test witness in this directory is stored in a file whose name is the SHA2 256-bit hash of its contents followed by the filename extension .zip. The format of each test suite is described on the format web page: <a href="https://gitlab.com/sosy-lab/software/test-format">https://gitlab.com/sosy-lab/software/test-format</a> A test suite contains also metadata in order to relate it to the test task for which it was produced.</li> <li><code>witnessInfoByHash/</code>: This directory contains for each test suite (witness) in directory witnessFileByHash/ a record in JSON format (also using the SHA2 256-bit hash of the witness as filename, with .json as filename extension) that contains the meta data.</li> <li><code>witnessListByProgramHashJSON/</code>: For convenient access to all test suites for a certain program, this directory represents a function that maps each program (via its SHA2256-bit hash) to a set of test suites (JSON records for test suites as described above) that the test-generation tools have produced for that program. For each program for which test suites exist, the directory contains a JSON file (using the SHA2 256-bit hash of the program as filename, with .json as filename extension) that contains all JSON records for test suites for that program.</li> </ul> <p>A similar data structure was used by SV-COMP and is described in the following article: Dirk Beyer. <em>A Data Set of Program Invariants and Error Paths.</em> In Proceedings of the 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR 2019, Montreal, Canada, May 26-27), pages 111-115, 2019. IEEE. <a href="https://doi.org/10.1109/MSR.2019.00026">https://doi.org/10.1109/MSR.2019.00026</a></p> <p><strong>Other Archives</strong></p> <p>Overview of archives from Test-Comp 2023 that are available at Zenodo:</p> <ul> <li><a href="https://doi.org/10.5281/zenodo.7701126">https://doi.org/10.5281/zenodo.7701126</a> Test Suites from Test-Comp 2023 Test-Generation Tools. Store of coverage witnesses (containing the generated test suites)</li> <li><a href="https://doi.org/10.5281/zenodo.7701118">https://doi.org/10.5281/zenodo.7701118</a> Test-Suite Generators from Test-Comp 2023. Executable tools that were evaluated in the competition</li> <li><a href="https://doi.org/10.5281/zenodo.7701122">https://doi.org/10.5281/zenodo.7701122</a> Results of the 5th Intl. Competition on Software Testing (Test-Comp 2023). Results (XML result files, log files, file mappings, HTML tables)</li> <li><a href="https://doi.org/10.5281/zenodo.7627783">https://doi.org/10.5281/zenodo.7627783</a> SV-Benchmarks: Benchmark Set of SV-COMP 2023 and Test-Comp 2023. Verification tasks, version testcomp23</li> <li><a href="https://doi.org/10.5281/zenodo.7612021">https://doi.org/10.5281/zenodo.7612021</a> BenchExec, version 3.16. Benchmarking framework</li> <li><a href="https://doi.org/10.5281/zenodo.7635975">https://doi.org/10.5281/zenodo.7635975</a> CoVeriTeam, version 1.0. Remote execution and continuous integration of testers</li> </ul> <p>All benchmarks were executed for Test-Comp 2023 <a href="https://test-comp.sosy-lab.org/2023/">https://test-comp.sosy-lab.org/2023/</a> by Dirk Beyer, LMU Munich, based on the following components:</p> <ul> <li><a href="https://gitlab.com/sosy-lab/test-comp/archives-2023">https://gitlab.com/sosy-lab/test-comp/archives-2023</a> testcomp23 bd9d84151c52ba7ad549212a590e2b3a18c071bc</li> <li><a href="https://gitlab.com/sosy-lab/benchmarking/sv-benchmarks">https://gitlab.com/sosy-lab/benchmarking/sv-benchmarks</a> testcomp23 f87854c275a177e8dc3673fe6959cd89038652af</li> <li><a href="https://gitlab.com/sosy-lab/test-comp/bench-defs">https://gitlab.com/sosy-lab/test-comp/bench-defs</a> testcomp23 21a5ba27dc84c8e59fefe18369b5723550c96786</li> <li><a href="https://gitlab.com/sosy-lab/software/benchexec">https://gitlab.com/sosy-lab/software/benchexec</a> 3.16 b43e7384112770a41b571399135065daa7f387ab</li> <li><a href="https://gitlab.com/sosy-lab/benchmarking/competition-scripts">https://gitlab.com/sosy-lab/benchmarking/competition-scripts</a> testcomp23 e6f84b5a79626b4295108a0f96ea370edde1f023</li> <li><a href="https://gitlab.com/sosy-lab/test-comp/test-format">https://gitlab.com/sosy-lab/test-comp/test-format</a> testcomp23 e6b0eff82a5132a6e4e4b52f8fbfaa3553af3ebb</li> <li><a href="https://gitlab.com/sosy-lab/software/coveriteam">https://gitlab.com/sosy-lab/software/coveriteam</a> 1.0 78d9f9f9d5fefc4fdd934d1e0f43ddba4ec51711</li> </ul> <p><strong>Contact</strong></p> <p>Feel free to contact me in case of questions: <a href="https://www.sosy-lab.org/people/beyer/">https://www.sosy-lab.org/people/beyer/</a></p>
Generated ontology matching tests and matcher results
This archive contains all the files supporting the results published in [1] using the Alignment API [2]. This consists of generating tests from ontology matchers using a seed ontologies, running ontology matchers on these tests and evaluating their results. In order to facilitate reproducibility, scripts to obtain and analyse the results are provided.<br>The archive contains:<ul><li>scripts to generates the tests</li><li>scripts to evaluate the results</li><li>a directory of the original benchmarks data set</li><li>a directory of the four seed ontologies</li><li>a directory of the generated datasets (ontologies and reference alignments) and the alignments obtained by 10 matchers</li><li>a directory of the analysed results.</li></ul><br>More information is available in the paper [1] itself.<br>[1] Jérôme Euzenat, Maria Roşoiu, Cássia Trojahn dos Santos, Ontology matching benchmarks: generation, stability, and discriminability, <i>Journal of web semantics</i> 21:30-48, 2013 [DOI:<a href="https://doi.org/10.1016/j.websem.2013.05.002">10.1016/j.websem.2013.05.002 </a>]<br>[2] <a href="https://gitlab.inria.fr/moex/alignapi/">https://gitlab.inria.fr/moex/alignapi/</a><br><br>
Study to Verify Clinical Utility of Point-of-Care (POC) Thyroid Stimulating Hormone (TSH) Test Kits as Compared to Third Generation TSH Test Kit
ClinicalTrials.gov study NCT01921452. IPD Sharing: Not stated. Countries: 1. Publications: 1.
Development and Testing of a New Generation of Diabetic Footwear
ClinicalTrials.gov study NCT01816906. IPD Sharing: NO. Countries: 1. Publications: 11.
Evaluation of the 4th Generation QuantiFERON-TB Test (QFT-Plus) for the Detection of Tuberculosis Infection
ClinicalTrials.gov study NCT02687529. IPD Sharing: Not stated. Countries: 1. Publications: 2.
Hybrid ATPG (Automatic Test Pattern Generation) algorithm
Open the record for dataset details and reuse information.
Feasibility of assessing vegetative and generative endpoints of crop- and non- crop terrestrial plant species for non-target terrestrial plant (NTTP) regulatory testing under greenhouse conditions
Open the record for dataset details and reuse information.
EOSC-Nordic climate 14 years dataset (generated from CESM 2.1.0) to test owncloud (WP5)
<p>This dataset has been created using CESM 2.1.0 and ran on Saga Norwegian HPC (<a href="https://www.sigma2.no/">https://www.sigma2.no/</a>).</p> <p>The dataset contains 14 years of CESM F2000climo compset at resolution f19_g17:</p> <pre><code> module use /cluster/projects/nn1000k/modulefiles module load cesm/2.1.0 create_newcase --case $HOME/cases/F2000climo-f19_g17 --res f19_g17 --compset F2000climo --mach saga --run-unsupported --project nn1000k</code></pre> <p> </p> <p>netCDF outputs have been converted to zarray format for testing access on owncloud (part of WP5 EOSC-Nordic project). No further post-processing has been applied. </p>
Understanding the Differences in the Unit Tests Produced by Humans and Coverage-Directed Automated Generation
<p>Automated test generation - the use of tools to create all or part of test cases - has a critical role in controlling the cost of testing. A particular area of focus in automated test generation research is unit testing. Unit tests are intended to test the functionality of a small isolated unit of code - typically a class. </p> <p>In automated test generation research, it is not abnormal to compare the effectiveness of the test cases generated by automation to those written by humans. Indeed, a common premise of automation research - implicitly or explicitly - is that effective automation can replace human effort. The hypothesis postulated is that, if we make enough advances, a tool could replace the tremendous effort expended by a human tester to create those unit tests. </p> <p>This observation leads to two natural questions. Do the tests produced by humans and automation differ in the types of faults they detect? If so, in what ways are the tests produced and the faults detected different? Understanding when and how to deploy automation requires a clearer understanding of how the tests produced by humans and automation are different, and how those differences in turn affect the ability of those test cases to detect faults. Insight into the differences between human and automation-produced test cases could lead not only to improvements in the ability of automation to replace human effort, but improvements in our ability to use automation to augment human effort. The goal of this study is to explore and attempt to quantify those differences. </p> <p>In this study, we make use of the EvoSuite test generation framework for Java. We generate test suites targeting two configurations - a traditional single-criterion configuration targeting Branch Coverage over the source code and a more sophisticated multi-objective configuration targeting eight criteria. Controlling for coverage level, we compare the suites generated by EvoSuite to those written by humans for five mature, popular open-source systems in terms of both their syntactic structure and their ability to detect 45 different types of faults. Our goal is not to declare a "winner'", but to identify the areas where humans and automation differ in their capabilities, and - in turn - to make recommendations on how human and automation effort can be combined to overcome gaps in the coverage of the other. We aim to identify lessons that will improve human practices, lead to the creation of more effective automation, and present natural opportunities to both augment and replace human effort. </p>
Using White-Box Test Generation During Development: A Replicated Study
<p>This package contains the artifacts for our external, differentiated replication of an empirical study on using white-box test generation.</p> <p>The original experiment is described in the following paper.</p> <blockquote> <p>José Miguel Rojas, Gordon Fraser, and Andrea Arcuri. 2015. Automated unit test generation during software development: a controlled experiment and think-aloud observations. In Proceedings of the 2015 International Symposium on Software Testing and Analysis (ISSTA 2015), 338–349. DOI: 10.1145/2771783.2771801</p> </blockquote> <p>30 developers and students participated in the experiment in January 2016.</p> <p>The main difference in the replication was using the IntelliTest test generator tool instead of EvoSuite.</p> <p>The contents of the package are the followings.</p> <ul> <li>/assignments <ul> <li>session_starts_endings.csv - Timestamps when each session was started</li> <li>assignments_with_projects.csv - Assigments of participants to projects, classes and sessions</li> </ul> </li> <li>/projects <ul> <li>/golden - Contains the golden implementation and test suites of all 4 classes</li> <li>/user - Contains the user implementation and test method stubs of all 4 classs</li> </ul> </li> <li>/results <ul> <li>time_merged.csv - File of timing analysis containing each test run of subjects</li> <li>results.csv - Contains the coverage and other required data of each participant tasks</li> <li>exit.csv - Answers of the exit survey</li> <li>background.csv - Answers of the background questionnaire</li> </ul> </li> <li>/scripts <ul> <li>/ps <ul> <li>Get-Results.ps1 - Gets the results of both tasks for one specified participant (invokes MSBuild, MSTest, VisualMutator, OpenCover)</li> <li>Get-Failures-Errors.ps1 - Gets failures and errors of both tasks for one specified participant (invokes MSBuild, MSTest)</li> <li>Get-TimeData.ps1 - Iterates over all test runs for each participant</li> </ul> </li> <li>/r <ul> <li>likert.R - Generates the Likert chart</li> <li>si_st.R - Generates table of subject implementation executed with subject test suites</li> <li>gi_st.R - Generates table of results where subject test suites was run on golden implementation</li> <li>time_spent_tests.R - Generates a table of time and activity of testing</li> <li>errors_failures.R - Generates table of errors and failures obtained using the golden test suite</li> <li>correlation_analysis.R - Generates table containing correlation between lack of correctness and IntelliTest usage</li> </ul> </li> </ul> </li> </ul>
STEG data of manuscript "Electrical Generation of a Ground Level Solar Thermoelectric Generator: Experimental Tests and One-year Cycle Simulation" submitted to Energies
<p>Figure_7_data: laboratory data of TEG output power working at low temperature differences. Data used in Figure 7 of manuscript "Electrical Generation of a Ground Level Solar Thermoelectric Generator: Experimental Tests and One-year Cycle Simulation" submitted to Energies.</p> <p>Figure_9_data: experimental data of TEG temperature differences from July 24 to July 31, 2017. Data used in Figure 9 of manuscript "Electrical Generation of a Ground Level Solar Thermoelectric Generator: Experimental Tests and One-year Cycle Simulation" submitted to Energies.</p> <p>Figures_11_14_data: input and output data of the STEG model. One-year cycle data. Used to obtain figures 11 to 14 of manuscript "Electrical Generation of a Ground Level Solar Thermoelectric Generator: Experimental Tests and One-year Cycle Simulation" submitted to Energies</p>
Search-based Test Data Generation for Mutation Testing: a tool for Python programs
<p>Test data generation for mutation testing consists of identifying a set of inputs that maximizes the number of mutants killed. Mutation Testing is an excellent test criterion for detecting faults and measuring the effectiveness of test data sets. However, it is not widely used in practice due to the cost and complexity to perform some activities as generating test data. Although test suites can be produced and selected manually by a tester this practice is susceptible to errors and tools are needed to facilitate it. Several tools have been developed to automate mutation testing, but, only a few address the test data generation. The present paper proposes an automated test data generation tool based on weak mutation for Python programming language using the Hill Climbing algorithm. For evaluation, we performed an experiment concerning the effectiveness and cost computational of the tool in a database composed of 348 mutants and we compare it with random generation. Overall, the experiment achieved an average mutation score of 86% for our proposed tool and random testing 64% on average.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.