总结一下今晚遇到的问题及其思考：
首先是 travis.ci 上的 ft 一直有 19个 case 没有跑过，看到异常信息里面有个 can not find endpoint to access 由于本地有时也会遇到这个问题，是由于ak不对，找不到 endpoint的问题。下意识地以为 ci 环境由于账号权限不够，找不到环境变量的 ak。
吃完饭，后来稍晚些时候，本地跑 ft 时发现怎么也有19个错误呢，这时没有把本地的错误和线上发生的错误联系起来。于是就去单步断点调试发现哪里有问题，先是手动设置endpoint ，发现 服务端 返回 400 错误，version 不正确。这时候能断定的一点就是确实是我的代码出现问题了。
接下来是排查本地代码的问题了，我查看了Github 上上次提交的代码的CI，是否成功运行，发现之前都是能成功运行的，问题锁定在今天提交的代码上，查看 PR 的 diff，终于在一个类的构造器初始化中发现了端倪。
具体是为什么其实已经不重要了，虽然这其实是个 很低级的错误，Setter 方法中不仅仅赋值。还添加到了 dict 中。然而我直接赋值给了 this.version 和 this.actionName 当然有问题。
其实发现这个问题，以及如何解决这个问题都是很简单，很简单的。
事后思考了一下，为什么如此简单的问题，自己会排查很久呢？
这整个排查过程至少有两个阶段我可以得出是我代码的问题。而不是权限不足的问题。
首先第一，我在 travis.ci 中配置了如果没有获取到 ak，则不跑 集成测试。然而现实情况是线上跑了一部分集成测试。
第二，在本地跑集成测试时发现错误后，发现和线上的错误数量case一样时，也应该想到。
为什么没有提早发现呢？
其一，先入为主的把之前的经验带入，进行判断。
其二，PR 的信息太乱了，没有遵循 一个PR，做一件事的思想。
获得到的经验以及自己的想法：
1，再一次验证了 把测试 回归起来的好处，可以验证自己写的代码到底有没有问题。
2，首先找自己的问题，有十足把握确定没问题了，再去检验别人的问题，给出你的观点和验证。
3，解决问题并不重要，重要的是知道为什么会出现这个问题，以及下次是否还会遇到这个问题。
具体 PR 的地址：https://github.com/aliyun/aliyun-openapi-net-sdk/compare/downward_compatible_csharp5_version