|This paper illustrates how software can be described precisely using LD-relations, how these descriptions can be presented in a readable manner using tabular notations, and one way such descriptions can be used to test programs. We describe an algorithm that can be used to generate a test oracle from program documentation, and present the results of using a tool based on it to help test part of a commercial network management application. The results demonstrate that these methods can be e ective at detecting errors and greatly increase the speed and accuracy of test evaluation when compared with manual evaluation. Such oracles can be used for unit testing, {in situ} testing, constructing self-checking software and ensuring consistency between code and documentation. Index Terms|Program testing, test oracle, formal speci cation, nite state machine.
A fundamental assumption of software testing is that there is some mechanism, an oracle, that will determine whether or not the results of a test execution are correct. In practice this is ofien done by comparing the output, either automatically or manually, to some pre-calculated, presumably correct, output [17]. HoweveG 1~the program is formally documented it is possible to use the specljication to determine the success or failure of a test execution, as in [1], for example. This paper discusses ongoing work to produce a tool that will generate a test oracle from formal program documentation.In [9], [10] and [11] Parnas et al. advocate the use of a relational model for documenting the intended behaviour of programs. In this method, tabular expressions are used to improve readabili~so that formal documentation can replace conventional documentation. Relations are described by giving their characteristic predicate in terms of the values of concrete program variables. This documentation method has the advantage that the characteristic predicate can be used as the test oracle --it simply must be evaluated for each test execution (input & output) to assign pass or fail. In contrast to [1], this paper discusses the testing of individual programs, not objects as used in [1]. Consequently, the method works with program documentation, written in terms of the concrete variables, and no representation function need be supplied. Documentation in this form, and the corresponding oracle, are illustrated by an example. Finally, some of the implications of generating test oracles from relational specifications are discussed. Permission to copy without fee all or patt of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and Its date appear, and notice is given that copying is by permission of the Association of Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. ISSTA 94-8/94 Seattle Washington USA Q 1994 ACM 0-89791 -683-2/94/0008..$3.50 1,0 INTRODUCTION As software becomes pervasive in our society, its correct behaviour becomes increasingly critical to the safety and well being of people and businesses. Consequently, there is an increasing need for the strict application of engineering discipline to the development of software systems. The Software Engineering Research Group at McMaster University seeks to address this need by developing techniques and tools to facilitate the production of software design documentation that is 1) clear enough to be read and understood by both 'domain experts' and programmers with a minimum of special training, and 2) complete and precise enough to allow thorough analysis, both manually and mechanically. The use of tabular expressions to represent relations [12] is one of the cornerstones of these techniques. All software testing research and practice assumes that there is some mechanism, an oracle, for determining whether or no...
The paper explores the use of a GPU-Event-Mechanics (GEM) simulation to assess local ice loads on a vessel operating in pack ice. The methodology uses an event mechanics concept implemented using massively parallel programming on a GPU enabled workstation. The simulation domain contains hundreds of discrete and interacting ice floes. A simple vessel is modeled as it navigates through the domain. Each ship-ice collision is modeled, as is every ice-ice contact. Each ship-ice collision event is logged, along with all relevant ice and ship data. Thousands of collisions are logged as the vessel transits many tens of kilometers of ice pack. The GEM methodology allows the simulations to be performed much faster than real time. The resulting impact load statistics are qualitatively evaluated and compared to published field data. The analysis provides insight into the nature of loads in pack ice. The work is part of a large research project at Memorial University called STePS2 (Sustainable Technology for Polar Ships and Structures).
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.