5 research outputs found

    Improve Relevancy of Object Oriented Class Cohesion Metrics with Inheritance

    Get PDF
    Cohesion is a very important quality attribute in software. As we know that there are number of cohesion metrics are proposed in the literature to measure the cohesion of software systems. These metrics gives undefined values for a large number of classes which comes under special cases. Because of this reason, these metrics became non-applicable for these classes as they are unable to give cohesion values for these classes. In this paper, a value assignment criterion would be used to make cohesion metrics applicable and the concept of inheritance would be included for these special cases. Study the effect of including or excluding the inherited elements i.e., methods and attributes

    Pemetaan Secara Sistematis Pada Metrik Kualitas Perangkat Lunak

    Get PDF
    . Software quality assurance is one method to increase quality of software. Improvement of software quality can be measured with software quality metric. Software quality metrics are part of software quality measurement model. Currently software quality models have a very diverse types, so that software quality metrics become increasingly diverse. The various types of metrics to measure the quality of software create proper metrics selection issues to fit the desired quality measurement parameters. Another problem is the validation need to be performed on these metrics in order to obtain objective and valid results. In this paper, a systematic mapping of the software quality metric is conducted in the last nine years. This paper brings up issues in software quality metrics that can be used by other researchers. Furthermore, current trends are introduced and discussed

    Regression Testing of Object-Oriented Software based on Program Slicing

    Get PDF
    As software undergoes evolution through a series of changes, it is necessary to validate these changes through regression testing. Regression testing becomes convenient if we can identify the program parts that are likely to be affected by the changes made to the programs as part of maintenance activity. We propose a change impact analysis mechanism as an application of slicing. A new slicing method is proposed to decompose a Java program into affected packages, classes, methods and statements identified with respect to the modification made in the program. The decomposition is based on the hierarchical characteristic of Java programs. We have proposed a suitable intermediate representation for Java programs that shows all the possible dependences among the program parts. This intermediate representation is used to perform the necessary change impact analysis using our proposed slicing technique and identify the program parts that are possibly affected by the change made to the program. The packages, classes, methods, and statements thus affected are identified by traversing the intermediate graph, first in the forward direction and then in the backward direction. Based on the change impact analysis results, we propose a regression test selection approach to select a subset of the existing test suite. The proposed approach maps the decomposed slice (comprising of the affected program parts) with the coverage information of the existing test suite to select the appropriate test cases for regression testing. All the selected test cases in the new test suite are better suited for regression testing of the modified program as they execute the affected program parts and thus have a high probability of revealing the associated faults. The regression test case selection approach promises to reduce the size of regression test suite. However, sometimes the selected test suite can still appear enormous, and strict timing constraints can hinder execution of all the test cases in the reduced test suite. Hence, it is essential to minimize the test suite. In a scenario of constrained time and budget, it is difficult for the testers to know how many minimum test cases to choose and still ensure acceptable software quality. So, we introduce novel approaches to minimize the test suite as an integer linear programming problem with optimal results. Existing research on software metrics have proven cohesion metrics as good indicator of fault-proneness. But, none of these proposed metrics are based on change impact analysis. We propose a changebased cohesion measure to compute the cohesiveness of the affected program parts. These cohesion values form the minimization criteria for minimizing the test suite. We formulate an integer linear programming model based on the cohesion values to optimize the test suite and get optimal results. Software testers always face the dilemma of enhancing the possibility of fault detection. Regression test case prioritization promises to detect the faults early in the retesting process. Thus, finding an optimal order of execution of the selected regression test cases will maximize the error detection rates at less time and cost. We propose a novel approach to identify a prioritized order of test cases in a given regression selected test suite that has a high chance of fault exposing capability. It is very likely that some test cases execute some program parts that are more prone to errors and have a greater possibility of detecting more errors early during the testing process. We identify the fault-proneness of the affected program parts by finding their coupling values. We propose to compute a new coupling metric for the affected program parts, named affected change coupling, based on which the test cases are prioritized. Our analysis shows that the test cases executing the affected program parts with high affected change coupling have a higher potential of revealing faults early than other test cases in the test suite. Testing becomes convenient if we identify the changes that require rigorous retesting instead of laying equal focus to retest all the changes. Thus, next we propose an approach to save the effort and cost of retesting by identifying and quantifying the impact of crosscutting changes on other parts of the program. We propose some metrics in this regard that are useful to the testers to take early decision on what to test more and what to test less
    corecore