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

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

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

我现在使用消息队列，每个人的框架，都往该 MQ 订阅消息。当 web server 收到任务请求，向 MQ 生产消息。本地的框架收到消息后，判断标识，true 的话，就开始本地环境执行测试。

driver.tap 试试先啦，driver.scroll 这个可以从 A 元素滚动到 B 元素

识别后，就可以获取到坐标啦

appium 新增了图片识别。可以试试

你能实现到 grpc 的客户端，就可以自动化啦。这个跟 http 几乎没什么区别。

但要实现共享。只能内网没啥用。

难点还有一个，解决局域网连接设备。

成本好高啊。

好的。谢谢

这样整体的测试运行效率会好低

还没开始写呢

目前设计上，是否每次都需要重启 chrome，由写用例的人决定。

这样也可以，但得保证设备和测试工具在局域网。

是第一种方式，大概理解了 opendx 的调试方式，可以借鉴借鉴。哈哈哈

也是可以哦。谢谢

日志实时展示与在报告查看应该差别不大，主要是看不到浏览器 (客户端) 的界面

请问在 web 平台上编写关键字用例后，如何调试。

其实也不闲的吧，当游戏强更或者其他更新，推渠道包时，你得回归所有渠道包。

发行商更关注的是账号系统，支付系统而不太关注游戏质量，纯软件测试。除了两个基础系统外，还会有客服系统，数据统计系统等等；运营活动和周更只是其中的日常工作之一，但也是回归上述的软件内容，而不是游戏。

1 万并发限制，会报错的

请求接口，请求量越大越好，可以用压测工具。然后统计数据。分析是否与配置的概率一致

有可能，涉及到参数排序，计算 sign，重写 url

666