CSE 591 Interaction Testing and Software Testing
Contact Information:
I am located in Brickyard 444.
Contact me by email at Charles.Colbourn@asu.edu as the most reliable way to reach me.
The class schedule is T Th 9:15-10:30 in BYAC240.
Despite the claim on the Registrar's page, there is no prerequisite other than interest.
Background in software engineering or algorithms or discrete mathematics or hardware testing would be useful.
In many environments, both those arising in the real world and those artificially constructed, components interact in a coherent manner to produce a large system. Component-based software design provides one example of this, and hardware design another.
However there are many more. Combining chemicals to produce a reaction yielding a desired product involves interactions among many chemical components.
Gene interaction in biological organisms are essentially involved in development of the organism. Indeed anywhere that simpler ingredients combine (interact) to form a system, the need to detect, quantify, and understand the interactions between and among
components can be crucial.
In the software setting, imagine that a number of software components have been independently developed and each tested thoroughly. Some components serve the same function, and so we choose one among them; others serve complementary functions and so we
choose one of each and integrate them.
Here's where problems might arise. Operating system A, disk controller D, and cache C may each function separately; each may observe the interface requirements that we have set. And yet after integration, the system may fail because of an interaction
among these three. The solution is easy: test A, D, and C together.
But there may be tens or hundreds of different component types, and tens or hundreds of components of each type. We cannot test all possibilities. So what we try to do in interaction testing is to design test suites with the property that, for every
small number t of components, and every choice of t of the components, there is at least one test for each of the possible choices of instances for those components.
Some questions:
- How big are such test suites?
- How do we make them by computer?
- Are they useful in actually testing a system?
These questions look easy, but they turn out to lead to many interesting topics in algorithms, software design and testing, and discrete mathematics.
Assessment:
- a project counting 100%.
The main features are:
- the topic is different for each individual, and is chosen by the
student. Particular project topics should be discussed with me to ensure
that they are reasonable.
- You may choose a project which is a literature review, an
implementation and experimentation, or theoretical research (i.e., you
may focus your activities on reading, coding, or thinking -- but, of course,
you must do all three to some degree!)
- Plan on making an in-class presentation (duration: 25 minutes plus 12.5 minutes questions) to the class.
- Due date is at the final exam time for the course.
Start on the project
early!
- Feel free to consult anyone, especially me, about the project as you
work on it.
- The most important thing that I want to see in the projects is a
creative and innovative approach that clearly demonstrates a deep understanding
of some topic relevant to the course. In general, depth is preferred to
breadth, and your ideas are preferred to someone else's.
- No tests or examinations are planned.