【正文】 asemethod coverage information can be determined. After a program is modified, regression test selection requires a subset of test cases, R, to be selected from T for rerunning on the modified program with the objective of providing confidence that no unintended effects have been caused by the modification. It would be costly for regression testing to repeat the whole set of test cases T used in the initial development of the program and unreliable to choose a random subset of test cases from T. Therefore, it is necessary to select a suitable subset of test cases from T to run. Regression test selection reduces the cost of testing by focusing on the changes that take place in the program. A number of regression test selection approaches have been developed. Several approaches and techniques have addressed the problem of regression testing for procedural programs. Examples of proceduralbased techniques are: slicing, data flow, firewall, and optimization [1–4]. Others have dealt with object oriented (OO) programs. Some of these OO techniques for regression test selection are based on UML diagrams and make use of only design information. Examples of these techniques are presented in [5–9]. Also, object oriented firewall techniques have been proposed in [10]. Extended firewalls are proposed for Object Oriented Regression Testing in [11]. Their algorithm makes a distinction between affected ponents and checked ponents. Then, it detects all the ponents that directly or indirectly call the modified ponent. These are called faults. The authors find that the extended firewall revealed more faults than normal firewall techniques. The object oriented code based techniques have been based on Java and C++ to handle the inter procedural control flow and the features of these languages. To handle the Java constructs and features, a regression test selection algorithm has been developed which builds a Java interclass graph as an extension of the control flow graph [12]. Rothermel et al. [13] have addressed the regression test selection technique problem for C++ software which is a codebased technique that builds an interclass control flow graph in order to find the difference between the original and the new programs. Jang et al. [14] presented another regression testing technique for C++ software. The authors mainly focus on functions that should be retested in C++ programs. They identify the type of change, and a firewall of its type is determined in order to find the dependency between the statements. A unit firewall is a set of member functions which require unit level retesting。 an integration firewall is a set of interactions between member functions which require integration level retesting. Recently, Li and Harrold [15] presented a method for random test selection based on the Cher off bound. Chittimalli and Harrold [16] described a regression test selection technique based on system requirements. Also, Qu et al. [17] proposed configurationaware regression testing technique for evolving software systems using binatorial interaction testing, configuration sampling, and prioritization. C is a fairly new object oriented programming language which is integrated in the Microsoft’s .NET framework for application development. However, no work has been reported on regression testing C applications with their specific features. The objective of this paper is to present, for the first time, a codebased regression test selection technique for C programs. This technique is a three phase technique. In the first phase, we build an Affected Class diagram covering the classes that are changed or affected by such changes in the source code. In the second phase, we develop a C interclass graph, which represents the control flow of the methods in the classes considered in the affected class diagram and their interrelationships. This phase extends previous object oriented techniques by covering C specific features. In the third phase, we assign weights to test cases using a proposed metric. According to the weights, we reorder the test cases that need to be rerun. We show the usefulness of our technique by presenting the results of applying it to a few examples. This paper is organized as follows. Section 2 presents some assumptions and describes required data structures. Sections 3–5 describe our technique for selecting test cases from the initial suite of tests. Section 6 presents and discusses our empirical results. Section 7 proposes further work. Section 8 concludes the paper.2. Assumptions and NotationWe assume that we have the test suite, T, consisting of the test cases determined during the initial development of the program. Each test case in T covers one or more methods in the classes. We use an adjacency table to represent the test casemethod coverage information. After modifying the program, we also save the set of directly changed methods, M1, and the set of deleted methods, M2. The set of affected methods are the methods that are directly or indirectly calling the changed, added, or deleted methods. These methods are gathered from the trace file produced by the .Net framework. The main purpose of the trace file is for testing and optimization after an applications piled and released. We instrument the trace file by writing information about each method that calls another method.3. Technique OverviewOur technique for test case selection consists of three . Test case selection based on the affected class diagram (ACD).Step 1. Generate the ACD that contains: all the classes that contain modified and/or deleted methods。 the base classesand derived classes of the changed classes。 the classes that use the changed classes (containing methods that call directly or indirectly the modified methods). In addition to classes, the ACD may also contain the following: Interfaces。 Web and windows services, which is the use of an external method or class outside the program o