/etc/hosts 文件里增加域名映射
写测试用例是测试人员最基本的武器。这个都要扔了?
1、职场上技术真不是最主要的。
2、做事了就得让领导知道,没做也得让领导觉得你产出了,这也是一种能力。
3、有人的地方就有江湖,人际关系很重要。
实战好文。
技多不压身,会的话就比别人多一个优势。
pytest --alluredir=/var/jenkins_home/workspace/auto_test_invoice/automation_test/invoice_auto_test/test_cases/allure-results 改这个试试
可以先放开简历看看外面的机会。做好两手准备
项目借人很正常,但是没有需求文档,对接人讲不清楚需求,那测试的最终输出是什么,总不能都是糊涂帐吧?还是要明确需求和目标,不然干活的人很心累。
接口异常,查具体接口的问题呗,我理解这个属于业务问题。
破案了。10M 的带宽理论传输速度是 1.25MB/s,再加上网络损耗,设备原因等影响,并发情况下 800 多 KB/s 也属于正常。可以判定为网络限制导致。
30 个并发 30 多秒。感觉是文件上传接口是单线程处理的,没有使用线程池。
我也差不多,基本上都是贴着简历问。主要还是看干活的能力,理解能力和沟通能力。不会我可以手把手教,但是你理解能力得跟上。
有两个时间的参数要设置的大一点,时间太短了可能没收到数据就报错了
看你是 WebSocket、gRPC、HTTP/2 哪种框架和协议了,需要依赖插件或自定义脚本
1、pytest-xdist
2、Jenkins 或 GitLab CI
年轻的时候在外打拼,年纪大了回老家。
打了一段经验之谈,读了一遍感觉太说教了,想想还是删掉了。个人感觉成长最快的一个方法:多揽活。
不太靠谱,性能测试更多需要的是实战经验积累(测试 + 分析 + 调优),大部分培训班只教你工具的使用,说到底性能测试还是得靠解决一个个问题积累,无法短期内有较大提升(业务 + 技术)。
压测的重点是被测接口,前期的请求只能算作数据准备阶段,数据准备的方式应该没有限制,能把数据完整模拟出来就行。
换个报告插件呗,目前在用 pytest-testreport,自己改了改源码,放到 Jenkins 里集成,还挺合适的。
依次递增请求参数,需要用到__V() 函数进行参数拼接, 参考:https://www.cnblogs.com/MyRecords/p/17982763
总结问题与经验,更新测试用例,测试方案,开座谈会交流,各种技能提升分享会。可以包括任何主题:比如自动化,性能,问题定位,业务知识,PPT 技巧。之前组内还有人分享摄影和美食,认真准备的情况下其实效果都不错。
在 Apache JMeter 中设置 7 个线程组和 1 个线程组的区别主要体现在以下几个方面:
7 个线程组:
每个线程组可以独立配置参数,如线程数、Ramp-Up 时间、循环次数等。
可以模拟不同类型的用户行为或不同的使用场景。例如,一个线程组可以模拟普通用户,另一个线程组可以模拟管理员用户。
更容易进行负载均衡和分布式测试,每个线程组可以独立地运行在不同的机器上。
1 个线程组:
所有虚拟用户共享相同的配置参数。
不适合模拟复杂的使用场景或多种类型的用户行为。
所有负载集中在一个线程组中,可能导致单点瓶颈。
7 个线程组:
每个线程组可以独立配置和管理,便于维护和调整。
可以更灵活地添加或删除某些类型的测试,而不影响其他测试。
更容易调试和排查问题,因为每个线程组可以单独运行和分析。
1 个线程组:
配置较为简单,但灵活性较差。
修改一个测试场景可能会影响所有虚拟用户,增加了维护难度。
调试和排查问题时,需要处理整个测试计划中的所有请求,难以单独分析某一类请求。
7 个线程组:
可以创建复杂的测试场景,每个线程组模拟不同的业务流程或操作步骤。
更适合大规模、复杂系统的性能测试,可以细化到每种操作类型的性能评估。
1 个线程组:
适合简单、单一业务流程的性能测试。
不适合需要区分多种操作类型或用户行为的复杂系统。
在性能测试中,线程是模拟并发用户行为的关键概念,每个线程代表一个虚拟用户,可以同时执行一组操作,从而模拟多个用户同时访问系统的情景。
如果是前面没有性能测试积累,可以先做简单的单接口并发测试,像 “并发 5000 然后网关炸了” 这种情况就是单接口测试场景。
基于单接口测试的指标前提,可以设计出复杂的性能测试场景,比如 “系统可以支持 8w 在线用户”,不可能 8W 用户同时去请求同一个接口,可以按照一定的比例拆分去做不同的业务,比如有的用户去请求登录,有的用户去请求搜索,有的用户去请求提交订单,有的用户就什么都不做,这块可以参考系统功能模块使用情况分析。这样测试出来的性能指标才是真实有效的。
性能测试要注意的事项:
1.合理设置 Ramp-Up Period:确保系统有足够时间处理逐渐增加的负载,而不是瞬间启动所有线程。
2.使用定时器模拟真实用户行为:添加适当的延迟,以更贴近实际使用情况。
3.监控资源使用情况:在运行性能测试时,监控服务器和网络资源使用情况,以便识别瓶颈和优化点。
4.逐步增加负载进行压力测试:从小规模开始逐步增加负载,观察系统表现,避免突然施加过大压力导致系统崩溃。