另外，还支持接口自动化测试的调度和报告展示。

用例页：

用例详情：
封装的操作关键字：["点击","坐标点击","输入","清除","双击","长按","前往","睡眠","上滑","下滑","左滑","右滑","android 按键操作","ios 键盘操作","切到 webview","切到 NATIVE","切到新 window","切到旧 window","登录","登出"]

开始测试页：
调试地址即 selenium grid master 的地址。
调试环境即 本地执行框架的标识

报告页：

m1 在图片 1 中的位置坐标，是一个绝对坐标来的。可以通过计算相对坐标。这样会准确点

可以详细说说夸网段是如何控制的嘛？比如 A 设备在 B 网段，C 用户是 D 网段，C 用户需要控制 A 设备。

nginx 也没有这个功能，只是添加了模块。也属于自己开发。哈哈哈。整个网关是独立设计的话，限制逻辑不是难点，正如楼上所说，高性能高可用才是难点。

如果是使用 nginx 的话，可以利用 lua 做。这个限制策略就看需求了。基本上都是统计单位时间段内，该 ip 的访问次数，到达限制策略，将该 ip 加入黑名单，后续收到黑名单的 ip 请求就做限制处理。限制时间到后，黑名单删除该 ip。然后循环这种逻辑。

一般做法是修改服务配置文件的第三方服务域名，让其走到 mock 服务，如果是开发写死了第三方服务域名，则让开发修改。

https://tech.meituan.com/2015/10/19/mock-server-in-action.html
我参考美团这个文章设计，做了一个 mock-server。

中台与业务层，是不是可以走契约测试。从而快速识别需要回归的上层业务。

看下 master 的资源情况，是否 CPU、负载 或者带宽满了。

Connection refused to host: 115.227.33.18 网络不通啊

靶场练习可以快速知道各个方法，但真正应用在产品上时，有点挫败感。背景是这样的，开发怀疑用户信息泄露了，每天都有同一个 ip 请求同一个接口，用户信息各不相同。但把学习的测试方法实践起来，完全不是一回事，忙碌了一周，没找到到底是怎么泄露的，压力大的很。

得明确目标，是容量规划还是性能测试，不同的目标，做不同的事，如容量规划，让开发和产品根据场景定义目标 TPS，而这个目标 TPS，是否能够通过加机器方式提升 (即扩容线性增加)。如性能测试，更多是寻找性能瓶颈。TPS 固然重要，但其目标是发现系统的瓶颈。

并发我之前尝试过，不能超过 1 万。超过 1 万个会报错。具体没深究。反正业务上不太可能超过这个值。
同意 1 楼。

抄袭 jmeter 既视感

感谢分享。还是希望贴下源码参考参考。哈哈哈

性能测试我认为应该是理解什么是性能测试，性能测试的目标等等概念，其核心是设计测试方案，发现性能问题，分析排查性能问题。
工具只是工具，在进行测试时做一定的选型，为什么选这个，而不是选哪个。脱离工具就无法进行性能测试吗？并不是，性能测试客户端，可以通过编码实现，监控可以通过 linux 命令。工具是使开展性能测试更加方便。不要本末倒置。
如何发现性能问题呢?

• 通过性能测试工具返回数据，比如 QPS，耗时等等
• 通过服务器的资源消耗数据，比如 cpu，内存，io，负载，带宽等等

如何排查性能问题呢？

• 被压测服务、中间件的日志等
• 被压测服务、中间件的资源消耗数据
• linux 命令，以及其他命令等查看数据

上述发现和排查问题可能不完整，但是最基本方法。

其实可以将预发布环境做成线上环境，然后通过一些调度方案，将真实用户不调度到该环境，或者将少量用户调度到该环境。这样基本上可以不用管数据问题了。

可以定义成公共的类/方法，然后请求时调用。

感谢大佬。感觉数据部分的真好复杂。假设业务迭代周期较快。维护数据上也的花很多精力。

不能。自动化就代码实现呗

bloomRPC GUI 工具，导入 pb 协议既可使用

一般情况下，流量回放是回放到一个特定的环境，而非线上环境。有几个问题咨询下，望大佬解答下。
1，如上述背景下。数据库以及其他中间件的数据是如何准备的，以及是基于什么策略与线上同步
2，当数据库同步解决后，一般会进行脱敏，清洗，那如何保证数据的真实性的，有效性
3，同样，流量回放的请求参数也会进行脱敏以及清洗，偏移，那么如何保证数据中心改造的数据是有效的，比如 user_id 和 token 是强挂钩的，业务字段偏移后如何保证数据库是存在的。

支持楼上。
------------- 引用 --------------
微服务架构在现代系统架构中已被普遍使用，业务复杂性和系统复杂性双重作用使得保障和维持整个系统的高可用性变得困难异常，同时对研发效率也有较大负面影响。为了解决性能瓶颈保证系统的高可用，需要对系统实施性能测试，但传统的性能测试有仿真性、局部性和黑盒性三大问题。
仿真性：传统的性能测试通常在测试环境或者性能环境实施，但这些环境都只是对生产环境的仿真，无法真正代表生产环境。
局部性：传统性能测试有时会在生产环境的单一局部服务实施，或者只压测读类型的接口，但局部高可用不代表整体链路的高可用。
黑盒性：传统的性能测试只能获得 TPS 等性能结果，无法在复杂的微服务架构系统中定位和分析存在性能瓶颈的服务节点。
------------- 引用 --------------

1，事实上，全链路压测是需要系统架构改造，并不是说，使用了某工具就能实施全链路压测。当一天没实施改造完成，最有效的方式，还是仿真线上环境，实施性能测试。
2，局限性，根本就是性能测试的策略问题。这个跟工具有关吗？当有足够的资源，完全可以克隆一套线上环境。还会存在所谓局限性吗？
3，黑盒性，压测工具能够获取到 TPS，耗时分布等数据已经是足够了。至于系统中的瓶颈，难道没监控系统吗？难道测试人员和开发人员不会分析吗？从系统资源占用，压测工具的数据 (TPS,耗时等)，基本上可以分析到压测过程中的问题，瓶颈。

未来的数据和现在的数据，数据结构上都不会有差别，就日期字段上的值不一样而已。测现在数据和测未来数据，有啥不同。。实在是要，往数据库插未来的数据呗