[Home] [Search] [How to Buy] [Products] [Solutions] [Developers] [Services and Support] [Serious Fun]
sgi  
Developer Central
Development ProductsProgram & BenefitsLibraryMarketing ResourcesTechnologyOpen Source
Open Source
image image image
About this site

Linux Test Project
Overview
News
FAQ
Mailing List
How to Contribute
Source Tree
Download
License

 
SGI Open Source
Project List
 
 

LTP FAQ

Our FAQ is a bit unorganized at this point. We're adding questions as they pop up. When topic areas become clear, we'll reorder the questions into topic areas.

What is LTP ?
Linux already has a successful testing model. How will this project benefit Linux further?
What is in the LTP, so far.
How do I build this?
How do I run this? How does it work?
How do I analyze the results?
What if a test program reports a failure?
What is a test?
Are you doing benchmarking?
Are you doing standards testing?


What is LTP ?

LTP is the Linux Test Project. LTP is a project that aims to develop a set of tools and tests to verify the functionality and stability of the Linux kernel (including regression tests). We hope this will support Linux development by making unit testing more complete and minimizing user impact by building a barrier to keep bugs from making it to the user.

Linux already has a successful testing model. How will this project benefit Linux further?

The Linux development community utilizes two important (some would argue most important) testing techniques in it's normal operations: Design and Code Inspections. The intent of LTP is to support this by giving developers an ever growing set of tools to help identify any operational problems in their code that may be missed by human review. One of the toughest categories of problems to catch with inspection is that of interaction of features. With a continuously improving set of tests and tools, developers can get an indication of whether their changes may have broken some other functionality.

There is no such thing as a perfect test base. It's only useful if it keeps up with new and changing functionality, and if it actually gets used.

What is in the LTP, so far?

The first release of code from SGI for LTP was a set of tools for testing file systems. Since that first release, a group of tests we call Quickhit tests have been released. These are simple tests aimed at running through a few execution paths in a number of system calls. Watch the news link for updates on the content of the LTP releases.

How do I build this?

We've made a decision to not put effort into a grand build process in favor of a minimal makefile approach. We did this because the project is just starting and we don't want to impose an "SGI approach" in favor of a more open source approach decided more by open source contributors. For now, from the root of the tree, a simple 'make' should do it. Send your build errata to ltp@oss.sgi.com.

How do I run this? How does it work?

Currently, you can't really "run" this -- at least not in terms of a single starting command line. Instead, LTP is made up of a number of individual test programs. These test programs usually test some some portion of a feature's functionality. Most tests can be run without any command line options. Others offer variable functionality specified from the command line.

A problem that needs to be addressed is how to store different command lines and determining when to run them. A couple examples are, should a bigmem test be run on a 128Mb system? Should a file system test that requires 2Gb of scratch space be run on a system without such a test space? These two example highlight a couple of issues that need to be addressed in regard to the runtime framework for tests.

How do I analyze the results?

Our philosophy on writing functional tests is that each test program is responsible for setting up an environment for testing the target functionality, performing an operation using the target functionality, and then analyzing whether the functionality performed according to expectations and reporting the results. Reporting the results can take a couple of different forms.

The simplest form is the exit status of the program. If a test hits a scenario where it finds unexpected or improper results, calling exit() with a non-zero exit status would flag the caller that the test failed for some reason. Conversely, if the test completes with the functionality performing as expected, a zero exit would flag the caller that the test passed. Summarizing: exit(0)==PASS, exit(!0)==FAIL. Additionally, the test program could report some sort of information on standard output indicating why the test passed or failed.

Another form of results reporting used within SGI is a hybrid of the exit() style reporting. It still uses the exit status for reporting, but incorporates a standard format for output from standard output of the test program. This accomplishes two things: allows the reporting of the functional testing results to be more understandable for both humans and a computer analysis tool and allows more than one test case result to be reported from within one test program. This is in contrast to a pure exit status analysis where a test program may contain N test cases and one test case fails, the test program returns a non-zero value. It appears that the whole test fails. Compare this to a scenario where a test reports for each test case a PASS or FAIL token on standard output.

For quick clarity, take this example:

$ ./dup02
dup02       1  PASS  :  dup(-1) Failed, errno=9 : Bad file descriptor
dup02       2  PASS  :  dup(1500) Failed, errno=9 : Bad file descriptor
dup02 is a test program that tests a couple of scenarios for the dup() call. Each of the test cases call dup() in an effort to be sure dup() responds with a correct errno value after deliberately calling dup() with bad arguments. In both cases above, dup() is called with non-existent (1500) or undefined (-1) file descriptor values. In both cases, dup() should respond with an errno indicating a 'Bad File Descriptor'. In both cases, the test reports that dup() responded as expected by printing a PASS token.

Additionally, the exit status should be zero, indicating all the test cases passed. Accessing the exit status of the test program can be reported immediately after running the test program by printing the $? variable.

$ echo $?
0

Finally, we can analyze the results of the dup02 test program on two fronts. We can see from the two PASS lines, that both test cases in the dup02 program passed. We can also see from the exit status that the dup02 program as a whole passed.

What if a test program reports a failure?

After a failure report, analysis consists of three parts: determining what test case reported the failure, determining if the reported failure was really a failure, and comparing results with a passing baseline.

Determining what test case is reporting a failure is sometimes a challenge. In some cases, in a multiple test case test program, previous test cases can cause failure in subsequent test cases. If a test is well written, the output on standard output can be useful.

Once the test case the "failure" is occuring under is osolated, determining whether the "failure" is really a failure needs to be determined. If a test is poorly written and certain environmental conditions are not handled properly, a false failure may occur.

Comparing the failure on the system under test against a baseline system is important. If the test fails on a system but it is unknown if it ever passed on any other system, its not possible to determine if the problem is a new failure. Comparing how the functionality under test performs on the baseline against how it acts on the test system is the most important method for determining how the "failure" occured.

What is a test?

Take a look at the LTP Glossary at http://oss.sgi.com/projects/ltp/glossary.html. It covers some of the basic testing definitions, including 'test'.

In software testing, the word 'test' has become overloaded and increasingly tough to define. In operating system testing, we might be able to categorize tests into a few different areas: functional (regression), duration, stress (load), and performance.

Are you doing benchmarking?

Not at this time. We're more interested in functional, regression, and stress testing the Linux kernel. Benchmarking may be workable to compare the performace among Linux versions.

Are you doing standards testing?

No, we're leaving that to Linux Standard Base (LSB). Check out http://www.freestandards.org/.

about this site  |  privacy policy | owner(s) of project ltp
Copyright © 1999 Silicon Graphics, Inc. All rights reserved. | Trademark Information