我们在Alfastrakhovanie使用SAP ERP作为过程损失解决系统。 碰巧发生了，我们需要对其进行最终确定，这不可避免地导致代码中的错误。 如果错误影响了生产系统，那就不好了。 应该避免这种情况，一种方法是回归测试。 在本文中，我将确切讨论我们如何对SAP进行“回归”，因为我们这样做（哦！）是非标准的。
这一切都始于几年前。 在那些年里，我们已经在积极地使用回归测试，但是我们无法在SAP中使用回归测试-所使用的工具无法与SAP配合使用，测试团队也不想研究针对SAP而言“锐利”的工具。 我不记得确切的原因，但是我把它当作一个挑战（甚至在我转向日期工程之前），并决定“研究”这个问题。
研究的结果（以及“正在做的事情”）-在本文（以下）中，我将简单地说：我们自动测试SAP（及其直接环境），我们做得很有效（在每种意义上），我们没有在许可证和授权上花费一个卢布培训，我们的方法简单且完全可重复。 而且，我们不使用任何SAP工具来自动测试SAP（在我们内置于其传输系统中的地方除外）。
大笔画
进入细节有可能会迷失读者，我会尽量避免这样做（作为作者，我知道所有细节）。
一切始于研究，与SAP，我们的合作伙伴和Google先生沟通。
交流的结果如下：
- SAP拥有用于测试自动化的工具（我们仔细研究了eCATT和SAP CBTA）
- 他们需要大量的沉浸力（尤其是SAP CBTA）
- 可能有必要采取一些限制措施，如果有必要，这些限制应超出SAP的限制（他不在我们身边）
- 有第三方产品（例如HP），但是我们没有第三方的能力，就像我们购买了许可证一样
- 有一种从外部“管理” SAP的方法（Convista公司告诉我这个想法，非常感谢）
由于我个人不了解SAP，因此我决定尝试从最后一个方向进行挖掘-管理SAP并非来自SAP。 Google先生很快提供了“用于Windows和Java平台的SAP GUI脚本API”文档，这是该计划的一个良好开端。 对我最喜欢的python进行的快速测试表明它可以工作。
接下来，这是一件小事-找到适合测试自动化的框架。 由于python是我最喜欢的语言，因此很快就考虑了Robot Framework。 而且，实际上，在他进入名单并受到审判之后，只有他留在了名单上。 受“它”立即起作用的事实的欢迎（展望未来-仍然起作用，我对自己的选择一分钟不后悔）。
一位小飞行员表明，SAP是完全由机器人“控制”的（我将机器人框架称为俄语）是：快速，同步，可预测且可靠。 同时-我强调-我们使用SAP记录的与SAP GUI交互的方式（不是某种“拐杖”）。
建筑学
（是的，让我在这里使用这个词）
运作方式：
- 脚本是在服务器上执行的（在此计算机上，“ server”一词代表我们的测试请求。在这种情况下，使用“ client”一词更为正确，因为它是控制测试过程的脚本）
- 通过远程机器人的标准机制，脚本与在SUT（被测系统）上运行的机器人的服务器组件进行交互
- 该服务器组件调用SAP管理库的方法
- SAP GUI处理这些请求（同步，这一点很重要）
- 执行查询或仅将“拍子”执行的结果返回到“服务器”上的脚本，在测试过程中将其使用
技术上
- “服务器”是Ubuntu下的虚拟机
- SUT-安装和配置SAP工作站的工作站（在我们的情况下，它是Windows计算机或虚拟机）
- SAP管理库是用python编写的（有几行-几百行）
- “脚本”是机器人框架可以理解的语言中的“程序”
- 该机器人（因此）意味着一个命令行，因为ABAP开发人员不习惯使用它，所以我制作了一个WEB界面，该界面特别提供了集体工作（稍后再进行介绍）。
什么很棒
实际上，除了缺乏许可负担外，我们还能得到什么？
很多事情，如果简短而又关于主要问题：
俄语
该脚本如下所示：
在旅程的开始阶段（可能是在飞行员的过程中），我想-并且我们将打破舌头，自己想出一些难以理解甚至可以说的话吗？ 机器人暗示您将创建自己的关键字（对不起，术语-这就是他所说的）。 那么，为什么不立即用俄语提出呢？ 他在测试人员社区（Internet上的某个地方）问-他们“让我感到沮丧”：这很危险，为什么，谁说的，等等。 我确实按照自己的方式行事-我们拥有所有俄语版本（变量，单词，仅保留了机器人的控制结构，但必须将它们隐藏在关键字中-如果您看到的是英语，那么该重构了。）
俄语有什么好处（除了没有字典的易懂性之外）-脚本可以显示给非IT专家，商人。 您可以直接与他一起编写此脚本（我什至在这里都不会尝试进入ATDD主题-这是一篇单独的重要文章，有一天我会写它）。
全面控制和可扩展性
我确切地知道测试过程中会发生什么。 根本没有魔术-一切都非常清晰。 我不知道有人喜欢我
关于可扩展性-我们可以在任何方向上开发功能，我们一直在积极地使用它们：
- 我设法提出了自己的测试脚本“语言”，这对企业来说是可以理解的
- 可以在测试结束时自动检查接口中的字段是否正确填充（为此，特别是，我们将机械手变量分为启动参数和接口参数，从而可以确定哪个接口元素应具有哪个启动参数）
- 可以将断点添加到测试中；在断点期间，请查看变量的值
- 我们实现了一种机制，用于创建文件模板并将其放入执行过程中-否则，将无法测试VLP这样的动物（并且我们以完全自动化的模式对其进行了测试-从生成应用程序到解析摘录）
我们自己的Web界面的存在增加了更多的扩展选项-例如，我们有能力修改机器人语言（例如，我们想到了条件运算符-我们和我们的业务用户不喜欢标准的“运行关键字if”）。 之所以成为可能，是因为Web应用程序为机器人生成了带有测试源代码的文件。
易于进入
通常，测试人员不了解SAP基础架构，尤其是SAP编程。 他们在几周内设法掌握了机器人及其对我们的改进。
使用说明
我们也转向“我们的威廉...”-文档。 对于任何人来说这都不是秘密-通常，该系统没有文档，即使有文档，它也会很快过时。 用户通过使用“口口相传”系统的规则。 如果自动测试代码是作者描述的如何使用系统的描述，那么为什么不将其转换为指令呢？
当然，在此片段上很难看到细节，以完全自动的方式（包括屏幕截图）生成和更新指令非常重要。 该说明始终是最新的（因为自动测试始终有效）。 对于SAP，通常会很好地接收屏幕截图-在SAP中，您始终可以找到一个界面元素-一个矩形，其坐标与测试代码中的当前位置相关，该控件（对眼睛不可见）用作关键字“拍摄屏幕截图”的参数（此字，当然，它仅在适当的测试启动模式下有效-为什么只花这么多电）。
我们使用Sphinx格式化了说明（我相信很多人都了解了配色方案），因此可以在在线手册和印刷版中找到它们。
关于机器人框架的一些知识
然而，关于机器人，没有什么可以说的-它会变得过于困惑和肤浅。 我会简短地尝试。
该框架的主要思想是创建自己的测试语言的能力（在机器人的术语中，可执行单元是关键字-关键字）。 该框架提供
- 程序执行环境（程序员-不要冒犯）
- 功能丰富的库（从使用字符串和列表到ssh和selenium）
- 报告（在使用过程中，甚至没有写过任何报告的想法）
- 由关键字组成程序的简单范例（有点特殊，但您可以习惯它），其中包括变量，参数和“调用”（关键字）的结果
- 简单而强大的可扩展性-使用python（例如，我们以这种方式使用Excel）创建自己的库非常简单，既可以在本地（即在与测试代码相同的位置执行），也可以在远程（例如，用于控制SAP GUI）
创建测试的过程非常简单
- 我们形成一系列动作并将其转化为机器人的术语（与被测系统交互的细节要低一些）
- 重复序列在其（新）关键字中重构
- 运行测试，查看其工作原理，修复，改进
- 调试是由断点提供的（具有查看变量的能力-由体系结构提供，更准确地说-是使用机器人的远程库）
结果甚至不是程序（请参见上面的示例），而是一个正式的动作序列，顺便说一句，它以作者想要的形式描述了程序的使用（请参见上面的ATDD）。
与被测系统的交互
在我们的案例中，我们在用户界面级别进行测试（即，我们的测试在GUI级别与SAP交互-它们“单击”按钮，填写文本字段等）。 人们普遍认为，这种编写测试的方法不是最好的。 我对此表示部分同意，但是我准备倾听并讨论如何测试SAP GUI应用程序（例如我们的SAP FS CM）。
有一个大师-罗伯特·马丁（Robert Martin（又名“叔叔鲍勃”）–“清洁编码员”的作者，如果有人读过的话），我们对此做了一些说明。 他们同意，如果执行起来不是很困难，它不会经常更改（破坏测试），那么可以-您还可以通过界面进行测试。
就我而言，我可以这样说：对于SAP GUI，实现用户界面的选项不多。 例如，如果您需要添加跟踪IMEI代码的功能，则可以采用几乎一种方式来实现此目的-通过将适当的字段添加到其中一个书签中。 因此，我认为客户可以并且应该考虑到此“添加”的所有细微差别（如何在界面，宽度，使用顺序等中调用此字段）。 他可以直接在脚本中执行此操作，然后脚本会自动对其进行测试。 如果您无法仔细考虑到底的修订版本（正如他们所说-好吧，您会这样做的，我们会看到的），那么最好不要进行此修订。 并尽力思考。 好吧，我再次进入ATDD ...
回到与SAP GUI的交互：正如我已经写过的，我们在python中管理了大约200行，并管理了大约10种不同的界面管理功能（例如“转到书签”，“填写字段”，“按下按钮”）。 这个集合几乎是在早期形成的，随后没有扩展太多。 对于SAP来说，我注意到一切工作都非常快-眼睛没有时间跟踪界面如何“闪烁”，在控制周期中插入了延迟以减慢速度（在需要视觉监视的情况下）。 我还注意到了同步操作的优点-您无需在代码中的任何地方等待任何事情，例如，如果按下了按钮，则与按钮单击相对应的操作已经完成（例如，丢失已保存）。
def get_ctrl_attr ( self, uid, attr ): """ ( ) ( ) exception = ( log) """ ctrl = self._get_ctrl(uid) try: retText = getattr( ctrl, attr ) except: raise AssertionError(" {1} {0}".decode("utf-8").format(attr,uid)) return retText
关于代码的一些注释
- SAP GUI管理库的片段
- 一个库是一个对象，方法可以直接在测试中使用（例如，关键字），例如，上述方法可以这样调用：“ res = get ctrl attr $ {UID} text”（使用机器人符号）
- 如果发生错误，则异常文本将显示在机器人的日志中（您无需为此做任何事情-只需“杀死”异常
代码很简单，很高兴。
运行测试
遵循机器人的逻辑，在我们的项目中组合了各个测试。 可以从Web界面手动启动测试或项目。 回归测试过程也已集成到SAP传输系统中：
- 产品所有者在业务测试阶段结束时批准运输要求进行转移
- 批准的请求一次一次“移动”到预生产环境，在该环境中，根据设置，将启动一组或另一组测试（更确切地说是项目）
- 如果测试结果为肯定，则释放请求并将其“转到”生产环境
- 当发生错误时，将向请求的作者发送一封带有测试报告链接的信件（由机器人生成），请求不会继续进行
重要-网络界面大大降低了进入测试过程的门槛：启动测试非常简单-单击“开始”按钮。 同时（由于使用了Robot Framework），保留了测试文件表示形式的所有优点（版本控制，命令行和相关的自动化等）。
不液汁
我们成功地将开发成果应用于不仅测试SAP GUI，而且在python和django中进行了小规模开发（简化的损失注册界面）。 由于我们已经实现了所有基本点，因此所需要做的就是编写一个浏览器管理库（与我必须通过Selenium来管理SAP GUI相同）。 结果非常棒：
- 测试仍可在Linux虚拟机上运行（在同一虚拟机上-SAP测试而非SAP测试位于同一“实例”中）
- 浏览器在测试人员的工作场所“闪烁”（完全视觉控制，没有任何花招）
- 标准报告，熟悉的工具
在该系统的测试中，我走得更远（朝ATDD迈进）-在测试中最初形成了视觉可见的元素（标签和占位符），在那里他们与业务部门达成一致，然后“掉进”系统本身的源代码（事实证明有点干）-您不能编写代码而不先编写测试。 很酷
当然，已经为Web应用程序开发了许多工具，但是我不能说我在工作中遇到了任何不便。 原来这里很好...
总结一下
SAP的世界很大，而且似乎包含了开发人员完全满意的一切。 但这并不意味着您仅需要遵循SAP及其生态系统“步伐”的那些路径。 在开始时问自己一个问题是很有用的：我是否一定要“像其他所有人一样”做事？ 我们在Alfastrakhovanie不仅是在IT方面，还要求他自己问。
而且，编程中一切皆有可能，问题只是时间和金钱（动机）。