Abstract: In order to be certified by the FAA, airborne software must comply with the DO-178B standard. For the unit testing of safety-critical software, this standard requires the testing process to meet a source code coverage criterion called Modified Condition/Decision Coverage. This part of the standard is controversial in the aviation community, partially because of perceived high cost and low effectiveness. Arguments have been made that the criterion is unrelated to the safety of the software and does not find errors that are not detected by functional testing. In this paper, we present the results of an empirical study that compared functional testing and functional testing augmented with test cases to satisfy MC/DC coverage. The evaluation was performed during the testing of the attitude control software for the HETE-2 (High Energy Transient Explorer) scientific satellite (since that time, the software has been modified). We found in our study that the test cases generated to satisfy the MC/DC coverage requirement detected important errors nor detectable by functional testing. We also found that although MC/DC coverage testing took a considerable amount of resources (about 40% of the total testing time), it was not significantly more difficult than satisfying condition/decision coverage and it found errors that could not have been found with that lower level of structural coverage.

Abstract: We propose checking the execution of an abstract data type's imperative implementation against its algebraic specification. An explicit mapping from implementation states to abstract values is added to the imperative code. The form of specification allows mechanical checking of desirable properties such as consistency and completeness, particularly when operations are added incrementally to the data type. During unit testing, the specification serves as a test oracle. Any variance between computed and specified values is automatically detected. When the module is made part of some application, the checking can he removed, or may remain in place for further validating the implementation. The specification, executed by rewriting, can be thought of as itself an implementation with maximum design diversity, and the validation as a form of multiversion-programming comparison.

Abstract: The paper discusses an experience in applying the extreme programming approach to the 4 year team design project course. Extreme programming is a methodology for software system development that focuses on high customer integration, extensive testing, code-centered development and documentation, refactoring and paired programming. Typically, the project course is managed using the standard waterfall or V-shaped development models with a faculty advisor acting as a customer for the project. In this project extreme programming has been used instead. Extreme programming is based on a sequence of development practices, including pair programming, very accurate configuration management, strong customer interaction based on "system stories", detailed testing. In this project, paired programmers are used for the duration of a release and then the pairs rotate. The distributed programming environment is handled using the JCVS suite of configuration management tools. Every 3-4 weeks, a new fully functional release is delivered and reviewed by the customer. The specifications for each release are captured incrementally using use case scenarios. Only the essential requirements for the current iteration are implemented. The JUnit test suite is also used to test each of the Java classes on an ongoing basis. The test suite verifies all aspects of the software at each build; this is necessary when refactoring components. Requirements capture, design and implementation of the deliverables are performed incrementally and result in quicker development times and reduced defects. Refactoring is applied wherever possible to simplify the code. Documentation is applied using the standard JavaDoc utility and is kept to a minimum. Finally, customer feedback is immediately incorporated into future iterations of the design process.

Abstract: With the advent of object-oriented languages and the portability of Java APIs, the development and use of reusable software components is becoming a reality. Effective component reuse depends on component reliability, which in turn depends on thorough testing. The literature, however, provides few approaches to component testing that are practical for the input generation and output checking of the large number of test cases required. In this paper, we present the "Roast" tool and techniques for the testing of Java APIs. The tool and techniques are illustrated on two non-trivial components, and quantitative results are presented to substantiate the practicality and effectiveness of the approach.

Abstract: : Never has the need for simulation in design of systems been more acute. Today's financial/philosophical environment requires innovative thinking in the business of product development, especially for the big-ticket' ordnance items such as main battle tanks and armament. The manufacturing costs of these items and related components prohibit use of the classical method of product development. This method, which is an iterative process, includes initial design, prototype manufacture, system testing, and redesign. As a result, considerable time and money is invested for manufacturing and testing of prototype components. We need to rethink the use of this loop if we are to remain competitive and reduce the cost of development. The answer lies in the use of a new class of electronic computational product development functions, namely, virtual performance simulation (VPS), validation by component testing (VCT), and scale model manufacture by stereo lithographic fabrication (STL). By using these methods, prototype manufacture and physical testing phases are minimized and replaced by STL and VPS. Costs are greatly reduced since the system components reside in virtual space, allowing for rapid electronic design changes and performance ratings by simulation rather than physical testing. In the end, hardware must eventually be manufactured and tested; however, this may be done after a considerable number of excursions' through VPS and STL.

Abstract: In order to be certified by the FAA, airborne software must comply with the DO-178B standard. For the unit testing of safety-critical software, this standard requires the testing process to meet a source code coverage criterion called Modified Condition/Decision Coverage. This part of the standard is controversial in the aviation community, partially because of perceived high cost and low effectiveness. Arguments have been made that the criterion is unrelated to the safety of the software and does not find errors that are not detected by functional testing. In this paper, we present the results of an empirical study that compared functional testing and functional testing augmented with test cases to satisfy MC/DC coverage. The evaluation was performed during the testing of the attitude control software for the HETE-2 (High Energy Transient Explorer) scientific satellite (since that time, the software has been modified). We found in our study that the test cases generated to satisfy the MC/DC coverage requirement detected important errors not detectable by functional testing. We also found that although MC/DC coverage testing took a considerable amount of resources (about 40% of the total testing time), it was not significantly more difficult than satisfying condition/decision coverage and it found errors that could not have been found with that lower level of structural coverage. To be certified by the FAA, aviation software must satisfy a standard labelled DO-178B [4]. Software development processes are specified in this standard for software of varying levels of criticality. With respect to testing, the most critical (Level A) software, which is defined as that which could prevent continued safe flight and landing of the aircraft, must satisfy a level of coverage called Modified Condition/Decision Coverage (MC/DC). The requirement for MC/DCcoverage has been criticized This paper was presented at DASC (Digital Aviation Systems Conference) in

Abstract: Component software development is definitely on a high trend in the sofware engineering field. However, integrating components which the producer does not have complete control over increases the risk of getting unexpected software behavior. So developing components for reuse by third-party integrators is a challenging task that one can make easier if the behavior of these software components is precisely specified. In this paper, we introduce a specification language complementing the interface definition language IDL3 proposed by OMG to describe CORBA Component Model compliant components. This specification language is based on communication history : the sequence of observable events - method calls, return of method calls, events, exceptions -- that occurred since the system has been started. It allows us to characterize the functional behavior of components by way of invariants : an interface invariant specifies a contract between a component that provides it and each of its clients, whereas a component invariant constraints the whole communication between one component and all its clients and servers. We propose a procedure based on this notation for generating specification-based test cases adapted to unit testing and discuss how to use this notation for validation purposes.

Abstract: PROBLEM TO BE SOLVED: To attain the common and standard production of programs to prevent the occurrence of simple bugs and also to early pick up these bugs by preparing a debugging part to debug a source program, a display part to show the result of a unit test part and the like. SOLUTION: When an operating instruction is given to a program production support device 10, a source reading part 12 reads a coded program D1. Then the program D1 is collated with a language specification check 40 and a coding protocol 50 at a compiling part 14 to undergo the protocol violation check and also to be compiled. The input data 30 to be used for a unit test are registered at a data register part 20, and a module test is carried out at a unit test part 18. A debugging part 16 receives the unit test result and compiling result and performs the source correction, etc. These output results are shown on a display as a result list L1.

Abstract: This paper describes the object oriented simulation architecture for rapid spacecraft prototyping. The design of this spacecraft dynamic simulator architecture incorporates a uniquely designed C++ virtual database class with linked and embedded classes for the environment, spacecraft (including dynamics), sensors, actuators, time, automated procedures, visualization windows and communication sockets for distributed processing. This architecture provides the foundation for prototyping spacecraft without the need for re-compiling for each variation of the spacecraft design mission. This architecture lends itself to both real-time and non real-time simulations where it may be used in the (1) attitude determination and control system (ADACS) design process; (2) flight software unit testing; (3) flight software/hardware-in-the-loop real-time integration & test; (4) ground control system for mission planning and checkout; (5) post flight anomaly investigation. The heritage for the simulation models is the GSFC hybrid dynamic simulator which was converted to C++ object oriented code. The significant features are: (1) the virtual database; (2) autonomous state integration; (3) transformation engine; (4) scripting Language; (5) C-code generation.

Abstract: The Internet has been recognised not only as a tool for communication in the 21st century but also as an environment for enabling changes in the paradigm of teaching and learning. The paper describes our development effort, sponsored by the Committee of University Teaching Development (CUTSD98) Grant, in designing educational material on object oriented (OO) testing in an Internet environment. The aim of the work is to enhance the state of the art in learning OO testing by visualizing the testing process and interactive courseware in virtual communities. We have endeavoured to create an effective Internet based courseware known as LIGHTVIEWS which contains OO testing case studies described by visual images, animation, and interactive lessons, to assist active participation by learners to result in better understanding and knowledge retention. Our approach employs appropriate UML diagrams, makes the diagrams test ready by including details of constraints as part of state/event transitions, and provides interactive lessons for learning OO software testing. We have used four case studies to explore the various test selection techniques. We have included black-box testing at unit level in case study 1, and at the system level in case study 3. Case study 2 was used to illustrate event based testing by visually representing the dynamics of Java applets at work, and using interactivity to learn how to test Java applets, threads, and applet communication. Case study 4 explores the various aspects of distributed component testing. More details are available on the project Web page http://www.sd.monash.edu.au/sitar/se-educ-proj.

Abstract: ’Faster, Cheaper, Better’ is a phrase commonly used. With unit and integration testing, typically being 20% of the cost of development, significant improvements can be made by either reducing the required effort or increasing the effectiveness of testing. Tools such as, TestMate and StateMate can be used to further increase the level of automation used in unit and integration testing, even to the point of producing inputs and expected results. This paper presents the procedures developed by the SITAR project and the results of the evaluation showing a cost saving.

Abstract: This paper puts forward a test system framework TFDS (test system framework for distributed software system) for the testing of distributed programs, and as an illustration, introduces its prototype implementation PSET * (distributed program structure and event trace, revised version) on heterogeneous network platforms. The main functions of TFDS are for unit testing and integration testing. And the framework is divided into two parts: one for specification design and source code analysis, which works statically; and the other for program execution and event sequence manipulation, which works dynamically. Along with TFDS, and by a component based architecture, the functionality of the PSET * can be easily improved and reinforced.

Abstract: A model engineering approach is used in developing a testing method called VISWAS for the validation of distributed systems to test for safety and liveness properties. The VISWAS method is an integrated testing method, which incorporates a test environment with software modelling and automatic test sequence generation. This paper describes the three layered test architecture model of VISWAS, which includes a distributed architecture model (Ken-Gate model), a method (UML, OCL) and techniques (with Temporal Logic and TLA), to develop a tool for automatic test sequence generation.

Abstract: The title of this article is a variation on a theme from Extreme Programming (XP). XP is a code-centric discipline for getting software done right, on time, within budget, while having fun along the way. Quit laughing. The XP approach is to take the best software practices to the extreme. For example, if code reviews are good, then code should be reviewed constantly, even as it’s written, hence the XP practice of Pair Programming, where all code is written by two developers sharing a single workstation. One programmer pilots the keyboard while the other watches to catch mistakes and gives strategic guidance – then they switch roles as needed. The next day they may pair up with other folks. Likewise, if testing is good, then all tests should be automated and run many times per day. An ever-growing suite of unit tests should be executed whenever you create or modify any function, to ensure that the system is still stable. Furthermore, developers should integrate code into the complete, evolving system and run functional tests often (at least daily).

Abstract: Structural testing techniques are widely used in the unit testing process of softwares. A major challenge of this process consists in generating automatically test data, i.e., in finding input values for which a selected point in a procedure is executed. We introduce here an original framework where the later problem is transformed into a CLP(FD) problem. Specific operators have been introduced to tackle this kind of application. The resolution of the constraint system is based upon entailment techniques. A prototype system -- named INKA -- which allows to handle a non-trivial subset of programs written in C has been developed. First experimental results show that INKA is competitive with traditional ad-hoc methods. Moreover, INKA has been used successfully to generate test data for programs extracted from a real application.