LTP Code introduces a two-step method of learning, personally I think that the best, effective fast.

Method 1 View the official presentation document (if you came into contact with ltp, you must see Step 1)

1) with the configuration described in Example Makefile, see:https://github.com/linux-test-project/ltp/wiki/BuildSystem
example describes the use, see:https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines
two URLs above, LTP is the official Guidelines, please read the LTP during learning, which can only be familiar with writing code format.

2) LTP git repository doc information, including:
README.md
doc/ltp-howto.txt
doc/style-guide.txt
doc/test-writing-guidelines.txt
doc/ltp-run-files.txt
and the like (preferably all the time if there is probably visit again).

3) themselves do not want to write anything introductory text, because official information considered personal ltp introduced very comprehensive, totally do not need others to waste the tongue, but still write about attention (often before others areas of doubt).

. A ltp compiled directory, use cases binary all on testcases / bin, personal habits alone cd into execution, but before executing do PATH = $ PATH: / home / ltp / testcases / bin will add its directory to the environment variable, which ltp itself because some framework binary files, such as tst_brk other use cases executed directly tst_brk call, if the environment variable is not added to the command error can not be found, such as:
./wc01.sh
./wc01.sh: line 24: .: tst_test.sh: file not found
in fact tst_test.sh testcases / bin below.
(ltp in fact this has already been mentioned, but few people to pay attention, then most ltp introductory document, will not write so fine, just tell you how to perform)

b. Each use case includes setup (void) and clean (void) environment initialization and cleanup functions, followed by Example test01 (void), test02 (void) and the like are named (test not much predetermined to be characteristic of all names _test01 can).

c. ltp inner wrapper script contains many, basically satisfy the inspection performed embodiment, the print error and the like, such as
require root authority performs ::

tst_require_root()

The success or failure of the implementation of print:

tst_res(TPASS, "getenv(" ENV1 ") = '"ENV_VAL "'");
tst_res(TFAIL, "getenv(" ENV1 ") = '%s', expected '"ENV_VAL "'", ret);

Creating open close:

SAFE_MKDIR(MNTPOINT, 0777);
SAFE_MKFS(tst_device->dev, tst_device->fs_type, NULL, NULL);
fd1 = SAFE_OPEN(cleanup, FILE1, O_CREAT | O_RDWR, 0666);
SAFE_CLOSE(fd1);

Please look at the code in time recognize this point, we do not see here is considered not read.

Test-Writing-Guidelines Description:
Instead of writing: fd =
open(“/dev/null”, O_RDONLY); if (fd < 0) tst_brk(TBROK | TERRNO,
“opening /dev/null failed”); You write just: fd =
SAFE_OPEN(“/dev/null”, O_RDONLY);

In fact, the general system calls package, reducing the return value judgment calls, etc., optimize the structure, allowing developers to pay more attention to patients with functional logic, rather than the return value check and other "chores."

. D LTP print There are five levels:
-. TPASS Test has passed performed with Example PASS
-. TFAIL Test has failed performed with Example FAIL
- TINFO General message by executing process necessary in message (as not too much).
- TBROK Something has failed in test preparation phase preparation phase Broken use case, the main means does not satisfy the Setup () when a test environment or test execution condition is not satisfied suddenly found, the system abnormality or the like. broken nature of the appearance of exit
- TCONF Test is not appropriate for current configuration (syscall not implemented, unsupported arch, ...) does not satisfy the current architecture, platform, system use case.

e. LTP including C code and shell code with the embodiment, the look Test-Writing-Guidelines when distinction, the main call frame C code interface functions, shell code main Invocation Framework interfaces of binary (such tst_res TPASS "xx"), wherein tst_res is testcases / bin binary below.

**

Code submitted by the previous method of learning

**
personal recommendation two directories:
1) c learning the language code, see testcases / kernel / syscalls /, which is the use case of system calls, you can pick your favorite syscall, such as open, see open01.c open02. c ...
General Catalog embodiment with at least two, including a normal functional verification system comprises a call abnormal test case, in fact, the man open DESCRIPTION: Description Function, parameter description and ERRORS: All The return value and error led to the wrong reasons covered
(man can look I do not knowCommissioning tool user mode (b): perror and man man command description).

Pick a simple comb down, open01.c

/*
 *   Copyright (c) International Business Machines  Corp., 2001
 *    07/2001 Ported by Wayne Boyer
 *    06/2017 Modified by Guangwen Feng <[email protected]>
 *
 *   This program is free software;  you can redistribute it and/or modify
*   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 2 of the License, or
 *   (at your option) any later version.
 *
 *   This program is distributed in the hope that it will be useful,
 *   but WITHOUT ANY WARRANTY;  without even the implied warranty of
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
 *   the GNU General Public License for more details.
 *
 *   You should have received a copy of the GNU General Public License
 *   along with this program;  if not, write to the Free Software
 *   Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
This is when you submit code to the open source community (ltp), must be declared, follow the GNU General Public License Agreement (do not know what can be found). The main provisions of the code is available for others to use, whether to allow modification, whether commercial use, and so on.
 */

/*
 * DESCRIPTION
 *      Open a file with oflag = O_CREAT set, does it set the sticky bit off?
 *      Open a dir with O_DIRECTORY, does it set the S_IFDIR bit on?
 *
 * ALGORITHM
 *      1. open a new file with O_CREAT, fstat.st_mode should not have the
 *         01000 bit on. In Linux, the save text bit is *NOT* cleared.
 *      2. open a new dir with O_DIRECTORY, fstat.st_mode should have the
 *         040000 bit on.
 */
 Use Case descriptive text, if they submit, remember to write clearly and Kazakhstan

#define _GNU_SOURCE             /* for O_DIRECTORY */
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include "tst_test.h"
 It contains documents,"tst_test.h"Is to call the interface framework, it must be included

#define TEST_FILE       "testfile"
#define TEST_DIR        "testdir"

static int fd;

static struct tcase {
        char *filename;
        int flag;
        mode_t mode;
        unsigned short tst_bit;
        char *desc;
} tcases[] = {
        {TEST_FILE, O_RDWR | O_CREAT, 01444, S_ISVTX, "Sticky bit"},
        {TEST_DIR, O_DIRECTORY, 0, S_IFDIR, "Directory bit"}
};
 Initializing variables and use cases, to mention here, the code for scalability, the system call parameters extracted as much as possible, the use of an array of storage structures, add or delete a convenient embodiment. Example Operative use Direct open (tcases [0]->filename,tcases[0]->flag…)。

static void verify_open(unsigned int n)
{
        struct tcase *tc = &tcases[n];
        struct stat buf;

        TEST(open(tc->filename, tc->flag, tc->mode));
        fd = TEST_RETURN;
        if (fd == -1) {
                tst_res(TFAIL, "Cannot open a file");
                return;
        }

        SAFE_FSTAT(fd, &buf);
        if (!(buf.st_mode & tc->tst_bit))
                tst_res(TFAIL, "%s is cleared unexpectedly", tc->desc);
        else
                tst_res(TPASS, "%s is set as expected", tc->desc);

        SAFE_CLOSE(fd);
        if (S_ISREG(buf.st_mode))
    SAFE_UNLINK(tc->filename);
}
 verify_open () with the body cases

static void setup(void)
{
        SAFE_MKDIR(TEST_DIR, 0755);
}
 setup initialization

static void cleanup(void)
{
        if (fd > 0)
                SAFE_CLOSE(fd);
}
 cleanup clean up the environment

static struct tst_test test = {
        .tcnt = ARRAY_SIZE(tcases),
        .needs_tmpdir = 1,
        .setup = setup,
        .cleanup = cleanup,
        .test = verify_open,
};
 Architecture declaration that cases of arrays, functions, etc. using the framework directly called.

2) shell language, see testcases / commands, which is the basic kernel command shell written test
not talked about here, no meaning, their use cases through sh -x, go to the next process performed with Example bar.

The last sentence speaks digression, before a lot of people use ltp encounter fails, such as broken, crash, or TFAIL, think about it over directly for help, I think it is very wrong, and some people even asked him what the code is the execution failed where there is no preliminary analysis and so can not answer, I think the normal process should include:
1) sequentially scan the code. (As a performer himself, at least the code read through it ~);
2) re-read the code, the code to understand what is (this is what function to achieve? What test interfaces?)
3) initial state positioned by an individual user commissioning tools, such as strace, gdb, sh -x other single step of formula (user mode for debugging the strace very easy to use,Commissioning tool user mode (a): strace and ltraceOr perror ())
After 4) to locate the code, look at what went wrong to execute, why would a mistake, use case what is expected, what is now the phenomenon is a phenomenon you think this normal?
So far, I think it is ok, do you think is not normal, because you have limited capacity, may not be able to judge, but I hope to speak out their ideas, just do not know, but also They say it, but the previous three steps, please do it again, even though you may not know why. The rest do not know, can help.

Please look at the issue delve a day or two every possible means to solve it (google problem, try to learn a new debugging method, etc.), so as to progress. I learn ltp, and all syscall command executes a compiled in ubuntu, fail to spend a week to analyze all the use cases completed, the analysis was to develop good habits.