Too Trivial To Test? An Inverse View on Defect Prediction to Identify Methods with Low Fault Risk

Background. Test resources are usually limited and therefore it is often not possible to completely test an application before a release. To cope with the problem of scarce resources, development teams can apply defect prediction to identify fault-prone code regions. However, defect prediction tends to low precision in cross-project prediction scenarios. Aims. We take an inverse view on defect prediction and aim to identify methods that can be deferred when testing because they contain hardly any faults due to their code being "trivial". We expect that characteristics of such methods might be project-independent, so that our approach could improve cross-project predictions. Method. We compute code metrics and apply association rule mining to create rules for identifying methods with low fault risk. We conduct an empirical study to assess our approach with six Java open-source projects containing precise fault data at the method level. Results. Our results show that inverse defect prediction can identify approx. 32-44% of the methods of a project to have a low fault risk; on average, they are about six times less likely to contain a fault than other methods. In cross-project predictions with larger, more diversified training sets, identified methods are even eleven times less likely to contain a fault. Conclusions. Inverse defect prediction supports the efficient allocation of test resources by identifying methods that can be treated with less priority in testing activities and is well applicable in cross-project prediction scenarios.Comment: Submitted to PeerJ C

The Composite Spectrum of Strong Lyman-alpha Forest Absorbers

We present a new method for probing the physical conditions and metal enrichment of the Intergalactic Medium: the composite spectrum of Ly-alpha forest absorbers. We apply this technique to a sample of 9480 Ly-alpha absorbers with redshift 2 < z < 3.5 identified in the spectra of 13,279 high-redshift quasars from the Sloan Digital Sky Survey (SDSS) Fifth Data Release (DR5). Absorbers are selected as local minima in the spectra with 2.4 < tau_Ly-alpha < 4.0; at SDSS resolution (~ 150km/s FWHM), these absorbers are blends of systems that are individually weaker. In the stacked spectra we detect seven Lyman-series lines and metal lines of O VI, N V, C IV, C III, Si IV, C II, Al II, Si II, Fe II, Mg II, and O I. Many of these lines have peak optical depths of < 0.02, but they are nonetheless detected at high statistical significance. Modeling the Lyman-series measurements implies that our selected systems have total H I column densities N_HI ~ 10^15.4cm-2. Assuming typical physical conditions rho / = 10, T = 10^4 - 10^4.5 K, and [Fe/H]= -2 yields reasonable agreement with the line strengths of high-ionization species, but it underpredicts the low-ionization species by two orders of magnitude or more. This discrepancy suggests that the low ionization lines arise in dense, cool, metal-rich clumps, present in some absorption systems.Comment: 7 pages, 4 figures, 1 table, accepted by ApJL, revisions mad

Interpretive computer simulator for the NASA Standard Spacecraft Computer-2 (NSSC-2)

An Interpretive Computer Simulator (ICS) for the NASA Standard Spacecraft Computer-II (NSSC-II) was developed as a code verification and testing tool for the Annular Suspension and Pointing System (ASPS) project. The simulator is written in the higher level language PASCAL and implented on the CDC CYBER series computer system. It is supported by a metal assembler, a linkage loader for the NSSC-II, and a utility library to meet the application requirements. The architectural design of the NSSC-II is that of an IBM System/360 (S/360) and supports all but four instructions of the S/360 standard instruction set. The structural design of the ICS is described with emphasis on the design differences between it and the NSSC-II hardware. The program flow is diagrammed, with the function of each procedure being defined; the instruction implementation is discussed in broad terms; and the instruction timings used in the ICS are listed. An example of the steps required to process an assembly level language program on the ICS is included. The example illustrates the control cards necessary to assemble, load, and execute assembly language code; the sample program to to be executed; the executable load module produced by the loader; and the resulting output produced by the ICS