Here a brief list of cool and challenging projects. For more details, contact us!
Robotic Testing
As promulgatd by Mark Harman, robotic testing is a new form of testing; a set of techniques where black box testing will really be black box testing!
Inspired by Ke Mao, Mark Harman and Yue Jia seminal work we started a new exciting research line. Our goal is to use robotics, computer vision, deep learning and search based software engineering to develop a new generation of fully automated black box testing approaches.
Android APP energy optimization
Nexus 4 Setup
Why is my cell phone battery already low? How did I use almost all the data of my monthly Internet plan? Is my recently released new application more efficient than similar competing applications? These are not easy questions to answer. Different Android applications implementing similar or identical functionalities may have different energy consumption and network usages. We have developed a setup and an approach aimed at precisely measuring app energy consumption. Our power consumption setup is based on a precise digital oscilloscope TiePie Handyscope HS5.
We use this device because it allows to measure using high frequencies and because it offers the LibTiePie SDK, which is a cross platform library for using TiePie engineering USB oscilloscopes through third party software. Between the power supply and the phone we connect, in series, a uCurrent7 device, which is a precision current adapter for multimeters converting the input current in a proportional output voltage. The resolution can be as high as 16 bits and the frequency up to 125kHz, therefore a measure is taken each eight microseconds.
With such a setup several research lines are possible. For example, define the most parsimonious set of apps or decide how to partition an app between client and server to maximize security but minimize energy consumption and data transfer.
Technical debt modeling and prediction
Help? No Thanks!
Technical Debt (TD) refers to portions of a software system that are, from different perspectives, not in the most suitable shape yet. Cunningham defines TD as “not quite right code which we postpone making it right”. TD could be code containing workaround, poorly structured or hard-to-read code, or even code that under some circumstances could turn out to be faulty.
Technical debt has been related to various life cycle activities and various software artifacts, e.e., requirements, design, code, test, or documentation. The challenge is: how can TD reliably be identified? How can we pin-point code sections worth annotating as TD?
