秒杀主要关注消息队列
之前测试期货交易的时候会把前端和接口返回的参数分别遍历组合一次执行下单(我们有 2 套前端逻辑、以及公用的 1 套接口逻辑),每个单子开仓、平仓、强平、部分平仓过程的前、中、后都会校验一次系统资金状态、正确性。
需求不能量化,能量化的是指标
你可以先把需求转化为(评测的)指标,然后对指标进性量化
你已经有一些比较具体的需求(20 万、持续时间 5min),涉及接口数 n
从需求来讲,就是:20 万个用户,在持续 5 分钟内,连续调用这 n 个接口的整个过程里面:流畅、稳定、成功率高
所以,这里的评测指标除了你已经提到的:TPS
应该至少还包括:各接口的平均响应时间、响应时间方差、(n 个接口作为一个事务的)事务通过率
如果是,不考虑逻辑的前提下,那覆盖率能达到多少呢?如果覆盖率足够高也有一定意义
这样业务逻辑上可以通过 UI 自动化补充实现
用 1、10、20 个线程分别跑个 10 分钟得出一个基准场景,看看主要的开销是在 CPU 还是内存还是带宽出口,在开销达到瓶颈的范围内的可产生的负载就是该机器最大的负载,所以,还得看脚本针对的业务场景,大批量静态文件下载产生的压力小一点,相对简单的表单提交可能大一点
原来大家都是差不多,插句话,关于需求调研,和产品那边沟通大概就是 把期望转成需求,把需求转成指标,依据经验对指标的量化做出阈值界定,最好别让太多人掺和太多性能指标和阈值相关的事情。
写的基本都是接近验收阶段的测试了
因为大部分系统的业务知识价值低
1、由于测试时间不足,所以:花 1 天时间评估系统大概的业务流程、业务角色、场景,评估紧急上线过程所产生的性能风险;
2、由于没有人配合你,所以:尽可能抓住你所理解的重点进行测试,在开干之前,出一个简要的性能测试方案以尊重目前时间进度紧张的客观事实,简要方案里面包括:
3、依据 评审 意见,修改方案,看看责任人是协调资源给你解决、还是增加测试时间、还是带着风险上线;
尽量不要瞎操心给项目增加无谓工作量,说不定系统压根就没有人用呢?
app 的启动页发
首先看测试需求,既然是股票类的 APP 接口,那实时性、数据正确性当然少不掉对吧?
实时性的话,脚本同时请求第三方数据源接口数据,比较你们接口数据的延迟情况是否在可接受范围内、以及数据响应的稳定性、连续性。
另外就是数据的正确性,针对返回报文格式内容、状态是否符合预期。
大致想到这两点。
你们是做第三方接口的吗?
45 可以了,实操 50 相对满意一点
有区别,例如:LR 录制脚本本身带有页面上的静态资源请求,而你直接对 API 接口压测是没有这部分请求的,因此在同等的并发数下,由于录制的方式会在静态资源请求/响应上有一定的时间消耗,相应的对 API 产生的负载会低一点。
除此之外,采用 LR 以录制方式进行脚本开发,LR 可能会插入一些例如并发组之类的语句,在结果输出里面,也同样对你理解单个接口性能表现产生差异(和单独编写 API 接口脚本对比而言)。
#4 楼 @seveniruby 感谢关注,就如我 3 楼回复的方法已经解决了
按照一楼的建议改了源码,..\npm\node_modules\appium\lib\server 里面 找到 parser.js
在:
[['-bp', '--bootstrap-port'], {
defaultValue: RndNum(4)
, dest: 'bootstrapPort'
, required: false
, type: 'int'
, example: "4724"
, help: '(Android-only) port to use on device to talk to Appium'
}],
把 defaultValue 原来的默认值是 4724,现在配置为随机的 4 位数端口,算是把问题解决了。这样同时启动多个 appium 服务和多个脚本同时执行也不会报错。
最近我在三星设备上面遇到丢失按键的情况,比如 ‘123456’,实际输入为 ‘23456’,其它设备不存在这个问题
#1 楼 @weamylady 就是不想改端口,找到一个老帖子 http://testerhome.com/topics/1639
目测还是得改呢。
#15 楼 @jinjun0620 不对呀 我是 AppiumForWindows-1.3.4.1 还是找不到中文 xpath
try:
WebDriverWait(dr,30).until(EC.presence_of_element_located((By.NAME,"下载")))
except:
print "got exception"
else:
print "not exception"
find_element_by_accessibility_id