当然 exists(timeout) 和 waitForNonExistence(timeout) 并不能解决所有问题，比如上面例子中，点击 Ignore 按钮后对话框的内容和布局都会发生变化，但是对话框本身并不会被关闭，所以在这里插入等待的代码是必要的。在实际测试中，我们总结出一些针对步骤间等待的方法和原则：
● 尽量避免直接使用 sleep(timetime)，因为我们无法预知在不同的机器上，在不同的平台上，等待多少时间是合适的；时间太长影响执行效率，时间太短在某些配置较低的机器上测试可能不通过。
● 许多方法支持超时等待，如 exists(timeout) 和 dbOpen(timeout)，尽量使用这些方法代替 sleep()
● 尽量使用轮询，而非直接等待固定长度的时间。
● 在不得不使用 sleep（）的情况下，等待预定义的时长。我们定义了 giSTO、giTO 和 giLTO 三个常量分别表示较短时长，正常时长和较长时长，测试人员可以在不同的测试环境中设定这 3 个常量的具体数值
关于异常处理
我们永远无法预测哪一步会导致自动化测试的失败以及异常退出，也许是测试用例的某一步骤编写的不合理，也许是因为产品出现瑕疵，因此异常处理也是测试用例编写中从最开始就必须注意的。
在 Lotus Notes 的测试用例中，我们建议所有的测试用例主体代码都要位于如下 try/catch 代码块中
例 4. 注重异常捕获的脚本模板
| try{ … // 初始化测试环境 setUpTestCase(); … // 开始测试代码 … // 结束测试代码 }catch (IllegalArgumentException e) { ScriptTool.templateIllegalArgumentException (e); }catch(RationalTestException e){ ScriptTool.templateRationalTestException (e); }catch (RuntimeException e) { ScriptTool.templateRuntimeException (e); }catch(Exception e) { ScriptTool.templateException (e); }finally { ScriptTool.templateFinally(sScriptName); } // end finally try { … // 清理测试环境 cleanUpTestCase(); ScriptTool.cleanup (); }catch (Exception e) { Logger.logError("Exception thrown from CleanupTestcase"); Logger.logError("Cause of the exception: " + e.getCause()); Logger.logException(e); }finally{ // 标志测试用例结束 ScriptTool.endTC(sScriptName); } |
即使在脚本执行过程中出现异常，我们也可以在日志中输出完整的脚本执行记录，并完成环境的清理工作。cleanUpTestCase() 和 ScriptTool.endTC(sScriptName) 将确保被执行。
进阶——数据驱动和配置驱动
在 IBM 框架的支持下，我们已经可以写出结构清晰的测试脚本。对于一些复杂的测试情况，我们还可以通过其他一些技巧来拓展脚本的灵活性，其中就包括数据驱动和配置驱动。下面，先让我们来看一看数据驱动。
数据驱动
有时候，我们需要在应用中输入不同的数据，并在进行一系列同样的操作后验证输出结果的正确性。比如说 Lotus Notes 提供的联系人自动补全功能，在用户输入部分联系人名称之后，Notes 将通过搜索后台的最近联系人列表、用户自定义联系人列表和服务器目录来完成联系人名称的补全工作。
