TL;DR: This article maps the testability terrain for object-oriented development to assist the reader in finding relatively shorter and cheaper paths to high reliability.
Abstract: estability is the relative ease and expense of revealing software faults. This article maps the testability terrain for object-oriented development to assist the reader in finding relatively shorter and cheaper paths to high reliability. Software testing adds value by revealing faults. It is fundamentally an economic problem characterized by a continuum between two goals. A reliability -dtiven process uses testing to produce evidence that a pre-release reliability goal has been met. Time and money are expended on testing until the reliability goal is attained. This view of testing is typically associated with stringent, quantifiable reliability requirements. Other things being equal, a more testable system will reduce the time and cost needed to meet reliability goals. A resource-limited process views testing as a way to remove as many rough edges from a system as time or money permits. Testing continues until available test resources have been expended. Measurement of test adequacy or system reliability are incidental to the decision to release the system. This is the typical view of testing. Other things being equal, a more testable system provides increased reliability for a fixed testing budget.
TL;DR: Assessing testability from program specifications and an experiment shows that it takes less time to build and test a program developed from a domain-testable specification than a similar program developing from a nondomain- testable specification are discussed.
Abstract: The concept of domain testability of software is defined by applying the concepts of observability and controllability to software. It is shown that a domain-testable program does not exhibit any input-output inconsistencies and supports small test sets in which test outputs are easily understood. Metrics that can be used to assess the level of effort required in order to modify a program so that it is domain-testable are discussed. Assessing testability from program specifications and an experiment which shows that it takes less time to build and test a program developed from a domain-testable specification than a similar program developed from a nondomain-testable specification are also discussed. >
TL;DR: Experimental results show that the proposed framework to incorporate both testing-effort and change-point for SRGM has a fairly accurate prediction capability.
Abstract: In this paper, a scheme for constructing software reliability growth model based on Non-Homogeneous Poisson Process is proposed. The main focus is to provide a method for software reliability modeling, which considers both testing-effort and change-point. In the vast literature, most researchers assume a constant detection rate per fault in deriving their software reliability models. They suppose that all faults have equal probability of being detected during the software testing process, and the rate remains constant over the intervals between fault occurrences. In reality, the fault detection rate strongly depends on the skill of test teams, program size, and software testability. Therefore, it may not be smooth and can be changed. On the other hand, sometimes we have to detect more additional faults in order to reach the desired reliability objective during testing. It is advisable for project managers to purchase new automated test tool, technology or additional manpower. These approaches can provide a conspicuous improvement in software testing and productivity. In this case, the fault detection rate will be changed during the software development process. Therefore, here we incorporate both generalized logistic testing-effort function and change-point parameter into software reliability modeling. New theorems are proposed and software testing data collected from real application are utilized to illustrate the proposed model. Experimental results show that the proposed framework to incorporate both testing-effort and change-point for SRGM has a fairly accurate prediction capability.
TL;DR: The goal of this work is to define and evaluate a set of metrics that can be used to assess the testability of the classes of a Java system.
Abstract: We investigate factors of the testability of object-oriented software systems. The starting point is given by a study of the literature to obtain both an initial model of testability and existing OO metrics related to testability. Subsequently, these metrics are evaluated by means of two case studies of large Java systems for which JUnit test cases exist. The goal of This work is to define and evaluate a set of metrics that can be used to assess the testability of the classes of a Java system.
TL;DR: The goal of this paper is to identify and evaluate a set of metrics that can be used to assess the testability of the classes of a Java system.
Abstract: In this paper we investigate factors of the testability of object-oriented software systems. The starting point is given by a study of the literature to obtain both an initial model of testability and existing object-oriented metrics related to testability. Subsequently, these metrics are evaluated by means of five case studies of commercial and open source Java systems for which JUnit test cases exist. The goal of this paper is to identify and evaluate a set of metrics that can be used to assess the testability of the classes of a Java system.