loadTest

参考值：考虑此项目组以前开发过的系统性能情况，能否做为一个参考值
压测数据管理：压测数据打标签 tag字段、影子库、云原生可以考虑容器方案快速拉起等比环境压测之后再释放
性能分析：
性能调优：
电商系统测试：
测试代码覆盖率：
阿里全链路测试:https://my.oschina.net/cctester/blog/994727

容量规划：业务流量预估阶段(通过历史数据分析未来某一个时间点业务的访问量会有多大)、系统容量评估阶段(初步计算每一个系统需要分配多少机器)、容量的精调阶段(通过全链路压测来模拟大促时刻的用户行为)、流量的控制阶段(对系统配置限流阈值等系统保护措施)
要计算一个系统需要多少台机器，除了需要知道未来的业务调用量之外，还有一个更重要的变量，就是单台机器的服务能力。单机压测既需要保证环境的真实性，又要保证流量的真实性。
最小机器数 ＝ 预估的业务访问量 ／ 单机能力。
单机压测没有考虑到依赖环节压力都比较大的情况，会引入一个不确定的误差。
并发连接数-SBC:每秒钟服务器链接的总TCP数量，就是并发连接数
请求数-QPS（Query Per Second）/RPS（Request Per Second）
请求数有2个缩写，可以叫QPS也可以叫RPS。单位是每秒多少请求。Query=查询，也相当于请求。请求数指的是客户端在建立完连接后，向http服务发出GET/POST/HEAD数据包，服务器返回了请求结果后有两种情况：
http数据包头包含Close字样，关闭本次TCP连接；
http数据包头包含Keep-Alive字样，本次连接不关闭，可继续通过该连接继续向http服务发送请求，用于减少TCP并发连接数。
常见QPS有到亿的但TPS只到万
请求量不是特别庞大的话，利用分布式的原子操作可以满足中大量级的需求，请求量特别庞大的情况下，可以控制路由层，让同一个用户的请求分发到同一个服务器，甚至同一个线程(路由＋队列)，仅同一服务器，可以用cas，同一线程，那同一用户的请求就直接串行了。数据库加锁，这个方案适合体量小的服务。
业务模型包含 100 多个业务因子
全链路压测的所有数据都在生产环境做了数据隔离，包含存储、缓存、消息、日志等一系列的状态数据。在压测请求上会打上特殊的标记，这个标记会随着请求的依赖调用一直传递下去，任何需要对外写数据的地方都会根据这个标记的判断写到隔离的区域，我们把这个区域叫做影子区域。
流控并不仅仅用于流量高峰，它在很多的场景都可能用的到。比如在一个业务的链路上，有一个下游系统出现了问题，响应时间变得很长。这个问题在链路上会被放大，甚至导致整个链路不可用。这意味着流控也需要可以根据响应时间来控制系统的健康，当一个应用响应的时间超过阈值，我们可以认为这个应用不可控，应该迅速将它降级。
只把核心链路的系统扩大几十倍的系统吞吐量
把非核心系统从核心链路上剔除
selenium定位动态元素包 wqrfnium
方法：starts-with ends-with contains
[@id='cascader-menu-3932'] [contains(@id,"cascader-menu")]
xenu 走查ui空链接
因为任何的页面接口都不是单独存在的，都会受到公共资源的制约，如：DB、Redis、MQ、网络带宽等。比如当店铺首页达到 10w QPS 的时候，商品详情页可能要达到 8w 的 QPS 了，也会消耗公共资源。当公共资源的能力下降时，势必会影响所有的系统。所以，通过单机性能算出来的理论值，跟实际情况会相差很远。
整个集群的性能其实取决于接口的短板效应
gatling 提供天然的转化率配置脚本，用起来非常方便