1. UI自动化
2. API自动化
3. 性能测试
4. 测试服务架构
5. 部分迁移AI,数据相关的测试技术.
1. 关于软件研发的发展
传统业务是大鱼吃小鱼
软件业务是快鱼吃慢鱼
软件业其实是一门不是很规范的手工业.
存在很多问题, 当然了也是因为存在的问题多,才有测试的立足之地.
第二天还讲解到了一个十万块的边界值检查的案例.
其实我感受很深刻. 不成熟不规范的手工业很大的缺陷就是 你付出的多了 木秀于林风必摧之
会情不自禁的进入内卷. 在管理不正规的企业内卷带来的往往不是自己得提高, 而只是管理者的政绩.
还有同僚的排斥.
2. 关于研发猛将的理解:
善战者无赫赫之功，善医者无煌煌之名
很多看起来处处救火的人,毕竟是高绩效的员工.
防患于未然才是优秀杰出的员工.
公司里面也存在这样的情况. 很多时候很多人不听取别人的建议.
乐于在问题出现时出面救火, 显示自己的能力, 表现自己的忠心和勤奋.
学习中老师讲解必须有CTO研发负责人进行复盘.
不是最终boss带领下的复盘都会出现偏颇与甩锅.
这一点我感觉航空航天的问题归零是真的很有必要的. 一个问题如果不打破砂锅问到底
早晚生产都会死给大家看.
很多事故,都是一个个不起眼的小细节导致最终的崩溃.
3. 很多新工具
3.1 UI测试里面的 recheck-web 可以实现记录部分页面的对象的所有属性,
在脚本中属性出现变化时动态获取正确的对象.
我这边没研究过,但是可能对存储和CPU的消耗会比较大
3.2 web page performance test
可以对网页进行性能测试时,给出结论.
这个可以进行一下私有化的部署和搭建. webpagetest_3.0.zip
3.3 LLM的一些工具.比如自动化测试用例生成,脚本生成, 这一块我没有研究过.
学习时正好也在处理一个项目问题. 这一块学习我吸收的不太好.
3.4 契约测试
茹老师说,使用契约测试之后,测试脚本只需要之前脚本的三分之一.
很早之前我看过契约测试, 但是我感觉这一块对研发的技术和人品要求极高.
适合服务稳定不会需求变动多的场景. 我们这边产品的变动惊天动地..研发给不出一个合适的契约数据.
3.5 混沌测试
没有讲解具体的内容. 我们这边跟建超老师学习过chaos blade 等两个工具.
感觉更多的是模拟网络延迟. 阻塞,丢包. 以及可以模拟磁盘等故障来实现故障注入.
核心是要控制爆炸半径. 不能让一个人拖死所有人.
3.6 微服务治理与测试
滴滴的微服务有5000多个, 已经没有人能够了解所有微服务的调用了. 理论上必须有统一日志平台
统一跟踪和可观测性. 随着微服务的越来越深入. 可测试性是非常重要的. 没有可测试性就没有可以发版的信息.
3.7 性能测试
重点说了下 并发测试与相应时间. 茹老师是LR等软件的资深架构师. 对测试工具的使用很有经验.
我理解并发测试是数据正确性测试, 性能测试, 功能测试, 与极限测试的统称.
3.8 LLM,chatgpt的工具集成. 这一块没有深入讲解. 需要继续学习.
主要有一些code brush,以及代码自动补齐, 测试用例,测试脚本自动生成等内容.
等等其他内容.
4. 谁是质量的第一负责人
谁设计谁开发谁部署谁on-call
优秀的杰出的产品不是测试出来的, 是设计,是开发,是精心养育出来的.
代码都是千人千面
相同人在不同心情下的代码质量也是不一样的.
代码规范, 尤其是一个完美的代码样例是非常关键的.
研发依据一个完善的样例进行开发, 他的代码往往不会有很多低级问题.
没有经过学习和锤炼的研发,会写错很多低质量的垃圾代码.
测试是QA是用来保证产品下线的. 他只能保证产品最坏的情况
但是客户需要的是产品最佳的情况. 这一块需要大家一起努力.
5. 性能测试与环境
性能环境主要讲解了一些概念.
我理解最重要的是各种基线的处理.
我这边获取服务器最好是通过类似于
SPECJVM2008,SPECCPU2006,FIO,redis-benchmark,sysbench,unixbench,lmbench
等等工具进行一些基线数据的获取.
而且最好的是在测试之前,对测试环境的晚上, 早上10点, 下午三点左右进行基线获取.
虚拟化平台尽量要获取超售以及硬件平台的基础情况. 避免出现说不清楚的问题.
性能测试也是如此, 最好是模拟超长时间下的 性能表现, 不仅仅要模拟高峰,还要模拟低谷和退出的场景
要视始为终,从头就要重视.做好测试场景规划,测试数据规划才可以.
也讲解了一些其他的概念
配置测试, load test
性能测试的核心是要摸到产品的天花板.
我理解性能测试其实就是<长空之王>里面的试飞员.
要验证各种天气(硬件),高度(配置),最高最低速度(TPS基线和RT极限),然后给后来的使用者一些指导意见.
而且性能测试与试飞员一样, 一次尽量只修改一个变量, 不要修改太多变量进行测试.
多个变量会导致结果的较难分析. 对应的性能测试来收变量太多了, 需要长时间的准备和实施,
常见的参数有: 数据库配置,类型, 数据库参数. 磁盘类型, io优化程度. 事务类型.
应用的数据库连接池大小, 线程池大小, jvm的内存. jvm的gc算法. linux的tcp内核参数.
负载均衡的算法. 数据量的大小.等等等等.
性能测试其实也分两种. 一种是取长板, 一种是取短板
长板主要是用于验证修改的一些特性, 是产品优化的方向. 是产品的热点和卖点
短板主要是用于发现产品的性能瓶颈, 保证产品在最差的情况下能够满足客户的SLA,SLO等概念.
长板与短板都重要, 没有长短可能没有新客户. 短板太差老客户都会流失.
多参与一些学习挺好的. 更重要的是应该将学习中遇到的工具进行落实.
只学习不干, 或者是只看不练都是不可取的.
回想工作这些年, 我这边也就参与过公司外的一两次学习. 大部分都是自己学习.
基本上都是靠自己.
靠自己虽然很充实,但是很累, 也没人会看到你的价值.
其实看公司对一个人好不好和看另一半对你好不好是一样的
舍不舍得给你时间. 舍不舍得给你钱. 舍不舍得给你未来. 舍不舍得给你发展
饼不是未来.
GaussDB(for Influx)推出了单机版方案，可用于开发、测试等场景，既能享受到服务化带来的便利，也可以明显地降低使用成本。
数据安全法实施后，国家监管部门加强了对企业数据安全的监管力度。在这个大的背景下，为保障物流体系系统安全，提前规避安全风险，由测试组牵头制定安全测试流程规范并持续推进安全测试常态化。