应该去问，开发是通过什么判断上一秒接口返回是否正确

只是从具体来做时来分析，csv 的形式只是实现比较简单，但是根据维护成本和用例复杂度来考虑的话，应该还是优先考虑 pageobject 模式吧

csv 的话，像是测试流程时存在复用时应该只是复制黏贴，po 的话直接调用某个类和方法即可，可读性高
另外就是前端 UI 变动时，针对有复用的情况改的地方多些
我没做过这块，上面的只是分析来说会存在的情况，不正确的话还请指正哈

666，最近经常点外卖，回去玩玩

兄弟讲的是真的真实啊

极客时间买了些，上下班地铁上慢慢就看的差不多了

负责人不是高级测试工程师，而是高级工程师，有理由相信，至少人家是想撇掉测试头衔的。
测试真的很尴尬，一亩三分地还被开发染指，抢走责任田。

测试的职业生涯真的不要那些毒鸡汤，什么推动了这个，推动了那个，成为核心竞争力，太毒了。

兄弟太真实了，这个深有感受

做测试的也羡慕开发，工资和发展是一方面

关注了，经常听到这个框架

1～9 通过 n/3 和 n%3 得到的值作为横纵坐标，然后任意一步的下一个可选数字需满足：
1、该数字没有被选过
2、该数字的坐标不在上个数字坐标的横纵坐标分别加或减 2 上

复盘啊，拉上技术老大、产品老大、项目负责人总结问题，你以后提测前把用例抄送技术部，提测让发邮件，提测质量差直接邮寄打回，问他们自测为什么覆盖不到

你这个不是 apk 的实际下载链接，要自己去抓包看看。

自定义个关键词

xpath

来学习下

客服关注的多是用户安抚啦，正常之后都会建个工单转给测试或者开发

收藏看看

学习了。内容很详细

马克，之前也做过相关的

—— 来自 TesterHome 官方 安卓客户端

早晚要背锅的节奏

个人理解，如果是一般场景下这种 A 和 B 这 2 个接口确实不应独立来测。
只是这个 sid，特殊在于它有效期一般都比较长，客户端登录后都会存储在本地，遇到待测场景的时候再取出 sid 拼接到参数里面，这种情况的话压测时还是要独立吧
————————————————————————————————
想了下，还是先请求一遍登录接口，把 sid 存在本地，然后压测时再去读 sid

例如我们现在想要知道当前服务器下能承受的接口 A 的最大并发量，
但是接口 A 请求的参数需要带上一个标示不同用户的叫做 sid 的参数，而 sid 是每个用户调用登录接口 B 后服务器返回的一个唯一的一个字符串
我们想要模拟最真实的压测情景的话，是希望待压测的接口 A，在压测过程中每个请求带的参数 sid 都不同
现在就是纠结这样的需求怎么处理好呢

恩~就是我们压测目标的接口的时候，实际上在压测的过程中，被测系统实际上是同时收到 2 个接口的请求
那么对于最后我们得出的，被测系统所能承受的待测接口的最大并发数，数据上是不是会有偏差呢

前辈你好，最近正在看您的 blog 的脚本增强篇，关于里面的提到的关联部分
使用了增强后，实际在压测的时候是不是会同时请求一个接口获取参数和待压测接口，这样的话压测接口是不是误差就比较大了
还是我对关联的理解有问题？

想问下，是怎么实现在原本的 web 界面新增字段，例如截图上的除了原始 body 内容，还展示了解密后和 eventlog
anyproxy 自定义规则只能修改原有的字段。。js 完全不熟，项目里面的 main.js 看了 2 天，楞是找不到请求的参数什么的是从哪传过去的

Doctor，总结最后一句是把 fork 拼错了吧