Course Number:
CMSC737.
Meeting
Times: Tue.
Thu. - 8:00AM - 9:15AM (CSIC
1121).
Office Hours:
Tue. Thu. - 9:15AM - 11:00AM
(4115 A. V. Williams Building) Other meetings may be scheduled individually and
held over Skype and Phone.
Catalog
Course Description: This course will examine
fundamental software testing and related program analysis techniques. In
particular, the important phases of testing will be reviewed, emphasizing the
significance of each phase when testing different types of software. The course
will also include concepts such as test generation, test oracles, test
coverage, regression testing, mutation testing, program analysis (e.g.,
program-flow and data-flow analysis), and test prioritization.
Course
Summary: This course will examine fundamental
software testing and program analysis techniques. In particular, the important
phases of testing will be reviewed, emphasizing the significance of each phase
when testing different types of software. Students will learn the state of the
art in testing technology for object-oriented, component-based, concurrent,
distributed, graphical-user interface, and web software. In addition, closely
related concepts such as mutation testing and program analysis (e.g.,
program-flow and data-flow analysis) will also be studied. Emerging concepts
such as test-case prioritization and their impact on testing will be examined.
Students will gain hands-on testing/analysis experience via a multi-phase
course project. By the end of this course, students should be familiar with the
state-of-the-art in software testing. Students should also be aware of the
major open research problems in testing.
The grade of
the course will be determined as follows: 10% midterm exam 1, 10% midterm exam
2, 5% presentation, 25% final exam, 50% class project.
Credits:
3
Prerequisites:
Software engineering CMSC435 or equivalent.
Status with
respect to graduate program: MS qualifying course (Midterms
+ Final exam), PhD core (Software Engineering).
Student
Presentations: All students are required to present
a topic related to software testing. You must prepare slides and select a date
for your presentation. Group presentations are encouraged if the selected topic
is broad enough.
Syllabus:
The following topics will be discussed (this list is tentative and
subject to change).
o
Ray
Chen; On DynInst.
o
Robert
Gove; Mobile usability testing; SOURCES:
·
Henry Been-Lirn Duh, Gerald C. B. Tan,
and Vivian Hsueh-hua Chen. Usability evaluation for
mobile device: a comparison of laboratory and eld
tests. In MobileHCI '06: Proceedings of the 8th
conference on Human-computer interaction with mobile devices and services,
pages 181-186, New York, NY, USA, 2006. ACM.
·
Christian Monrad Nielsen, Michael
Overgaard, Michael Bach Pedersen, Jan Stage, and Sigge
Stenild. It's worth the hassle!:
the added value of evaluating the usability of mobile systems in the eld. In NordiCHI '06: Proceedings
of the 4th Nordic conference on Human-computer interaction, pages 272-280, New
York, NY, USA, 2006. ACM.
·
Henry Been-Lirn Duh, Gerald C. B.
Tan, and Vivian Hsueh-hua Chen. Usability evaluation
for mobile device: a comparison of laboratory and eld
tests. In MobileHCI '06: Proceedings of the 8th
conference on Human-computer interaction with mobile devices and services,
pages 181-186, New York, NY, USA, 2006. ACM.
·
Rudy Schusteritsch, Carolyn Y.Wei, and Mark LaRosa. Towards
the perfect infrastructure for usability testing on mobile devices. In CHI '07:
CHI '07 extended abstracts on Human factors in computing systems, pages
1839-1844, New York, NY, USA, 2007. ACM.
o Christoph Schulze;
Web Testing; SOURCES: From formal requirements to
automated web testing and prototyping, Ernesto Cid Brasil
de Matos and Thiago C. Sousa, From
the issue entitled "Special Issue ICFEM'09".
GUI Test Reduction with SVMs and Induced Grammars
Jorge Faytong
and Robert Gove
Model-based GUI software testing is
an emerging paradigm for automatically generating test suites. In the context of
GUIs, a test case is a sequence of events to be executed which may detect
faults in the application. However, a test case may be infeasible if one or
more of the events in the event sequence are disabled or made inaccessible by a
previously executed event (e.g. a button may be disabled until another GUI
widget enables it). These infeasible test cases are less likely to detect
faults, so software testers would like to modify the test suite execution to
run only feasible test cases. Current techniques focus on repairing the test
cases to make them feasible, but this relies on executing all test cases,
attempting to repair the test cases, and then repeating this process until a
stopping condition has been met. We propose avoiding infeasible test cases altogether.
We demonstrate the success of two supervised learning methods (support vector
machines (SVMs) and grammar induction) for classifying infeasible test cases
which can then be removed from the current queue of test cases in the test
suite.
Network Measures and GUI testing
Ethar
Ibrahim
In this project, I study the
correlation between the event ranking that results
from applying some network measures on the EFG and the occurrence of these
events in various types of test suites. The network measures chosen for this
study are Betweenness Centrality and Degree
Centrality measures. The types of test suites chosen are SequenceLengthCoverage,
and CoverAllEvents. This study will help us later in
GUI test case prioritization, GUI maintenance, and GUI regression testing.
Investigating the Dyninst Test
Suite
Ray Chen
The test suite for Dyninst consists of over 23K unique test cases. I will present comparisons of these test
cases based on information gathered from coverage analysis.
Automated test case generation for Web-Testing
Christoph
SChulze
The goal of the project was the
implementation and evaluation of an approach that can automatically generate
test-cases for web testing. The approach generates test-cases by executing a
state machine model of the system. Execution of the state machine yields
high-level test-cases that have no direct relationship to the test subject. In
order to get executable Selenium tests a mapping between the transitions of the
state machine and Selenium/NUnit had to be established.
A self-programmed website was used to evaluate the quality of the approach.
Utilizing symbolic execution for
test case generation for C Preprocessor's programs
Raul Guerra, Vassilios
Lekakis, Khoa Doan (rguerra,lex,khoadoan@cs.umd.edu)
Symbolic analysis is a well known
software testing technique that appeared for the first time in the early 70's.
It is known that its major drawback is the exponential growth of path condition
due to the number of paths that need to be checked in order for the final test
cases to be generated. However, research approaches have shown that with the
use of heuristics like path size reduction techniques make symbolic execution
appealing even for today's big and complex programs.
In our project for the software
testing class we decided to apply symbolic execution on C preprocessor's
programs. The preprocessor is a separate program that is being invoked from the
C compiler. Despite the fact that a lot of research effort has focused on the
core parts of C programs, not many have included the preprocessor directives on
their analysis. We believe that the small size of the C preprocessor directives
along with the path reduction techniques make symbolic execution appealing for
the test case generation in this environment. Latendresse's
work [1] is our major source of inspiration. In our project we develop a
framework for test case generation in C preprocessor programs. Like in Latendresse's work, we utilized conditional values,
symbolic representations of the form c → e1 ◊
e2. If the condition c is true
then the value for the conditional value is e1 otherwise
e2. We then use formal
simplification rules to reduce the size of the path condition easier to solve.
We are able to generate the simplified trees that are the base for the
generation of the test cases.
References
[1] Mario Latendresse.
Fast symbolic evaluation of c/c++ preprocessing using
conditional values. In Proceedings of the Seventh European
Conference on Software Maintenance and Reengineering, pages 170{, Washington,
DC, USA, 2003. IEEE Computer Society.
TITLE
Student
Text
[NOTE:
This is the standard project for this class to be done individually. If you
don’t want to do this project, you are welcome to propose your own. I have some
project ideas too; feel free to stop by and discuss. We will have to agree on a
project together with a grading policy.]
Summary:
A major problem with software testing is that some bugs are difficult to
replicate. That is, a tester finds a bug and reports it; but a developer fails
to reproduce the bug. This problem of “nondeterministic” bugs is related to
variation in software configurations (a combination of hardware, OS, run-time
environment, memory). For example, a tester (or an end-user) who is running
Java version 6, update 20 encounters a problem in a Java application; reports
it; the developer, running Java version 6, update 21 attempts to reproduce the
bug but fails. The reason is that the bug is masked by the Java update. In this
project, we will study the issues that surround such problems.
Phase
1
Goal:
Downloading and running all the applications.
Procedure:
In this phase, you need to demonstrate that you are able to run four
applications (JFCRipper, GUIStructure2GraphConvert, TestCaseGenerator, JFCReplayer)
in GUITAR (use the application in http://guitar.svn.sourceforge.net/viewvc/guitar/examples/RadioButton/
as input). The source code for all these applications resides in a Subversion
repository that can be viewed at http://guitar.svn.sourceforge.net/viewvc/guitar/.
Please refer to https://sourceforge.net/projects/guitar/develop
for additional help with Subversion. Each application (let’s call it foo for fun)
resides in the folder foo.tool/ in the repository. Checkout this
folder, for each application, and read its README.txt file. You will find more
information about the modules that foo uses for building and execution. You will also find
instructions on how to build and run foo.
Deliverables:
There are no deliverables for this phase. Points will be awarded for demos.
Grading
session: During the grading session, you will
have access to a new machine (Windows or Linux) that is connected to the
Internet. You will have to download, build, and execute all four applications
and run them on all the inputs. You will also need to install Ant, Subversion,
Java, and any other tools needed to run the applications. Each application is
worth 10 points.
Points:
40
Due
on or before Sep. 14 by 2:00pm. [Late submission policy – you lose 20% (of the maximum
points) per day]
Phase
2
Goal:
Replicating http://comet.unl.edu/benchmarks.php?q=group&g=umd.length1-2.efg.2010
and obtaining coverage (statement and branch) reports.
Procedure:
Visit the page http://comet.unl.edu/benchmarks.php?q=group&g=umd.length1-2.efg.2010
and download the benchmark. Regenerate all the artifacts in this benchmark
using the same configuration (Linux
version 2.6.31-19-generic Ubuntu 9.10, Java 1.6
update 15, Gnome 2.28.0) described in the benchmark document. Store these
regenerated artifacts in a folder (Original/) using the structure used in the
benchmark. Add coverage (statement and branch) reports for the test cases, both
at test case level and test suite level. Select four NEW unique platform
configurations (ensure that they have not already been selected by another
student; see table below) and regenerate all artifacts again; store them in new
folders (New1/, New2/, New3/, New4/); also generate coverage (statement and branch)
reports. Document any differences found between the artifacts and coverage
(differences.txt), if any, and explain their causes.
STUDENT NAME |
Configurations Selected |
Christopher Neylan |
·
Ubuntu 9.10, kernel 2.6.31-19-generic, Oracle
Java 1.6u16, Gnome 2.28.0 ·
Ubuntu 9.10, kernel 2.6.31-19-generic, Oracle
Java 1.6u20, Gnome 2.28.0 ·
Ubuntu 9.10, kernel 2.6.31-19-generic, OpenJDK 1.6.0_18, Gnome 2.28.0 ·
Ubuntu 9.10, kernel 2.6.31-20-generic, Oracle
Java 1.6u15, Gnome 2.28.0 |
Raul David Guerra |
·
Ubuntu 10.04.1, kernel 2.6.32-generic, Oracle
Java 1.6u15, Gnome 2.30 ·
Ubuntu 10.04.1, kernel 2.6.32-generic, Oracle
Java 1.6u16, Gnome 2.30 ·
Ubuntu 10.04.1, kernel 2.6.32-generic, Oracle
Java 1.6u17, Gnome 2.30 ·
Ubuntu 9.10, kernel 2.6.31-19-generic, Oracle
Java 1.6u21, Gnome 2.2 |
Jorge Faytong |
·
Ubuntu 10.04.1, kernel 2.6.32-generic, Oracle
Java 1.6u21, Gnome 2.30 ·
Ubuntu 10.04.1, kernel 2.6.32-generic, Oracle
Java 1.6u20, Gnome 2.30 ·
Ubuntu 10.04.1, kernel 2.6.32-generic, Oracle
Java 1.6u19, Gnome 2.30 ·
Ubuntu 10.04.1, kernel 2.6.32-generic, Oracle
Java 1.6u18, Gnome 2.30 |
Jiarong Jiang |
·
Linux version 2.6.32-24-generic, java 1.6 update 21, Gnome 2.30 ·
Linux version 2.6.32-24-generic, java 1.6 update 20, Gnome 2.30 ·
Linux version 2.6.32-24-generic, java 1.6 update 19, Gnome 2.30 ·
Linux version 2.6.32-24-generic, java 1.6 update 18, Gnome 2.30 |
Leslie Milton |
·
Ubuntu 9.10, kernel 2.6.31-14-generic, Oracle
Java 1.6u16 GNOME 2.28.1 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Oracle
Java 1.6u17 GNOME 2.28.1 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Oracle
Java 1.6u18 GNOME 2.28.1 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Oracle
Java 1.6u19 GNOME 2.28.1 |
Naga Prathyusha Kanala |
·
Linux 2.6.32-24-generic, Ubuntu 10.4, Open jdk 1.6u20, Gnome 2.30.2 ·
Linux 2.6.32-24-generic, Ubuntu 10.4, Open jdk 1.6u19, Gnome 2.30.2 ·
Linux 2.6.32-24-generic, Ubuntu 10.4, Open jdk 1.6u18, Gnome 2.30.2 ·
Linux 2.6.32-24-generic, Ubuntu 10.4, Open jdk 1.6u17,
Gnome 2.30.2 |
Jayant Kumar |
·
Ubuntu 9.10, kernel 2.6.31-14-generic, Java
1.6u17 GNOME 2.28.0 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Java
1.6u18 GNOME 2.28.0 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Java
1.6u19 GNOME 2.28.0 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Java
1.6u20 GNOME 2.28.0 |
Arnold Robin Fernandes |
·
Ubuntu 9.10, kernel 2.6.31-14-generic, Java
1.6u14, Gnome 2.28.1 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Java
1.6u15, Gnome 2.28.1 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Java
1.6u20, Gnome 2.28.1 ·
Ubuntu 9.10, kernel 2.6.31-14-generic, Java
1.6u21, Gnome 2.28.1 |
Richard B. Johnson |
·
Windows 7 Ultimate (x64) - Kernel 6.1 - Java 1.6u18 ·
Windows 7 Ultimate (x64) - Kernel 6.1 - Java 1.6u19 ·
Windows 7 Ultimate (x64) - Kernel 6.1 - Java 1.6u20 ·
Windows 7 Ultimate (x64) - Kernel 6.1 - Java 1.6u21 |
Deliverables:
Original/, New1/, New2/, New3/, New4/, and differences.txt.
Grading
session: Based on a meeting and discussion.
You may be asked to regenerate the artifacts for a new configuration.
Points:
200 (50 per new configuration plus discussion).
Due
on or before Oct. 5 by 2:00pm. [Late submission policy – you lose 20% (of the maximum
points) per day]
Phase
3
Goal:
Obtaining fault matrices, one for each configuration.
Procedure:
Execute all test cases from the previous phase and determine if any crash
(terminate unexpectedly or throw an uncaught exception) the application. Find the
causes of the crash and document them. If none cause a crash, then generate new
tests that cause a crash (obtain their statement and branch coverage reports);
or prove that no tests can cause a crash.
Deliverables:
Four fault matrices, new test cases (if any) with coverage reports, and causes
of crashes.
Grading
session: Based on individual meeting and
discussion. You may be asked to regenerate a part of the fault matrix for a new
configuration.
Points:
200 (50 per new configuration plus document).
Due
on or before Nov. 9 by 2:00pm. [Late submission policy – you lose 20% (of the maximum
points) per day]
Phase
4
Goal:
Improving the tests and obtaining new fault matrices.
Procedure:
The test cases use “default” strings for text-fields. Improve the test cases by
replacing the default strings with new values obtained using the
category-partition method. Execute the test cases and determine if any crash
(terminate unexpectedly or throw an uncaught exception) the application. Find
the causes of the crash and document them. If none cause a crash, then revise
the text strings so that they crash the application; or prove that no text
strings will ever cause the application to crash. Report the test coverage.
Deliverables:
New tests and their coverage, four fault matrices, and causes of crashes.
Grading
session: Based on individual meeting and
discussion. You may be asked to regenerate a part of the fault matrix for a new
configuration.
Points:
200 (50 per new configuration plus document).
Due
on or before Dec. 1 by 2:00pm. [Late submission policy – you lose 20% (of the maximum
points) per day]