DBMS中的单元测试-我们如何在Sportmaster中进行测试,第一部分

哈Ha!

我叫Maxim Ponomarenko,我是Sportmaster的开发人员。 我在IT领域拥有10年的经验。 他的职业生涯开始于手动测试,然后转向数据库开发。 在过去的4年中,我积累了在测试和开发中获得的知识,一直从事DBMS级别的测试自动化。

我已经加入Sportmaster团队一年多了,并参与了其中一个主要项目的自动化测试开发。 4月,我和Sportmaster Lab的同事在克拉斯诺达尔的一次会议上发表了讲话,我的报告被称为DBMS中的单元测试,现在我想与大家分享。 会有很多文字,所以我决定将报告分成两部分。 在第一篇中,我们将讨论一般的自动测试和测试,在第二篇中,我将讨论我们的单元测试系统及其应用结果。



首先,有点无聊的理论。 什么是自动测试? 这是由软件执行的测试,在现代IT中,它越来越多地用于软件开发中。 这是由于以下事实:公司在增长,其信息系统也在增长,因此需要测试的功能数量也在增长。 进行手动测试变得越来越昂贵。

我曾在一家大公司工作,每两个月发布一次。 同时,一整个月的时间用在十几位测试人员身上,以手工检查其功能。 由于一小群开发人员引入了自动化,因此我们能够将测试时间缩短为一年半到2周。 我们不仅提高了测试速度,而且提高了质量。 自动化测试会定期进行,并且它们始终会完成其内在的测试的整个过程,也就是说,我们排除了人为因素。

现代IT的特点是,不仅可能要求开发人员编写产品代码,而且要求编写验证该代码的单元测试。

但是,如果您的系统主要基于服务器逻辑怎么办? 市场上没有一站式解决方案和最佳实践。 通常,公司通过创建自己的自行编写的测试系统来解决此问题。 在我们的项目中创建了这样一个专有的自写自动测试系统,我将在报告中讨论它。



测试忠诚度


首先,让我们谈谈部署自动化测试系统的项目。 我们的项目是Sportmaster的忠诚度系统(顺便说一句,我们已经在这篇博文中对此进行了介绍 )。

如果您的公司足够大,那么您的忠诚度系统将具有三个标准属性:

  • 您的系统将负载沉重。
  • 您的系统将包含复杂的计算过程。
  • 您的系统将得到积极开发。

让我们去吧。 Sportmaster拥有大量正在积极销售的商店。 自然,忠诚度系统是一个高负载的系统。 而且由于该项目正在积极使用中,所以我们必须提供最高质量标准,因为软件中的任何错误都会造成大量金钱,声誉和其他损失。

同时,Sportmaster会进行一百多种不同的促销活动。 份额有很大的不同:有商品,有定时到星期几,与特定商店绑定,有支票金额中的份额,有商品数量。 一般来说,不弱。 客户有奖金,购物时会使用促销代码。 所有这些导致了一个事实,即任何订单的计算都是一项非常艰巨的任务。

实现订单处理的算法确实是可怕而复杂的。 而且对该算法的任何更改都是非常危险的事情。 似乎存在最外在的微小变化,可能导致相当不可预测的影响。 但是正是如此复杂的计算过程,更重要的是,实现关键功能是自动化的最佳选择。 用手检查数十个相同类型的案件非常耗时。 而且,由于该流程的入口点没有更改,因此一旦对其进行了描述,便可以快速标记自动测试并确定其功能。

由于我们的系统一直在积极使用,因此业务将需要您的新东西,最新信息并以客户为中心。 在我们的忠诚度系统中,发布版本每两个月发布一次。 因此,每两个月我们需要对整个系统进行一次完全回归。 当然,与此同时,就像在任何现代IT中一样,开发并不是立即从开发人员到生产的。 它起源于开发人员的电路,然后依次通过测试台,发布,验收,然后才投入生产。 至少在测试和发布电路上,我们需要对整个系统进行完整的回归。

所描述的属性是几乎所有忠诚度系统的标准属性。 让我们谈谈我们项目的功能。

从技术上讲,我们的忠诚度系统90%的逻辑是基于服务器的,并在Oracle上实现。 Delphi上有一个公开的客户端,它执行AWP管理员的功能。 存在用于外部应用程序(例如网站)的公开Web服务。 因此,如果我们部署一个自动化测试系统,那么我们将在Oracle上执行它是非常合乎逻辑的。

Sportmaster中的忠诚度系统已经存在7年以上,并且是由单个开发人员创建的。在这7年中,我们项目的平均开发人员数量为3-4人。 但是在过去的一年中,我们的团队有了长足的发展,现在有10个人在从事该项目。 也就是说,不熟悉典型任务,流程和体系结构的人来了项目。 而且,我们跳过错误的风险也越来越大。

该项目的特点是没有专门的测试人员作为工作人员。 当然,测试是在进行,但分析师除了其他主要职责外,还从事测试:与业务客户,用户沟通,制定系统需求等。 等等...尽管测试是非常定性的(特别值得一提的是,因为其中一位分析师可能会注意到此报告),但没有人取消专业化和专注于一件事的有效性。

鉴于上述所有情况,为了提高所发行产品的质量并减少开发时间,在项目上进行自动化测试的想法似乎是合乎逻辑的。 在忠诚度系统存在的不同阶段,各个开发人员都在努力用单元测试覆盖其代码。 通常这是一个相当分散的过程,每个人都使用其体系结构和方法。 单元测试对于最终结果很普遍:测试已经开发,使用了一段时间,堆叠在版本化的文件存储中,但是在某些时候,它们停止了启动并被遗忘了。 这主要是由于测试更多地与特定的执行者而不是项目相关联。

UtPLSQL可以解救




您对史蒂芬·弗伊尔斯坦(Stephen Feuerstein)知道吗?

这是一个很聪明的人,他在职业生涯的大部分时间里都致力于与Oracle和PL / SQL的合作,为此主题撰写了大量的著作。 他的一本著名的书叫做:“ Oracle PL / SQL。 对于专业人士。” 拥有utPLSQL解决方案或Oracle PL / SQL的单元测试框架的开发者是Steven。 utPLSQL解决方案创建于2016年,但他们继续积极致力于此解决方案并发布新版本。 在撰写本报告时,最新版本为2019年3月24日。
这是什么 这是一个单独的开源项目。 考虑到示例和文档,它重达几兆字节。 从物理上讲,它是ORACLE数据库中的一个独立方案,带有一组用于组织单元测试的包和表。 安装需要几秒钟。 utPLSQL的一个独特功能是易于使用。
在全球范围内,utPLSQL是用于运行单元测试的机制,其中,单元测试是指常规的Oracle批处理过程,其组织遵循某些规则。 除了启动之外,utPLSQL还存储您所有测试运行的日志,并且还有一个内部报告系统。

让我们看一个例子,说明这种技术实现的单元测试代码的样子。



因此,屏幕上显示了带有单元测试的软件包标准规范的代码。 有哪些要求? 程序包必须具有utp_前缀。 所有带有测试的过程都应具有完全相同的前缀。 该软件包必须包含两个标准过程:“ utp_setup”和“ utp_teardown”。 通过重新启动每个单元测试来调用第一个过程,第二个过程-在启动之后。

通常,“ Utp_setup”使我们的系统准备运行单元测试,例如,创建测试数据。 “ Utp_teardown”-相反,所有内容均恢复为原始设置并重置启动结果。

这是最简单的单元测试的一个示例,该测试检查输入的客户电话号码是否符合我们的会员系统的标准外观。 没有使用单元测试编写程序的强制性标准。 通常,调用被测系统的一种方法,并将该方法返回的结果与参考值进行比较。 重要的是,参考结果与结果的比较必须通过标准utPLSQL方法进行。

单元测试可以进行任意数量的检查。 从示例中可以看到,我们连续四次调用被测方法以标准化电话号码,并且在每次调用之后我们都会评估结果。 在开发单元测试时,必须考虑到存在不会以任何方式影响系统的检查,并且在进行某些检查之后,有必要回滚到系统的初始状态。
例如,在提出的单元测试中,我们只需格式化输入的电话号码,这不会影响会员系统。

而且,如果我们使用创建新客户端的方法编写单元测试,则在每次检查之后,系统中都会创建一个新客户端,这可能会影响随后的测试启动。



这就是单元测试的运行方式。 有两个可能的启动选项:从特定程序包启动所有单元测试或在特定程序包中启动特定单元测试。



这是内部报告系统的示例。 根据单元测试的结果,utPLSQL构建了一个小报告。 在其中,我们可以看到每个特定测试的结果以及单元测试的总体结果。

自动测试的6条规则


在开始创建用于忠诚度系统自动测试的新系统以及管理层之前,我们确定了未来的自动测试应遵循的原则。



  1. 自动测试应该有效并且应该是有益的。 我们有很棒的开发人员,我不得不说,因为其中一个可能会看到此报告,并且他们编写了出色的代码。 但是,即使他们精彩的代码也不是完美无缺的,包含的,也将包含错误。 需要自动测试才能发现这些错误。 如果不是这样,那么我们要么编写糟糕的自测程序,要么就来到一个死区,原则上该死区尚未最终确定。 在这两种情况下,我们都在做错事,而我们的方法毫无意义。
  2. 应该使用自动测试。 花大量时间和精力编写软件产品,添加其存储库而忘记它是没有意义的。 测试应尽可能定期进行。
  3. 自动测试应该稳定运行。 无论一天中的任何时间,发射台或其他系统设置如何,运行测试都应得出相同的结果。 通常,这是通过自动测试对具有固定系统设置的特殊测试数据进行工作来确保的。
  4. 自动测试应该以您的项目可接受的速度运行。 该时间是针对每个系统分别确定的。 有人可以负担得起一整天的工作,而有人则可以适应数秒之内。 我将在稍后介绍我们在项目中达到的速度标准。
  5. 自动测试的开发应该灵活。 仅仅因为我们还没有这样做或出于某些其他信念,拒绝测试任何功能是不可取的。 utPLSQL并没有施加任何开发限制,并且Oracle原则上允许您实现各种事情。 大多数任务都有解决方案,唯一的问题是时间和精力。
  6. 可部署性。 我们有几个支架,您需要在这些支架上进行测试。 在每个展位上,都可以随时更新数据转储。 有必要进行自动测试的项目,以使其能够轻松完成全部或部分安装。


在几天的第二篇文章中,我将告诉您我们已经做了什么以及已经取得了什么结果。

Source: https://habr.com/ru/post/zh-CN464335/


All Articles