嘿哈布尔！
我叫 Maxim Ponomarenko，是 Sportmaster 的一名开发人员。 我在 IT 领域有 10 年的经验。 他的职业生涯始于手动测试，然后转向数据库开发。 在过去的 4 年里，我积累了在测试和开发中获得的知识，一直在 DBMS 级别进行自动化测试。
我在 Sportmaster 团队工作了一年多，正在为一个主要项目开发自动化测试。 四月份，我和来自 Sportmaster Lab 的人员在克拉斯诺达尔的一次会议上发表了演讲，我的报告被称为“DBMS 中的单元测试”，现在我想与您分享。 文字会很多，所以我决定将报告分成两篇文章。 在第一篇中，我们将讨论一般的自动测试和测试，在第二篇中，我将更详细地讨论我们的单元测试系统及其应用结果。
首先，有点无聊的理论。 什么是自动化测试？ 这是使用软件进行的测试，在现代 IT 中，它越来越多地用于软件开发。 这是因为公司在不断发展，其信息系统也在不断发展，因此需要测试的功能量也在不断增加。 进行手动测试变得越来越昂贵。
我在一家大公司工作，该公司每两个月发布一次版本。 同时，花了整整一个月的时间让十几名测试人员手动检查功能。 由于一小群开发人员实施了自动化，我们能够在一年半的时间里将测试时间减少到两周。 我们不仅提高了测试速度，还提高了测试质量。 自动化测试会定期启动，并且始终执行其中包含的整个检查过程，也就是说，我们排除了人为因素。
现代 IT 的特点是，开发人员可能不仅需要编写产品代码，还需要编写检查该代码的单元测试。
但是如果您的系统主要基于服务器逻辑怎么办？ 市场上没有通用的解决方案或最佳实践。 通常，公司通过创建自己编写的测试系统来解决这个问题。 这是我们自己写的自动化测试系统，是在我们的项目上创建的，我将在我的报告中讨论它。
测试忠诚度
首先说一下我们部署自动化测试系统的项目。 我们的项目是 Sportmaster 忠诚度系统（顺便说一句，我们已经在 ).
如果您的公司足够大，那么您的忠诚度系统将具有三个标准属性：
- 您的系统将处于高负载状态
- 您的系统将包含复杂的计算过程
- 您的系统将得到积极改进。
让我们按顺序进行... 总的来说，如果我们考虑所有 Sportmaster 品牌，那么我们在俄罗斯、乌克兰、中国、哈萨克斯坦和白俄罗斯拥有 1000 多家商店。 这些商店每天约有 300 万次购买。 也就是说，每秒有 000-3 个支票进入我们的系统。 当然，我们的忠诚度系统负载很高。 由于它被积极使用，我们必须提供最高的质量标准，因为软件中的任何错误都意味着巨大的金钱、声誉和其他损失。
与此同时，Sportmaster 还举办一百多项不同的促销活动。 促销有很多种：有产品促销，有专门针对一周中某一天的促销，有与特定商店相关的促销，有针对收据金额的促销，还有针对商品数量的促销。 总的来说，还不错。 客户在购买时可以使用奖金和促销代码。 所有这些导致计算任何阶数都是一项非常重要的任务。
实现订单处理的算法确实很糟糕而且很复杂。 而且这个算法的任何改变都是相当危险的。 似乎最看似微不足道的变化可能会导致相当不可预测的影响。 但正是如此复杂的计算过程，尤其是那些实现关键功能的计算过程，才是自动化的最佳候选者。 手工检查数十个类似案例非常耗时。 由于流程的入口点没有改变，只描述过一次，您就可以快速创建自动测试，并确信该功能将发挥作用。
由于我们的系统被积极使用，企业会希望从您那里得到一些新的东西，与时俱进并以客户为导向。 在我们的忠诚度系统中，每两个月发布一次。 这意味着每两个月我们需要对整个系统进行一次彻底的回归。 与此同时，自然地，就像在任何现代 IT 中一样，开发不会立即从开发人员转向生产。 它起源于开发人员的电路，然后依次经过测试台、发布、验收，最后才最终投入生产。 至少，在测试和发布电路上，我们需要对整个系统进行完整的回归。
所描述的属性是几乎所有忠诚度系统的标准属性。 我们来谈谈我们项目的特点。
从技术上来说，我们的忠诚度系统 90% 的逻辑都是基于服务器并在 Oracle 上实现的。 Delphi 中公开了一个客户端，它执行自动化工作场所管理员的功能。 有针对外部应用程序（例如网站）的公开 Web 服务。 因此，如果我们部署自动化测试系统，我们会在Oracle上进行，这是非常合乎逻辑的。
Sportmaster 中的忠诚度系统已经存在了 7 年多，并且是由单个开发人员创建的......这 7 年里我们项目的开发人员平均数量为 3-4 人。 但在过去的一年里，我们的团队有了显着的成长，现在有 10 个人在做这个项目。 也就是说，参与该项目的人们并不熟悉典型的任务、流程和架构。 而且我们错过错误的风险也会增加。
该项目的特点是没有专门的测试人员作为参谋单位。 当然还有测试，但测试是由分析师执行的，此外还有其他主要职责：与业务客户、用户沟通、开发系统需求等。 等等...尽管测试的质量非常高（这一点特别值得一提，因为一些分析师可能会注意到这份报告），但专业化和专注于一件事的有效性并没有被取消。
考虑到上述所有因素，为了提高交付产品的质量并减少开发时间，对项目进行自动化测试的想法似乎非常合乎逻辑。 在忠诚度系统存在的不同阶段，个别开发人员努力通过单元测试覆盖他们的代码。 总的来说，这是一个相当脱节的过程，每个人都使用自己的架构和方法。 最终结果对于单元测试来说是常见的：测试已开发，使用了一段时间，存储在版本化文件存储中，但在某些时候它们停止运行并被遗忘。 首先，这是因为测试更多地与特定执行者相关，而不是与项目相关。
utPLSQL 来救援
你了解斯蒂芬·费厄斯坦吗？
这是一个聪明的人，他将其职业生涯的大部分时间都投入到了 Oracle 和 PL/SQL 的工作中，并就此主题撰写了大量著作。 他的一本著名著作名为：《Oracle PL/SQL》。 对于专业人士来说。” Stephen 开发了 utPLSQL 解决方案，或者，正如其代表的那样，Oracle PL/SQL 的单元测试框架。 utPLSQL 解决方案于 2016 年创建，但仍在积极开发中并发布了新版本。 截至报告时，最新版本可追溯到 24 年 2019 月 XNUMX 日。
它是什么。 这是一个单独的开源项目。 它重达几兆字节，包括示例和文档。 从物理上讲，它是 ORACLE 数据库中的一个单独模式，具有一组用于组织单元测试的包和表。 安装需要几秒钟。 utPLSQL 的一个显着特点是它的易用性。
在全球范围内，utPLSQL是一种运行单元测试的机制，其中单元测试被理解为普通的Oracle批处理过程，其组织遵循一定的规则。 除了启动之外，utPLSQL 还存储所有测试运行的日志，并且还有一个内部报告系统。
让我们看一下使用此技术实现的单元测试代码的示例。
因此，屏幕显示了带有单元测试的典型包规范的代码。 有哪些强制性要求？ 数据包必须以“utp_”为前缀。 所有带有测试的过程都必须具有完全相同的前缀。 该包必须包含两个标准过程：“utp_setup”和“utp_teardown”。 第一个过程是通过重新启动每个单元测试来调用的，第二个过程是在启动后调用。
通常，“utp_setup”准备我们的系统运行单元测试，例如创建测试数据。 “utp_teardown” - 相反，一切都返回到原始设置并重置启动结果。
以下是最简单的单元测试示例，用于检查输入的客户电话号码是否标准化为我们的忠诚度系统的标准形式。 关于如何编写单元测试程序没有强制性标准。 通常，调用被测系统的方法，并将该方法返回的结果与参考结果进行比较。 重要的是，参考结果与获得的结果的比较是通过标准 utPLSQL 方法进行的。
单元测试可以有任意数量的检查。 从示例中可以看出，我们连续调用四次测试方法来标准化电话号码，并在每次调用后评估结果。 在开发单元测试时，您必须考虑到有些检查不会以任何方式影响系统，并且在某些检查之后您需要回滚到系统的原始状态。
例如，在所提供的单元测试中，我们只是格式化输入的电话号码，这不会以任何方式影响忠诚度系统。
而如果我们采用创建新客户端的方式来编写单元测试，那么每次测试后系统都会创建一个新的客户端，这会影响后续测试的启动。
这就是单元测试的运行方式。 有两种可能的启动选项：从特定包运行所有单元测试或在特定包中运行特定单元测试。
这就是内部报告系统的示例。 根据单元测试的结果，utPLSQL 构建一个小报告。 在其中我们可以看到每个特定检查的结果以及单元测试的总体结果。
自动测试的 6 条规则
在开始创建用于忠诚度系统自动化测试的新系统之前，我们与管理层一起确定了未来自动化测试应遵循的原则。
- 自动测试必须有效并且有用。 我们有出色的开发人员，他们肯定需要被提及，因为他们中的一些人可能会看到这份报告，并且他们编写了精彩的代码。 但即使他们精彩的代码也并不完美，并且过去、现在、将来都会继续包含错误。 需要自动测试来发现这些错误。 如果情况并非如此，那么要么我们正在编写糟糕的自动测试，要么我们已经进入了原则上尚未开发的死区。 在这两种情况下，我们都做错了，我们的方法根本没有意义。
- 应使用自动测试。 花费大量时间和精力编写软件产品，将其放入存储库然后忘记它是没有意义的。 应该运行测试，并且尽可能定期运行。
- 自动测试应该稳定工作。 无论一天中的什么时间、发射台和其他系统设置如何，测试运行都应该得到相同的结果。 通常，自动测试使用具有固定系统设置的特殊测试数据这一事实可以确保这一点。
- 自动测试应该以您的项目可接受的速度进行。 该时间是针对每个系统单独确定的。 有些人可以负担一整天的工作，而另一些人则认为在几秒钟内完成工作至关重要。 稍后我将告诉您我们在项目中达到了哪些速度标准。
- 自动测试开发应该灵活。 不建议仅仅因为我们以前没有做过或出于其他原因而拒绝测试任何功能。 utPLSQL 不会对开发施加任何限制，并且 Oracle 原则上允许您实现各种事物。 大多数问题都有解决办法，只是时间和精力的问题。
- 可部署性。 我们有几个需要进行测试的站。 在每个站，数据转储可以随时更新。 有必要以这样的方式进行自动测试项目，以便您可以轻松地执行其全部或部分安装。
在几天后的第二篇文章中，我将告诉您我们做了什么以及我们取得了哪些成果。
来源： habr.com