Abstract: Data-flow testing relies on static analysis for computing the definition-use pairs that serve as the test case requirements for a program. When testing large programs, the individual procedures are first tested in isolation during unit testing. Integration testing is performed to specifically test the procedure interfaces. The procedures in a program are integrated and tested in several steps. Since each integration step requires data-flow analysis to determine the new test requirements, the accumulated cost of repeatedly analyzing a program can contribute considerably to the overhead of testing. Data-flow analysis is typically computed using an exhaustive approach or by using incremental data-flow updates. This paper presents a new and more efficient approach to data-flow integration testing that is based on demand-driven analysis. We developed and implemented a demand-driven analyzer and experimentally compared its performance during integration testing with the performance of (i) a traditional exhaustive analyzer, and (ii) an incremental analyzer. Our experiments show that demand-driven analysis is faster than exhaustive analysis by up to a factor of 25. The demand-driven analyzer also outperforms the incremental analyzer in 80% of the test programs by up to a factor of 5.

Abstract: This study derives and validates an empirical effort estimation model for graphical user interface (GUI) systems. It investigates the relationship between the effort to code and unit test GUI systems and the numbers of different types of widgets (e.g., text boxes, check boxes, list boxes) designed in those systems. The study focuses on systems implemented using Visual Basic, a popular Microsoft Windows programming language. The GUI effort estimation model was empirically derived from an agent diary system implemented in an international bank. The model exhibited a strong relationship (R/sup 2/=0.863, p<0.001) between estimated effort and the numbers of different types of widgets. In an exploratory test of robustness, the GUI effort estimation model was applied without calibration to a different development environment. As expected there was a high error level, confirming the need for calibration when applying effort estimation models to foreign settings.

Abstract: Development of the original IEEE 1149.1 boundary-scan standard in 1990 was motivated primarily by concerns about the complexity of testing increasingly dense printed-circuit board assemblies in manufacturing. As a result, most test generation efforts have been targeted at unit test, which is most applicable to testing MCMs and boards. As boundary-scan technology has matured, there is a new focus on extending the technique to testing all levels of an assembly's hierarchy, at all phases in its life cycle.

Abstract: PURPOSE: To provide an automatic generation method for a test item slip to be used for unit testing a program module CONSTITUTION: When the test item slip to be used for unit test executed for each module of a hierarchical program is generated, a module of the test object is selected SA1 Its source program is read in, and the processing structure (tree structure) is acquired by syntax analysis, and all of test items passing through each path of this tree structure at least once are extracted to generate a test item file SA2 Finally, a test item data file is read in to output a test item slip SA3

Abstract: Keywords: Testing ; Conform ; OOMethod ; peraire ; Paper Reference LGL-CONF-1996-003 Record created on 2005-09-20, modified on 2016-08-08

Abstract: The testing system uses a holding and contacting device (2), for mechanically supporting the component to be tested and providing an electrical contact with each of its electrical terminals, with selective connection of the holding and contacting device to one of a number of different testing devices (5a,5b,...5n). The testing is effected with the selected testing device, with switching over to each of the other testing devices in turn, for effecting a full testing sequence for a wide number of different component parameters.

Abstract: Mutation testing is a technique for testing software units that has great potential for improving the quality of testing, and thereby increasing our ability to assure the high reliability of critical software. The paper presents a technique that uses mathematical constraints to automatically detect equivalent mutant programs. The paper also describes how the approach is used for the feasible path problem. The paper describes how test criteria are formalized as mathematical constraint systems, how equivalent mutants are represented as infeasible constraints, and how infeasible constraints are detected. A proof of concept implementation has been developed to demonstrate this technique, and experimental results from using this tool are presented. Limitations of the system and the method are described, and proposals for improvements are made.

Abstract: Testing is a complex engineering effort and must be well planned in order to be executed properly. In order to test a product the supplier must be able to identify the various levels of testing to be performed and the requirements for those levels of testing. This chapter focuses mainly on the supplier’s responsibilities for testing the product from the unit tests through system-level testing and on into field tests. Generally speaking, for each level of testing the supplier must identify the requirements being tested, test methods to be used, software and hardware resources required to execute the tests, and schedule and budget required to develop the test cases, identify the expected results, and actually run the tests.