第一部分在这里 。
想象一下情况。 您面临着开发新功能的任务。 您有前辈的发展。 假设您没有道德义务，您会怎么做？
通常，所有旧的成就都被遗忘，一切又重新开始。 没有人喜欢深入研究别人的代码，如果有时间，为什么不开始创建自己的系统？ 这是典型的方法，在很大程度上是正确的。 但是在我们的项目中，我们做错了。 我们为前辈基于utPLSQL的单元测试建立的未来自动化测试系统奠定了基础，然后在多个平行方向上开展了工作。
- 恢复旧的单元测试。 恢复是指使测试适应忠诚度系统的现有状态，并使测试适应utPLSQL标准。
- 通过自动测试可以了解并理解问题的解决方案以及确切的方法和过程。 您必须牢记此信息或根据自动测试代码本身得出结论。 因此，我们决定创建一个目录。 我们为每个自动测试分配了唯一的助记码，形成了说明并修复了设置（例如，在什么条件下应该开始，或者如果测试开始失败应该怎么办）。 本质上，我们填写了有关自动测试的元数据，并将此元数据放入标准的utPLSQL模式表中。
- 定义扩展策略，即 选择要由自动测试检查的功能。 我们决定注意三件事：新系统改进，生产事件和关键系统流程。 因此，我们正在与发行版并行开发，以提供更高的质量，同时扩大回归量并确保关键位置的系统可靠性。 此类瓶颈的第一个瓶颈是分配支票折扣和奖金的过程。
- 自然，我们开始开发新的自动测试。 最初发布的任务之一是评估忠诚度系统的预定义样本的性能。 在我们的项目中，有一堆严格固定的sql查询，这些查询根据条件选择客户端。 例如，获取所有上次购物在特定城市中的所有客户的列表，或平均购买金额高于特定值的客户的列表。 编写自动测试之后，我们检查了预定义的样本，固定了参考性能参数，此外还进行了负载测试。
- 使用自动测试应该很方便 。 通常，执行两个操作：运行自动测试和创建测试数据。 因此，在我们的系统中出现了两个辅助模块：启动模块和数据生成模块。
启动器以带有一个输入文本参数的单个通用过程表示。 作为参数，您可以传递自动测试助记码，程序包名称，测试名称，自动测试设置或保留关键字。 该过程选择并运行所有满足条件的自动测试。
数据生成模块以包的形式提供，其中针对被测系统的每个对象（数据库中的表），创建一个特殊的过程，将数据插入该过程。 在此过程中，将尽可能填充默认值，以确保单击手指即可创建对象。 为了便于使用，创建了用于生成数据的模板。 例如，使用测试电话和完美的购买来创建某个年龄段的客户。 - 自动测试应在系统可接受的时间运行。 因此，每天组织一次夜间发布会，其结果将生成结果报告，并通过公司邮件将其发送给整个开发团队。 恢复旧的自动测试并创建新的自动测试后，总操作时间为30分钟。 这样的性能适合所有人，因为发布是在几个小时后进行的。
但是我必须致力于优化工作速度。 夜间更新生产忠诚度系统。 作为发行版的一部分，我不得不在夜间紧急进行更改。 在凌晨三点等待半小时的自动测试结果并没有使负责发布的人高兴（向Alexei Vasyukov致以诚挚的问候！），第二天早上，对我们的系统说了很多好话。 但是根据结果，确定了5分钟的工作标准。
为了提高性能，我们使用了两种方法：自动测试开始在三个并行线程中运行，由于忠诚度系统的体系结构，这非常方便。 当自动测试不为其自身创建测试数据，而是尝试在系统中找到合适的内容时，我们便放弃了这种方法。 进行更改后，总操作时间减少到3-4分钟。 - 具有自动测试功能的项目应能够部署在各个展台上。 在旅程的开始，曾尝试编写您自己的批处理文件，但很明显，自行编写的自动安装完全让人感到恐惧，我们转向了工业解决方案。 由于该项目具有许多直接代码（首先，我们存储用于自动测试的代码）和很少的数据（主要数据是有关自动测试的元数据），事实证明将Liquibase引入项目非常简单。
它是一个独立于开源数据库的库，用于跟踪，管理和应用数据库架构更改。 通过命令行或诸如Apache Maven之类的框架进行管理。 Liquibase的操作原理非常简单。 我们有一个以某种方式组织的项目，其中包括需要滚动到目标服务器上的更改或脚本，以及控制文件，这些文件确定应以什么顺序和安装哪些参数。
在DBMS级别，将创建一个特殊的表，其中Liquibase存储了运行日志。 每个更改都有一个计算得出的哈希，每次在项目与数据库状态之间进行比较。 多亏了Liquibase，我们可以轻松地将系统更改扩展到任何电路。 现在，自动测试可以在测试和发布循环以及容器（开发人员的个人循环）上运行。
因此，让我们谈谈应用我们的单元测试系统的结果。
- 当然，首先，我们坚信我们开始开发更好的软件。 自动测试每天运行，每年发现数十个错误。 而且，其中一些错误仅与我们真正想要更改的功能间接相关。 怀疑这些错误是通过手动测试发现的。
- 团队对特定功能正常工作充满信心。首先，它关系到我们的关键流程。 例如，在过去的六个月中，尽管发行版本有所变化，但支票上的折扣和红利的分配仍然没有问题，尽管在前几个时期中有时会出现错误
- 我们能够减少测试迭代的次数。 由于自动测试是针对新功能编写的，因此分析和兼职测试人员可以获得更高质量的代码，因为 它已经被验证。
- 开发人员使用了自动化测试的部分开发内容。 例如，使用对象生成模块创建容器上的测试数据。
- 重要的是，我们开发了开发人员自动测试系统的“采用”。 有一种理解，这是重要且有用的。 从我自己的经验来看，我可以说情况并非如此。 需要编写自动测试，必须维护和开发自动测试，分析结果，并且通常这些时间成本根本不值得。 投入生产并在那里解决问题要容易得多。 在我们这里，开发人员排队，并要求通过自动测试来涵盖其功能。
接下来是什么
让我们谈谈自动化测试项目的开发计划。
当然，尽管Sportmaster的忠诚度系统仍然有效并且正在不断发展，但几乎可以无休止地进行自我测试。 因此，发展的主要方向是扩大覆盖范围。
随着自动测试数量的增加，他们的总工作时间将稳定增长，我们将不得不再次回到生产力问题上。 解决方案最有可能的是增加并行线程的数量。
但是，这些是显而易见的发展道路。 如果我们谈论一些比较琐碎的事情，那么我们重点介绍以下内容：
- 当前，自动测试是在DBMS级别进行管理的，即 您需要PL / SQL知识才能成功工作。 如有必要，控制系统（例如，启动或创建元数据），则可以使用Jenkins或类似工具创建某种管理面板。
- 每个人都喜欢定量和定性指标。 对于自动化测试，此类通用度量是代码覆盖率或代码覆盖率度量。 使用该指标，我们可以确定自动测试覆盖了测试系统代码的百分比。 从版本12.2开始，Oracle提供了计算该指标的功能，并建议使用标准软件包DBMS_PLSQL_CODE_COVERAGE。
我们的自动测试系统已有一年多的历史了，也许现在是评估覆盖率的时候了。 在我过去的项目（不是Sportmaster的项目）中，它发生了。 在进行自动测试的一年后，管理层设定了一个目标，以评估我们涵盖的代码百分比。 覆盖率超过1％，管理层将很高兴。 我们，开发人员，预期会有大约10％的结果。 测得的固定代码覆盖率达到20％。 为了庆祝，我们去了一个奖项，但是我们如何去去以及后来去的地方是一个完全不同的故事。 - 自动测试可以检查公开的Web服务。 Oracle允许您执行此操作，我们将不再遇到许多问题。
- 而且，当然，我们的自动化测试系统可以应用于其他项目。 我们的解决方案是通用的，只需要使用Oracle。 我听说在Sportmaster的其他项目中，对自动测试很感兴趣，也许我们会去做。
结论
让我们总结一下。 在该项目中，我们成功地在Sportmaster的忠诚度系统中实施了自动测试系统。 它的基础是Stephen Feuerstein提供的utPLSQL解决方案。 utPLSQL周围是自动测试代码和辅助自写模块：启动模块，数据生成模块等。 自动测试每天运行，最重要的是，它可以工作并带来收益。 我们坚信我们已经开始发布更高质量的软件。 同时，所产生的解决方案是通用的，可以自由应用于需要在Oracle DBMS上组织自动化测试的任何项目。
PS：本文不是很具体：有很多文字，几乎没有技术示例。 如果该主题在全球范围内都很有趣，那么我们准备继续并继续进行下去，在此我们将告诉您过去六个月中发生了什么变化并给出代码示例。
如果将来有值得重点关注的地方或需要披露的问题，请写评论。