嗨，社区！
在这篇文章中，我想分享一下我对BW（Bex）查询自动化测试的经验和想法。在升级/迁移项目期间，客户希望确保其BW（Bex）查询在升级前后返回相同的结果。这并不总是正确的，海量数据，因为SAP作为供应商对BW（Bex）查询中使用的标准功能模块、类等进行了修改。即使我们知道wht在最近安装的service pack中发生了更改，问题"它如何影响一组特定的关键BW（Bex）查询？"是开放的。这就是为什么自动化测试BW（BEx）查询可以保证您永远不会错过负担不起的更改。它节省了项目成本，因为你只需要几分钟就可以进行对比测试并找出问题所在。
博客由两部分组成：摘要和细节。
在摘要部分我只发布了一个截图。它显示带有测试结果的最终屏幕：Bex query result set before changes[在系统中/在查询数据中/在查询逻辑或smth中]。就像那样]在改变之后。单元格中的红色表示比较失败："更改后"执行的查询（上半部分）与"更改前"执行的查询（下半部分）相比产生不同的结果。
在详细的第一部分"逐步"发布一系列屏幕截图，以设置大部分相关设置。
首先，大数据的发展，决定要测试的查询。为他们的选择屏幕准备他们的技术名称和变量值。然后运行tcode:RSTT并为其他用户激活trace
现在您可以开始记录更改后要比较的查询结果。在我的调查期间，记录查询结果的最佳方法是使用tcode RSRT和HTML表示。不幸的是，这种类型与BW4/HANA无关。但其他类型的表示，数据呈现，如列表、BIC，很难进行比较。你自己试试看，我知道你能理解我的意思。
然后回到RSTT，停止追踪。让我们在选项卡中查看跟踪结果
"参考数据"您可以看到记录的查询执行结果（在我的示例中，我记录了2个bex查询，这就是为什么您可以在以前的一些幻灯片上看到日志中的2个记录）。
这里记录的结果：
然后我为测试过程的自动化做了一些设置。我创建了带有跟踪记录的测试包…
…和测试作业，大数据课程，以便下次在BW系统中进行一些更改后执行测试包。
通过单击网格中的报告图标可以看到作业执行的结果（见上图）。然后你钻到作业日志分离的BexQuery（见filter on log GUID字段），它表示一切正常（消息类型S）
接下来我在BW系统中做了一些更改，这导致了Bex查询结果的更改。并立即（再次）执行作业
作业完成后，我进入"作业日志"选项卡，再次钻取带有作业日志的BExQuery
消息类型中的错误状态！
所以我们接下来需要做详细的调查！转到CATTS跟踪并再次执行跟踪记录
我们看到错误状态，云服务器，这意味着保存的结果与上次记录的结果不同。
转到详细信息并查看。。与博客摘要部分相同的幻灯片
