抓包不行 属于 SDK 底层

前面波动的报错具体是什么？还有你的脚本能保证一直稳定的每 5 秒并发一万个请求嘛？先找找自身脚本有没问题，再看报错原因。后续稳定后是都一直请求成功么。还有压力测试时要注意热机，模拟真实场景，不能拿到脚本就开跑。你压测时开始是有请求拥塞的，所以服务器的压力比较大会有波动去处理这些请求，当 TPS 稳定后就会像你后面的一样了，所以这样设计脚本就很有可能出现这种情况。你也可以设定稳定的 QPS 去压测

这个就要看需求了。服务端逻辑和前端逻辑是应该保持一致的，这种也是安全问题，可以篡改

还是得看具体业务

?

xmind 吧 特别是项目灵活的，且测试人员不是很够的情况，写用例耗时间而且不灵活，人少考虑的不完善。xmind 就可以一目了然，而且可以各种覆盖。。测试人员少项目迭代快需求不清晰的去写用例就存粹是耍流氓，你会发现很多时候用例满足不了以及不灵活

用例上添加了这个监听类是可以生效的，xml 运行可以。但是用 ant 构建就不行

嗯 我再多看看

这是路径 是 c 盘根目录下的一个报告。直接用 ant 跑没问题，用 jenkins 输出两份报告的时候就会报错

毕竟是 UI 自动化 要和接口连起来太多判断了不建议，最好把日志打印出来每一步干什么，然后分析有问题的时候是哪一步出现可问题再结合报告的报错原因。可以把日志也生成一个报告

要么数据库要么关联接口校验。建议这两个都用，只是数据库校验不是每个接口都要用的

慢慢来，已不可能纯粹做功能测试的，你会发现有时候很多东西功能测试满足不了或是不好满足的，自动化是一个渠道

验收的话受益其实不低的，前期花点时间。提测功能那种也可以提前编写一些接口自动化的流程呀，提前保证一些流程性的业务，也花不了多少时间的，再评估看有没工作量的时间投入到一些细节测试，根据公司产品开发而定嘛。最主要的是前期推动，要从自动化体验出测试的价值

说实话 java 写太沉余了

一般自动化测试分为两种 一种是接口自动化提前发现问题，一种是验收主流程。。所以和你说的并不产生冲突。在研发还未提测功能时，你就可以走接口测接口提前发现流程和一些单接口的问题还能提高健壮性。在迭代功能测完后也可以走验收主流程的自动化测试也能大大减少人力操作，因为有些迭代你也不知道是不是会影响一些主功能。所以自动化测试还是有必要的，能提高质量和保证质量

首先安全漏洞，并不是全部都得借助工具扫描。工具扫描只是一种批量标准化的手段，burpsuit 用的比较多吧，可自定义扫描铭感信息这些。漏洞扫描这个东西还是最好有个方案再执行吧，不然一头雾水

放心这些基本上现在多了防中间人攻击，要么本地代理安全交付平台的，要么是 sslpining 双向验证。你不可能能抓到的，除非让开发给你打包屏掉这些

不太会用 yapi 的 Pre-request Script 请求配置，请问在哪可以学习呢

与你所在的网络也有关系，线程数上去可能会流量丢包，出现报错，服务器压力却上不去

好的

emmm 没用过 list 存值,正则取值放 List 吗，然后用 beanshell 前置处理器随机取参么

是的 我就是用的 csv，不过就是不太只能，每一次用了待审批 ID 后，还得取创建，再去取值

问题是要用的那个 ID 是正则表达式取出来的，很多值，他不能一次性放环境变量里的样子，放了，它取不了

不行，foreach 里面可不能添加同步定时器。foreach 是循环，在循环里面添加定时器，他会永远等不到并发数

主要是我跨线程的这个参数又是一个多值的变量，比如调用这样写 就不太行的样子 ${P(V(newprojectid_${__Random(1,20,)}),)}。。。貌似还是只能在同线程组内进行，不能做到第一个请求只做一次，第二个请求利用它的响应数据做参数并发多次