Fundamentals of Software Testing

Fall 2010

 

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

 

Course Project (Studying the Role of Configurations in Testing)

[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]