日常体验中确实感觉京东比淘宝的 App 体验棒一些

此处所言的图像识别, 是基于 opencv 做的对吧. 严谨点说这应该叫图像匹配. 缺点就是分辨率会影响匹配的准确性. 尤其是在复杂页面并且兼容多手机的需求下.

请教下 关于 TPS 是如何统计的呢? 每个请求响应完成之后计数? 那么测试过程中动态 TPS 图画的时候, 是当前秒的完成数量, 还是当前秒之前所有的完成数量/当前秒-StartTime 呢？
问题来源是当一些业务 (ERP 业务) 的 API 响应时间横跨 1-100s 都正常的情况下, TPS 动态画图, 如果画每个时间段的实时 TPS 图, 该如何画呢？ 我尝试使用当前秒完成的响应数量作为 TPS 去间隔 5s 画个图的节点, 但是结果很失真.....

咨询下, 在设计 Boomer 的时候, 关于 TPS 是如何统计的呢? 每个请求响应完成之后计数? 那么动态 TPS 图画的时候, 是当前秒的完成数量, 还是当前秒之前所有的完成数量/当前秒-StartTime 呢？
问题来源是当一些业务的 API 响应时间横跨 1-100s 都正常的情况下, TPS 动态画图, 如果画每个时间段的实时 TPS 图, 该如何画呢？

虽然没用过 Jmeter, 但你这结论看下也感觉不正确啊. 对于静态资源, 每个浏览器都有自己不同的同域名并行下载限制, 像 Chrome 和 Firefox 好像是 6？
而且对于测试工具来说, 它必须支持串行 (同线程下流程场景) 和并行 (线程并发), 所以你测试 1 个线程中 Jmeter 串行应该是正常吧？
另外: 性能测试和性能工具完全不相等,

数据的脱敏,偏移的前提是保证数据处理之后的准确性.
感觉流量回滚这种方案,用在 ERP 这种行业上,光处理数据这块就能卡很久.

有个思路是错误处理的思路, 和一楼的方案一样, 将代码功能业务的弹出放入到列表中, 在动作失败的时候, 如果判断是 Alert 异常导致的, 则开始判断是否存在于列表. 然后处理掉之后重新回调出错的函数. 使用例继续向下运行.

使用反射机制 + 装饰器,可以很快实现一个微型的单元测试驱动模块,用来做自动化测试的时候就可以抛弃 pytest,unittest 从而更好定制需求. 实现效果起来非常通畅

好的. 有个轮廓概念了. 知道下一步怎么样做了.
ThankQ

好的, 我找下课程阅读下, 感谢感谢......

另外, 关于你举的柜台 5 个顾客的例子, 我有个数据疑问, 如果在柜台处理业务过程中, 有个顾客存钱是刷卡, 处理很快, 有的顾客存在是点钞, 存钱相对慢, 有的顾客存在是称重硬币, 过程会相对更慢, 更有的顾客是人工点钞 (1 块 10 块一麻袋),速度最慢. 那么对于这种业务, 虽然 API 都是同一个处理存钱, 但是柜台 (服务器) 会因为顾客携带的钱类型 (API 的 body 数据) 而导致处理时间长短差别非常大. 这种情况下, 5 个客户同时刷卡和同时扛着麻袋存钱, 响应时间是非常差别大 (TPS 也跟着波动大小).
这种场景下, 对比 TPS 的参考性大么？

其实归结就是, 性能测试过程中, API 的数据因素干扰很大的时候, 如何处理呢? (数据是真实客户都有可能发生的数据,从客户的 Log 中抓来的, 并不是随便生成的)

再请教下案例问题:
有个场景, 昨天碰到的, 它的 API 响应时间波动较大, 受并行和使用的数据影响波动很大. 举个例子, 我对这个 APi 设置了场景为第一分钟启动 10 个并发, 然后往后每分钟增加 2 个并发.(起始是 10 个客户, 每分钟递增 2 客户), 然后每个线程的操作都是 While True 的方式去请求这个 API.(可以理解为第一分钟有 10 个客户在持续操作, 第二分钟有 12 个客户在持续操作.往后类推).
测试结果中, API 的响应时间最低 3.2 秒, 最高 300 多秒. 1 个小时一共运行了 1900 多个数据.

问题: 对于这种测试, 它的 TPS 有参考意义吗？ 个人感觉好像没有多大意义, 因为大量的请求横跨的时间太长了, 中位数基本在 120 秒. 横跨这么久. 我按照 Locust 统计的方式去计算了每秒的 TPS 值 (以完成时间统计, 并且每秒值为之前 10s 的平均数). 结果 TPS 的记录在 0.3-1.7 之间高低波动并且没有看到起伏规律 (像无序,没看到有受并发增加而影响高/低). 反而其他监控比如 CPU 的资源监控, 响应时间监控. 都能够看到受到并行增加而对应升高, 直到升满. 趋势有规律

那就明白了, 其实并不是说请求起始时间到结束时间的横跨时间内不需要计算 TPS, 而是从性价比考虑, 请求完成时间来代表的话已经能够基本满足 TPS 的波动图所反映的服务器处理能力, 它结合响应时间图, 还有资源消耗的监控来整体评估判断.

非常感谢解答......

感谢回答
是的,因为业务的关系,,有个需求是需要设计个分布式的发压能力且频率可定制 (类似回滚场景). 但是对性能这块的概念没整明白关于数据的统计存在这些疑惑.
TPS 的字面意思每秒完成的事务总数. 我大概明白这个. 但是像对于问题 1, APi 在服务器端被处理了 15s(忽略等待时间), 那么每秒占比 1/15, 第一个 10 秒内它占了处理过程的 10/15 的时间, 按照这个理解的话, TPS 解释中每秒完成的事务总数, 重点是"完成"态么？并不需要对前面消耗的负载时间做统计的意思吗.

Locust 理解错了, 重新捋了下, 它的 TPS 是按照最近 2s 内的统计结果计算的.
不过这仍然没解决问题 1 和 2 的疑问 ......

所以最好的办法是推动开发增加类似 testID(RN) 来支持 Accessible 这样就方便测试了. 其他都是不得已而选择

最大问题在于元素定位教困难. 如果能推动开发规范控件描述的话会更好.
另外, 类似 airtest 一样, 可以基于 OpenCV 封装一套图片识别, 然后在支持上 OCR 接口, 组合使用效果会更好.

"复杂的结构导致写 case 时需要调用很多 api 的方法，频繁的引用对象的方式使用例结构更加复杂"
这种问题不是应该从优化测试代码结构入手么. 出效果会更快, 灵活性也更强

找下无法提供 Debug 包的原因, 看能解决不

算是吧, 平台这个词的概念太广. 我见你帖子说的也是这种

往常情况下有堡垒机的情况,大部分是网络限制，比如 AWS 的网络安全组功能, 非安全组内的 IP 是无法访问的, 所以只能运行在堡垒机上, 或者考虑加个安全组 IP 到你的测试环境.

目前支持中在使用的: 测试执行, 场景组合 (暂时不是太好用), 与 OA 的交互 (比如 BUG 的测试结果自动分配给对应开发), 报告整合, 结合 OA 的报表功能, 测试环境的管理 (启动,关闭,部署之类)
计划中的需求: 测试数据解耦后的生成, MySql 快速回滚.
以上都是 UI 测试这块的. 顺便说下, 平台的前提是 Case 脚本能够稳定的运行, 尽量降低误报的错误, 否则测试脚本不健壮的情况下,测试人员的精力基本都再维护脚本上.

逻辑没问题,我意思是实现这样的装饰器结构, 然后具体哪些弹窗是需要点击的, 哪些是错误弹出需要中断用例的, 你可以在装饰器中得到弹窗的信息去判断. 而不是说一箩筐的就直接点击不处理信息的.
甚至这个基础之上可以任意拓展, 比如你定义一套正常弹窗信息的字符串格式, 或者异常的一套格式,然后正则匹配. 再或者你可以自定义错误异常类型, 用来控制哪些流程遇到弹窗需要处理重试哪些不需要. 大同小异

代码优化建议: 按照你文章中说的思路, 其实使用一个装饰器来捕获异常然后根据异常类型做对应的处理,根据异常消息判断是否需要重试. 其实会更友好

WebUI 的, MobileUI 的, WinFormUI 的, 还有 API 的, 我们这块看到业务相对面积较大, 自动化涉及的业务也就较多.
还是那个意思,自动化是为业务服务的, 所以根据业务模式去设计测试脚本的代码架构, 好用的永远是契合业务高的.

因为我们的业务有部分包含你描述的几个模块, 所以提几个模糊的建议:

1. 先从单个接口开始做, 比如一个接口测试做成一个 func, 依赖的数据可以从数据库查询.
2. 因为业务关联较大,承接关系较多, 所以可以在单接口的测试中做基于 Feature 的组合业务接口.
3. pytest,unittest 之类的单测驱动可能不太适合, 建议自己写个简化的框架驱动, 然后对接口函数进行标签化/排序/依赖关系组合, 从而方便从 1-2 的组织的同时必须要另写代码.