性能测试培训 2018年8月31日 口述记录
哪些系统要做性能测试
性能指标
需要怎么调研
性能测试目的
系统稳定性 上线之后 不知道支持多少并发 响应时间多少 TPS多少
我拿一个系统，开发和产品 第一个给压测指出指标，第二个没有给出指标
然后还有一种情况，性能测试还有一个目的，数据验证准确性的问题
请求了很多，诺库的时候会丢了很多数据，
我下一个单，获取了不同的运单号，并发的情况下，可能会出现多个并发，多个订单号可能是会出现一样的
功能测试的时候测不出来，并发的时候才会出现
性能测试的稳定性，长时间运行是否稳定，
如何评价系统的性能？
最重要的是TPS，每秒处理事务数
每秒多少单，每秒多少次，是一个效率的指标
并发用户数，辅助参考数，不能决定一个系统的性能
一个用户下一个单，本来需要一毫秒就完成了，1/1毫秒，TPS=1000
1000个用户，完成1000笔交易，需要1s完成，那么也是TPS=1000
并发用户数为什么是辅助参考数，接口测试没必要加思考时间
站在用户的角度上，也就是前端的角度，例如我点击一个登陆，功能的角度上看，下一个单，提交一个订单，付钱，还有一个登陆之后我查询一下我喜欢的东西，
站在后端服务的角度，
单场景，还有一个混合场景
单场景，压一个单个接口
混合场景是什么？混合场景就是说，比如说我去到网上买东西，第一件事是登录，登录这个操作是单场景，混合场景，搜索，购买，下单，一系列是混合
但是你是一个人，多个人的时候，看权重来压测的，80%是买东西，20%是在做搜索操作，按她的权重，来划分她的线程数
还有一个就是说，大型项目，大型的业务量比较高，配置足够高的，5000个用户
她要求是10万个，没有超过1000万个并发，这是在测试环境
并发多少，取决于你的硬件资源，jmeter刚开始启动比较消耗资源，
被压系统的复杂程度，jmeter的平台，jmeter无法看出最多并发多少
--------------------
然后性能测试的原理
一个控制机，多个肉鸡，被压测系统
尽量避免网络上的瓶颈
最好和服务器直连，才好判断到底是哪些地方出了性能问题
--------------------
哪些系统需要做性能测试
访问频度比较高的接口或者系统
核心业务模块
公共服务类的项目（多借点访问的共享区域）
数据准确性、时效性要求比较高的项目，数据不能丢失
关键节点项目
活动类/形象类（节日/公司文化）
计划中需要测试的项目（领导提到日程上的项目）
以系统的主要功能划分的重要模块或者接口
系统架构变更的系统
------------------------
判断是否进行性能测试依据
1. 从业务角度来分析，如果一个项目上去后使用的人数比较多，量比较大，就有做性能测试的必要，反之，如果一个项目上线后，没有几个客户在用，无论系统多大，设计如何复杂，并发性的性能测试是没有必要做的，前期可以否决。
2. 从系统架构角度来分析，如果一个系统采用的框架是老的系统框架，只是在此框架上增加一些应用，其实是没有必要做性能测试，除非做容量测试。如果一个系统采用的是一种新的框架，可以考虑做负载测试。
3. 从实时性角度来分析，如果一个项目要求某个功能的响应时间，这个有作并发测试的可能性，在大并发量的场景下，查看这个功能的响应时间。
4. 从数据库角度分析，很多情况下，性能测试是大数据量的并发访问、修改数据库，而瓶颈在于连接数据库池的数量，而非数据库本身的负载、吞吐能力。这时，可以结合DBA的建议，来决定是否来做性能测试。
有时候性能测试需求分析可以采用类推性，可比性。举个例子：如果性能需求中对两个类似的功能要求做性能测试，如果这两个功能内部处理逻辑大体一致，仅是功能展示不同而已，这就有可能做其中的一个来做性能测试，通过这次的性能测试结果来类推另一个功能模块。
---------------陈显评曰：
有一次我遇到基准测试，响应时间数值特别大，就没必要再往下做性能测试了。后来一查，连接池不仅小，更严重的是，数据库没有加索引，导致响应时间过大
要有自己的想法，不要被别人忽悠，判断分析能力要足
-------------------------------------
如果要进行性能测试，接下来我们就需要确定相应的性能点。主要从以下 4 个维度进行确定：
1. 关键业务。
首要维度，是确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如快捷签约、交易等接口。如果项目（或功能点）不属于关键业务（或关键业务点），则可转入第二、三、四个维度。
2. 日请求量。
第二个维度，是界定被测项目各功能点的日请求量。如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试；而且其关键业务点，可以被确定为性能点。
3. 逻辑复杂度。
第三个维度，是判定被测项目各功能点的逻辑复杂度。如果一个主要业务的日请求量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式方式的调用中，当某一个环节响应较慢，就会影响到其它环节，造成雪崩效应。
4. 运营推广计划。
第四个维度，是根据运营的推广计划来判定待测系统未来的压力。未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用。
例如，运营计划做活动，要求系统每天能支撑多少 PV、多少 UV，或者一个季度后，需要能支撑多大的访问量等等数据。
当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要做性能测试。
5.其它
以上 4 个评估维护，是相辅相成、环环相扣的，它们合成一个维度集。在实际工作中应该具体问题具体分析。例如，当一个功能点不满足以上 4 个维度，但又属于内存高消耗、CPU高消耗时，也可列入性能测试点行列。
--------------------------------------
陈显：并发量10万，有一段时间是高峰期，对高峰期这段时间进行压测，一个小时内调用了多少接口，处理了多少量，看看TPS，是否能达到要求的相应时间，这就是满足系统需求的。
应该做基准测试，负载测试，稳定性测试
基准测试：单用户的接口可不可测，通不通，要求100ms，高并发的时候最大TPS能达到多少，例如100，
响应时间一测，我艹，500ms，还测什么，不要测了
-----------用jmeter测性能注意的地方：
陈显：用jmeter测性能，不要用GUI，要用命令行，不要用监听器(jmeter -t让监听器失效)，监听器用的查看结果树和聚合报告，都是TMD耗资源的
不要用很多samplers，应该使用一个sampler在一个循环里，然后使用csv data set去改变具体sampler的变量（也就是用参数化）
不要用使用功能模式
使用CSV输出，不要使用xml格式输出（用jmeter自带的properties文件）
脚本不要写无关的内容，用尽量少的断言
性能测试和功能测试最主要的区别：功能测试是事件流，性能测试是数据流。
（是一个流的区别）
UV:独立访问量
PV：页面访问量
-------性能测试调研
最主要的收集来源，业务量，接口量，响应时间，测试人员去收集，应该是产品经理提供，他们也有可能没有
压dubbo
压网关
压网关，再走dubbo
架构是什么样的，可能出现的性能瓶颈点
测试环境和生成环境的差异：测试环境只有一台，生产环境有多台4he8G,......操作系统，中间件。。。
生产环境1个亿的数据，测试环境没有，，，这就引入数据的容量测试，
接口协议，http协议，socket协议，有无第三方的调用
业务模型分为：平缓型、激进型（28原则，80%的交易量是在20%的时间内完成的）
平缓型：一天的量/收集的工作时间
激进型：我一天的量是在哪个时间段爆发出来的，其他时间段没有问题
二八法则
简单峰值法
并发数精算法
并发数估算法
------------案例
接到一个压测任务，要压测xxx
1.压测的目的是什么
2.调研一段时间内，该接口调用量多少或者说被访问量多少，在哪个时间段内被调用最多
3.通过一天内或者一段时间的高峰量算出，峰值TPS和预估相应时间，这个RT相应时间接口类的200ms左右
4.算法有2/8原则，TPS=10w*80%/8*3600*20%
,最高峰值法：TPS=（8W/3600）*N
5.通过业务调研处的TPS和RT为参考
成功事务数>=99.99%
---------------
集合点：反应爆发用户量，秒杀。。。