也许每种痛苦都知道这种痛苦-不相关的文档。 无论团队多么努力，在现代项目中，我们都会如此频繁地发布，以致几乎无法描述所有更改。 我们的测试团队与系统分析师一起决定尝试使我们的项目文档焕发活力。
Alfa-Bank的网络项目使用
Akita测试自动化框架，该框架用于BDD脚本。 迄今为止，该框架因其较低的入门门槛，可用性和测试布局的能力而广受欢迎。 但是我们决定走得更远-在描述的测试方案的基础上生成文档，从而大大减少了分析师花费在更新文档这一永恒问题上的时间。
实际上，已经与Akita一起使用了文档生成插件，该插件通过脚本中的步骤并将其上传为html格式，但是为了使该文档流行，我们需要添加：
- 屏幕截图
- 变量值（配置文件，用户帐户等）；
- 状态和查询参数。
我们查看了现有的插件，实际上是一个静态分析器，并根据.feature文件中描述的脚本生成了文档。 我们决定添加扬声器，并且为了不使插件看起来像插件，我们决定编写自己的插件。
首先，我们决定找出如何从功能文件中收集测试脚本中使用的屏幕截图和变量值。 事实证明一切都很简单。 黄瓜，当为每个功能文件运行测试时，会创建一个单独的cucumber.json。
该文件中包含以下对象：
测试用例名称和关键字：
元素数组-脚本和步骤本身：
输出字段包含其他信息，例如变量-地址，链接，用户帐户等：
嵌入包含硒在测试过程中拍摄的屏幕截图：
因此，我们只需要遍历Cucumber.json文件，收集测试套件的名称，测试脚本，提取步骤，收集其他信息和屏幕截图。
为了使文档显示在后台发生的请求或特定的操作，我们必须向前端开发人员寻求帮助。 借助代理，我们能够捕获traceId，从而生成前端服务请求。 通过相同的traceId，日志以弹性形式编写，从此处我们将所有必要的查询参数提取到测试报告和文档中。
结果，我们得到了Asciidoc格式的文件-一种方便的文件格式，比markdown类比的文件有点复杂，但是具有更多的格式化选项（您可以插入图像或表格，而在markdown中是无法做到的）。
要将生成的Asciidoc转换为其他格式，我们使用Ascii doctorj，它是AsciiDoctor Java工具的正式版本。 结果，我们获得了html格式的现成文档，可以将它们一起下载，发送给同事或放入存储库中。
如何连接？
现在，要为您的项目生成前端文档，只需将文档插件连接到它，然后在运行所有测试后运行
adoc命令。
我们要改善什么？
- 添加可配置的技术步骤。
在插件的当前版本中，有步骤“并截取了屏幕截图...”。 这些步骤不会为文档带来语义上的负担，因此我们希望将其隐藏。 现在我们已经将它们缝在了插件内部，并且被跳过了，但是存在一个缺点-此步骤的每次添加都会导致我们需要构建插件的新版本这一事实。 为了避免这种情况，我们计划将这些步骤转移到配置文件，并写下我们不想在脚本中看到的那些步骤。 - 制作一个开放的源插件。
哪些团队适合我们的实施？
- 使用Cucumber（或类似框架）；
- 希望获得有关前端和知识库的最新文档；
- 他们想让分析师参与测试。
结果：
多个团队的试验表明，借助插件，我们设法使文档保持最新，分析师不再需要花费时间来维护文档。 另外，此功能的实施使我们考虑继续在团队中实施成熟的BDD。 今天，我们正在进行一项实验-分析师为客户制定了一条积极的道路，使用Akita BDD步骤指出了业务限制，测试人员则针对这些情况编写了自定义步骤和其他检查。
顺便说一下，关于霍利瓦尔，是否需要BDD，我们将在星期一举行一次
特别会议 。