基于模型的测试_实用的基于模型的测试打招呼

基于模型的测试

In this post, you’ll learn how to build your first Mode-Based Testing automation, using Java and GraphWalker.

在本文中，您将学习如何使用Java和GraphWalker构建您的第一个基于模式的测试自动化。

*It’s important to note that it is possible to use GraphWalker for testing other language codes by running it as a service

*请务必注意，可以通过将GraphWalker作为服务运行来使用它来测试其他语言代码

让我们首先提供一个示例，说明我们将要构建的内容。 (Let’s begin by providing an example of what we are going to build.)

All the detailed explanations of each step will be given later in the post when we go through the development steps themselves.

当我们逐步完成开发步骤时，将在后面的文章中给出每个步骤的所有详细说明。

Imagine that your team’s development workflow is as follows:

想象一下，您的团队的开发工作流程如下：

1. The PM (Product Manager) brings some new requirements:
   PM(产品经理)带来了一些新要求：

• A pedestrian traffic lights
  行人交通灯
• Begin with a Green light
  从绿灯开始
• Toggle between Red and Green lights
  在红色和绿色指示灯之间切换

2. You formalize the requirements into the following model:

2.您将需求形式化为以下模型：

3. The Test-Generator automatically generates a full coverage test-case suite:

3. Test-Generator自动生成一个完整的测试用例套件：

4. At this stage you can execute those automated generated test-cases ….

4.在这一阶段，您可以执行那些自动生成的测试用例……。

“But wait!”, you would probably say, “Those changes are not implemented yet”.

“但是等等！”，您可能会说，“这些更改尚未实现”。

5. Go ahead and write the implementation. You can run the generated tests during implementation and stop writing code when all the automated test-cases have passed.

5.继续并编写实现。 您可以在实现过程中运行生成的测试，并在所有自动化测试用例通过后停止编写代码。

In the example above, the Model created from the requirements is also your automated executable acceptance test, which also becomes your DoD (the feature’s Definition of Done).

在上面的示例中，根据需求创建的模型也是您的自动化可执行验收测试，该测试也成为您的DoD(功能的完成定义)。

You have executable acceptance test, right at the beginning of the sprint, and before you write a single line of code.

在冲刺开始时以及编写单行代码之前，您已经进行了可执行的验收测试。

If this looks like a TDD (Test-Driven Development) to you, you are right. But MBT (Model-Based Testing) not only removes the dependency between test-cases and implementation, it actually creates a very strong dependency between the test cases and the business requirements.

如果这对您来说似乎是TDD(测试驱动的开发)，那么您是对的。 但是MBT(基于模型的测试)不仅消除了测试用例与实现之间的依赖关系，而且实际上在测试用例与业务需求之间创建了非常强的依赖关系。

Code [ → Driven By → ] Test [ → Driven By → ] Business Requirements

代码 [ →驱动者→ ] 测试 [ →驱动者→ ] 业务需求

Business Requirements, Test and Code, are strongly connected (unlike offline test-cases that are disconnected from the requirements and code) meaning that with a proper SDLC process, the code must be updated with any change to the formalised requirements (the model), otherwise the continuous automated generated tests, by using MBT, will fail.

业务需求，测试和代码是紧密连接的(不同于与需求和代码断开连接的离线测试用例)，这意味着在正确的SDLC流程下，必须对形式化需求(模型)进行任何更改来更新代码，否则，使用MBT进行的连续自动生成的测试将失败。

Such development process can also be seen as BDD (Business Driven Development and Behaviour Driven Development).

这样的开发过程也可以视为BDD( 业务驱动开发和行为驱动开发 )。

But you don’t have to change your development processes to TDD or BDD in order to use MBT — it can be used on an already implemented project.

但是，您不必为了使用MBT而将开发过程更改为TDD或BDD，就可以在已经实施的项目中使用它。