这个时候，这个你画个数据流向流程图用例就可应付了
http://testerhome.com/topics/33072

大部分都是对公业务，非个人的居多，而且这些第三方的真实账户申请流程、准备的资料都很复杂，测试作为业务下游去搞很麻烦。

并且这个问题的矛盾点在于：
这种线上验证的真实账户该不该由测试来提供和申请？
是不是产品人员提供更合适，毕竟他们作为需求提出者、外部对接方和验收方？

性能只受 I/O 影响？你确定指数型正则解析不影响 I/O？
具体案例见二楼回复

那你认为的性能测试是什么？用个工具压一压？
错误的代码（这里是正则），会造成服务器或浏览器异常
这种类似白盒性质测试，会提前发现性能问题

至于正则造成的性能故障，有很多现实实例，比如：
https://zhuanlan.zhihu.com/p/456349063

不确定你认为的动态 sql 是怎样的，但 flask 中一般推荐 orm 工具 SQLAlchemy 集成。
如果想实现动态 sql 也简单，如下

query=db.session.query(x1,x2,x3).filter(公共条件)
if 情况1:
    query=query.filter(条件1)
if 情况2:
    query=query.filter(条件2)
rst=query.order_by(排序).all()

他换了个字（酔->醉），知乎上再来一波
https://www.zhihu.com/people/python-xiao-bai-92

还有知乎。。

我看过 kylinPET 的 HTTP2 的说明，说是 “在处理 HTTP/2 协议的 HTTP 的请求并发模型依据请求的父子关系，按照一定的算法进行并发”。
就是不知道这个工具内部是否利用多路复用特性，还是单纯的用并发来模拟

HTTP/2 情况下，不知道这个工具仿真能力怎样
有的工具支持 HTTP/2 协议，但不一定模拟多路复用。

另外，HTTP2 的压测工具需要解决几个问题：
1、端口复用问题，否则会造成端口使用完
2、客户端在 1 个连接中创建的 stream 上限（如 nginx 的 http2_max_concurrent_streams）
3、1 个连接的请求次数上限问题（如 nginx 的 http2_max_requests），达到上限，nginx 那边会切断连接，那压测端会不会自动做一些处理

针对你想少点代码写这个 70 个接口并发想法，我有个小建议：
LocustUser 的 Tasks 是个 TaskSet 的 list，可以尝试写方法将你的 70 个接口构造对应 TaskSet 放进去

我有个建议，可参考

那个 print 只会运行 1 次

这个是在 1 个 iframe 里面吗
（随便提一下，xpath 到属性@src的目的是？）

【一】部门负责的业务还是很复杂的，尤其工作流和对接第三方系统上面，这种用例已经得到普遍使用。
1-评审时，这种流程图用例比文字型更加方便大家理解业务流程流转，因此这种用例的评审大家提出的问题要更有效
2-执行起来还是比较高效的，能更快的 “断点续测”
3-领导检查时，很快清楚执行情况 (-_-!)
【二】流程图用例编写确实要比普通的用例花的时间多些，但说成本就不好说了，因为如果将 1 个流程图清晰的画出来而且没有矛盾、冲突，说明这个测试者对测试业务理解至少已经相当 OK 了，执行效率、给其他人传达就会更有效、省时间。
【三】如果有非常庞大的业务流程，建议按模块拆成多个子流程用例。
【四】特别要注意的是：多路径汇集后再多路径扩散时，执行时要注意多覆盖些情况 (通过备注说明已经覆盖的分支)。

locust 有个参数是可以获取响应的，再对响应检查就可以了
但这样会增加压测机的消耗，得看你实际情况了

觉得测试没技术，是觉得自己业务烂熟了吗，用例覆盖执行效率很好了吗，各种脚本工具都溜了吗。。。

为啥觉得没技术含量，熟练重复的东西觉得没技术含量。
开发的东西算技术吗，他们自己也会说没技术，熟练后 copy 改改而已。
架构师的东西算技术吗，经验丰富后也会觉得自己的东西没技术。

如果觉得没技术，但就多学习，多看看其他大厂分享经验

可能的原因是 jenkin 作为服务启动时，可能角色为 system：需要使用 admin 角色去显式启动（命令方式）jenkins 才行。

......这个是你自己挖的坑呐......

(//td)[1] 表示全部 td 中的第 1 个

得看你的需求了，
1-如果你想定时自动化登录去做一些事，那就得想法子绕开校验（ ，如上楼所说，请慎重）
还有如果是通过 webdriver 自带 click 无法点击，那就试着 webdriver 打开页面后手动点击试试，如果可以，那就尝试用 webdriver 执行 js 代码 ($("input[xx]").click())
2-如果只是一次性的，那你就手动登录后，将 cookie 拷贝出来，在 webdriver 中设置好 cookie 绕开登录

过不了 “造火箭” 的面试（很强能力），是去不了字节点点点的

无意中，看到了这个帖子：https://testerhome.com/topics/30396
贴子内容很极端，口气像是一个测开对测试推广自己的平台无效后的泄愤，也充斥着对测试的片面的理解。不知道原贴人看到这个帖子后，回答能不能想上面的 15 楼和 21 楼一样好，还是单纯的认为点点就好。

嗯...自己有些想法不吐不快，也算总结吧。

测试除了业务，也要懂技术，除了测试技术、自动化技术，开发技术也要会点：
代码不一定写，但至少要会数据库、了解架构及中间件的作用，各个应用服务的作用以及被测功能实现逻辑及处理流程。

对于开发平台，我也反对重复再重复造轮子做同样的自动化类的平台，因为实在已经太多了，实在是卷的不行。
但不是说测试不要去学技术，学技术写小工具、写自动化可以让测试便捷、测试的边界更大，更能与开发做沟通。
另外测试平台也是需要的，但得结合部门实际的测试工作规范、工作习惯来设计，而不是对测试片面了解的测开自认为 “高屋建瓴” 的搞个出来。大家不用就是说 “我这个很好用，你们不要浪费时间学技术了，你们学不好的，乖乖的用我这个”。
这边也在维护部门的日常测试工具以及一个测试用例平台（2 个功能测试开发的），但我们都是兼顾着在做功能测试的。我们了解功能测试、部门的测试规范及流程，而且需求方就是我们的其他测试人员。这样这个平台我们部门自己用的很舒畅，以致其他部门也一起用了，甚至产品部都想拿来做需求归档了

测试，不是看到需求明面上东西点点就好。这个帖子以微信支付为例，那是微信大家都用，但设想的测试场景就层次不一样，可以预见之和的用例设计、上下游的沟通协作、执行效率也不一样。另外学技术也是必要的，可以提高工作效率，可以测试更内层的内容。

这一行入行简单，但不代表这行的上限低，积累、学习，共勉。

厉害

因为是面试题，不会给你长篇的规则限制的，所以可以说没有真正的答案的。看的就是你能发散考虑的范围，考虑问题的能力。

所以你的补充也是 OK 的。
其实你的问题再仔细思考需求时，能推测可能的答案：余额为啥要给折扣？
是不是想鼓励人去把钱放到余额吧？
是不是余额是平台自己的，不像信用卡一样需要额外的手续费，或者风控上的风险（信用、拒付等等呢）？
这些受益人是平台，所以折扣由平台出（而不是商户）是不是更合理？那应不应该有上限？

其实真正的目的就是 15 楼所说的。
功能测试可不是点点点，不是要求别人尽善尽美，不是学个测试基础理论就能干好，不是预设自己处于理想化的工作环境中。
这个需求看上去很简单，但不同层次的测试人员看到的东西就是不一样：有的只是流于表面的字里行间，有的已经将整个资金体系都纳入考虑范围：这个就是功能测试人的价值——有的已经超越了产品经理的业务广度。

现在很多刚入行的面试时一来就各种技术说的贼溜，但问及点功能测试的内容就支支吾吾，解释说自己是不做功能测试的只做自动化......说的好像功能测试是很受鄙视的（还是太年轻......）

傲气