主要是对外提供的是接口，不直接提供 APP，所以传统的功能测试手段不能有很好的测试覆盖

是不是一开始方向就不对，为什么必须得是白盒测试呢，黑盒很好或更好吧。
“这个 json 是基于动态获取某一个接口类下获取的所有方法生成的”——怎么还动态获取，直接参考接口设计文档不行吗？

看到标题进来后，感觉这个白盒和我理解有点出入。我理解这个只是灰盒，不至于纯黑盒只看到界面，但也没像白盒那样深入代码校验分支覆盖。

我觉得你这个方向还是不错的，通过反射让方法名和参数都变成配置文件可以自由配置的项，这样可以不写代码，只改配置来完成测试用例，写起来应该比较快。缺点是没有 idea 自动提示，有可能会写错而不自知；另一个缺点是不好选择性执行，可能要通过手动注释的方法来做。

其实一般这类接口都不会轻易改的，可以考虑类似单测那样，直接就老老实实一个一个函数调用写上去，有 idea 自动补全还不容易写错。如果要做参数化可以结合数组之类的做，可以参考 groovy 的 spock 测试框架，或者 testng 的 parameters 来做入参配置化。好处和缺点和你的 json 方案刚好反过来。你可以按自己需要选择。

另外，异常场景要考虑抛异常这类场景，毕竟是 java 接口，抛 exception 还是很正常的，但我看你好像没提到。

直接针对提供出去的 API 接口做接口测试不香吗？

Java 接口，不是 http 接口，需要编程去调用

谢谢大佬的建议，之前有考虑过老老实实写单测，但是只能有代码能力的人做，CTO 的建议是做成一个工具，说像 postman 那样的工具。思来想去，就往 jmeter、postman 这类工具的做法上走了。

我想法是这样：
写个执行的 apk 跑在安卓设备上，电脑上写个类似于填空的 gui 界面跑着，可以动态从指定的待测类上获取所有方法相关信息过来，这样搞完用例保存成 json；
执行的时候，在电脑的 gui 工具上选 json 文件，再选择执行这样的，推送 json 到设备上反射执行完回收结果，出个测试报告之类的

关于异常，在执行的时候做了全局 try，catch，把内容放在测试结果返回去了

Java 接口，不是 http 接口，需要编程才可以调用

都做 Java 接口级别的测试了，还要专门搞个工具给没有代码能力的同学去测试，感觉是不是有点本末倒置？

不是应该想办法让大家学习掌握些测试所需的写代码能力么？做代码相关的测试，却不掌握代码能力，那不如让开发直接基于 sdk 能力搞个 app（类似各种控件 demo app），让你界面直接调用 sdk 提供的各项功能，做黑盒测试？

暂时条件有限，学的事情都在培训教，我先探探路

直接针对提供出去的 API 接口做接口测试不香吗？

我跟 4 楼是一样的观点。