1. 内部测试时，渠道方无测试环境，那么自己 mock 即可，保证跟渠道方接口协议一致，覆盖错误码，加验签/加解密可以直接 让开发通过接口调用保障；
2. 内部测试完毕，可以增加白名单/灰度的能力，方便线上测试；

楷模孙老师

依旧求简历中～

依旧求简历～

有的，可以发简历看下～

求简历～

测试

已经说了离职的话，不要真的等到那个时候再走，立马准备面试吧，不然后面的发展可能不像你想象的那样

https://blog.csdn.net/huilan_same/article/details/52246012

我记得有个地方蛮多都是测试数据，之前找过

python 自动化测试

https://testerhome.com/topics/14611

for file in `find /A -name "*.jpg"`;do mv $file /B;done

https://testerhome.com/topics/16169

arr = [-3,-2,-1,0,0,0,0,0,0,0,0,0,6,6,7]
print arr[arr.index(0)-1]
print arr[::-1][arr[::-1].index(0)-1]

我明白你的意思了，你的意思就是相当于传参是特殊构造的，然后根据传参可以直接通过业务逻辑 “计算” 出期望值，从而避免了从数据库中查找再组装数据，这个针对简单的业务来说应该是比较好的方式了，我再想想哈，谢谢了哈

哈哈，我这个可以理解为交易造的数据，在查询数据的时候会根据业务作出相应的过滤；如果按照大佬的意思，期望值 A 值怎么来的呢？查数据库？fake 数据？

如果数据复杂一点，更本就验证不了...

但是不与数据库对比的话怎么保证返回数据的正确性呢？曾经就有一个 bug，就是返回的一个价格都是一样的，对比数据库之后发现了，目前我们有返回值的 schema 验证，不知道各位大佬有什么更好的验证方式；

大佬怎么验证的？与支付有关，不都得验证数据库么？

但是我感觉这样不好，因为一个字典元素里面的值都是有关联的，强行拆开验证就算没有问题，但是也不能保证这个接口返回了正确的值：
假设接口返回了 [{"a":1,"b":2},{"a":11,"b":22}]，我按照 Keys 再组装成{"a":[1,11],"b":[2,22]}，那么，可能数据库返回了 [{"a":1,"b":22},{"a":11,"b":2}]，这样实际上是不对的，但是测试通过了；

哈哈，这哥们也是有心了，小黑屋蹲着吧