Generating oracles from your favorite temporal logic specifications

Dillon, Laura K.; Ramakrishna, Y. S.

doi:10.1145/250707.239116

Cited by 20 publications

(19 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We also intend to explore the use of other temporal logics, especially Computation Tree Logic (CTL) and the µ-calculus [19], for the specification of security policies. The method mentioned in [10] suggests a means of modularizing the temporal logic engine out of the model-checker, allowing the same modelchecking system to be used for multiple temporal logics by changing which temporal logic engine is used. Examining how to use several of these engines at once seems a promising direction for our tool as well.…”

Section: Discussionmentioning

confidence: 99%

ActionScript bytecode verification with co-logic programming

DeVries

Gupta

Hamlen

et al. 2009

Proceedings of the ACM SIGPLAN Fourth Workshop on Programming Languages and Analysis for Security

View full text Add to dashboard Cite

A prototype security policy verification system for ActionScript binaries is presented, whose implementation leverages recent advances in co-logic programming. Our experience with co-logic programming indicates that it is an extremely useful paradigm for elegantly expressing algorithms that lie at the heart of model-checking technologies. This results in an unusually small trusted computing base, making the verification system well-suited to frameworks like certifying in-lined reference monitoring systems, which require small, light-weight verifiers. Preliminary experiments and progress are discussed.

show abstract

Section: Discussionmentioning

confidence: 99%

ActionScript bytecode verification with co-logic programming

DeVries

Gupta

Hamlen

et al. 2009

Proceedings of the ACM SIGPLAN Fourth Workshop on Programming Languages and Analysis for Security

View full text Add to dashboard Cite

show abstract

“…In most cases, the expected behavior of the software is assumed to be provided by the test designer. This behavior may be specified in several ways: (1) as predicates represented in a tabular form to express functional specifications of the software [40], (2) as temporal constraints that specify conditions that must not be violated during software execution [8,9,43,44], (3) as logical expressions to be satisfied by the software [11], and (4) as formal specifications [1,4,6,10,14,15,41], e.g., algebraic specifications to represent abstract data types (ADTs) [4,10,15]. This expected behavior is then used by a verifier that either performs a table lookup [40], creates a state-machine model [9,20], or evaluates a boolean expression [11] to determine the correctness of the actual output.…”

Section: Related Workmentioning

confidence: 99%

Designing and comparing automated test oracles for GUI-based software applications

Xie

Memon

2007

ACM Trans. Softw. Eng. Methodol.

135

100

View full text Add to dashboard Cite

Test designers widely believe that the overall effectiveness and cost of software testing depends largely on the type and number of test cases executed on the software. This paper shows that the test oracle, a mechanism that determines whether a software executed correctly for a test case, also significantly impacts the fault-detection effectiveness and cost of a test case. Graphical user interfaces (GUIs), which have become ubiquitous for interacting with today's software, have created new challenges for test oracle development. Test designers manually "assert" the expected values of specific properties of certain GUI widgets in each test case; during test execution, these assertions are used as test oracles to determine whether the GUI executed correctly. Since a test case for a GUI is a sequence of events, a test designer must decide (1) what to assert, and (2) how frequently to check an assertion, e.g., after each event in the test case or after the entire test case has completed execution. Variations of these two factors significantly impact the fault-detection ability and cost of a GUI test case. A technique to declaratively specify different types of automated GUI test oracles is described. Six instances of test oracles are developed and compared in an experiment on four software systems. The results show that test oracles do affect the fault-detection ability of test cases in different and interesting ways: (1) test cases significantly lose their fault-detection ability when using "weak" test oracles, (2) in many cases, invoking a "thorough" oracle at the end of test case execution yields the best cost-benefit ratio, (3) certain test cases detect faults only if the oracle is invoked during a small "window of opportunity" during test execution, and (4) using thorough and frequently-executing test oracles can make up for not having long test cases.

show abstract

“…2) Temporal properties -the order of events, which can be checked by comparing the sequence of observed events with that specified by either a temporal logic [7], [8]; a finite state machine model [15], [6]; or a context-free grammar [2]. 3) Timing constraints -the time elapsed between events, which can be expressed using a real-time logic [23], [17]; or as extensions on a finite state machine model [25], [34].…”

Section: Related Workmentioning

confidence: 99%

Requirements-based monitors for real-time systems

Peters

2000

Proceedings of the 2000 ACM SIGSOFT International Symposium on Software Testing and Analysis

View full text Add to dashboard Cite

Abstract-Before designing safety-or mission-critical real-time systems, a specification of the required behavior of the system should be produced and reviewed by domain experts. After the system has been implemented, it should be thoroughly tested to ensure that it behaves correctly. This is best done using a monitor, a system that observes the behavior of a target system and reports if that behavior is consistent with the requirements. Such a monitor can be used both as an oracle during testing and as a supervisor during operation. Monitors should be based on the documented requirements of the system.If the target system is required to monitor or control real-valued quantities, then the requirements, which are expressed in terms of the monitored and controlled quantities, will allow a range of behaviors to account for errors and imprecision in observation and control of these quantities. Even if the controlled variables are discrete valued, the requirements must specify the timing tolerance. Because of the limitations of the devices used by the monitor to observe the environmental quantities, there is unavoidable potential for false reports, both negative and positive. This paper discusses design of monitors for real-time systems, and examines the conditions under which a monitor will produce false reports. We describe the conclusions that can be drawn when using a monitor to observe system behavior.

show abstract

Generating oracles from your favorite temporal logic specifications

Cited by 20 publications

References 11 publications

ActionScript bytecode verification with co-logic programming

ActionScript bytecode verification with co-logic programming

Designing and comparing automated test oracles for GUI-based software applications

Requirements-based monitors for real-time systems

Contact Info

Product

Resources

About