background:最近两个月被分配做UI automation,原因是换了一套平台,需要重新部署,有些业务需求改了case都跑不过了,我的任务是debug case,把case都跑通。工具是Robot Framework。
当时感觉task相对轻松,因为业务相对简单,只是Case多些,但debug case,应该是我强项(这些年的工作经验里debug 代码了解业务是我的强项,虽然不是什么好的学习代码的习惯吧),不过越debug越傻眼,因为核心逻辑就那几个keywords,有时可能牵一发动全身,而且最最郁闷的是,公司用的是AWS,采用的是Lambda+API Gateway的request方式,而lambda每天有访问次数限制,超过峰值速度就会特别慢,每天下午基本debug不了case,所以要早上早早的到,争分夺秒改case跑case,效率真的很低,每天改四五个case很不错了;而且坑很多,明明看着没问题,debug也发现不了哪儿错,case就是不过,后来发现如果sleep几秒(争分夺秒的秒是这么滴重要,哈哈),case就pass了,可不知道的时候,就会花几个小时。
后来领导说效率太低,要改进测试方法,这可乐坏本宝宝了,因为之前研究过自动化测试,虽然没怎么做过,但我知道我们的automation测试症结在哪儿。
浅谈API测试与UI Auomation一点心得_第1张图片

从自动化测试金字塔的角度出发,UI的投入产出比是最低的,我们UI的case很多,但是没有API测试,而且最怕的就是把automation 做成了倒金字塔。于是征得领导同意后我开始研究怎么做UI 的API测试,我是从以下几个方面调研的:学习工具的成本、是否开源、开发的成本、与jenkins的集成、case是否容易管理,自动生成report。后来发现TestNG是最佳选择,但是由于某些原因,TestNG被否了,最终的决定是用HTTPClient jar包自己写Keyword,然后用Robot调用这些keyword。
当时为了验证TestNG的可行性,自己写了个Demo,感觉用TestNG写case很省时间。后来自己写keyword在eclipse下debug的时候发现也还算好,虽然没有TestNG那么高效,但比Robot cost小很多。
可当用Robot调用这些keyword的时候问题来了,而且让我再次感慨Robot还是不方便,原因有以下几点吧

  1. Eclispe debug方便直观,而Robot只能加log,不容易定位问题。
  2. 如果是keywod的问题,Eclipse可以直接debug定位,而Robot是对keyword进行了调用,还需要回到eclipse再次debug,debug需要更长的时间
  3. 最后核心还是Robot写的keyword,而不是java的keyword,这样其实和UI automation没什么太大区别,我感觉cost还是很高。

不过API测试也不是万能的,比如最近新加的一个功能,本来我全用API写的,没有UI Automation,但后来因为一个手工测试,API case跑过了,但UI测试是能catch住的一个bug,所以让我更坚信一句话:无论手工测试还是自动化测试,最核心的还是case的design。怎样用测试理论中的最少的case cover更多的功能,怎样设计case使得UI Automation、API测试更合理化,都是一个功底活儿