我们日常实现系统级别自动化测试的时候,一个用例需要执行多种类型的测试步骤,包括:数据库、日志、 Web 和一些模拟工具的操作。 Sikuli 实现界面类型的测试步骤是其长处。本文研究了如何将 Sikuli 融合到系统级别的自动化测试流程中,解决系统测试用例中界面测试步骤无法实现的问题。
在实际做某平台项目自动化测试的过程中,发现平台的自动化测试一直无法有效开展。平台项目本身系统及其复杂,造成测试难度就比较高。因为
1、 项目的模块众多;
2、 版本类型多;
3、 功能多;
4、 流程状态链长,导致状态路径多,任何一个出错都会导致失败。
除了系统复杂,导致自动化测试比例不高的另外一个重要的原因是原来的自动化测试方案:通过完全的消息收发来实现流程的方案,有很多弊端。
1、 消息都是私有协议封装的消息,消息都是二进制类型的。导致测试用例的配置繁琐,工作量大(大量的资源都用于配置消息字段级的值),且容易出错。
2、 采用消息流的方式导致测试过程不直观,无法对正常的手动测试产生帮助
3、 工具复杂,维护难度大,现在已经没人维护,导致新功能无法实现自动化测试。
原文转自:https://mp.weixin.qq.com/s/XMsmK6kaysG7Y_DUZjnx-Q