R. Binder. Design for testability in object-oriented systems. Communications of the ACM, 37(9):87--101, 1994.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Code must be failure tolerant. When a fault occurs error handlers must bring the system back to a safe state. 1) Failure Tolerance [41] TESTABILITY Only testable requirements should be specified. Code should be designed to be testable. 1) Domain Range Ratio (DRR) 40] 2) Controllability [2] 3) Observability [2] 4) Sensitivity Analysis [39] USABILITY Requirements should be formulated with 1) Total Training Time [38] NFRs should be testable, and quantitative so that metrics can be easily applied and measured. For example, a poor non functional requirement (NFR) is one that cannot ....

....tolerant. When a fault occurs error handlers must bring the system back to a safe state. 1) Failure Tolerance [41] TESTABILITY Only testable requirements should be specified. Code should be designed to be testable. 1) Domain Range Ratio (DRR) 40] 2) Controllability [2] 3) Observability [2] 4) Sensitivity Analysis [39] USABILITY Requirements should be formulated with 1) Total Training Time [38] NFRs should be testable, and quantitative so that metrics can be easily applied and measured. For example, a poor non functional requirement (NFR) is one that cannot be easily tested and ....

BINDER, R. V.: "Design For Testability In Object-Oriented Systems" Communications Of The ACM, 1994, 37 (9) pp. 87 - 101.

....needed for testing of the software, the architecture must be designed so that it is easy to test, i.e. having high testability. The testability is dependent on three individual properties: observability, controllability, and for concurrent systems and systems dependent on time, reproducibility [Bind94]. Testability is consequently an indirect quality property as well. In order for a test case to be useful, the result of it must be observed. If the components in the architecture are seen as black boxes , i.e. the structural view, only the interfaces are observable. The bigger interface, the ....

R. V. Binder, Design for Testability in Object-Oriented Systems, Communications of the ACM, Volume 37, No 9, pp. 87-101, 1994

.... approach significantly reduces the size of the test data set without affecting its fault finding properties, 3] Design for test Not many software developers realise that the design can affect the effectiveness of testing and the issue of design for test is one that should be considered more, [7]. Organising the system in a particular way can make an enormous difference; some systems are almost impossible to test properly if this is not done. The two key issues are controllability and observability . By controllability we mean putting in enough functionality so that we can drive the ....

Robert V. Binder, "Design for testability in objectoriented systems", Communications of the ACM, 37(9):87- 101, September 1994

....data flow specification, predict the controllability observability of the software unit in terms of the information loss through the possible data flows. Several designs for testability strategies based on controllability of the component s input and observability of its output are suggested in [5]. They include information hiding and separation of concerns, test scaffolding, and adding explicit built in test functions to report internal state on demand. For the purposes of measurement in TROMLAB environment, we focus on the evaluation of the component s testability independent of any ....

R. Binder, "Design for Testability in Object-Oriented Systems". Communications of the ACM (37), 9, 1994, pp.87-101.

....have a line that can be drawn between functionality implementing the interface and functionality providing operations the interface encapsulates. Recognising, and incorporating this separation of concerns in development is important because it helps to improve the testability of the software (Binder, 94) A component that is easily controllable, in terms of setting internal state, is easier to test. If user interface capabilities are entwined with basic application service providing functions then it will be more difficult to verify each function, as observability of program outputs, along with ....

BINDER, R. V.: "Design For Testability In Object-Oriented Systems" Communications Of The ACM, 1994, 37 (9) pp. 87 - 101.

....aspects of a software : in [Thvenod Fosse Waeselynck 1993, Waeselynck 1993] the authors use Statemate, a tool based on Statecharts [Harel et al. 1990] for designing test cases. Unfortunately, little work is made to use object oriented analysis and design methodologies for the testing process [Binder 1994, Poston 1994] 3. On going work In that context, our purpose is to study new models (and test criteria for these models) or adaptation of classical ones that take into account object orientedness : functional and behavioral modeling. New features like encapsulation, inheritance, polymorphism, ....

R. V. Binder, "Design for Testability in Object-Oriented Systems", Communication of the ACM, 37 (9), pp.87-101, 1994.

.... object oriented metrics [12, 13] much work has been undertaken to define measurements for attributes of object oriented code, much of which has been concerned with design [1, 11, 31, 44, 55, 57] reusability [22, 39, 4, 6, 26] and traditional software code measurement concerns such as complexity [8, 27, 29, 54]. Robin Whitty at Southbank University Centre for Systems and Software Engineering provides a long, annotated (and electronically available [53] list of source references concerned with Object Oriented Metrics. Mark Lorenz and Jeff Kidd [36] provide an extensive survey text on the subject. In ....

Binder, R. V. Design for testability in object--oriented systems. Communications of the ACM 37 (1994), 87--101.

....articles provide techniques for class testing (as opposed to system testing) The ACE tool [19] an enhancement of PGMGEN [12, 20] supports the testing of Eiffel and C classes and has seen substantial industrial use. Arnold and Fuson [21] discuss class testing issues and techniques. Binder [22] describes how classes can be designed to reduce test cost. The text by Marick [23] devotes two chapters to class testing, focusing primarily on test plans. With Marick s approach, extensive test documentation is developed for each class. In contrast, our approach minimizes the need to document ....

R.V. Binder. Design for testability in object-oriented systems. Commun. ACM, 37(9):87--101, 1994.

....Aircraft. This evaluation clarifies the prospective costs and benefits of applying Siddhartha within a software development organization. 1. Introduction Specification based program testing seeks to automate test case generation and test case evaluation by exploiting formal specifications [1, 2, 4, 5, 8, 12, 13, 16, 17]. In specification based testing, a formal specification serves as an unambiguous standard against which the behavior of the program unit under test (UUT) can be automatically compared and as a mechanism by which tests can be developed. Adoption of specification based testing tools in industry has ....

....theoretical considerations and under emphasize application domain specific constraints. For example, many specification based testing tools constrain program units under test and their formal specifications of intended behavior to possess fully encapsulated and syntactically equivalent interfaces [1, 2, 4]. This constraint simplifies translation between test case specifications, which are written in the language and vocabulary of the formal specification, and ground (i.e. variable free) test 2 2 Ada is a registered trademark of the United States government. case input and output data, which ....

[Article contains additional citation context not shown here]

Binder, R.V. Design for testability in object-oriented systems. Communications of the ACM, Sept. 1994, vol.37, (no.9):87-101.

....conformance testing [40] etc. Multiple techniques such as simulation, modeling, and formal analysis are applied to study a particular system in [33] Various tools for specification [23] and analysis of specific properties [1] exist. Issues related to design for testability of software are in [6]. Techniques for different emulation interfaces can be used for conformance testing protocol implementations [74] The work in these areas is complementary to our focus on the design and development of routing protocols. Protocol specification, testing, and verification techniques are ....

R.V. Binder. Design for testability in object-oriented systems. Communications of the ACM, 37(9):87--101, September 1994.

....Introduction The object oriented (OO) paradigm is rapidly expanding its acceptance in the software industry. However, the powerful features of this new paradigm also introduce a new set of testing and maintenance problems. The pioneering work in identifying these new problems includes [1] 2] 3] [4] [5] 6] 7] The problems can be summarized as: 1) the understanding problem; 2) the complex interdependency problem; the object state behavior testing problem; and 4) the tool support problem. Detailed discussions of these problems will be provided in the next section. Our industrial experience ....

R. Binder, "Design for testability in object-oriented systems," CACM Vol. 37, No. 9, pp. 87 - 101, September 1994.

....could increase the productivity, not just in a sence of a bigger quantitiy of executable test cases, but also in raising the quality of class testing by circumventing these psycholocical restraints. There is a great agreement between researchers, that automication is crucial for successful testing [Jac92, Bin94a, MK94]. But it is also obvious that the knowledge and creativity of experienced testing personal should not hindered by inflexible tools. This yields flexibility as an important design goal of the library: 1. Automatic features shall be widely controllable through parametrization. 2. The extension of ....

Robert V. Binder. Design for Testability in Object-Oriented Systems. Communications of the ACM, September 1994.

No context found.

R. Binder. Design for testability in object-oriented systems. Communications of the ACM, 37(9):87--101, 1994.

No context found.

Binder, R.V.: Design for testability in object-oriented systems. Commun. ACM 37 (1994) 87--101

No context found.

Binder, R.: Design for testability in object-oriented systems. Communications of the ACM 37 (1994) 87--101

No context found.

Binder, R. V., Design for testability in object-oriented systems, Communications of the ACM 37 (1994), pp. 87--101. 10

No context found.

Binder, R., Design for testability in object-oriented systems, Communications of the ACM 37 (1994), pp. 87--101.

No context found.

R. Binder. Design for testability in object-oriented systems. Communications of the ACM, 37(9):87--101, 1994.

No context found.

R. V. Binder, "Design for Testability in Object-Oriented System", Communications of the ACM, Vol. 37, No. 9, pp87-101, September 1994.

No context found.

R. V. Binder, "Design for Testability in Object-Oriented System", Communications of the ACM, Vol. 37, No. 9, pp87-101, September 1994.

No context found.

R. V. Binder, "Design for Testability in Object-Oriented Systems," Communications of the ACM, vol. 37, pp. 87-101, Sept. 1994.

No context found.

R. V. Binder. Design for Testability in Object-Oriented Systems. Communications of the ACM. September 1994, pp. 87--101.

No context found.

R. Binder. Design for testability in object-oriented systems. Comm. of the ACM, 37(9):87--101, 1994.

No context found.

R. Binder. Design for testability in object-oriented systems. Comm. of the ACM, 37(9):87--101, 1994.

No context found.

Robert V. Binder. Design for testability in object-oriented systems. CACM, 37(9):87-101, September 1994.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC