Linux test project что это

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

License

linux-test-project/ltp

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

The kernel requires that fs-verity blocksize must be at most equal to the filesystem blocksize. Testing on small loop device means that mkfs.ext4 will very likely default to blocksize of 1024. Set fs-verity blocksize to the filesystem blocksize to avoid errors. Link: https://lore.kernel.org/ltp/20230714114244.32109-1-mdoucha@suse.cz/ Reviewed-by: Petr Vorel Tested-by: Petr Vorel Signed-off-by: Martin Doucha

Git stats

Files

Failed to load latest commit information.

README.md

Linux Test Project is a joint project started by SGI, OSDL and Bull developed and maintained by IBM, Cisco, Fujitsu, SUSE, Red Hat, Oracle and others. The project goal is to deliver tests to the open source community that validate the reliability, robustness, and stability of Linux.

The LTP testsuite contains a collection of tools for testing the Linux kernel and related features. Our goal is to improve the Linux kernel and system libraries by bringing test automation to the testing effort. Interested open source contributors are encouraged to join.

The discussion about the project happens at LTP mailing list: http://lists.linux.it/listinfo/ltp

LTP mailing list is archived at: https://lore.kernel.org/ltp/

The git repository is located at GitHub at: https://github.com/linux-test-project/ltp

Be careful with these tests!

Don’t run them on production systems. Growfiles, doio, and iogen in particular stress the I/O capabilities of systems and while they should not cause problems on properly functioning systems, they are intended to find (or cause) problems.

Quick guide to running the tests

If you have git, autoconf, automake, m4, pkgconf / pkg-config, libc headers, linux kernel headers and other common development packages installed (see INSTALL and ci/*.sh), the chances are the following will work:

$ git clone https://github.com/linux-test-project/ltp.git $ cd ltp $ make autotools $ ./configure 

Now you can continue either with compiling and running a single test or with compiling and installing the whole testsuite.

For optional library dependencies look into scripts for major distros in ci/ directory. You can also build whole LTP with ./build.sh script.

Shortcut to running a single test

If you need to execute a single test you actually do not need to compile the whole LTP, if you want to run a syscall testcase following should work.

$ cd testcases/kernel/syscalls/foo $ make $ PATH=$PATH:$PWD ./foo01 

Shell testcases are a bit more complicated since these need a path to a shell library as well as to compiled binary helpers, but generally following should work.

$ cd testcases/lib $ make $ cd ../commands/foo $ PATH=$PATH:$PWD:$PWD/../../lib/ ./foo01.sh 

Open Posix Testsuite has it’s own build system which needs Makefiles to be generated first, then compilation should work in subdirectories as well.

$ cd testcases/open_posix_testsuite/ $ make generate-makefiles $ cd conformance/interfaces/foo $ make $ ./foo_1-1.run-test 

Compiling and installing all testcases

This will install LTP to /opt/ltp .

• If you have a problem see INSTALL and ./configure —help .
• Failing that, ask for help on the mailing list or Github.

Some tests will be disabled if the configure script can not find their build dependencies.

• If a test returns TCONF due to a missing component, check the ./configure output.
• If a tests fails due to a missing user or group, see the Quick Start section of INSTALL .

To run all the test suites

Note that many test cases have to be executed as root.

To run a particular test suite

To run all tests with madvise in the name

$ ./runltp -f syscalls -s madvise 

Test suites (e.g. syscalls) are defined in the runtest directory. Each file contains a list of test cases in a simple format, see doc/ltp-run-files.txt.

Each test case has its own executable or script, these can be executed directly

$ testcases/bin/mesgq\_nstest -m none 

The vast majority of test cases accept the -h (help) switch

Many require certain environment variables to be set

$ LTPROOT=/opt/ltp PATH="$PATH:$LTPROOT/testcases/bin" testcases/bin/wc01.sh 

Most commonly, the path variable needs to be set and also LTPROOT , but there are a number of other variables, runltp usually sets these for you.

Note that all shell scripts need the PATH to be set. However this is not limited to shell scripts, many C based tests need environment variables as well.

Network tests require certain setup, described in testcases/network/README.md (online at https://github.com/linux-test-project/ltp/tree/master/testcases/network).

Before you start you should read following documents:

• doc/test-writing-guidelines.txt
• doc/build-system-guide.txt
• doc/library-api-writing-guidelines.txt

There is also a step-by-step tutorial:

If something is not covered there don’t hesitate to ask on the LTP mailing list. Also note that these documents are available online at:

Although we accept GitHub pull requests, the preferred way is sending patches to our mailing list.

It’s a good idea to test patches on GitHub Actions before posting to mailing list. Our GitHub Actions setup covers various architectures and distributions in order to make sure LTP compiles cleanly on most common configurations. For testing you need to just push your changes to your own LTP fork on GitHub.

Источник

How we use Linux Test Project to test and improve Linux

The Linux Test Project (LTP) is a general-purpose, integrated test suite designed to help organizations using and developing Linux better understand what things work and what still needs work. It is comprised of regression and conformance tests designed to confirm the behavior of the Linux kernel and glibc. Its tools and test suites aim to verify the Linux kernel and related subsystems.

In short, the Linux Test Project (LTP) is aimed at testing and improving Linux. Its goal is to deliver a suite of automated testing tools for Linux and publish the results of the tests they run. For example, we use LTP tests on Red Hat Enterprise Linux (RHEL) to improve the Linux kernel and system libraries.

What is RHTS-LTP?

Automation advice

LTP has a consistent development rhythm; it releases a new stable version of the test suite every four months. The main branch of upstream LTP is always in development. RHEL releases a minor stream every six months and provides a major update every three years. That means the RHEL production environment needs a diverse, safe, high-efficiency, and reliable test suite. For this reason, Red Hat maintains an internal version of LTP called Red Hat Test Suite-Linux Test Project (RHTS-LTP).

Understanding the workflow between the upstream and Red Hat

RHTS-LTP doesn’t operate in isolation. It builds upon what LTP provides and submits patches back upstream. From an engineering perspective, here is the general workflow:

1. Choose a stable package version from upstream as the baseline
2. Backport new patches from the latest branch, which includes:
   • Updating Common Vulnerabilities and Exposures (CVE) and emergency test cases
   • Bug fixes for the framework or test defect
3. Submit the patch to upstream for common problem solving
   • Bug fix, new regression test, and so on

Backporting patches

The development process, in terms of the upstream project, looks like this:

ltp-full-20210121 —> ltp-full-20210524 —> ltp-full-20210927 —> ltp-full-next

Only the stable version is downloaded to RHTS-LTP. So, ltp-full-20210927 along with its patches gets used in the internal test. Usually patches that fix critical common issues, RHEL regression bugs, or the test framework itself are backported.

[ Register for the free online course Red Hat Enterprise Linux Technical Overview to learn basic practical techniques for Linux and system administration tasks. ]

The stable version of the LTP test source is released every four months. After conducting centralized testing and fixing problems with some of the mainstream Linux distributions, the test release version gets tagged with the latest date. Then it’s uploaded as a compressed tarball by the project maintainers, and users can download it from the LTP GitHub.

Before RHTS-LTP gets built in the final step, some internal configurations (important parameters, firmware, and so on) are applied to make it fit for the RHEL environment or a specific testing hardware system. After that, many RHEL-only patches get applied to build the LTP binary.

Triaging known issues

The point of testing is to identify errors, and errors get fixed only if they’re reported. The most important part of RHTS-LTP is the problem-triage process, which helps internal users discern known from unknown issues. Red Hat maintains an internal LTP known-issues list so that testing can ignore false positives or fix the errors causing them.

The LTP known-issues list is based on various RHEL releases to ensure LTP’s compatibility in Beaker tasks, including RHEL 5, RHEL 6, RHEL 7, RHEL 8, RHEL 9, and upstream versions. When a case of RHTS-LTP fails during running, the known-issue list is checked to identify whether the LTP tool is defective or if the RHEL build requires fixes.

This definitely benefits internal users testing minor releases and major releases, especially for various product lines, to locate problems promptly.

Examining RHTS-LTP’s mechanics

RHTS-LTP consists of four parts:

• Stable LTP package
• Upstream patches
• Internal configuration
• Known-issue filtering

We always choose the latest stable version of LTP and then add our custom changes to build a dedicated test suite for RHEL.

Here’s the complete LTP maintenance process in diagram form:

Supporting minor derivative versions

In addition to a special configuration and known-issues handling, RHTS-LTP also provides a shared library to support more derivative test versions for dedicated use in different functional teams. All of these use the common LTP stable version, with the same known issues, although the focus is on different components. These include:

• RHTS-Ltp-lite-test
• RHTS-Ltp-filesystem-test
• RHTS-Ltp-generic-test
• RHTS-Ltp-openposix-test
• RHTS-Ltp-git-test

LTP also deploys for CentOS Stream testing and future various kernel support in Red Hat (including ark-kernel, mainline-kernel, and cki-testing). Almost every new forked branch is based on this with secondary development work. The internal maintainers exchange information through the include-library and work closely to enable efficient troubleshooting.

Testing together

Career advice

Testing is a vital part of quality assurance, and we all want Linux to consistently be at its highest quality. This makes LTP and RHTS-LTP important parts of Linux development.

Linux isn’t just a huge project; it’s a diverse and widespread one. Contributions to testing come from the community. Whether that contribution is in the form of a patch or a specialized configuration, it has a definite positive impact on the upstream branch. It promotes the healthy growth of LTP and better testing in software development. With CentOS Stream working closer with RHEL than ever before, community participation is even easier than it was in the past. Visit the LTP wiki to learn how you can get involved.

Источник