事情是这样的，公司的的中间件 就是一个简单工程，打成 jar 放到客户的共享服务器上，这个 jar 就 2 个作用
1.把客户服务器的文档数据读出来，调用我们公司 openAPi 将数据同步到我们系统
2.调用我们公司 openApi，将我们公司数据读出来，写成一个文档，存储在客户共享服务器上
目前我做测试 做了读取数据的业务场景的 增删改，和个别可能有性能负载场景的 性能测试
然后这些数据在我们系统的使用做了业务测试，保证数据接进来可用
是不是做的有点简单啦？老哥们给看看
别沉啊
可以做的简单，也可以做的复杂，但是业务本身简单，是否需要投入这么多成本？
除了正常场景，有些异常场景是否也要覆盖，比如 读取的文件不存在、文件格式不符合要求、大文件、空文件等
可以写成几个内容的工具在根据实际情况串起来。好像是类似一个 forward+ 转换生成文档的服务（好多有基建的公司都有文件转换服务的，其中一个功能就和这个类似）
1.打成 jar 放到客户的共享服务器上，是否只能同步 jar 包其他格式比如 war 同步，jar 包启动是否成功，同步方式验证同步后的文件大小一致，版本是否一致。
2.客户服务器的文档数据是什么格式，需要转换成什么样的数据 (bo 成什么)，Bean 转换后到 openAPI 的接口参数测试
- openAPI 是否有调用的频率限制 (时间或者数量限制)，转换成文档是否可以打开，读取字节数量和服务器文档数据是否一致。 熟悉 java 写单测是最好的，或者用其他语言写工具都行。
深一点的话，可以针对数据存储、服务依赖、服务异常做些故障演练，数据存储可以了解缓存穿透、击穿、雪崩，比方说在读取数据时数据正在删除中，会不会抛出捕捉不到的异常。服务相关的可以参考 panic 服务的场景考虑，比方说依赖的应用程序崩溃，在测试环境 kill -9 模拟，服务请求超时，依赖服务 connect fail 等。