The original file has added some words in commit c797997a244cd2c58908
("Documentation: dev-tools: Add Testing Overview"), hence update the
Chinese translation of them.
Signed-off-by: Hu Haowen <[email protected]>
---
Documentation/translations/zh_CN/dev-tools/index.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst
index fd73c479917b..7ba02fc392a6 100644
--- a/Documentation/translations/zh_CN/dev-tools/index.rst
+++ b/Documentation/translations/zh_CN/dev-tools/index.rst
@@ -11,6 +11,9 @@
目前这些文档已经整理在一起，不需要再花费额外的精力。
欢迎任何补丁。
+有关测试专用工具的简要概述，参见
+Documentation/dev-tools/testing-overview.rst
+
.. class:: toc-title
目录
--
2.25.1
Create new translations for dev-tools/testing-overview.rst and link it
to dev-tools/index.rst with TODOList modifications.
Signed-off-by: Hu Haowen <[email protected]>
---
.../translations/zh_CN/dev-tools/index.rst | 2 +
.../zh_CN/dev-tools/testing-overview.rst | 99 +++++++++++++++++++
2 files changed, 101 insertions(+)
create mode 100644 Documentation/translations/zh_CN/dev-tools/testing-overview.rst
diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst
index 7ba02fc392a6..b6b6d3b09acc 100644
--- a/Documentation/translations/zh_CN/dev-tools/index.rst
+++ b/Documentation/translations/zh_CN/dev-tools/index.rst
@@ -22,6 +22,7 @@ Documentation/dev-tools/testing-overview.rst
:maxdepth: 2
gcov
+ testing-overview
Todolist:
@@ -32,6 +33,7 @@ Todolist:
- ubsan
- kmemleak
- kcsan
+ - kfence
- gdb-kernel-debugging
- kgdb
- kselftest
diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
new file mode 100644
index 000000000000..6e2046ac53ff
--- /dev/null
+++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
@@ -0,0 +1,99 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/dev-tools/testing-overview.rst
+:Translator: 胡皓文 Hu Haowen <[email protected]>
+
+============
+内核测试指南
+============
+
+有许多不同的工具可以用于测试Linux内核，因此知道什么时候使用它们可能
+很困难。该文档提供了它们之间区别的一个粗略概览，并阐释了它们怎样糅
+合在一起的。
+
+编写和运行测试
+==============
+
+大多数内核测试都是用kselftest或KUnit框架之一编写的。它们都让运行测试
+更加简化，并为编写新测试提供帮助。
+
+如果你想验证内核的行为——尤其是内核的特定部分——那你就要使用kUnit或
+kselftest。
+
+KUnit和kselftest的区别
+----------------------
+
+KUnit（Documentation/zh_CN/dev-tools/kunit/index.rst）是用于“白箱”测
+试的一个完整的内核内部系统：因为测试代码是内核的一部分，所以它能够访
+问用户空间不能访问到的内部结构和功能。
+
+因此，KUnit测试最好不要写得太小，也不要有内核中本身包含的部分，以便
+能够独立地测试。‘单元’测试的概念亦是如此。
+
+比如，一个KUnit测试可能测试一个单独的内核功能（甚至通过一个函数测试
+一个单一的代码路径），而不是整个地测试一个特性。
+
+这也使得KUnit测试构建和运行非常地快，从而能够作为开发流程的一部分被
+频繁地运行。
+
+有关更详细的介绍，请参阅KUnit测试代码风格指南
+Documentation/translations/zh_CN/dev-tools/kunit/style.rst
+
+kselftest（Documentation/translations/zh_CN/dev-tools/kselftest.rst），
+另一方面，大量地在用户空间被实现，并且测试通常是用户空间的脚本或程序。
+
+这使得编写复杂的测试，或者需要操作更多全局系统状态的测试更加容易（诸
+如生成进程之类）。然而，从kselftest直接调用内核函数是不行的。这也就
+意味着只有通过某种方式（如系统调用、驱动设备、文件系统等）导出到了用
+户空间的内核功能才能使用kselftest来测试。为此，有些测试包含了一个伴
+生的内核模块用于导出更多的信息和功能。不过，对于基本上或者完全在内核
+中运行的测试，KUnit可能是更佳工具。
+
+比如，一个新的系统调用应该伴随有新的kselftest测试。
+
+代码覆盖率工具
+==============
+
+Linux内核支持不同代码之间的覆盖率测量工具。这能被用来验证一个测试是
+执行的特定的函数或者特定行的代码。这有助于决定内核被测试了多少，或
+用来查找合适的测试中没有覆盖到的极端情况。
+
+:doc:`gcov` 是GCC的覆盖率测试工具，能用于获取内核的全局或每个模块的
+覆盖率。与KCOV不同的是，这个工具不记录每个任务的覆盖率。覆盖率数据可
+以通过debugfs读取，并通过常规的gcov工具进行解释。
+
+:doc:`kcov` 是能够构建在内核之中，用于在每个任务的层面捕捉覆盖率的一
+个功能。因此，对于代码执行位置信息的其它情况，它是非常有用的，比如在
+一个单一系统调用里使用它就很有用。
+
+动态分析工具
+============
+
+内核也支持许多动态分析工具，用以检测正在运行的内核中出现的多种类型的
+问题。这些工具尤其用于不同类型的漏洞，比如非法内存访问，诸如数据竞争
+的并发问题，或者整型溢出的其它未定义的行为。
+
+一些工具如下：
+
+* kmemleak检测可能的内存泄漏。参阅
+ Documentation/dev-tools/kmemleak.rst
+* KASAN检测非法内存访问，如数组越界和释放内存后再使用的错误。参阅
+ Documentation/dev-tools/kasan.rst
+* UBSAN检测C标准中未定义的行为，如整型溢出。参阅
+ Documentation/dev-tools/ubsan.rst
+* KCSAN检测数据竞争。参阅 Documentation/dev-tools/kcsan.rst
+* KFENCE是一个低开销的内存问题检测器，比KASAN更快而能被用于批量构建。
+ 参阅 Documentation/dev-tools/kfence.rst
+* lockdep是一个锁定正确性检测器。参阅
+ Documentation/locking/lockdep-design.rst
+* 除此以外，在内核中还有一些其它的调试工具，大多数能在
+ lib/Kconfig.debug 中找到。
+
+这些工具倾向于对内核进行整体测试，并且不像kselftest和KUnit一样“传递”。
+它们能与kselftest和KUnit结合起来，通过激活这些工具在一个内核上运行测
+试：之后你就能确保这些错误在测试过程中都不会发生了。
+
+一些工具与KUnit和kselftest集成，并且当问题被检测时测试会自动失败。
+
--
2.25.1
> Create new translations for dev-tools/testing-overview.rst and link it
> to dev-tools/index.rst with TODOList modifications.
>
> Signed-off-by: Hu Haowen <[email protected]>
> ---
> .../translations/zh_CN/dev-tools/index.rst | 2 +
> .../zh_CN/dev-tools/testing-overview.rst | 99 +++++++++++++++++++
> 2 files changed, 101 insertions(+)
> create mode 100644 Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>
> diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst
> index 7ba02fc392a6..b6b6d3b09acc 100644
> --- a/Documentation/translations/zh_CN/dev-tools/index.rst
> +++ b/Documentation/translations/zh_CN/dev-tools/index.rst
> @@ -22,6 +22,7 @@ Documentation/dev-tools/testing-overview.rst
> :maxdepth: 2
>
> gcov
> + testing-overview
>
> Todolist:
>
> @@ -32,6 +33,7 @@ Todolist:
> - ubsan
> - kmemleak
> - kcsan
> + - kfence
> - gdb-kernel-debugging
> - kgdb
> - kselftest
> diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
> new file mode 100644
> index 000000000000..6e2046ac53ff
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
> @@ -0,0 +1,12 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +.. include:: ../disclaimer-zh_CN.rst
> +
> +:Original: Documentation/dev-tools/testing-overview.rst
> +:Translator: 胡皓文 Hu Haowen <[email protected]>
> +
> +============
> +内核测试指南
> +============
> +
> +有许多不同的工具可以用于测试Linux内核，因此知道什么时候使用它们可能
s/知道/了解/
> +很困难。该文档提供了它们之间区别的一个粗略概览，并阐释了它们怎样糅
maybe
本文档粗略概述了它们之间的区别
是怎样
> +合在一起的。
> +
> +编写和运行测试
> +==============
> +
> +大多数内核测试都是用kselftest或KUnit框架之一编写的。它们都让运行测试
>
> 都提供了让运行测试更简单的的基础设施，
>
> +更加简化，并为编写新测试提供帮助。
> +
> +如果你想验证内核的行为——尤其是内核的特定部分——那你就要使用kUnit或
> +kselftest。
> +
> +KUnit和kselftest的区别
> +----------------------
> +
> +KUnit（Documentation/zh_CN/dev-tools/kunit/index.rst）是用于“白箱”测
Seems we don't have this translation yet, so plese use the link point to En version.
So as followed paths.
> +试的一个完整的内核内部系统：因为测试代码是内核的一部分，所以它能够访
> +问用户空间不能访问到的内部结构和功能。
> +
> +因此，KUnit测试最好不要写得太小，也不要有内核中本身包含的部分，以便
seems a translation mistake?
against small, self-contained parts of the Kernel
最好针对内核中较小的、自包含的部分，
> +能够独立地测试。‘单元’测试的概念亦是如此。
‘’ -> “” would be better
> +
> +比如，一个KUnit测试可能测试一个单独的内核功能（甚至通过一个函数测试
> +一个单一的代码路径），而不是整个地测试一个特性。
missed a sentence
, such as an error handling case
> +
> +这也使得KUnit测试构建和运行非常地快，从而能够作为开发流程的一部分被
的测试构建和运行非常快
> +频繁地运行。
> +
> +有关更详细的介绍，请参阅KUnit测试代码风格指南
> +Documentation/translations/zh_CN/dev-tools/kunit/style.rst
^path
> +
> +kselftest（Documentation/translations/zh_CN/dev-tools/kselftest.rst），
^path
> +另一方面，大量地在用户空间被实现，并且测试通常是用户空间的脚本或程序。
相对来说，大量用于用户空间，并且通常测试用户空间的脚本或程序。
> +
> +这使得编写复杂的测试，或者需要操作更多全局系统状态的测试更加容易（诸
> +如生成进程之类）。然而，从kselftest直接调用内核函数是不行的。这也就
> +意味着只有通过某种方式（如系统调用、驱动设备、文件系统等）导出到了用
> +户空间的内核功能才能使用kselftest来测试。为此，有些测试包含了一个伴
> +生的内核模块用于导出更多的信息和功能。不过，对于基本上或者完全在内核
> +中运行的测试，KUnit可能是更佳工具。
> +
missed a paragraph
kselftest is therefore suited well to tests of whole features, as these will
expose an interface to userspace, which can be tested, but not implementation
details. This aligns well with 'system' or 'end-to-end' testing.
> +比如，一个新的系统调用应该伴随有新的kselftest测试。
> +
> +代码覆盖率工具
> +==============
> +
> +Linux内核支持不同代码之间的覆盖率测量工具。这能被用来验证一个测试是
支持两种不同的代码覆盖率测试工具。
它们可以用来验证一项测试执行的确切函数或代码行。
> +执行的特定的函数或者特定行的代码。这有助于决定内核被测试了多少，或
> +用来查找合适的测试中没有覆盖到的极端情况。
> +
> +:doc:`gcov` 是GCC的覆盖率测试工具，能用于获取内核的全局或每个模块的
> +覆盖率。与KCOV不同的是，这个工具不记录每个任务的覆盖率。覆盖率数据可
> +以通过debugfs读取，并通过常规的gcov工具进行解释。
> +
> +:doc:`kcov` 是能够构建在内核之中，用于在每个任务的层面捕捉覆盖率的一
> +个功能。因此，对于代码执行位置信息的其它情况，它是非常有用的，比如在
因此，它对于模糊测试和关于代码执行期间信息的其它情况非常有用。
> +一个单一系统调用里使用它就很有用。
> +
> +动态分析工具
> +============
> +
> +内核也支持许多动态分析工具，用以检测正在运行的内核中出现的多种类型的
> +问题。这些工具尤其用于不同类型的漏洞，比如非法内存访问，诸如数据竞争
这些工具通常每个去寻找一类不同的缺陷，比如非法内存访问，数据竞争等并发问题，
或整型溢出等其他未定义行为。
> +的并发问题，或者整型溢出的其它未定义的行为。
> +
> +一些工具如下：
如下所示
> +
> +* kmemleak检测可能的内存泄漏。参阅
> + Documentation/dev-tools/kmemleak.rst
> +* KASAN检测非法内存访问，如数组越界和释放内存后再使用的错误。参阅
释放后重用（UAF）
> + Documentation/dev-tools/kasan.rst
> +* UBSAN检测C标准中未定义的行为，如整型溢出。参阅
> + Documentation/dev-tools/ubsan.rst
> +* KCSAN检测数据竞争。参阅 Documentation/dev-tools/kcsan.rst
> +* KFENCE是一个低开销的内存问题检测器，比KASAN更快而能被用于批量构建。
而 -> 且
> + 参阅 Documentation/dev-tools/kfence.rst
> +* lockdep是一个锁定正确性检测器。参阅
> + Documentation/locking/lockdep-design.rst
> +* 除此以外，在内核中还有一些其它的调试工具，大多数能在
> + lib/Kconfig.debug 中找到。
> +
> +这些工具倾向于对内核进行整体测试，并且不像kselftest和KUnit一样“传递”。
> +它们能与kselftest和KUnit结合起来，通过激活这些工具在一个内核上运行测
> +试：之后你就能确保这些错误在测试过程中都不会发生了。
它们可以通过在启用这些工具时运行内核测试以与kselftest或KUnit结合起来：
> +
> +一些工具与KUnit和kselftest集成，并且当问题被检测时测试会自动失败。
并且在检测到问题时会自动打断测试。
> +
> --
> 2.25.1
And please re-arrange your patches in appropriate thread and remember to change
version each time when you send them, or may let Corbet confused.
Thanks,
Wu X.C.
在 2021/5/23 下午10:03, Wu X.C. 写道:
>> Create new translations for dev-tools/testing-overview.rst and link it
>> to dev-tools/index.rst with TODOList modifications.
>>
>> Signed-off-by: Hu Haowen <[email protected]>
>> ---
>> .../translations/zh_CN/dev-tools/index.rst | 2 +
>> .../zh_CN/dev-tools/testing-overview.rst | 99 +++++++++++++++++++
>> 2 files changed, 101 insertions(+)
>> create mode 100644 Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>>
>> diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst
>> index 7ba02fc392a6..b6b6d3b09acc 100644
>> --- a/Documentation/translations/zh_CN/dev-tools/index.rst
>> +++ b/Documentation/translations/zh_CN/dev-tools/index.rst
>> @@ -22,6 +22,7 @@ Documentation/dev-tools/testing-overview.rst
>> :maxdepth: 2
>>
>> gcov
>> + testing-overview
>>
>> Todolist:
>>
>> @@ -32,6 +33,7 @@ Todolist:
>> - ubsan
>> - kmemleak
>> - kcsan
>> + - kfence
>> - gdb-kernel-debugging
>> - kgdb
>> - kselftest
>> diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>> new file mode 100644
>> index 000000000000..6e2046ac53ff
>> --- /dev/null
>> +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>> @@ -0,0 +1,12 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +.. include:: ../disclaimer-zh_CN.rst
>> +
>> +:Original: Documentation/dev-tools/testing-overview.rst
>> +:Translator: 胡皓文 Hu Haowen <[email protected]>
>> +
>> +============
>> +内核测试指南
>> +============
>> +
>> +有许多不同的工具可以用于测试Linux内核，因此知道什么时候使用它们可能
> s/知道/了解/
>
>> +很困难。该文档提供了它们之间区别的一个粗略概览，并阐释了它们怎样糅
> maybe
> 本文档粗略概述了它们之间的区别
>
> 是怎样
>
>> +合在一起的。
>> +
>> +编写和运行测试
>> +==============
>> +
>> +大多数内核测试都是用kselftest或KUnit框架之一编写的。它们都让运行测试
>>
>> 都提供了让运行测试更简单的的基础设施，
>>
>> +更加简化，并为编写新测试提供帮助。
>> +
>> +如果你想验证内核的行为——尤其是内核的特定部分——那你就要使用kUnit或
>> +kselftest。
>> +
>> +KUnit和kselftest的区别
>> +----------------------
>> +
>> +KUnit（Documentation/zh_CN/dev-tools/kunit/index.rst）是用于“白箱”测
> Seems we don't have this translation yet, so plese use the link point to En version.
> So as followed paths.
>
>> +试的一个完整的内核内部系统：因为测试代码是内核的一部分，所以它能够访
>> +问用户空间不能访问到的内部结构和功能。
>> +
>> +因此，KUnit测试最好不要写得太小，也不要有内核中本身包含的部分，以便
> seems a translation mistake?
>
> against small, self-contained parts of the Kernel
> 最好针对内核中较小的、自包含的部分，
>
>> +能够独立地测试。‘单元’测试的概念亦是如此。
> ‘’ -> “” would be better
>
>> +
>> +比如，一个KUnit测试可能测试一个单独的内核功能（甚至通过一个函数测试
>> +一个单一的代码路径），而不是整个地测试一个特性。
> missed a sentence
> , such as an error handling case
>
>> +
>> +这也使得KUnit测试构建和运行非常地快，从而能够作为开发流程的一部分被
> 的测试构建和运行非常快
>
>> +频繁地运行。
>> +
>> +有关更详细的介绍，请参阅KUnit测试代码风格指南
>> +Documentation/translations/zh_CN/dev-tools/kunit/style.rst
> ^path
>
>> +
>> +kselftest（Documentation/translations/zh_CN/dev-tools/kselftest.rst），
> ^path
>
>> +另一方面，大量地在用户空间被实现，并且测试通常是用户空间的脚本或程序。
> 相对来说，大量用于用户空间，并且通常测试用户空间的脚本或程序。
>
>> +
>> +这使得编写复杂的测试，或者需要操作更多全局系统状态的测试更加容易（诸
>> +如生成进程之类）。然而，从kselftest直接调用内核函数是不行的。这也就
>> +意味着只有通过某种方式（如系统调用、驱动设备、文件系统等）导出到了用
>> +户空间的内核功能才能使用kselftest来测试。为此，有些测试包含了一个伴
>> +生的内核模块用于导出更多的信息和功能。不过，对于基本上或者完全在内核
>> +中运行的测试，KUnit可能是更佳工具。
>> +
> missed a paragraph
>
> kselftest is therefore suited well to tests of whole features, as these will
> expose an interface to userspace, which can be tested, but not implementation
> details. This aligns well with 'system' or 'end-to-end' testing.
>
>
>> +比如，一个新的系统调用应该伴随有新的kselftest测试。
>> +
>> +代码覆盖率工具
>> +==============
>> +
>> +Linux内核支持不同代码之间的覆盖率测量工具。这能被用来验证一个测试是
> 支持两种不同的代码覆盖率测试工具。
>
> 它们可以用来验证一项测试执行的确切函数或代码行。
>
>> +执行的特定的函数或者特定行的代码。这有助于决定内核被测试了多少，或
>> +用来查找合适的测试中没有覆盖到的极端情况。
>> +
>> +:doc:`gcov` 是GCC的覆盖率测试工具，能用于获取内核的全局或每个模块的
>> +覆盖率。与KCOV不同的是，这个工具不记录每个任务的覆盖率。覆盖率数据可
>> +以通过debugfs读取，并通过常规的gcov工具进行解释。
>> +
>> +:doc:`kcov` 是能够构建在内核之中，用于在每个任务的层面捕捉覆盖率的一
>> +个功能。因此，对于代码执行位置信息的其它情况，它是非常有用的，比如在
> 因此，它对于模糊测试和关于代码执行期间信息的其它情况非常有用。
>
>> +一个单一系统调用里使用它就很有用。
>> +
>> +动态分析工具
>> +============
>> +
>> +内核也支持许多动态分析工具，用以检测正在运行的内核中出现的多种类型的
>> +问题。这些工具尤其用于不同类型的漏洞，比如非法内存访问，诸如数据竞争
> 这些工具通常每个去寻找一类不同的缺陷，比如非法内存访问，数据竞争等并发问题，
> 或整型溢出等其他未定义行为。
>
>> +的并发问题，或者整型溢出的其它未定义的行为。
>> +
>> +一些工具如下：
> 如下所示
>
>> +
>> +* kmemleak检测可能的内存泄漏。参阅
>> + Documentation/dev-tools/kmemleak.rst
>> +* KASAN检测非法内存访问，如数组越界和释放内存后再使用的错误。参阅
> 释放后重用（UAF）
>
>> + Documentation/dev-tools/kasan.rst
>> +* UBSAN检测C标准中未定义的行为，如整型溢出。参阅
>> + Documentation/dev-tools/ubsan.rst
>> +* KCSAN检测数据竞争。参阅 Documentation/dev-tools/kcsan.rst
>> +* KFENCE是一个低开销的内存问题检测器，比KASAN更快而能被用于批量构建。
> 而 -> 且
>
>> + 参阅 Documentation/dev-tools/kfence.rst
>> +* lockdep是一个锁定正确性检测器。参阅
>> + Documentation/locking/lockdep-design.rst
>> +* 除此以外，在内核中还有一些其它的调试工具，大多数能在
>> + lib/Kconfig.debug 中找到。
>> +
>> +这些工具倾向于对内核进行整体测试，并且不像kselftest和KUnit一样“传递”。
>> +它们能与kselftest和KUnit结合起来，通过激活这些工具在一个内核上运行测
>> +试：之后你就能确保这些错误在测试过程中都不会发生了。
> 它们可以通过在启用这些工具时运行内核测试以与kselftest或KUnit结合起来：
>
>> +
>> +一些工具与KUnit和kselftest集成，并且当问题被检测时测试会自动失败。
> 并且在检测到问题时会自动打断测试。
>
>> +
>> --
>> 2.25.1
> And please re-arrange your patches in appropriate thread and remember to change
> version each time when you send them, or may let Corbet confused.
OK, I'll correct them.
Because this is my first time to kernel translation work, there might
be something wrong, after all thanks for pointing them out.
> Thanks,
> Wu X.C.
>
On Mon, May 24, 2021 at 08:13:50PM +0800, Hu Haowen wrote:
>
> OK, I'll correct them.
>
>
> Because this is my first time to kernel translation work, there might
> be something wrong, after all thanks for pointing them out.
>
Welcome to join us! <http://fars.ee/3TKR.gif>
The points which I given are just suggestions. If you have any ideas or
questions, just ask/say.
Thanks,
Wu X.C.
在 2021/5/23 下午10:03, Wu X.C. 写道:
>> Create new translations for dev-tools/testing-overview.rst and link it
>> to dev-tools/index.rst with TODOList modifications.
>>
>> Signed-off-by: Hu Haowen <[email protected]>
>> ---
>> .../translations/zh_CN/dev-tools/index.rst | 2 +
>> .../zh_CN/dev-tools/testing-overview.rst | 99 +++++++++++++++++++
>> 2 files changed, 101 insertions(+)
>> create mode 100644 Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>>
>> diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst
>> index 7ba02fc392a6..b6b6d3b09acc 100644
>> --- a/Documentation/translations/zh_CN/dev-tools/index.rst
>> +++ b/Documentation/translations/zh_CN/dev-tools/index.rst
>> @@ -22,6 +22,7 @@ Documentation/dev-tools/testing-overview.rst
>> :maxdepth: 2
>>
>> gcov
>> + testing-overview
>>
>> Todolist:
>>
>> @@ -32,6 +33,7 @@ Todolist:
>> - ubsan
>> - kmemleak
>> - kcsan
>> + - kfence
>> - gdb-kernel-debugging
>> - kgdb
>> - kselftest
>> diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>> new file mode 100644
>> index 000000000000..6e2046ac53ff
>> --- /dev/null
>> +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
>> @@ -0,0 +1,12 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +.. include:: ../disclaimer-zh_CN.rst
>> +
>> +:Original: Documentation/dev-tools/testing-overview.rst
>> +:Translator: 胡皓文 Hu Haowen <[email protected]>
>> +
>> +============
>> +内核测试指南
>> +============
>> +
>> +有许多不同的工具可以用于测试Linux内核，因此知道什么时候使用它们可能
> s/知道/了解/
>
>> +很困难。该文档提供了它们之间区别的一个粗略概览，并阐释了它们怎样糅
> maybe
> 本文档粗略概述了它们之间的区别
>
> 是怎样
>
>> +合在一起的。
>> +
>> +编写和运行测试
>> +==============
>> +
>> +大多数内核测试都是用kselftest或KUnit框架之一编写的。它们都让运行测试
>>
>> 都提供了让运行测试更简单的的基础设施，
>>
>> +更加简化，并为编写新测试提供帮助。
>> +
>> +如果你想验证内核的行为——尤其是内核的特定部分——那你就要使用kUnit或
>> +kselftest。
>> +
>> +KUnit和kselftest的区别
>> +----------------------
>> +
>> +KUnit（Documentation/zh_CN/dev-tools/kunit/index.rst）是用于“白箱”测
> Seems we don't have this translation yet, so plese use the link point to En version.
> So as followed paths.
How do I add a link to the English version? Should I mark this section
in a comment here or directly explain in the document?
>> +试的一个完整的内核内部系统：因为测试代码是内核的一部分，所以它能够访
>> +问用户空间不能访问到的内部结构和功能。
>> +
>> +因此，KUnit测试最好不要写得太小，也不要有内核中本身包含的部分，以便
> seems a translation mistake?
>
> against small, self-contained parts of the Kernel
> 最好针对内核中较小的、自包含的部分，
>
>> +能够独立地测试。‘单元’测试的概念亦是如此。
> ‘’ -> “” would be better
>
>> +
>> +比如，一个KUnit测试可能测试一个单独的内核功能（甚至通过一个函数测试
>> +一个单一的代码路径），而不是整个地测试一个特性。
> missed a sentence
> , such as an error handling case
>
>> +
>> +这也使得KUnit测试构建和运行非常地快，从而能够作为开发流程的一部分被
> 的测试构建和运行非常快
>
>> +频繁地运行。
>> +
>> +有关更详细的介绍，请参阅KUnit测试代码风格指南
>> +Documentation/translations/zh_CN/dev-tools/kunit/style.rst
> ^path
>
>> +
>> +kselftest（Documentation/translations/zh_CN/dev-tools/kselftest.rst），
> ^path
>
>> +另一方面，大量地在用户空间被实现，并且测试通常是用户空间的脚本或程序。
> 相对来说，大量用于用户空间，并且通常测试用户空间的脚本或程序。
>
>> +
>> +这使得编写复杂的测试，或者需要操作更多全局系统状态的测试更加容易（诸
>> +如生成进程之类）。然而，从kselftest直接调用内核函数是不行的。这也就
>> +意味着只有通过某种方式（如系统调用、驱动设备、文件系统等）导出到了用
>> +户空间的内核功能才能使用kselftest来测试。为此，有些测试包含了一个伴
>> +生的内核模块用于导出更多的信息和功能。不过，对于基本上或者完全在内核
>> +中运行的测试，KUnit可能是更佳工具。
>> +
> missed a paragraph
>
> kselftest is therefore suited well to tests of whole features, as these will
> expose an interface to userspace, which can be tested, but not implementation
> details. This aligns well with 'system' or 'end-to-end' testing.
>
>
>> +比如，一个新的系统调用应该伴随有新的kselftest测试。
>> +
>> +代码覆盖率工具
>> +==============
>> +
>> +Linux内核支持不同代码之间的覆盖率测量工具。这能被用来验证一个测试是
> 支持两种不同的代码覆盖率测试工具。
>
> 它们可以用来验证一项测试执行的确切函数或代码行。
>
>> +执行的特定的函数或者特定行的代码。这有助于决定内核被测试了多少，或
>> +用来查找合适的测试中没有覆盖到的极端情况。
>> +
>> +:doc:`gcov` 是GCC的覆盖率测试工具，能用于获取内核的全局或每个模块的
>> +覆盖率。与KCOV不同的是，这个工具不记录每个任务的覆盖率。覆盖率数据可
>> +以通过debugfs读取，并通过常规的gcov工具进行解释。
>> +
>> +:doc:`kcov` 是能够构建在内核之中，用于在每个任务的层面捕捉覆盖率的一
>> +个功能。因此，对于代码执行位置信息的其它情况，它是非常有用的，比如在
> 因此，它对于模糊测试和关于代码执行期间信息的其它情况非常有用。
>
>> +一个单一系统调用里使用它就很有用。
>> +
>> +动态分析工具
>> +============
>> +
>> +内核也支持许多动态分析工具，用以检测正在运行的内核中出现的多种类型的
>> +问题。这些工具尤其用于不同类型的漏洞，比如非法内存访问，诸如数据竞争
> 这些工具通常每个去寻找一类不同的缺陷，比如非法内存访问，数据竞争等并发问题，
> 或整型溢出等其他未定义行为。
>
>> +的并发问题，或者整型溢出的其它未定义的行为。
>> +
>> +一些工具如下：
> 如下所示
>
>> +
>> +* kmemleak检测可能的内存泄漏。参阅
>> + Documentation/dev-tools/kmemleak.rst
>> +* KASAN检测非法内存访问，如数组越界和释放内存后再使用的错误。参阅
> 释放后重用（UAF）
>
>> + Documentation/dev-tools/kasan.rst
>> +* UBSAN检测C标准中未定义的行为，如整型溢出。参阅
>> + Documentation/dev-tools/ubsan.rst
>> +* KCSAN检测数据竞争。参阅 Documentation/dev-tools/kcsan.rst
>> +* KFENCE是一个低开销的内存问题检测器，比KASAN更快而能被用于批量构建。
> 而 -> 且
>
>> + 参阅 Documentation/dev-tools/kfence.rst
>> +* lockdep是一个锁定正确性检测器。参阅
>> + Documentation/locking/lockdep-design.rst
>> +* 除此以外，在内核中还有一些其它的调试工具，大多数能在
>> + lib/Kconfig.debug 中找到。
>> +
>> +这些工具倾向于对内核进行整体测试，并且不像kselftest和KUnit一样“传递”。
>> +它们能与kselftest和KUnit结合起来，通过激活这些工具在一个内核上运行测
>> +试：之后你就能确保这些错误在测试过程中都不会发生了。
> 它们可以通过在启用这些工具时运行内核测试以与kselftest或KUnit结合起来：
>
>> +
>> +一些工具与KUnit和kselftest集成，并且当问题被检测时测试会自动失败。
> 并且在检测到问题时会自动打断测试。
>
>> +
>> --
>> 2.25.1
> And please re-arrange your patches in appropriate thread and remember to change
> version each time when you send them, or may let Corbet confused.
Other places have already fixed, waiting for a solution for the problem
above. Btw, I'm a bit busy these days, sorry for my late reply.
Thx,
Hu Haowen
> Thanks,
> Wu X.C.
>
