Developing student interest is critical to supporting student learning in computer science. Research indicates that student interest is a key predictor of persistence and achievement. While there is a growing body of work on developing computing identities for diverse students, little research focuses on early exposure to develop multilingual students’ interest in computing. These students represent one of the fastest growing populations in the US, yet they are dramatically underrepresented in computer science education. This study examines identity development of upper elementary multilingual students as they engage in a year-long computational thinking curriculum, and follows their engagement across multiple settings (i.e., school, club, home, community). Findings from pre- and post-surveys of identity showed significant differences favoring students’ experiences with computer science, their perceptions of computer science, their perceptions of themselves as computer scientists, and their family support for computer science. Findings from follow-up interviews and prior research suggest that tailored instruction provides opportunities for connections to out-of-school learning environments with friends and family that may shift students’ perceptions of their abilities to pursue computer science and persist when encountering challenges.

Collective impact is an approach for solving complex social problems at scale. The challenge of broadening participation in computing (BPC) is one such problem. The complexity of BPC is compounded by the decentralized nature of public education, where decisions are made primarily at the state level and subject to interpretation at the district level. As such, diversifying computer science (CS) pathways across the nation requires a systemic approach such as collective impact to engage all of the stakeholders who influence CS education and whose decisions can either facilitate or hinder BPC efforts. This experience report discusses how the collective impact framework has been used to advance the work of the Expanding Computing Education Pathways (ECEP) Alliance, an NSF funded BPC Alliance focused on states and state policy as the unit of change. We discuss how the five essential features of collective impact (common agenda, shared measurement, mutually reinforcing activities, continuous communication, and backbone support) coalesce to facilitate ECEP's theory of change. The report highlights specific policy changes that ECEP states have addressed to promote BPC, the flipped accountability that results from a non-hierarchical leadership model, and the challenges of measuring systemic changes as an intermediary to BPC.

In recent years, state members of the Expanding Computing Education Pathways (ECEP) Alliance have made efforts to increase access to and broaden participation in computing at the K-12 levels. Each ECEP state's K-12 computer science (CS) education journey has been documented during their ECEP membership resulting in over 25,000 digital documents. Over the course of the project it was necessary to track key events, identify trends across states, and maintain consumable records of state progress. A systematic way to collect and track the data is critical to conduct historical and cross-state analyses. In an effort to quantify and categorize, the researchers engaged in a review process of all ECEP reports, artifacts, and other relevant data to develop a system. Relevant and important components were identified in each type of document and assigned codes using ECEP's Five Stage Model ("a five-step process toward state-level CS education reform"), the Capacity, Access, Participation, and Experience (CAPE) framework (to measure equity in CS education implementation), and specific policies initiatives (alignment with various policy initiatives - Code.org's "Nine Policy Ideas to Make CS Fundamental to K?12 Education"). Indiana was identified as a state to conduct an initial, in-depth case study using this process. Indiana's case will be used as a model to further develop the stories of other ECEP Alliance member states. Through the development of a data dashboard, we hope to organize all of this information to make it more easily accessible for review and further analysis. The ECEP data dashboard development is currently in progress.

As reliance on technology increases in practically every aspect of life, all students deserve the opportunity to learn to think computationally from early in their educational experience. To support the kinds of computer science curriculum and instruction that makes this possible, there is an urgent need to develop and validate computational thinking (CT) assessments for elementary-aged students. We developed the Assessment of Computing for Elementary Students (ACES) to measure the CT concepts of loops and sequences for students in grades 3-5. The ACES includes block-based coding questions as well as non-programming, Bebras-style questions. We conducted cognitive interviews to understand student perspectives while taking the ACES. We piloted the assessment with 57 4th grade students who had completed a CT curriculum. Preliminary analyses indicate acceptable reliability and appropriate difficulty and discrimination among assessment items. The significance of this paper is to present a new CT measure for upper elementary students and to share its intentional development process.

There are over 1,000 community colleges (CC) in the U.S.; they enroll more than 13 million students--nearly half of all undergraduates-- and over half of CC students are non-white (American Association of Community Colleges). However, efforts to broaden participation in computing have been directed disproportionately to 4-year institutions. The focus of this panel is on research and strategies for increasing the retention of students from groups that are underrepresented in computing--female, Latinx, and African American students. It includes experts from across the US--from CC's and a research organization. The panelists will describe curriculum and programs that are designed to support students, and include the perspectives of students on what helps and hinders them from persisting. The intended audience for this panel is researchers, educators, and administrators from both community colleges and 4-year institutions.

Effective and equitable CS teaching is contingent on teachers’ robust understanding of equity issues in CS classrooms. To this end, this study examined high school teachers’ perceptions of equity during their participation in a CS teacher certificate program over two years. The participants are from various disciplines and from schools that serve under-represented students. Using a qualitative approach, we conducted content analysis of the teachers’ written reflections and responses to semi-structured interviews. Based on the justice-centered framework, we analyzed the major themes that emerged from the content analysis. The findings provide insights into high school CS teachers’ understanding of equity, the strategies that teachers use to address equity issues, and how teachers interpret the causes of inequities in CS classrooms. This research presents frameworks for examining teachers’ conceptualizations of equity and can inform the implementation of future professional development programs for CS teachers.

Self-efficacy is an important construct for CS teachers’ professional development, because it can predict both teaching behaviors as well as student outcomes. Research has shown that teachers’ self-efficacy can be as influential as their actual level of knowledge and abilities. However, there has been very limited research on CS teachers’ self-efficacy. This study describes the development and implementation of an instrument that measures secondary school teachers’ self-efficacy in teaching computer science. Teachers attended a nine-week hybrid professional development program and completed the computer science teaching self-efficacy instrument. Confirmatory factor analysis validated the self-efficacy instrument, which can be potentially used in other CS education settings. The results also indicated that teachers’ self-efficacy in the content knowledge and pedagogical content knowledge dimensions of teaching computer science significantly increased from participating in the professional development program.

Background/Context: The objective of achieving higher sustainability in our lifestyles by information and communication technology has lead to a plethora of research activities in related fields. Consequently, Software Engineering for Sustainability (SE4S) has developed as an active area of research. Objective/Aim: Though SE4S gained much attention over the past few years and has resulted in a number of contributions, there is only one rigorous survey of the field. We follow up on this systematic mapping study from 2012 with a more in-depth overview of the status of research, as most work has been conducted in the last 4 years. Method: The applied method is a systematic mapping study through which we investigate which contributions were made, which knowledge areas are most explored, and which research type facets have been used, to distill a common understanding of the state-of-the-art in SE4S. Results: We contribute an overview of current research topics and trends, and their distribution according to the research type facet and the application domains. Furthermore, we aggregate the topics into clusters and list proposed and used methods, frameworks, and tools. Conclusion: The research map shows that impact currently is limited to few knowledge areas and there is need for a future roadmap to fill the gaps.

A body of knowledge is a term used to represent the complete set of concepts, terms and activities that make up a professional domain. It encompasses the core teachings, skills and research in a field or industry. So far, the discipline of RE is lacking an official Requirements Engineering Body of Knowledge (REBoK). This working session brings together researchers and practitioners to elaborate the goals, requirements and constraints for a REBoK that shall serve as commonly agreed basis for developing a draft over the following months.

Widespread adoption of model-centric development has created opportunities for software testing, with Model-Based Testing (MBT). MBT supports the generation of test cases from models and the demonstration of model and source-code compliance. Models evolve, much like source code. Thus, an important activity of MBT is selective regression testing, which selects test cases for retest based on model modifications, rather than source-code modifications. This activity explores relationships between model elements and test cases that traverse those elements to locate retest able test cases. We contribute an approach and prototype to model-based selective regression testing, whereby fine-grain traceability relationships among entities in models and test cases are persisted into a traceability infrastructure throughout the test generation process: the relationships represent reasons for test case creation and are used to select test cases for re-run. The approach builds upon existing regression test selection techniques and adopts scenarios as behavioral modeling perspective. We analyze precision, efficiency and safety of the approach through case studies and through theoretical and intuitive reasoning.

Proper testing is an essential and critical part of any development effort. However, software testing is a complex undertaking, especially in the midst of today's security threats. Hackers, social engineering scams, and unaware users, are just a few potential threats that developers must consider not only during development, but more importantly during testing. There are significant reputation and financial losses related to security aspects that could have been addressed during requirements specification. While a variety of approaches to security requirements specification have been proposed, there is a tangible lack in the support that they offer during testing. In this paper we describe the tool support of a new security requirements engineering technique called SURE-Secure and Usable Requirements Engineering. ASSURE - Automated Support for Secure and Usable Requirements Engineering -, is a system developed to aid in the mapping of security requirements into testing artifacts. This support goes beyond mapping and aids also in the management of users and projects.

A significant focus in the United States recently has been to increase engagement and interest in STEM curricula, particularly among girls and underrepresented minorities [3]. In this work, we take an approach to teaching and learning that supports flexibility, experimentation, and play with technology. With this approach, we aim to make STEM curricula more comfortable and engaging for all types of children and teens, with a particular emphasis on lower socio-economic status female students. We designed and tested a computing course for middle school girls, and this work resulted in three best practices: hands-on work incorporating creativity through crafts into engineering and computing, the frequent presence of an audience to motivate engagement, and engineering-focused individual roles structuring group work. Pre- and post-surveys and exit interviews revealed significant changes in attitudes and an enthusiasm for engineering projects and careers as a result of participation in the course.

Requirements specification is an important problem in software engineering. Key challenges in Requirements Engineering (RE) include enabling different stakeholders to understand and validate the requirements, and enabling collaboration among different types of stakeholders with different skills and expertise and potentially conflicting needs and expectations. We contend that collaboration among both technical and non-technical stakeholders is improved by a requirements specification technique that provides both precision and usability - and a better balance of the two. We implement our specification technique in iMuse - Interactive Model-based Use-case and Storytelling Environment. In this demo, we show how iMuse can be used by stakeholders to express and view narrative functional requirements.

Throughout their life cycle, software artifacts are modified, and selective regression testing is used to identify the negative impact of modifications. Code-based regression test selection retests test cases sub-set that traverse code modifications. It uses recovered relationships between code parts and test cases that traverse them to locate test cases for retest when code is modified. Broad adoption of model-centric development has created opportunities for software testing. It enabled driving testing processes at higher abstraction levels and demonstrating code to model compliance by means of Model-Based Testing (MBT). Models also evolve, so an important activity of MBT is selective regression testing. It selects test cases for retest based on model modification, so it relies on relationships between model elements and test cases that traverse those elements to locate test cases for retest. We contribute an approach and prototype that during test case generation creates fine-grained traceability relationships between model elements and test cases, which are used to support model-based regression test selection.

Typical software systems in financial firms are message- based server-side systems , the regression testing of which is currently done through a 'log- replay' mechanism. As the production volumes are large and continue to grow rapidly, this approach leads to many problems such as scalability, resource crunch, reconciliation, redundancy, production impact. The approach in this paper continues to use the production log as the basis for regression testing. However, it deviates from the current approach in not using the entire production log but only a subset or sample of it.This approach has been implemented for regression testing of production systems in a major financial firm. The result was that the number of test cases executed converged to a small fraction of the number previously being executed, while still retaining a high degree of confidence in the code- coverage quality of the selected sample.

As technology continues to evolve, so do different entities that threaten the security of this technology. We believe that in order to build dependable software security should be treated just as any other important aspect of a system; to do this we must emphasize it at the beginning of our development cycle and be able to carry these security requirements down the cycle. We focus on a technique known as the Common Criteria, which allows for the development of security requirements. We extend the capabilities of Common Criteria beyond the requirements phase, to allow us to take security requirements into further stages of the cycle. In this paper we describe CCARCH, a technique accompanied by a set of tools, that takes Common Criteria expressed security requirements to the architectural level. Our approach aids in making the usage of Common Criteria more beneficial and applicable.

Model-driven development is leading to increased use of models in conjunction with source code in software testing. Model-based testing, however, introduces new challenges for testing activities, which include creation and maintenance of traceability information among test-related artifacts. Traceability is required to support activities such as selective regression testing. In fact, most model-based testing automated approaches often concentrate on the test generation and execution activities, while support to other activities is limited (e.g. model-based selective regression testing, coverage analysis and behavioral result evaluation)

The adoption of model-driven development is leading to increased use of models in conjunction with source code in software testing. Model-based testing, however, introduces new challenges for testing activities, which include creation and maintenance of traceability information among test-related artifacts. Traceability is required to support activities such as model-based result evaluation, regression testing and coverage analysis. In this paper, we present an automated approach that leverages model transformation techniques to support test generation. The test generation process includes creation of test-related models and fine-grained relationships among these models. We also motivate our approach with a simple example demonstrating support for model-based regression testing

The need to manually specify temporal properties of software systems is a major barrier to wider adoption of software model checking, because the specification of software temporal properties is a difficult, time-consuming, and error-prone process. To address this problem, we propose to automatically extract software library usage rules, which are one type of temporal specifications. Our approach uses a model checker to check a set of software library usage rule candidates against known good programs using that library, and identifies valid rules based on model checking results. These valid rules can help programmers learn about common software library usage. They can also be used to check new programs using the same library. We have implemented our approach in an Eclipse plug-in named LtRules, which can extract software library usage rules from C programs using BLAST as the underlying model checker.

The need to manually specify temporal properties of software systems is a major barrier to wider adoption of software model checking, because the specification of software temporal properties is a difficult, time-consuming, and error-prone process. To address this problem, we propose to automatically extract software library usage patterns, which are one type of temporal specifications. Our approach uses a model checker to check a set of software library usage pattern candidates against existing programs using that library, and identifies valid patterns based on model checking results. These valid patterns can help programmers learn about common software library usage. They can also be used to check new programs using the same library. We applied our approach to C programs using the OpenSSL library and the C standard library, and extracted valid usage patterns using BLAST. We also successfully used the extracted valid usage patterns to detect an error in an open source project hosted by SourceForge.net

This paper presents a specification-based approach that addresses several known challenges including false positives and domain knowledge errors. Our approach begins with a goal graph and plans. Source code is annotated with goals and events and precompiled to emit those at run time. Plans are automatically translated into a rule-based recognizer. An oracle is produced from the pre- and postconditions associated with the plan's goals. When the program is executed, goals and events are emitted and automatically tested against plans and oracles. The concept is demonstrated on a small example and a larger publicly available case study

Two main issues need to be covered when dealing with the dependability of component-based systems: quality assurance of reusable software components and quality assurance of the assembled component-based system. By focussing on the assembly, a software architecture specification of a component-based system allows to explicitly model the structure and required system behavior by specifying how components and connectors are intended to interact. Software architecture-based conformance testing techniques can yield confidence on the implementation conformance to expected structural and behavioral properties as specified in the architectural models. In this paper we explore software architecture-based regression testing methods that enable reuse of earlier saved results to test if a different assembly of components conforms to the evolved software architecture. The approach is presented through a running example.

Provides an abstract of the keynote presentation and a brief professional biography of the presenter. The complete presentation was not made available for publication as part of the conference proceedings.

Software engineering (SE) is very different in focus from traditional computer science: it is not just about computers and software, but as much about the context in which they are used. This means we must teach about software and information, development and design, technical and social issues, while creating solutions as well as understanding and analyzing them. In effect, we must teach a discipline broader than SE or CS alone for SE education to be effective. At UC Irvine, we designed and now offer a program doing just this -- a four-year B.S. degree in Informatics. The major brings topics in SE together with human-computer interaction, computer-supported collaborative work, social analysis, and management, along with other application disciplines. Here, we discuss the philosophy behind the major, its structure, and the questions concerning SE education that the new major raises.

In this poster we describe the diversification of our undergraduate curricula in the computing disciplines at UC Irvine, in particular the creation of Bachelor of Science degree in Informatics.

Because the field of computer science has broadened so much in recent years, traditional degree programs are becoming crowded with new courses, each introducing its own "essential" topic. However, with more and more such courses, it is no longer possible to cover every topic in a single, coherent, four-year program. Many alternative approaches are available to address this situation. At UC Irvine, we have chosen a solution in which we offer four coordinated degree programs: a B.S. in Computer Science & Engineering, a conventional B.S. in Computer Science, a new B.S. in Informatics, and a broad overview B.S. in Information and Computer Science. Of these, the B.S. in Informatics is the most innovative, focusing on software and information design. Context plays a particularly strong role in our B.S. in Informatics: Placing software development in context is critical to the delivery of successful solutions, and we educate our students accordingly. We present our definition of informatics, detail our curriculum, describe its pedagogical characteristics and objectives, and conclude with some critical observations regarding informatics and its place in computer science education.

During software maintenance, regression testing is an expensive but critical activity to ensure that modified versions of the system do not "regress". As software evolves, chances are that not only the implementation changes, but that the specification of the system changes too. We argue that guiding regression testing by the system specifications generated early in the software lifecycle will be more accurate than extracting specification from source code, and more cost effective. Model checking is used to reason about the truth of statements about the system specification. We use a model checker as part of a highly automated regression test generation tool, providing a practical approach to specification based regression testing. Features of our approach that support different specification description languages and different test coverage criteria are also presented.

The technology of redundant arrays of independent components (RAIC) uses groups of similar or identical distributed components to provide dependable services (Liu and Richardson, 2002). RAIC allows components in the redundant array to be added or removed dynamically during run-time. This paper gives a brief overview of RAIC and discusses its special application for dependable on-line upgrading of distributed systems. A proof-of-concept example is given to illustrate how problems that occur during upgrading can be masked by RAIC and thus not affect smooth operations of the system-under-upgrade.

Concurrent event-based components present characteristics that impose difficulties in understanding their dynamic behavior, mainly for interpreting the cause and effect relations between input and output events in component interactions. In this paper, we propose a technique to help in the process of understanding the dynamic behavior of concurrent event-based components. It checks the event trace (generated by monitoring the component execution) against a specification of the component communication protocol (even with a possibly incomplete or incorrect specification). The technique identifies and presents the more probable cause and effect relations between the component events, providing also a measurement related to this probability.

Component-based development has become an important area in the software engineering field. In spite of this, there has been little effort to understand and to manage the different forms of dependencies that can occur in systems built from components. Dependencies reflect the potential for one component to affect or be affected by the elements (e.g., other components) that compose the system. Understanding dependencies is an essential requirement to perform important tasks, such as evolution and testing, during a component-based system's life cycle. In this paper, we present a technique to analyze dependencies in large component-based systems.

Algorithmic cost estimation in the context of software evolution is being addressed as part of the FEAST/2 project with encouraging results from an industrial case study.

This formal research demonstration attempts to present an approach to develop and assess architecture and component-based systems based on specifying software architecture augmented by statecharts representing component behavioral specifications [1]. The approach is applied for the C2 style [2] and associated ADL and is supported within a quality-focussed environment, called Argus-I, which assists specification-based analysis and testing at both the component and architecture levels.

In many computer system security incidents, attackers successfully intruded computer systems by exploiting known weaknesses. Those computer systems remained vulnerable even after the vulnerabilities were known because it requires constant attention to stay on top of security updates. It is often both time-consuming and error-prone to manually apply security patches to deployed systems. To solve this problem, we propose to develop a framework for automated security checking and patching. The framework, named Securibot, provides a self-operating mechanism for security checking and patching. Securibot performs security testing using security profiles and security updates. It can also detect compromised systems using attack signatures. Most important, the Securibot framework allows system vendors to publish recently discovered security weaknesses and new patches in a machine-readable form so that the Securibot system running on deployed systems can automatically check out security updates and apply the patches.

Impediments to software quality are exacerbated when applications-under-test are developed using component-based software engineering. Component misuse is one such impediment. Component misuse occurs when a component is used in a way that differs from the component producer's expectation. This paper explores the cause of the component misuse problem and proposes a technique to discover, specify, and verify component usage. This technique utilizes regular expressions as the formalism to deal with component usage. This research is part of the software retrospector effort, which aims at a better approach to software analysis and testing for component-based software.

Siddhartha applies the domain-specific language (DSL) paradigm to solve difficult problems in specification-based testing (SBT). Domain-specific test case data specifications (TestSpecs) and difficult-to-test program design styles engender difficult SBT problems, which are the essential phenomena of interest to Siddhartha. Difficult-to-test program design styles are explicitly represented by domain-specific, unit test driver reference designs that accommodate the problematic program design styles. DSLs are developed to represent both TestSpecs and Driver reference designs. A DSL language processing tool (a translator) is developed that maps TestSpecs into Drivers. We developed a prototype implementation of Siddhartha via Reasoning SDK (formerly known as Software Refinery) and developed two domain-specific TestSpec/spl rarr/Driver translators. Each translator generated Drivers that revealed new failures in a real-world digital flight control application program.

No abstract available.

Specification-based testing is important because it relates directly to what the program is supposed to do and can detect certain errors that are often not detected by traditional code-based testing techniques such as branch coverage and statement coverage. We have developed an automated testing tool, called ADLscope, that utilizes the formal specification of a program unit as the basis for test coverage measurement. A tester uses ADLscope to test application programming interfaces (APIs) written in the C programming language. The API must be formally specified in the Assertion Definition Language (ADL). The tester uses ADLscope to generate coverage conditions from a program's ADL specifications. When the API is tested, ADLscope automatically measures how many of the coverage conditions have been covered by the tests.

Describes a system that improves testing quality by supporting automatic test data selection, execution and result verification. The system tests poorly-encapsulated Ada units against formal specifications. This task is difficult partly because the unit's interface is not explicit, but rather is buried in the body/implementation code. We attack this problem by making the unit's interface explicit and complete. This is accomplished via automatic and manual analysis of the body. The complete interface is represented using an extended algebraic signature notation. Once the signature has been discovered, it can be reformulated so that a collection of well-defined, static mappings are established between it and the signature of the unit's formal specification. These mappings guide the development of test artifact transformers and oracles, which support automatic test data selection, execution and result verification. This paper discusses problems that arise as a result of testing under low encapsulation, discusses our solution using an ongoing example, and compares our solution to earlier solutions.

The lifetime of many software systems is surprisingly long, often far exceeding initial plans and expectations. During software evolution and maintenance, developers and managers frequently gain or lose confidence in software artifacts, especially when existing uncertainties are relieved or new ones are encountered. Fluctuations in developers' confidences may in turn affect process actions or decisions, e.g. in determining the impact of change, whether regression testing is needed or when to stop testing. We present an approach that allows developers' confidences or “beliefs” regarding software components to be modeled and updated directly. This approach is part of an overall strategy that calls for explicit modeling of software uncertainties using the technique called Bayesian belief networks. Initially, we present several kinds of software uncertainty and how they may be modeled. This is followed by introducing Bayesian belief networks and how they may be used to either confirm, evaluate or predict software uncertainties. We discuss our experiences in constructing Bayesian-network models for an existing software system under development at Beckman Instruments. Once constructed, these models may be used by developers and managers in future software understanding, evolution and maintenance activities. We also list several factors that may affect confidence as identified in conjunction with the Beckman study. Finally, we describe the design and implementation of a Java program that allows software systems and associated beliefs to be modeled explicitly

This paper describes a specification-based black-box technique for testing program units. The main contribution is the method that we have developed to derive test conditions, which are descriptions of test cases, from the formal specification of each program unit. The derived test conditions are used to guide test selection and to measure comprehensiveness of existing test suites. Our technique complements traditional code-based techniques such as statement coverage and branch coverage. It allows the tester to quickly develop a black-box test suite.In particular, this paper presents techniques for deriving test conditions from specifications written in the Assertion Definition Language (ADL) [SH94], a predicate logic-based language that is used to describe the relationships between inputs and outputs of a program unit. Our technique is fully automatable, and we are currently implementing a tool based on the techniques presented in this paper.

Few would question that software testing is a necessary activity for assuring software quality, yet the typical testing process is a human intensive activity and as such, it is unproductive, error-prone, and often inadequately done. Moreover, testing is seldom given a prominent place in software development or maintenance processes, nor is it an integral part of them. Major productivity and quality enhancements can be achieved by automating the testing process through tool development and use and effectively incorporating it with development and maintenance processes.

RELAY is a model of how a fault causes a failure on execution of some test datum. This process begins with introduction of an original state potential failure at a fault location and continues as the potential failure(s) transfers to output. Here we describe the second stage of this process, transfer of an incorrect intermediate state from a faulty statement to output.

RELAY is a model of faults and failures that defines failure conditions, which describe test data for which execution will guarantee that a fault originates erroneous behavior that also transfers through computations and information flow until a failure is revealed. This model of fault detection provides a framework within which other testing criteria's capabilities can be evaluated. Three test data selection criteria that detect faults in six fault classes are analyzed. This analysis shows that none of these criteria is capable of guaranteeing detection for these fault classes and points out two major weaknesses of these criteria. The first weakness is that the criteria do not consider the potential unsatisfiability of their rules. Each criterion includes rules that are sufficient to cause potential failures for some fault classes, yet when such rules are unsatisfiable, many faults may remain undetected. Their second weakness is failure to integrate their proposed rules.>

Article Specification-based test oracles for reactive systems Share on Authors: Debra J. Richardson View Profile , Stephanie Leif Aha View Profile , T. Owen O'Malley View Profile Authors Info & Claims ICSE '92: Proceedings of the 14th international conference on Software engineeringJune 1992 Pages 105–118https://doi.org/10.1145/143062.143100Online:01 June 1992Publication History 114citation1,378DownloadsMetricsTotal Citations114Total Downloads1,378Last 12 Months18Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

The authors report on the results of their evaluation of path-selection criteria based on data-flow relationships. They show how these criteria relate to each other, thereby demonstrating some of their strengths and weaknesses. A subsumption hierarchy showing their relationship is presented. It is shown that one of the major weaknesses of all the criteria is that they are based solely on syntactic information and do not consider semantic issues such as infeasible paths. The authors discuss the infeasible-path problem as well as other issues that must be considered in order to evaluate these criteria more meaningfully and to formulate a more effective path-selection criterion.>

The partition analysis method compares a procedure's implementation to its specification, both to verify consistency between the two and to derive test data. Unlike most verification methods, partition analysis is applicable to a number of different types of specification languages, including both procedural and nonprocedural languages. It is thus applicable to high-level descriptions as well as to low-level designs. Partition analysis also improves upon existing testing criteria. These criteria usually consider only the implementation, but partition analysis selects test data that exercise both a procedure's intended behavior (as described in the specifications) and the structure of its implementation. To accomplish these goals, partition analysis divides or partitions a procedure's domain into subdomains in which all elements of each subdomain are treated uniformly by the specification and processed uniformly by the implementation. This partition divides the procedure domain into more manageable units. Information related to each subdomain is used to guide in the selection of test data and to verify consistency between the specification and the implementation. Moreover, the testing and verification processes are designed to enhance each other. Initial experimentation has shown that through the integration of testing and verification, as well as through the use of information derived from both the implementation and the specification, the partition analysis method is effective for evaluating program reliability. This paper describes the partition analysis method and reports the results obtained from an evaluation of its effectiveness.

White and Cohen have proposed the domain testing method, which attempts to uncover errors in a path domain by selecting test data on and near the boundary of the path domain. The goal of domain testing is to demonstrate that the boundary is correct within an acceptable error bound. Domain testing is intuitively appealing in that it provides a method for satisfying the often suggested guideline that boundary conditions should be tested.