调试问题

测试用例执行失败如果是因为被测系统的问题则意味着该用例找到了一个bug, 但是还有种不幸的情况是测试用例本身就是错误的(buggy).

失败的错误消息会在 command line output 和出现在 报告文件 中, 有时候仅凭这些错误信息就可定位问题. 更多的时候, 还需要参考 log files, 因为其中的日志包含了其它信息, 并指出实际执行失败的关键字.

当错误是由于被测应用引起的, 错误信息和日志信息应该足够能理解错误的原因. 如果不能的话, 则表示测试库没有提供 enough information, 需要进一步加强. 这种情况下手动再次执行测试也许能揭示更多错误相关的信息.

由测试用例自身或其使用的关键字所引起的错误有时会难以调试. 如果错误信息比较明显, 例如, 提示关键字的参数数量不对, 则修复该问题也会很容易. 然而如果一个关键字的错误以意料不到的方式发生, 则定位问题的根源会相当困难. 首先需要检查的地方是日志文件中的 execution errors. 例如, 测试库导入失败的错误可以很好的解释为什么会出现关键字缺失的问题.

如果日志文件不能提供足够的信息, 可以调低 日志级别 再次执行测试. 例如, 以 DEBUG 级别保存的回溯(tracebacks)信息可以指明错误发生的代码行, 这个信息对于定位个别库关键字问题非常宝贵.

然而日志记录的回溯没有包含Robot Framework框架本身的方法调用信息. 如果你怀疑错误是由于框架的bug引起的, 可以设置环境变量 ROBOT_INTERNAL_TRACES 为任意的非空值, 这样就可以显示内部跟踪(internal traces). 这个功能是在Robot Framework2.9.2版本后加入的.

如果日志文件信息仍然不足, 则可以启用 syslog_, 看看其中会有什么有用的信息提供. 还可以在测试用例中添加其它关键字来辅助调试下. BuiltIn_ 关键字 LogLog Variables 是很有用的工具.

如果所有招数都不管用, 可以考虑从 邮件列表 或其它地方寻求帮助了.

使用Python调试器(pdb)

Python标准库中的 pdb 模块可以用来在测试中设置中断并交互式地进行debug. 典型的使用方法是在Python代码中想中断的地方插入:

  1. import pdb; pdb.set_trace()

这种方法对Robot Framework不管用, 因为标准输出流在关键字执行时被重定向了. 使用下列的代码即可:

  1. import sys, pdb; pdb.Pdb(stdout=sys.__stdout__).set_trace()