测试方法的汇总，build.gradle文件比较，邮件配置，MOCK接口，模拟重试
1.项目中jar的配置，可以对比一个可以正常启动的分支，一个是异常分支的。 通过git的合并功能，来判断区别点是哪里，然后可以调整成可以正常启动的分支，解决问题。 比如： 需要去掉exclude，否则jenkins部署失败。build.gradle文件 compile('com.xuxueli:xxl-job-core:2.0.1-SNAPSHOT') // { // exclude module: 'jetty-server' // }
2.邮件发送功能模块化，可以将平台的基础功能服务化。且邮件的发送账号，密码需要使用公司的通用账号，而不是个人账户。 但是在个别的服务中，发现线上的邮件的配置是开发人员自己的账号和密码，这样很容易导致后面开发人员更改了密码等，导致项目无法启动成功。 jenkins在做health检查的时候，会报错。
3.可以考虑将mq接收的消息，改成mock test接口的方式来调用。且调用的数据不依赖于查询数据库，这样还可以解决造的订单号来测试。 通过造数据，mock调用接口。不依赖订单系统查询。 基本思路：开发的接口或功能，可以暴露出测试点，方便测试和触发。
4.接口的重置机制，在请求日志中加上“重试机制”的标识。 可以模拟调用外部接口返回异常的情况（将微服务默认返回失败等），而测试重试的功能。 5.本地电脑可以测试的，比如Apollo fake配置，不要部署到公共的测试环境来测试。一方面频繁的部署重启影响其他的同事使用，二来提交git，合并公共分支，然后jenkins部署，消耗更多的时间。 测试起来也不方便。
6.上线后测试接口。发现：token验证，发现是测试环境跟生产环境的配置是两套配置，不一样。 测试环境可以通过，是因为测试环境的配置key是一致。所以没有问题。比如：测试环境2个接口，2个接口的配置key是一样的，token = md5(时间戳 key)，无法发现问题。 看来测试环境的配置还是需要改成不一样的，每接入一个新配置一个key，且不相互影响，这样可以发现代码问题。不排除代码中用到的key可能存在公用的代码。
