谢谢，我去参考下

我们是自己探索跟实践，有经验丰富的人指导下，可以少走点弯路

因为我们那的需求都是单服务的需求，每个单服务都能够独立执行，所以没有一些外部需求背景，只有一份设计文档

不建议用这个思路去设计用例。
跟着开发的代码思路、设计思路写用例，和开发写的单元测试场景重复性高，会被开发带偏，容易忽略特殊的业务场景（可能开发漏了该业务场景的考虑），假设开发写了额外的代码逻辑在设计文档中未体现，就无法保证代码覆盖率等。

当初做服务端测试时，拿着开发给的设计文档写测试用例，被 P9 级大佬叼到无地自容，重写了 5 6 次用例

这个思路很难成立，有个前提就很难保证，需要相信开发的代码，不然只能全量覆盖

目前解决方案：降 rf 版本，将不支持的语法暂时写死值去取代

用了同事的版本 run 不起来， 降了版本存在语法错误，有的语法只有较新的版本支持

这边项目用的都是 python2 暂时不考虑升级

改了文件名 ride log 有这个报错

view parse log 有报错，但我只执行了第一条用例，报了其他用例的错误

没有

等待开源

还有重要的一个点，面试要自信，尽可能化被动为主动

可能你的技术是够了，但这面答确实不行，尽可能在每个问题的正确答案里添加一些个人简介及思路，多结合实际场景来回答，面试官对工作年限较高的工作者的考核，不仅仅是一个基本答案，一般还会关注你的可塑性，有没有做管理的潜质，思维是否灵活，业务的理解程度，有没有开发新业务的潜质，造轮子的工作谁都能做。

再扫一次报告无该漏洞就算解决了

小鹏的作息是怎样的

从你描述来看能有 50 并发就能满足这个场景，可以阶梯式压测，测测瓶颈，并发数 50 100 200 那样上去压，持续时间 30min 已经能满足了

如果岗位对标的只是点点点测试，不建议去，这种强度一般不会给你太多的空隙去学习，如果是测试开发岗或者自动化测试，有新框架或者能扩建技能树的话，可以去

我们是服务端接口自动化测试，覆盖率 75%~85%

有个方法可以试试，打开一个干净的 jmeter，把脚本复制过来试试，我之前遇过个报错，是脚本文件损坏还是啥来着。

可以参考我的方式，我们之前是按用例划分 testcase，这个 testcase 如果需要某个接口的返回值，就将该接口请求放置到前置条件，提取返回供用例执行，不违背用例原则。

初级的安全测试应该能够熟练使用 burpsuite、appscan 等安全扫描工具，能够手动重现 OWAPS TOP10 的漏洞；中级的能基于漏洞进行攻击，例如拿到一个 sql 注入点通过 sql 拆解分析获取到库中信息；高级的就比较牛了，无天花板，至少能够保证自己系统的安全。

刚刚验证完了，我这台机防火墙开放端口后，重启防火墙才生效。谢谢大佬