524 research outputs found
Property-Based Testing - The ProTest Project
The ProTest project is an FP7 STREP on property based testing. The purpose of the project is to develop software engineering approaches to improve reliability of service-oriented networks; support fault-finding and diagnosis based on specified properties of the system. And to do so we will build automated tools that will generate and run tests, monitor execution at run-time, and log events for analysis.
The Erlang / Open Telecom Platform has been chosen as our initial implementation vehicle due to its robustness and reliability within the telecoms sector. It is noted for its success in the ATM telecoms switches by Ericsson, one of the project partners, as well as for multiple other uses such as in facebook, yahoo etc. In this paper we provide an overview of the project goals, as well as detailing initial progress in developing property based testing techniques and tools for the concurrent functional programming language Erlang
From Temporal Models to Property-Based Testing
This paper presents a framework to apply property-based testing (PBT) on top
of temporal formal models. The aim of this work is to help software engineers
to understand temporal models that are presented formally and to make use of
the advantages of formal methods: the core time-based constructs of a formal
method are schematically translated to the BeSpaceD extension of the Scala
programming language. This allows us to have an executable Scala code that
corresponds to the formal model, as well as to perform PBT of the models
functionality. To model temporal properties of the systems, in the current work
we focus on two formal languages, TLA+ and FocusST.Comment: Preprint. Accepted to the 12th International Conference on Evaluation
of Novel Approaches to Software Engineering (ENASE 2017). Final version
published by SCITEPRESS, http://www.scitepress.or
Towards property-based testing of RESTful web services
Developing APIs as Web Services over HTTP implies adding an extra layer to software, compared to the ones that we would need to develop an API distributed as, for example, a library. This additional layer must be included in testing too, but this implies that the software under test has an additional complexity due both to the need to use an intermediate protocol in tests and to the need to test compliance with the constraints imposed by that protocol: in this case the constraints defined by the REST architectural style. On the other hand, these requirements are common to all the Web Services, and because of that, we should be able to abstract this aspect of the testing model so that we can reuse it in testing any Web Service. In this paper, as a first step towards automating the testing of Web Services over HTTP, we describe a practical mechanism and model for testing RESTful Web Services without side effects and give an example of how we successfully adapted that mechanism to test two different existing Web Services: Storage Room by Thriventures and Google Tasks by Google. For this task we have used Erlang together with state machine models in the property-based testing tool Quviq QuickCheck, implemented using the statem module. 1
Automating property-based testing of evolving web services
Web services are the most widely used service technology that drives the Service-Oriented Computing~(SOC) paradigm. As a result, effective testing of web services is getting increasingly important. In this paper, we present a framework and toolset for testing web services and for evolving test code in sync with the evolution of web services. Our approach to testing web services is based on the Erlang programming language and QuviQ QuickCheck, a property-based testing tool written in Erlang, and our support for test code evolution is added to Wrangler, the Erlang refactoring tool.
The key components of our system include the automatic generation of initial test code, the inference of web service interface changes between versions, the provision of a number of domain specific refactorings and the automatic generation of refactoring scripts for evolving the test code. Our framework provides users with a powerful and expressive web service testing framework, while minimising users' effort in creating, maintaining and evolving the test model. The framework presented in this paper can be used by both web service providers and consumers, and can be used to test web services written in whatever language; the approach advocated here could also be adopted in other property-based testing frameworks and refactoring tools
Narrowing in on property-based testing
Narrowing is one of the primary methods for implementing functional logic programming languages. Property-based testing is an automatic approach to assuring the correctness of software systems. In recent years, a number of systems have been developed that seek to apply the benefits of narrowing in the area of property-based testing. This thesis considers two limitations with these systems. First of all, most of the existing narrowing-based testing tools have focused on practical issues, and lack supporting theory. And secondly, these tools typically only perform well on properties that have particular forms. We address these limitations by developing an approach to narrowing that is both practical and principled, and demonstrate how this can be used to expand the range of properties that can be automatically tested using a narrowing-based approach
Property-based testing for the robot operating system
The Robot Operating System (ROS) is an open source framework for the development of robotic software, in which a typical system consists of multiple processes communicating under a publisher-subscriber architecture. A great deal of development time goes into orchestration and making sure that the communication interfaces comply with the expected contracts (e.g. receiving a message leads to the publication of another message). Orchestration mistakes are only detected during runtime, stressing the importance of component and integration testing in the verification process. Property-based Testing is fitting in this context, since it is based on the specification of contracts and treats tested components as black boxes, but there is no support for it in ROS. In this paper, we present a first approach towards automatic generation of test scripts for property-based testing of various configurations of a ROS system.The authors would like to thank the anonymous referees for their valuable comments and helpful suggestions. This work is financed by the ERDF – European Regional Development Fund through the Operational Programme for Competitiveness and Internationalisation - COMPETE 2020 Programme and by National Funds through the Portuguese funding agency, FCT - Fundação para a Ciência e a Tecnologia within project PTDC/CCI-INF/29583/2017 (POCI-01-0145-FEDER-029583)
Testing Graphical User Interfaces with Property-Based Testing
Before a software product is released, it has to be verified that the product works as it should.
Graphical User Interfaces (GUI) need to be tested like any other software products.
The purpose of testing GUIs is to detect defects but also unexpected behaviour of a GUI.
In 2000 John Hughes and Koen Claessen introduced a new software testing technique: \textit{Property-Based Testing}
(PBT). In this testing technique the functionality of the system under the test is defined as properties.
Properties are like rules
for the features under test. A property defines a relation between input and output that should always
hold for all inputs. A property is tested by generating a large number of inputs for which the property is tested.
The goal of this thesis is to explore if PBT is applicable to UI testing. We formulate properties that describe the rules
that a GUI should follow, then apply PBT and investigate whether defects could be exposed this way. We also explore whether
PBT solves any of the challenges of UI testing, in particular whether test coverage can be increased by using PBT.
As its results, this thesis shows that PBT can be applied in GUI testing and that there are defect classes that
might not be detectable by traditional testing methods, but can be found using PBT
- …