接口测试 各位大佬，请教一下无返回参数的接口应该怎么测试呢？
背景：
SDK 接口无返回值，里面封装了一系列逻辑，包括一些不对外的状态值的变更。
该接口无回参，成功与否会分别去调用监听器里不同的方法，返回不同的标志。
问题描述
接口执行后，测试可以去断言被调起的监听器的返回值是否符合预期。但是接口内部对于一些状态的改变如果存在不符合预期的情况，是不对外暴露出来的。这种情况下，怎么去监测不对外暴露的这些状态的正确性呢？
一些思考：
1、可以去看日志，日志里面有详细的输出各个状态的改变，但是问题是日志输出需要人工去看，没有办法实现自动化。
2、让开发把这些状态改变做成回参抛出来，但是估计不太现实。
求教各位大佬有没有相关的经验，指导一二，叩谢！
——————————————更新————————————
更新一下我这边的处理进度，给大家一个参考：
开发有个接口是做日志上报的，我把这个接口重写了，获取了 70% 想要的数据；
还剩下 30% 没有解决，考虑大佬的提议，用 shell 脚本进行解析。
1.可以实现自动化吧
sdk 是你们自家的么？如果是，让开发加几个一些可以查状态值的方法，是不是就可以？
1、可以去看日志，日志里面有详细的输出各个状态的改变，但是问题是日志输出需要人工去看，没有办法实现自动化。
为啥不可以实现自动化？
剪烛
回复
这话说的不严谨，其实是我不知道咋实现自动化。
难道是写成 shell 脚本去捞吗？
或者可以搭建另外一个服务去捞数据，然后做成 api 接口去获取？
爱吃螃蟹
回复
1、开发很忙不愿意配合——给你代码权限，你撸完加上单测，直接提 PR 给开发审核合并
2、从日志输出获取信息——不用那么复杂吧，最简单操作完毕后，直接调 shell 命令 tail 一下日志文件最后几行，用正则提取就好。
建议用第一种方式，既帮助你熟悉 sdk 内部实现，也降低自动化成本，关键还提高了你在开发眼中的地位，以后做这类可测性提升的意见建议也会更容易被接纳吧。
另外，不知道你这里提到的监听器具体对应是什么，建议你也先了解清楚内部实现以及为何这么实现，再确定最佳解决方案吧。
爱吃螃蟹
回复
不用好奇，接口无返回值对你们当前的情况可能是更好的设计实现。既然调监听器能达到测试验证的目的，就不用纠结什么了吧
爱吃螃蟹
回复
我帮回复下这条吧，如果有日志，那么可以借助 ELK 这种日志收集系统，自动收集和归档日志，然后你再用 ELK 的接口查询日志就可以了了，所以其实是可以实现自动化的。ELK 这个也挺成熟的。不过这个可能遇到的问题就是 ELK 收集日志可能会有一点延迟。
dive
回复
收到，前司用过 ELK，但是确实存在你说的这个问题，收集日志有延迟。所以基本属于废弃状态，都是直接去服务器拉日志。
不过当时的应用也只是手动去查询日志，不了解你说的这个可以用接口查询。我去了解一下，thks~
爱吃螃蟹
回复
Elasticsearch 本身就是个数据库，所以有对应的查询语言，Logstash 如果设置收集速度快一点的话，可能会好一点，基本没啥太大延迟，而且你本身自己自动化的时候，就可以稍微延迟一点再验证这个日志嘛
剪烛
回复
大佬，我刚才更新了一下我这边的处理方法，调用开发日志上报的接口解决了一部分问题，剩下一部分打算采用你说的 shell 命令解析。
但是有个疑惑想请教，日志里面很多信息，可能有重复信息，你怎么确保自己对应的操作能找到准确的那条日志呢？
我目前的打算是，用时间戳去缩小日志搜索范围，想请教一下大佬那边的做法
爱吃螃蟹
回复
这得看你怎么写了，我们很多策略，做多重验证，比如在一行里，验证 flag，还要验证 uid，或者在确定有结果才开始监控。反正基本跟写断言差不多咯