上上周一个同事加班到11点原因是ZXX001报表在测试环境运行正常一到UAT就少数据。他对着代码反复看怀疑排序怀疑BUFFER怀疑内表去重最后实在没辙在循环里写了个BREAK-POINT.。结果跑起来一看——好家伙内表里有一行重复的条码在测试环境里这行数据不存在。问题根本不在代码在数据环境。断点就是这种东西你盯了半天逻辑不如在某一行停下来亲眼看一看内表里到底坐着什么妖魔鬼怪。ABAP里断点分两种大路货一种写死在源程序里一种在调试器里临时挂。写死在源程序里用BREAK-POINT.。这个语句很粗暴程序跑到这里直接弹调试器。但是请注意生产代码里出现这种语句是要出人命的。有一次我接到一个用户报“一跑程序就卡死”查了半天发现三个月前有人调试时加了一句BREAK-POINT.忘删了正好那个报表每天凌晨被后台作业跑一遍作业一撞到这句就停下来等调试器后面全堵住。最后删掉那句话世界清净了。所以真要临时在源程序里写请用IF sy-uname ZTEST包一层并且记得调完立刻删。比如IF sy-uname ZTEST. BREAK-POINT. 只有这个用户触发其他人不受影响 ENDIF.调试器里临时挂的断点最常用是“会话断点”。你在SE38打开程序把光标放到某一行点行号旁边那个小方框或者菜单Breakpoints - Create行号后面会出现个小标记。这个断点只属于当前用户和当前登录会话你重登系统就没了。适合自己慢慢看。如果要调试别的用户跑的东西比如一个前台事务报错你不知道他点了什么不想让他一直在生产上瞎点就用外部断点。在SE38或SE80菜单里Breakpoints - External Breakpoints - Create。填上目标用户ID、程序名和行号甚至填上事务代码。这样那个用户一执行到这个位置系统就会进入调试模式你可以打开调试器看他在干嘛。但这个功能属于“核武器”别拿它来偷窥别人操作更别在生产高峰期设置一个用户级外部断点。不然人家正在过账突然屏幕卡住进入调试器他可能以为系统炸了。另一个值钱的部分是条件断点。很多新手打断点后就是一路F5单步执行看到眼瞎。你要做的是让断点“有脑子”。在调试器里断点列表中右键一个断点选“Create Breakpoint”或者“Properties”可以输入条件。比如你只想在LV_ID P001时停下来LV_ID P001注意ABAP的比较是不是。条件里也可以写SY-SUBRC 0或者GT_ITAB[] IS NOT INITIAL。只要表达式返回布尔值就行。如果你在循环里打断点条件会对每一行求值不用担心性能你没那么大数据量。还有一个很好用的东西监视点Watchpoint。假如你发现一个内表GT_DATA在程序后半段被改了但不知道是哪一段逻辑改的。你再怎么打断点单步看都是大海捞针。这时候在调试器里选中GT_DATA这个变量创建一个Watchpoint指定“Change”值变化时触发。然后直接F8继续程序一跑到修改这个变量的地方调试器会“咔嚓”停住。你一看调用栈就是那行MODIFY。监视点还可以针对某一行条件比如GT_DATA[ 2 ]-NAME不等于空时触发。注意监视点只在你当前调试上下文内有效一旦函数返回变量就不存在了监视点也会失效。所以别指望它跟着你跨模块到处跑。调试器里除了看数值还可以直接改数值。双击一个变量的Value列输入新值回车。这招很实用比如你想模拟SY-SUBRC为1的错误分支不用真的构造一个错误输入直接在调试器里把SY-SUBRC改成1然后执行。但记住这是调试器是让你分析问题的不是让你给生产数据做手术。我见过有人调RFC接口时把内表里一个金额字段改成0继续跑结果后面生成了一堆垃圾凭证最后花了两天冲销。那会儿改数据改得爽后面填坑填得苦。另外在命令栏里输/H再执行你要调试的事务码系统也会进入调试器。这是最快速的启动方式不用专门去打断点。但注意/H会触发当前用户的下一个可调试事件如果你开着很多窗口小心全被拦下来。定位段错误还有一个很有效的技巧看调用栈Call Stack。系统报dump时ST22短转储里已经给了错误地址但你还是不知道错误发生在哪个业务逻辑里。在调试器里打开Call Stack标签页你能从头到尾看一遍调用链。比如一个函数CALL FUNCTION REMOTE_LOG你看它里面为什么会dump直接双击栈顶某一层就能跳到那层所在的代码行。有时候错误在嵌套三层之后不看调用栈你根本不知道是第一个调用者传错了参数还是最后一个被调者用错了变量。后台作业和RFC怎么调试后台作业没有交互窗口你没法像前台一样挂会话断点。可以用外部断点把用户设为后台作业所属用户一般是SAP_BACKGROUND程序名填上作业运行的程序。这样作业执行到指定行时会停住然后你就可以在调试器里看它的现场。这个操作风险很大因为后台作业一旦停在断点上后续任务全部挂起。如果是财务月结期间你敢挂一个外部断点别怪生产经理骂街。所以记得调试完马上删掉外部断点。实在不行还可以临时在代码里加BREAK-POINT包IF判断把作业改成同步运行调试完再改回去。高级玩家还可以设异常断点。在调试器里有个专门针对异常类的断点比如CX_SY_CONVERSION_ERROR。你设置好之后只要程序里任何一个地方抛出这个异常调试器会在抛出点停住比ST22后转储更直接因为这个时候变量值就是原始现场。这个在排查这种“测试环境没事生产一跑就转换错误”的问题时特别好使。条件断点加异常断点基本能覆盖你日常开发八成的“诡异问题”。个人经验是断点这东西用得好是手术刀用不好就是刀片绊马索。我现在习惯了这样凡是自己加在源码里的临时断点一定带用户名条件并且立刻记在TODO清单里调试完随手删。生产机上绝不创建用户级外部断点除非领导签字并且盯着它。调试优先用条件断点和监视点而不是单步走。在调试器里改数据之前心里留个念改了什么自己心里有数改完立即验证。别手一抖把不该改的也改了。调试ABAP本质上是“跟踪数据的变化”不是“读代码”。你读代码只能读到作者想让你读到的逻辑数据环境一变化逻辑就跑偏了。断点就是你在数据流动过程中设卡查水表的地方。今天讲的这些足够应付日常开发七成问题剩下的三成等遇到再翻ST22吧。