这里面我理解是两个问题。
一个是接口测试是否有必要，接口测试的目的是为了增加测试覆盖度、深入度，对接口的各个参数做实际场景中很难遇到的异常场景的测试，保证接口的稳定性。如果在这个前提下接口测试还是没有发现 bug，那么可以 review 下历次迭代中是不是业务测试发现的所有 bug 都是前端的。如果是那么说明你们的后端开发工程师能力实在很强，应该恭喜你们遇到了这么给力的队友，在测试压力很大的情况下就可以酌情考虑不做接口测试前端测试完成就上线了。如果不是那就应该 review 你们的接口测试用例了。是不是用例设计的还不如业务测试全面，是不是用例设计的时候默认按照正常的取值范围，按照正常的业务逻辑进行的用例设计导致用例的覆盖还不如业务直接黑盒测出来的覆盖全。
另外一个是接口自动化测试是否有必要，自动化测试的目的主要就不是发现多少 bug 了，而是为了快速对接口做回归、做线上监控等，避免接口出现了低级问题、阻碍问题但是大家不能第一时间知道，等过了很长时间线上出了强反馈或者在错误接口的基础上又做了很多开发才被大家发现。当然，在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要，思路就会清楚一些。
整体上测试是为了保证业务中的 bug 能够在有限的资源下最大量、最快速的发现，业务实际情况不同、测试团队规模不同、测试与业务的合作模式、测试团队成员的技术能力等等都会影响测试方案的制定。我觉得你们团队有专人做接口测试，这种情况下接口测试定位到用来发现更多 bug 是没有问题的，如果没有发现 bug 那就需要仔细找找接口测试用例设计的问题。接口测试的目的不是取代业务测试，而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量。接口自动化测试的目的是在回归场景节约业务测试的工作量，在新业务测试中实际反倒会占用更多的测试资源。这是我对接口测试以及接口自动化测试的理解

我一开始有也遇到这个问题，后来我使用 appcrawler 2.1.3, appium 1.4.16, nodejs 6.9.4, 在执行指令前先启动 appium 就没有问题了