Current Research

You can find some of our research lines below. If you've got interested in any topic, do not hesitate in contact us and schedule a meeting.

Research Lines

Testing Process

Escaped Defect Analysis

We call escaped defects those bugs which could have been found by the Execution Team but ended up been found on a later testing phase or on the field. The main aim of this work is to reduce the escaped defects of the Execution Team. Preliminary studies have revealed the need for improvement in the way the data used on the analysis of escaped defects is being stored. The information is distributed over different systems and databases which are not yet integrated. We have also identified changes to the test selection process which may have an impact on the test coverage and, hopefully, on the escaped defects.

Contact: Renata Bezerra (

Test Case Prioritization

This work aims to increase the productivity of test execution by computing an ordered sequence of test cases that minimizes the execution effort and duration. This research extends previous work on test sequence generation by proposing different ordering criteria, different heuristics and the possibility of finding the perfect test sequence for a small number (around 15) of test cases. The reuse of test configuration and setup is used to calculate the best sequences. A prototype is under development in order to mechanize our approach.

Contact: Lucas Albertins (

Test Execution Effort and Capacity Estimation

The main goal of this research is the development and evaluation of test execution effort estimation models based on the specification of the test to be executed and testing cost drivers. For that, we defined a measure called execution points that measures the size and execution complexity of tests based on their specifications written in natural language. These specifications are automatically processed for calculating the execution points. Also, we study the creation of test execution capacity models based on execution points, test productivity, testing cost drivers and simulation techniques.

Contact: Eduardo Aranha (

Test Generation and Selection

Test Case Selection

Test case selection is a critical problem with no effective solution presented yet in the area of functional testing. Current solutions are based on structural strategies that have not been helpful to generate effective test suite, once that the number of possible test cases to be generated from the models is too big based on structural criteria. For functional testing, it is crucial to take semantical criteria into account.

Contact: Emanuela Gadelha (

Regression Test Selection

During regression tests, the re-execution of all test cases is generally economically unfeasible. You must therefore choose, within the universe of tests, a subset of those that are most appropriate to ensure the quality of software. The main purpose of this research is to define a method to support the selection of regression tests so that this selection defines a group of test cases more effectively. In this regard, some criteria for selection will be defined and a tool will be implemented to assist test architects to create test plans by selecting the best test cases according to the criteria defined.

Contact: Juliana Mafra (

Test Case Generation from Process Algebraic Models

This research aims at investigating the automatic test case generation from black-box systems specifications described in a formal notation named CSP (Communicating Sequential Processes). Restricting the observable behavior of the software to its input and outputs events, and some properties over the implementation under test (IUT), we define a test generation approach that mathematically guarantees the test cases generated from an input CSP specification of the system never refuse correct implementations (soundness). This strategy is implemented by the ATG (Abstract Test Generation) tool. We are working in an extension of this approach that: can extract the CSP model from use case specifications that contain, in addition to application flows described in natural language, embedded data elements (variables, constants and guards); and, generate test cases guided by the specification data. Other direction of this research is the mechanical verification for correctness of the IUT model (assuming there is an automatic way to obtain it) against the specification model, what is similar to an exhaustive testing. The verification capabilities of the FDR (Failures-Divergence Refinement) tool enable one to define several correctness criterion (implementation relations) as model checking problems verifiable by this tool.

Contact: Sidney Nogueira (

Modelling and Testing Interruptions in Reactive Systems

Reactive systems may be composed of a number of concurrent processes and network distributed services, where interruptions in a flow of execution can occur at any time. The possible number of combinations of allowed interruptions at different points of a flow of execution is huge. This makes the specification of each possibility unfeasible by using conventional notations and strategies. As a consequence and also due to the lack of a suitable test model, test case generation and selection is compromised. This work aims to develop a test model capable of representing interruptions. This model must focus on allowing interruptions specification to be defined and plugged at different points of execution of the interrupted model so that test cases can be effectively generated and selected.

Contact: Wilkerson Andrade (

Classification of Test Cases for Test Plan Creation

The classification has objective discover the knowledge that will allocate a new element in one of these existing classes (Boundary, Feature interaction, Negative, Stress, Performance),can use various rules to represent the knowledge such as rule of classification, tree decision-making, etc.), we will use the test cases to create a set that we can identify a class of words or Made Simple, pairs, or trio of words (terms), full sentences, part of phrases. At the end of this research we want to provide a tool to help architects of the test case to reduce its work in creating the plans of test cases.

Contact: Leonardo Lima (

Test Automation

Automated Stress Test Generation for Mobile Phone Applications

It is time-consuming and even difficult to stress test a mobile phone application. The first biggest concern is which specific parts of the phone are interesting areas to find defects (panics). Experts say that these areas are, commonly, the ones that already had a panic situation before, the ones with new features implemented in, and the ones known as instable areas. But it does not necessarily means that panics can only be found in those areas. For instance, they can be caused by simply repeating, a great number of times, some actions in a well-known stable area, one that has no history of detected defects. These repetitive actions can be done for over 30 hours or more, and sometimes no panics are found. In this context, with this research we intend to generate stress tests that exercise as much areas of the phone as possible and enable more panics to be encountered in a smaller amount of time.

Contact: Glaucia Peres (

Product Lines

Variability Management in Software Product Lines

Variability management is one common challenge for software product line (SPL) adoption. Specifically, the community needs for suitable mechanisms for describing or implementing each kind of variability that occurs at the different SPL models (such as requirement, architecture, implementation, and tests). This project aims to formalize the support for variability management offered by these models, in such way that will be possible to automatically derive variations from one model to another and improve traceability among them.

Contact: Rodrigo Bonifácio (

A DSL for Managing Software Product Line Variabilities

This research aims at defining a Domain Specific Language (DSL) for managing Software Product Line variabilities at source code. Many techniques to implement these variabilities are considered, such as Design Patterns, Property Files, Aspect-Oriented Programming (AOP), Conditional Compilation, and so forth. The DSL should help on evolving Product Lines due to the capability of changing those techniques easily through simple and straightforward statements provided by the language. This research will use TaRGeT as a case study.

Contact: Márcio Ribeiro (

Static Analysis of Configuration Knowledge

The construction and maintenance of a software product line (SPL) can be a really laborious task. Therefore, automated support for analyzing the models and artifacts that compose the product line must be provided, in order to avoid errors when generating products and enabling evolution of the SPL over time. This project aims to provide analysis for the models of a SPL, in order to generate sound products, according to the specification of the product line. This research will use TaRGeT as a case study, embedding SPL concepts in the test case generation process.

Contact: Leopoldo Teixeira (

Model Verification

An Approach to Apply Formal Verification to Aid Software Testing

Traditional software testing process uses requirement documents to generate system test cases. These are used to exercise the system under test (SUT); test cases represent a sampling of possible user interactions with the SUT. We propose an approach to use the high-level generated test cases to obtain formal characteristics about the SUT, like invariants, pre and post-conditions. Such properties can be obtained by existing tools, particularly Daikon. It is worth noting that the default use of Daikon is oriented towards unit tests rather than system tests. Therefore, we need a way to guide Daikon to explore units using system tests. From the information provided by Daikon, we intend to capture them as temporal properties, complement them, and use them in the model checker Java PathFinder. The key idea is to detect further situations not provided in the original use cases. For such situations where an exception is detected we intend to interact with the user to decide whether such an exception is really a bug or some incomplete specification. In the later case we also have as a goal to update the original use cases with this complementary information.

Contact: Cristiano Bertolini (

Topic revision: r6 - 2009-08-04 - EricaHori
This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

mersin escort bayan adana escort bayan izmit escort ankara escort bursa escort