LTP代码学习方法主要介绍两个步骤，个人认为效果最好，见效也快。
方法1 查看官方介绍文档（如果你最开始接触ltp，那么步骤1一定要看）
1）用例Makefile配置介绍，见：https://github.com/linux-test-project/ltp/wiki/BuildSystem
用例介绍，见：https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines
上面两个网址，是LTP官方Guidelines，学习LTP时请仔细阅读，方能熟悉里面代码的写作格式。
2）LTP git仓库doc资料，主要包括：
README.md
doc/ltp-howto.txt
doc/style-guide.txt
doc/test-writing-guidelines.txt
doc/ltp-run-files.txt
等等（如果有时间最好全部大概浏览一遍）。
3）自己不太想多写什么介绍性文字，因为ltp的官方资料个人认为介绍非常全面，完全不需要别人再浪费口舌，但是还是写点注意（之前别人经常疑问的地方）。
a. ltp编译后目录，用例二进制全部放在testcases/bin，个人习惯单独cd进去执行，但是执行前请执行 PATH=$PATH:/home/ltp/testcases/bin 将其目录添加到环境变量，这是因为ltp本身有些框架性二进制文件，比如tst_brk等，用例执行会直接tst_brk调用，如果不添加到环境变量则报错命令无法找到，比如：
./wc01.sh
./wc01.sh: line 24: .: tst_test.sh: file not found
其实tst_test.sh就在 testcases/bin 下面。
(其实这条ltp已经提到，只是很少人去注意，然后大部分ltp的介绍性文档，都不会写的这么细，都仅仅告诉你怎么执行)
b. 每个用例均包括setup(void)和clean(void)函数进行环境初始化和清理，然后用例test01(void)、test02(void)等方式命名（test没太大规定，可以特性名称_test01均可）。
c. ltp内部包含了很多的封装脚本，基本满足用例执行的检查，报错打印等等，比如
需要root用户权限执行:：
tst_require_root()执行成功or失败，打印：
tst_res(TPASS, "getenv(" ENV1 ") = '"ENV_VAL "'");
tst_res(TFAIL, "getenv(" ENV1 ") = '%s', expected '"ENV_VAL "'", ret);创建打开关闭：
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);在看代码时候请认识到这点，不要看到这里就认为看不懂了。
Test-Writing-Guidelines说明：
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);扫描二维码关注公众号，回复： 2789076 查看本文章
其实就是对一般系统调用进行封装，减少调用后的返回值判断等，优化结构，让开发者更关注用例的功能逻辑，而不是返回值check等“琐事”。
d. LTP中有五种打印级别：
- TPASS Test has passed. 用例执行PASS
- TFAIL Test has failed. 用例执行FAIL
- TINFO General message. 用例执行过程中必要的提示信息（尽量不要太多）
- TBROK Something has failed in test preparation phase. 用例准备阶段broken，主要指Setup()时候测试环境不满足，或者执行过程突然发现不满足测试条件，系统异常 等而出现的broken性质退出
- TCONF Test is not appropriate for current configuration (syscall not implemented, unsupported arch, …) 用例不满足当前架构、平台、系统等。
e. LTP主要包括C代码和shell代码用例，所以在看Test-Writing-Guidelines时候注意区分，C代码主要调用框架中接口函数，shell代码主要调用框架中接口二进制（比如tst_res TPASS “xx”），其中tst_res是testcases/bin下面二进制。
**
方法2 学习前人提交的代码
**
个人推荐2个目录：
1）c语言代码学习，查看testcases/kernel/syscalls/，里面是系统调用用例，可以挑个自己喜欢的syscall，比如open，会看到open01.c open02.c …
一般来说目录中用例至少两个，一个包括正常功能验证，一个包括系统调用异常测试情况，其实就是man open的DESCRIPTION：功能说明，参数说明 和ERRORS：所有错误返回值和导致错误原因覆盖
（man不太了解可以看下我的 https://blog.csdn.net/cui841923894/article/details/81395591 man命令介绍）。
挑个简单的梳理下，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
这段是当你提交代码到开源社区时（ltp），必须声明，遵循GNU General Public License协议（不知道的可以搜一下）。主要规定代码是否可供别人使用，是否可允许修改，是否可商业使用等等。
*/
/*
* 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.
*/
用例描述性文字，如果自己提交，记得写清楚哈
#define _GNU_SOURCE /* for O_DIRECTORY */
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include "tst_test.h"
包含有文件，其中"tst_test.h"是调用框架接口，必须包含
#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"}
};
变量和用例初始化，这里提一下，为了代码的可扩展性，系统调用参数尽量提取出来，使用结构体数组存储，方便新增或者删除用例。用例执行部分直接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（）用例主体
static void setup(void)
{
SAFE_MKDIR(TEST_DIR, 0755);
}
setup初始化
static void cleanup(void)
{
if (fd > 0)
SAFE_CLOSE(fd);
}
cleanup清理环境
static struct tst_test test = {
.tcnt = ARRAY_SIZE(tcases),
.needs_tmpdir = 1,
.setup = setup,
.cleanup = cleanup,
.test = verify_open,
};
架构声明，声明用例数组，函数等，框架会直接调用执行。2）shell语言，查看testcases/commands，里面是shell写的内核基本命令测试用例
这里就不讲了，没什么意思，自己通过 sh –x 用例，去看下用例执行流程吧。
最后讲句题外话，之前很多使用ltp的人，遇到执行失败，比如broken，crash，或者TFAIL，想都不想都直接求助过来，我认为是非常不对的，有的人甚至问他代码是干什么的，执行到哪里失败了，有没有进行初步分析等都无法回答，我认为正常的流程应该包括：
1）顺序浏览一遍代码（自己作为执行者，代码至少看一遍吧~）；
2）再次读代码，明白代码干什么的（这个是实现什么功能？测试什么接口？）
3）通过个别用户态调测工具进行初步定位，比如strace，gdb，sh -x等单步调式（strace对于用户态程序调试非常好用，https://blog.csdn.net/cui841923894/article/details/81395572，或者perror()）
4）定位到代码后，看一下执行到哪里出错，为什么会出错，用例期望是什么，现在现象是什么，这个现象你认为正常吗？
到此为止，我认为是ok了，你认为正不正常，因为你能力有限，可能无法判断，但希望大胆说出自己的想法，就是不知道，也要说出来，但是前面三步请做一遍，尽管可能你也不知道为什么这么做。剩下还不了解，可以求助。
看问题请钻研一到两天，用尽办法去解决它（google问题，学习尝试新的调试方法等），这样才能进步。本人学习ltp，把所有syscall和command在ubuntu执行一编，花一周时间分析所有fail用例完毕，才养成良好的分析习惯。
