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测试症结在哪儿。
从自动化测试金字塔的角度出发，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还是不方便，原因有以下几点吧
- Eclispe debug方便直观，而Robot只能加log，不容易定位问题。
- 如果是keywod的问题，Eclipse可以直接debug定位，而Robot是对keyword进行了调用，还需要回到eclipse再次debug，debug需要更长的时间
- 最后核心还是Robot写的keyword，而不是java的keyword，这样其实和UI automation没什么太大区别，我感觉cost还是很高。
不过API测试也不是万能的，比如最近新加的一个功能，本来我全用API写的，没有UI Automation，但后来因为一个手工测试，API case跑过了，但UI测试是能catch住的一个bug，所以让我更坚信一句话：无论手工测试还是自动化测试，最核心的还是case的design。怎样用测试理论中的最少的case cover更多的功能，怎样设计case使得UI Automation、API测试更合理化，都是一个功底活儿