之前在开发定制的 .Net 平台 Test Library 时,考虑过是做成 Remote Library 还是 Normal Library。
我更倾向于 Normal Library 的模式。
Remote Library
Remote Library 模式下,Test Library(实现具体功能的 dll 文件)host 在一个独立的进程中,也就是 Remote Server (如:NRobotRemote)。
优点
- 驱动更自由。CPython、IronPython 都行,只要装了相应的 Robot Framework。
缺点
- 对 Keyword 的调用不支持可选参数的模式,必须填写所有参数;
- 能传给 Keyword 的参数类型也太少,经常要在 Keyword 内部 Cast 参数类型;
- 需要额外维护 Remote Server 这个进程。
Normal Library
缺点
- 要调用 .Net Test Library 必须用 IronPython 驱动测试。
- IronPython 的 Built-In 及 第三方库 不及 CPython 丰富,很多第三方 Test Library 也不兼容。对此问题可以:
1. 不用 .Net Test Library。
如果 .Net Test Library 中关键字在具体测试中使用率不高,则尽量用其它方法替代这个 Library。如:《Robot Framework 网页自动化测试中“下载文件”》。
2. 可以启另一个进程去操作,操作完成就销毁这个临时进程。(比 Remote Server 轻)
3. 重新设计 Case。好的 Case 设计可以规避一些这类问题。
如:测 UI 的 Case 只操作 UI;测 SUT 内部逻辑的就做好 Service 层自动化,别管 UI。
Remote 形式的 Normal Library
(2015-07-31更新)
这种模式是指:将 Normal Library 以 Remote 的形式提供服务。(Python Remote Server for Robot Framework)
这种模式除了像 Remote 模式那样需要维护一个额外的 Remote 服务进程外,几乎规避了所有单纯的 Remote Library 或 Normal Library 的缺点;同时又有它们各自的优点。
当然,提供服务的进程驱动必须和 Normal Library 匹配。如:Normal Library 内部调用 .Net Assembly,服务进程就得是 IronPython。
另:搭建这个服务进程比单纯的 Remote Library 服务进程更方便。
from robotremoteserver import RobotRemoteServer
from mylibrary import MyNormalLibrary
RobotRemoteServer(MyNormalLibrary())