In recent years, Web applications have grown rapidly because of their abilities to provide online information access to anyone at anytime around the world. As Web applications become complex, there is a growing concern about their quality and reliability. This paper extends traditional data flow testing techniques to Web applications. Several data flow issues about analyzing HyperText Markup Language (HTML) documents in Web applications are discussed. An object-based data flow testing approach is presented. The approach is based on a test model that captures data flow test artifacts of Web applications. In the test model, each entity of a Web application is modeled as an object. The data flow information of the functions within an object or across objects is then captured using various flow graphs. Based on the object-based test model, data flow test cases for a Web application can be systematically and selectively generated in five different levels.

The object‐orientated paradigm provides the power for software development but at the same time introduces some brand new problems. One of these problems is that the relationships among classes are more complex and difficult to identify than those in the traditional paradigm. This problem becomes a major obstacle for regression testing of OO software, in which the relationships among classes as well as those between test cases and classes, must be determined a priori. In this paper we propose a new method to select only a fraction of the test cases from the entire test suite to revalidate an OO software system. This method is based on the concepts of class firewall and of marking all the classes ‘touched’ by a test case. From the class firewall, we can identify all of the affected classes after a new version of software is released. Together with the markings, we can also identify all the test cases in the test suite that need to be retested after the software change. A step‐by‐step process is proposed to identify the relationships between classes and test cases, compute the class firewall, and select only the appropriate test cases for retesting. © 1997 John Wiley & Sons, Ltd.

The object-orientated paradigm provides the power for software development but at the same time introduces some brand new problems. One of these problems is that the relationships among classes are more complex and difficult to identify than those in the traditional paradigm. This problem becomes a major obstacle for regression testing of OO software, in which the relationships among classes as well as those between test cases and classes, must be determined a priori. In this paper we propose a new method to select only a fraction of the test cases from the entire test suite to revalidate an OO software system. This method is based on the concepts of class firewall and of marking all the classes 'touched' by a test case. From the class firewall, we can identify all of the affected classes after a new version of software is released. Together with the markings, we can also identify all the test cases in the test suite that need to be retested after the software change. A step-by-step process is proposed to identify the relationships between classes and test cases, compute the class firewall, and select only the appropriate test cases for retesting.

The Brooks' Law says that adding manpower to a late software project makes it later. Brooks developed the law through observation of many projects and derived the generalization. His explanation was quite reasonable and convincing. However, it becomes a debilitating statement to any software project manager who is faced with a late project. This paper presents an in-depth study of Brooks' Law using the system dynamics simulation approach. Unlike the first order approximation of Brooks' Law, we found some interesting results that can benefit the practicing project managers. We have found that adding people to a late project will always increase its cost, but the project may not always be late. Only under certain degree of sequential constraints among project tasks will the project be delayed. To investigate the impact of sequential constraint, we simulated numerous task conditions and found that there is a time line T for each project that if enough manpower is added before T, the project still can finish before the scheduled deadline. If manpower adjustment is after T, then the project will definitely be late. This way, the Brooks' Law is revised and turned into a useful guiding principle to benefit software development.

No abstract