这是一个性能警告。 对于发现的问题，应该有一个很长的文字来说明问题：

如果在此处使用表表达式itab [...]，则编译器将应用" ASSIGNING"语义，这意味着在所选行上设置了内部字段符号。 行类型狭窄而平坦，但是，这意味着具有" INTO"语义的选择（将行复制到内部变量）应该会产生更快的运行时间。 为此，请将整个表表达式包含在VALUE运算符中：VALUE#（itab [...]）

复制而不是分配字段符号所带来的轻微性能是否与您的应用相关，当然取决于发生此错误的位置-在您的情况下，我怀疑您在单元测试中是否在意它，但实际上 如果这些表访问发生在长时间运行的循环中或类似地经常执行的代码段中，则值得注意。

我觉得错了。 我怀疑有错误。

嗨，乔恩，

感谢您的反馈，这很有意义。 但是，我发现有趣的是为什么将其包装在VALUE构造函数中会突然使内部字段符号构造消失。 在我看来，这将像以前一样简单地构造字段符号，然后复制值。

Matthew Billingham -我认为有很好的论据认为单元测试代码应与生产代码一样重要。 哪一个意味着相同的护理水平和质量，不是吗？ ：-）

有时需要使用CONV时，我使用## OPERATOR，但是警告"类型的冗余转换...可在聚合函数中使用..."

< p>例如，我将## OPERATOR用作" meth（conv#（sy-subrc））"，因为否则sy-subrc被系统更改为0并始终传递0。

但是我不这样做 不知道您的消息意味着什么。

您的版本/SP是什么？

PS：通过运行带有唯一选项"语法"的SLIN，我可以在此代码的7.52 SP1系统中重现。 检查警告"-但如果我取消注释" ixml"行，则警告消失，很奇怪！：

 CLASS lcl_ DEFINITION。
   公共部分。
     CLASS-METHODS测试。
   专用部分。
     类方法assert_equals
       输入
         行动任何类型
         exp TYPE任何。
 ENDCLASS。
 类别lcl_实施。
   方法测试。
     类型：BEGIN OF type，
               netpr TYPE p长度9小数，5
               " ixml TYPE引用为if_ixml，
             END OF类型。
     带有"空键"类型的数据总计"类型标准表"。
     assert_equals（act = totals [1] -netpr exp = 10）。
   终结法。
   方法assert_equals。
   终结法。
 ENDCLASS。

 选择开始。
   lcl _ => test（）。
 

您好Bjoern，

最后我的评论（由于该平台令人困惑的对话线程模型而在下方发布） ，我很好奇，因为很久以前我已经测试了复制，引用和字段符号对性能的影响，并且发现它几乎可以忽略不计，因此我再次进行了测试。

有趣的是，在某些情况下，VALUE变体速度较慢，但​​通常非常相似，并且与我以前的经验相符。 然后，我在混合中添加了一个方法调用，在这里我看到了很大的影响。 如果我在方法调用中使用itab [1]字段，它的速度比在IF语句中使用它的速度慢8倍，但是用VALUE包裹它时，速度仅慢4倍-换句话说，使用表表达式时VALUE的速度快两倍

有趣的是（令人印象深刻的）是SLIN检查仅抱怨方法调用，没有其他用法。

我更好地理解您的意思是选择性排除，这是明智的。 只是根据我的经验，在单元测试中我对SLIN检查没有太多问题，在奇怪的情况下，要使其符合标准需要2秒钟的工作。 也许这取决于我们所使用的不同环境。

与我的工作相关的其他类型的事情是自定义检查，很容易排除* CCAU代码。