第一部分 - .
想象一下情况。 您面临着开发新功能的任务。 你从你的前辈那里得到了发展。 如果我们假设你没有道德义务，你会做什么？
大多数情况下，所有旧的发展都被遗忘，一切都重新开始。 没有人喜欢深入研究别人的代码，但如果你有时间，为什么不开始创建自己的系统呢？ 这是一种典型的做法，而且在很大程度上是正确的。 但在我们的项目中我们做错了。 我们未来的自动测试系统是基于前人对utPLSQL单元测试的开发，然后在几个并行的方向上进行工作。
- 恢复旧的单元测试。 恢复意味着使测试适应忠诚度系统的现有状态，并使测试适应 utPLSQL 标准。
- 通过了解自动测试到底涵盖了什么、方法和流程来解决问题。 您必须将这些信息牢记在心，或者直接根据自动测试代码得出结论。 因此，我们决定创建一个目录。 我们为每个自动测试分配了一个唯一的助记码，创建了描述并记录了设置（例如，在什么条件下应该启动它，或者如果测试启动失败应该发生什么）。 本质上，我们填充了有关自动测试的元数据，并将该元数据放入标准 utPLSQL 模式表中。
- 定义扩张策略，即选择需要通过自动化测试进行验证的功能。 我们决定关注三件事：新系统改进、生产事件和关键系统流程。 因此，我们在发布的同时进行开发，确保其更高的质量，同时扩大回归范围并确保关键地方的系统可靠性。 第一个瓶颈是在支票上分配折扣和奖金的过程。
- 自然地，我们开始开发新的自动测试。 首批发布任务之一是评估忠诚度系统预定义样本的性能。 我们的项目有一组严格固定的 SQL 查询，可以根据条件选择客户端。 例如，获取最后一次购买位于特定城市的所有客户的列表，或者平均购买金额高于特定值的客户的列表。 编写自动测试后，我们检查了预定义的示例，记录了基准性能参数，此外我们还进行了负载测试。
- 使用自动测试应该很方便。 两个最常见的操作是运行自动测试和创建测试数据。 这就是我们系统中出现两个辅助模块的方式：启动模块和数据生成模块。
启动器被表示为具有一个文本输入参数的通用过程。 作为参数，您可以传递自动测试助记码、包名称、测试名称、自动测试设置或保留关键字。 该过程选择并运行所有满足条件的自动测试。
数据生成模块以包的形式呈现，其中对于被测系统的每个对象（数据库中的表），都创建了一个特殊的过程来在那里插入数据。 在此过程中，尽可能填充默认值，这确保只需点击手指即可创建对象。 为了便于使用，创建了生成数据的模板。 例如，创建一个具有测试手机并完成购买的特定年龄的客户。
- 自动测试应该在您的系统可接受的时间内启动和运行。 因此，每天都会组织一次夜间发布，根据结果生成一份结果报告，并通过公司邮件发送给整个开发团队。 恢复旧的自动测试并创建新的自动测试后，总运行时间为 30 分钟。 由于发布是在工作时间之外进行的，因此这种表演适合所有人。
但我们必须努力优化工作速度。 生产中的忠诚度系统在晚上更新。 作为其中一个版本的一部分，我们必须在晚上进行紧急更改。 凌晨三点等待半个小时的自动测试结果并没有让负责发布的人高兴（向阿列克谢·瓦修科夫致以热烈的问候！），第二天早上，人们对我们的系统说了很多善意的话。 但结果是，制定了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这篇文章不是很具体：有很多文字，而且几乎没有技术示例。 如果该主题总体上很有趣，那么我们准备继续它并返回一个延续，我们将告诉您过去六个月发生了什么变化并提供代码示例。
今后如果有需要强调的点，或者需要公开的问题，请写下评论。
只有注册用户才能参与调查。 拜托
我们要进一步写一下这个吗？
-
是的当然是的
-
不用了
12 位用户投票。 4 名用户弃权。
来源： habr.com