diff --git a/docs/master-soft-test-junit5/1.md b/docs/master-soft-test-junit5/1.md
index 471d16d0838d600d4e65cf8390eca0de51ae155c..7150dadddd631a92baae88278caba2917dfb89fd 100644
--- a/docs/master-soft-test-junit5/1.md
+++ b/docs/master-soft-test-junit5/1.md
@@ -252,7 +252,7 @@ ISO/IEC-25000 的质量模型将产品质量模型（即内部和外部属性）
 
 *   **代码覆盖率**定义了源代码的程度，例如，已测试的 LOC 百分比。代码覆盖率有几个标准：
     1.  语句覆盖率：代码覆盖粒度的一行。
-    2.  决策（分支）覆盖：控制结构（例如，if-else）覆盖粒度。
+    2.  决策（分支）覆盖：控制结构（例如，`if-else`）覆盖粒度。
     3.  条件覆盖率：布尔表达式（真-假）覆盖粒度。
     4.  路径覆盖：每个可能的路由覆盖粒度。
     5.  函数覆盖：程序函数覆盖粒度。
@@ -394,7 +394,7 @@ JUnit3 允许通过称为 TestRunner 的 Java 应用程序运行测试用例。J
 
 构建工具（如 Ant 或 Maven）和**集成开发环境**（**IDE**）（如 Eclipse 和 IntelliJ）实现自己的 JUnit 测试运行程序是一种常见做法。
 
-下图显示了当我们使用 JUnit Swing runner 时，以及当我们使用 Eclipse 运行相同的测试用例时，前面的测试是什么样子的。
+下图显示了当我们使用 JUnit Swing 运行器时，以及当我们使用 Eclipse 运行相同的测试用例时，前面的测试是什么样子的。
 
 ![](img/00012.jpeg)
 
@@ -443,7 +443,7 @@ JUnit4 仍然是一个开源框架，尽管许可证相对于 JUnit3 有所改
 
 JUnit4 与 JUnit3 的主要区别之一是 JUnit4 允许定义测试的方式。在 JUnit4 中，Java 注释用于将方法标记为测试。因此，JUnit4 只能用于 Java5 或更高版本。正如 JUnit 4.0 的文档在 2006 年所述：
 
-JUnit4.0 的体系结构与早期版本的体系结构有很大的不同。不再通过子类化 junit.framework.TestCase 来标记测试类，也不再通过以“test”开头的名称来标记测试方法，而是使用@test 注释来标记测试方法。
+JUnit4.0 的体系结构与早期版本的体系结构有很大的不同。不再通过子类化`junit.framework.TestCase`来标记测试类，也不再通过以`test`开头的名称来标记测试方法，而是使用`@test`注释来标记测试方法。
 
 # JUnit4 中的标准测试
 
@@ -548,11 +548,11 @@ public class TestSimple {
 
 # JUnit4 中的测试执行
 
-测试运行程序的概念也出现在 JUnit4 中，但是相对于 JUnit3 它有了一些改进。在 JUnit4 中，测试运行程序是一个 Java 类，用于管理测试的生命周期：实例化、调用 setup 和 teardown 方法、运行测试、处理异常、发送通知等等。默认的 JUnit4 测试运行程序名为`BlockJUnit4ClassRunner`，它实现 JUnit4 标准测试用例类模型。
+测试运行程序的概念也出现在 JUnit4 中，但是相对于 JUnit3 它有了一些改进。在 JUnit4 中，测试运行程序是一个 Java 类，用于管理测试的生命周期：实例化、调用配置和收尾方法、运行测试、处理异常、发送通知等等。默认的 JUnit4 测试运行程序名为`BlockJUnit4ClassRunner`，它实现 JUnit4 标准测试用例类模型。
 
 在 JUnit4 测试用例中使用的测试运行程序可以简单地使用注释`@RunWith`进行更改。JUnit4 提供了一个内置测试运行程序的集合，允许更改测试类的性质。在本节中，我们将回顾最重要的部分。
 
-*   为了运行一组测试（即测试套件），JUnit4 提供了`Suite`运行程序。除了 runner 之外，`Suite.SuiteClasses`类还允许定义属于该套件的各个测试类。例如：
+*   为了运行一组测试（即测试套件），JUnit4 提供了`Suite`运行程序。除了运行器之外，`Suite.SuiteClasses`类还允许定义属于该套件的各个测试类。例如：
 
 ```java
  package io.github.bonigarcia;
diff --git a/docs/master-soft-test-junit5/2.md b/docs/master-soft-test-junit5/2.md
index ebc465223a430d46dde8e8bc1c0df2aedb9ec108..e6ea4b05625a5639a3009c61c0cda72f52823f2b 100644
--- a/docs/master-soft-test-junit5/2.md
+++ b/docs/master-soft-test-junit5/2.md
@@ -43,9 +43,9 @@ JUnit 作为平台的成功阻止了 JUnit 作为测试工具的开发。我们
 
 # JUnit 4 级运动员
 
-JUnit4 的 runner API 也具有重要的威慑作用。如第 1 章“软件质量和 Java 测试回顾”所述，在 JUnit4 中，runner 是一个 Java 类，用于管理测试的生命周期。JUnit4 中的 runner API 非常强大，但是它有一个重要的缺点：runner 是不可组合的，也就是说，我们一次只能使用一个 runner。
+JUnit4 的运行器 API 也具有重要的威慑作用。如第 1 章“软件质量和 Java 测试回顾”所述，在 JUnit4 中，运行器是一个 Java 类，用于管理测试的生命周期。JUnit4 中的运行器 API 非常强大，但是它有一个重要的缺点：运行器是不可组合的，也就是说，我们一次只能使用一个运行器。
 
-例如，参数化测试不能与 Spring 测试支持相结合，因为两个测试都将使用自己的 runner 实现。用 Java 思考（参见下面给出的代码片段），每个测试用例都使用自己独特的`@RunWith`注释。第一个使用`Parameterized`跑步者：
+例如，参数化测试不能与 Spring 测试支持相结合，因为两个测试都将使用自己的运行器 实现。用 Java 思考（参见下面给出的代码片段），每个测试用例都使用自己独特的`@RunWith`注释。第一个使用`Parameterized`跑步者：
 
 ```java
 import org.junit.Test;
@@ -63,7 +63,7 @@ public class MyParameterizedTest {
 }
 ```
 
-虽然第二个示例使用的是`SpringJUnit4ClassRunner`runner，但由于 JUnit4 的限制（runner 是不可组合的），它不会与前一个示例结合使用：
+虽然第二个示例使用的是`SpringJUnit4ClassRunner`运行器，但由于 JUnit4 的限制（运行器是不可组合的），它不会与前一个示例结合使用：
 
 ```java
 import org.junit.Test;
@@ -568,7 +568,7 @@ Eclipse 中 ConsoleLancher 的示例
 
 JUnit5 被设计为向前和向后兼容。一方面，Vintage 组件支持在 JUnit3 和 JUnit4 上运行遗留代码。另一方面，JUnit 5 提供了一个 JUnit 4 运行程序，它允许在 IDE 中运行 JUnit 5，并构建支持 JUnit 4 的系统，但还不能直接支持新的 JUnit 平台 5。
 
-让我们看一个例子。假设我们想要在一个不支持 JUnit5 的 IDE 中运行 Jupiter 测试，例如旧版本的 Eclipse。在这种情况下，我们需要用`@RunWith(JUnitPlatform.class)`注释我们的 Jupiter 测试。`JUnitPlatform`runner 是一个基于 JUnit 4 的 runner，它支持在 JUnit 4 环境中运行其编程模型在 JUnit 平台上受支持的任何测试。因此，我们的测试结果如下：
+让我们看一个例子。假设我们想要在一个不支持 JUnit5 的 IDE 中运行 Jupiter 测试，例如旧版本的 Eclipse。在这种情况下，我们需要用`@RunWith(JUnitPlatform.class)`注释我们的 Jupiter 测试。`JUnitPlatform`运行器是一个基于 JUnit 4 的运行器，它支持在 JUnit 4 环境中运行其编程模型在 JUnit 平台上受支持的任何测试。因此，我们的测试结果如下：
 
 ```java
 package io.github.bonigarcia;
diff --git a/docs/master-soft-test-junit5/3.md b/docs/master-soft-test-junit5/3.md
index 37ec35af5750402b405bd30485ef46b29053a7f4..28e06e6e890bfc3c58a27979ef6daaa039f1c84c 100644
--- a/docs/master-soft-test-junit5/3.md
+++ b/docs/master-soft-test-junit5/3.md
@@ -301,13 +301,13 @@ class StandardAssertionsTest {
 }
 ```
 
-本节的以下部分回顾了 Jupiter 提供的 advance 断言：`assertAll`、`assertThrows`、`assertTimeout`和`assertTimeoutPreemptively`。
+本节的以下部分回顾了 Jupiter 提供的高级断言：`assertAll`、`assertThrows`、`assertTimeout`和`assertTimeoutPreemptively`。
 
 # 断言组
 
 一个重要的木星断言是`assertAll`。此方法允许同时对不同的断言进行分组。在分组断言中，始终执行所有断言，任何失败都将一起报告。
 
-方法`assertAll`接受 Lambda 表达式的 vargargs（`Executable…`）或这些表达式的流（`Stream<Executable>`）。可选地，`assertAll`的第一个参数可以是用于标记断言组的字符串消息。
+方法`assertAll`接受 Lambda 表达式的可变参数（`Executable…`）或这些表达式的流（`Stream<Executable>`）。可选地，`assertAll`的第一个参数可以是用于标记断言组的字符串消息。
 
 让我们看一个例子。在下面的测试中，我们使用 Lambda 表达式将几个`assertEquals`分组：
 
@@ -450,7 +450,7 @@ class TimeoutWithResultOrMethodTest {
 
 ![](img/00049.gif)
 
-assertTimeout第二例控制台输出
+`assertTimeout`第二例控制台输出
 
 另一个 Jupiter 超时断言称为`assertTimeoutPreemptively`。与`assertTimeoutPreemptively`关于`assertTimeout`的区别在于`assertTimeoutPreemptively`没有等到操作结束，当超过预期超时时，执行被中止。
 
@@ -486,11 +486,11 @@ class TimeoutWithPreemptiveTerminationTest {
 
 正如我们所看到的，为 Jupiter 提供的开箱即用的内置断言对于许多测试场景来说已经足够了。然而，有时可能需要更多的附加功能，例如匹配器。在这种情况下，JUnit 团队建议使用以下第三方断言库：
 
-*   [Hamcrest](http://hamcrest.org/)：一个断言框架，用于编写 matcher 对象，允许以声明方式定义规则。
+*   [Hamcrest](http://hamcrest.org/)：一个断言框架，用于编写匹配器对象，允许以声明方式定义规则。
 *   [AssertJ](http://joel-costigliola.github.io/assertj/)：流畅的 Java 断言。
 *   [Truth](https://google.github.io/truth/)：一个断言 Java 库，旨在使测试断言和失败消息更具可读性。
 
-在本节中，我们将简要回顾 Hamcrest。这个库提供了断言`assertThat`，它允许创建可读的高度可配置的断言。方法`assertThat`接受两个参数：第一个是实际对象，第二个是`Matcher`对象。此匹配器实现接口`org.hamcrest.Matcher`，并启用预期的部分或精确匹配。Hamcrest 提供不同的 matcher 实用程序，例如`is`、`either`、`or`、`not`和`hasItem`。Matcher 方法使用生成器模式，允许组合一个或多个 Matcher 来构建 Matcher 链。
+在本节中，我们将简要回顾 Hamcrest。这个库提供了断言`assertThat`，它允许创建可读的高度可配置的断言。方法`assertThat`接受两个参数：第一个是实际对象，第二个是`Matcher`对象。此匹配器实现接口`org.hamcrest.Matcher`，并启用预期的部分或精确匹配。Hamcrest 提供不同的匹配器实用程序，例如`is`、`either`、`or`、`not`和`hasItem`。`Matcher`方法使用生成器模式，允许组合一个或多个`Matcher`来构建`Matcher`链。
 
 为了使用 Hamcrest，首先我们需要在项目中导入依赖项。在 Maven 项目中，这意味着我们必须在`pom.xml`文件中包含以下依赖项：
 
@@ -1111,7 +1111,7 @@ class NestTest {
 }
 ```
 
-如果执行这个示例，只需查看控制台跟踪，就可以跟踪嵌套测试的执行。请注意，每次测试前都会执行 top`@BeforeEach`方法（称为`setup1`）。因此，在实际测试执行之前，跟踪`Setup 1`始终存在于控制台中。每个测试还向控制台写入一行代码。我们可以看到，第一个测试记录了`Test 1`。然后，执行内部类中定义的测试。第一个内部类执行测试`innerTest1`，但之后，执行顶级类和第一个内部类的设置方法（分别记录`Setup 1`和`Setup 2`。
+如果执行这个示例，只需查看控制台跟踪，就可以跟踪嵌套测试的执行。请注意，每次测试前都会执行顶部的`@BeforeEach`方法（称为`setup1`）。因此，在实际测试执行之前，跟踪`Setup 1`始终存在于控制台中。每个测试还向控制台写入一行代码。我们可以看到，第一个测试记录了`Test 1`。然后，执行内部类中定义的测试。第一个内部类执行测试`innerTest1`，但之后，执行顶级类和第一个内部类的设置方法（分别记录`Setup 1`和`Setup 2`。
 
 最后，执行最后一个内部类（`innerTest2`中定义的测试，但通常在测试之前执行设置方法的级联：
 
@@ -1440,4 +1440,4 @@ Jupiter 提供了一组丰富的断言，这些断言是类`Assertions`中的静
 
 我们已经了解了如何使用`@Nested`简单地注释内部 Java 类来创建嵌套测试。这可用于按照给定嵌套类关系的顺序创建测试执行。我们还研究了使用 JUnit5 编程模型创建重复测试的容易程度。注释`@RepeatedTest`用于该目的，提供重复测试指定次数的能力。最后，我们已经了解了 Jupiter 如何为几个遗留的 JUnit4 测试规则提供支持，包括`ExternalResource`、`Verifier`和`ExpectedException`。
 
-在第 4 章中“使用高级 JUnit 特性简化测试”我们继续发现 JUnit 编程模型。具体地说，我们回顾了 JUnit5 的高级特性，即依赖注入、动态测试、测试接口、测试模板、参数化测试、JUnit5 和 Java9 的兼容性。最后，我们回顾了 JUnit5.1 积压工作中计划的一些特性，在撰写本文时这些特性尚未实现。**
\ No newline at end of file
+在第 4 章中“使用高级 JUnit 特性简化测试”我们继续发现 JUnit 编程模型。具体地说，我们回顾了 JUnit5 的高级特性，即依赖注入、动态测试、测试接口、测试模板、参数化测试、JUnit5 和 Java9 的兼容性。最后，我们回顾了 JUnit5.1 积压工作中计划的一些特性，在撰写本文时这些特性尚未实现。
\ No newline at end of file
diff --git a/docs/master-soft-test-junit5/5.md b/docs/master-soft-test-junit5/5.md
index d32344308b881e93fba26dc2b5fc0b24850e4c94..34311e4db7a2d8ee73d61ae95f297e267de559a5 100644
--- a/docs/master-soft-test-junit5/5.md
+++ b/docs/master-soft-test-junit5/5.md
@@ -171,7 +171,7 @@ public class MockitoExtension
 MockitoAnnotations.initMocks(testInstance)
 ```
 
-这与在 Mockito 中使用 JUnit4 runner 的效果相同：`@RunWith(MockitoJUnitRunner.class)`。
+这与在 Mockito 中使用 JUnit4 运行器的效果相同：`@RunWith(MockitoJUnitRunner.class)`。
 
 此外，该扩展还实现了接口`ParameterResolver`。这意味着在注册扩展（`@ExtendWith(MockitoExtension.class)`的测试中允许方法级的依赖项注入。特别是，注释将为带有`@Mock`注释的测试参数（位于包`org.mockito`中）注入模拟对象。
 
diff --git a/docs/test-driven-java-dev/02.md b/docs/test-driven-java-dev/02.md
index bf5ac2bd275f862587de0dcbbce4bab45a6296d9..f97471ffbaf5fe1b37f9eb9f50e5df37c15b708c 100644
--- a/docs/test-driven-java-dev/02.md
+++ b/docs/test-driven-java-dev/02.md
@@ -659,7 +659,7 @@ dependencies {
 
 Mockito跑过JUnit赛跑者。它为我们创建所有必需的模拟，并通过测试将它们注入类中。有两种基本方法；我们自己实例化 mock，并通过类构造函数或使用一组注释将它们作为类依赖项注入。在下一个示例中，我们将看到如何使用注释来完成。
 
-为了让类使用 Mockito 注释，它需要与`MockitoJUnitRunner`一起运行。使用 runner 简化了流程，因为您只需向要创建的对象添加注释：
+为了让类使用 Mockito 注释，它需要与`MockitoJUnitRunner`一起运行。使用运行器简化了流程，因为您只需向要创建的对象添加注释：
 
 ```java
 @RunWith(MockitoJUnitRunner.class) 
@@ -734,7 +734,7 @@ public class FriendshipsTest {
 }
 ```
 
-从本质上讲，runner 的操作与 Mockito runner 相同：
+从本质上讲，运行器的操作与 Mockito 运行器相同：
 
 ```java
 @TestSubject 
diff --git a/docs/test-driven-java-dev/08.md b/docs/test-driven-java-dev/08.md
index e171b694a7985036fa57d5caa74066fee5ed8278..d539c9f228138c1a8afd8c36e85acbd630f55f47 100644
--- a/docs/test-driven-java-dev/08.md
+++ b/docs/test-driven-java-dev/08.md
@@ -225,7 +225,7 @@ Then book is removed
 
 # 杰伯哈夫
 
-JBehave 需要两个主要组件来运行 BDD 故事和步骤。runner 是一个类，它将解析故事、运行所有场景并生成报告。步骤是与场景中编写的步骤相匹配的代码方法。该项目已经包含所有 Gradle 依赖项，因此我们可以直接创建 JBehave runner。
+JBehave 需要两个主要组件来运行 BDD 故事和步骤。运行器是一个类，它将解析故事、运行所有场景并生成报告。步骤是与场景中编写的步骤相匹配的代码方法。该项目已经包含所有 Gradle 依赖项，因此我们可以直接创建 JBehave 运行器。
 
 # JBehave 转轮