首先让我们了解下这两类测试：
接口自动化测试（业务逻辑层）：主要检查验证模块间的调用返回以及不同系统、服务间的数据交换，常见的接口测试工具有postman、jmeter、loadrunner等。
UI自动化测试（GUI界面层）：UI层是用户使用产品的入口，所有功能通过这一层提供给用户，测试工作大多集中在这一层，常见的测试工具有UFT、Robot Framework、Selenium、Appium等。
在开始做自动化测试之前，需要确定项目是否适合做自动化测试：
- 软件需求稳定，不会频繁变更
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要不断更新测试用例以及测试脚本，而脚本的维护实际上是代码开发的过程，需要修改、调试，必要时还要修改自动化测试的框架，所花费的人力、物力大便不值得弄自动化测试。
- 项目进度压力不大、软件维护周期长
自动化测试需求的确定、框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，如果项目周期较短，没有足够时间支持，结果还不如手工测试来的快、简单，就不需要做自动化测试。
- 测试数据、测试用例、脚本的重用性较强
需要在多平台运行相同的测试用例、组合遍历型的测试、大量重复测浏览器的兼容、操作系统的兼容
- 被测系统开发较为规范，可测试性强
主要考虑三个方面，1）所测试的项目之间是否很大的差异性（如C/S系统和B/S系统的差异）；2）所选择的测试工具是否适应这种差异；3）测试人员是否有能力开发出适应这种差异的自动化测试框架。
具体来讲哪些适合做UI测试自动化，哪些适宜做接口测试自动化？
UI测试自动化
既有的UI界面变化很小，那么此时做UI测试是很有必要的。如果几天一小改，上十天一大改，那就不用考虑了。性价比太低，维护成本过大，不建议做UI自测试自动化。
接口测试自动化
不管何种团队，只要不是一看到代码就头晕，那做接口测试自动化是一个不错的选择。首先入口门槛低，借助工具如jmeter、soapUI等工具，通过少量的代码（网上搜罗一大筐）就能实现接口测试自动化。所以这似乎是性价比很高的选择了。
在了解上面UI测试自动化和接口测试自动化的适用场景后，做好选择后；
回到问题本身，怎么利用好UI/接口自动化测试，提升测试效率呢？
首先，注意选择一个团队学习成本最低，入手最快的工具，而不是你认为“最强大”的工具，并做好培训指导工作。除非你就是所在组织测试自动化的全部，你就根据时间“肆意而为”。
针对UI测试自动化：
- 不建议对所有界面做自动化，关键页面做好自动化即可。
- 用户压根不关注也不重要的页面，建议不用花过多精力在上面。
- 注意进行分阶段，比如第一个版本可以先尝试界面“正常”用例的自动化，后面再进行第二个版本、第三个版本的自动化。
针对接口测试自动化：
- 做好接口自动化的持续集成（如利用jenkins）；
- 每天定时执行接口测试自动化用例，并生成报告（只有及时发现问题，才是自动化的意义所在）；
- 做好接口测试自动化的维护工作，做好第一版很容易，但坚持更新往往是一个难题；
- 如果项目预留测试时间不够足的情况下，可以先考虑接口测试自动化，然后再进行UI测试自动化。