挺好的 感觉又被反向洗了一次脑

我怎么觉得你的这个问题，和你的软件设计的原始架构有关系呢？比如客户端不发起评分请求，是什么原因？还有地区覆盖的问题，我感觉这个就是接口设计不够完善造成的，假如你的接口结构里包含一个 “覆盖地区” 的 key，value 是对应覆盖的城市，是不是就没有这种问题了呢？

一定会有人反对你说，我是 xx 公司高管，年薪 xx 万，我就不写代码，靠思想指导下面人实现云云。无他，小马过河的典故而已，不同的人站在不同的高度上看问题，观点显然是不同的。难得的是如何找准自己的定位，而不是迷失在人云亦云的迷雾里飘飘然。作为一线执行的测试人员，在这一点上我赞成思寒的观念，少说多做，用事实说话。因为我比较单纯，嘴笨

我就服你，句句暴击。年纪比我小，技术比我好，经验比我丰富，连话都说得比我利索。。。。真想买块豆腐一头撞死啊

这应该不是微信的 bug 吧，是这个 zizhupark 的锅啊

没看明白。。。你这个 post 请求不是 https 的么？

我现在用 allpair 生成测试用例，但是根据业务条件筛选太麻烦了，费时费力，想用 python 做这个事情，又没有什么头绪

正交覆盖法也不少用例，然后根据业务需求一条条砍。。。。砍到剩 100 来条，发现，其实嘛。。。手工也行。。。懒是一种病

这是和蚂蜂窝类似的产品么？关注一下，给蚂蜂窝投了好多稿了，没下文

第一次执行 get_token 方法后 把他赋给一个变量 temp_token,其他的用例全都用 temp_token 入参不就可以了么

应该提示没有对方所在地的位置数据访问权限

好难，看不明白，

业务关键点的覆盖，用户场景的覆盖，可执行性和可复用性的平衡

重复请求 + 验签通过且不能修改验签规则，这要是实现了你不报 bug？

您的客服在美国上班

你会看到很多似曾相识的场景：比如产品经理派小弟过来宣布改需求，然后自己撒丫子跑

这个截图看不出问题呀，如果他的逻辑是这样的：扫码-》服务端判断这是不是和上次扫的车编码一样（如果一样，返回已获得奖励金 xxxx，我瞎编的，总之一段时间内，扫同一个编码的车辆应该是幂等的，不应该能重复获得奖励），-》如果不是同一辆车，判断是不是故障车,如果是故障车，那么直接返回 “与奖励金擦肩而过” 是不是心理上比较能接受一点 好了我编不下去了

我这显示的是 30 天，ios 版本

这个看产品设计，如果是前端控制，那么后端不校验也是无可厚非的，主要看业务逻辑，和使用场景，如果什么的都判断的话，那用起来就很笨重了。

你再退一次试试？哈哈，这不是什么 bug，ios 就是这样的，每个月运营商都会有大笔的坏账，苹果公司可不管，运营商也很难挨个回档。

这是 bug？我觉得设计如此啊。既然你已经取消关注了，左上角还显示 “订阅号”，显然与需求不符么，当然是显示该订阅号本身的名称。

确实翻译得不错，没有那种机翻味，不过既然选择学一门语言了，总得给自己定个小目标不是

正在努力学习日语，争取早日读懂原版的《挪威的森林》，读原汁原味的不可描述

只有我一个人把不可靠描述看成不可描述吗

最大响应时间在 5s 内？