性能测试理论总结

1、性能测试、负载测试、压力测试、稳定性测试

    性能测试验证系统表现是不是符合预期
    负载测试验证系统在超出预期的过程中，他的表现怎么样？
    压力测试重点是要找到系统在不断加压的过程中，什么时间点（并发量时）崩溃
    稳定性测试强调时间维度，重点是验证系统持续提供服务的时间、稳定情况。

2、怎么考虑性能测试的典型场景？
    产品规格：
            用户模型：用户喜欢什么功能，时间段用，大概有多少用户；
            系统数据：基础数据和业务数据
            比如：比如双11，用户名、地址信息是基础；买了什么东西付了多少钱这样的数据是业务数据。
            原则：宁多勿少
    系统架构：B ---Tomcat(Nginx) --Redis --Mysql
    运维日志‌：进一步确定真实用户的数据和行为；
    市场计划：未来帮助我们考虑性能的扩展性；
    项目管理计划：未来帮助我们明确测试的优先级；
            --测试需求-->设计出压测模型

3、性能测试流程（重点）
    流程是什么样？
            ===》 需求分析 - 测试计划 - 用例编写 - 测试执行 - 输出报告

              
                       -----------前期准备-----------    ----------中期准备----------------      ---测试执行----    --完成--
            ===》 需求分析 -- 方案设计 -- 计划 -- 脚本编写（环境搭建、预热、数据准备） -- 执行、监控、调优 --数据报告

    为什么需要流程？
        
            ===》保证项目顺利进行
            1)需求分析：做什么事情？见2；
            2)我怎么做这件事（宏观）
            3)计划：什么人、什么时间、做什么事
            4)脚本编写：先了解系统：接口、功能（模块）、彼此间的依赖关系，再开始编写；
                 错误做法：
                 a）脚本全放在一个Action；
                 b) 没有注释的
                 c) 写完后没在场景中跑，结果一压测脚本就各种报错；
             ……
            5)环境搭建：搭建环境需要多少资源，这个环境要满足什么样的需求（多少核多少G，带宽多少，需要多少台）
                  主要问题：线下环境如何模拟线上环境？
                  能在线做就在线做：没上线，可以在线做（没上线，没用户）；全链路（已上线，有用户）的方式；
                  模拟搭建环境，测试机器的扩展系数 + 自动化扩容（或服务降级）构成一个方案；
                  差异过大，不要做； 
                  PS搭建好之后要预热
             6)数据准备
                   主要是性能需求分析的结果：准备多少数据；
                   测试方案：怎么准备（业务生成、SQL存储过程、工具生成、导入线上数据（敏感数据要脱敏））
                   具体准备：测试准备
            7）执行：设置好场景，跑数据出来
                    监控：为了收集数据，为后面分析和调优做准备；
                    调优：为了软件更好，更能服务预期；
                    过程：迭代反复的；

4、负载测试时，有时服务器过大测试过程中没有测试出他的极限，上市后出现瘫痪，怎么解决？
    测试环境建设：
    1）尽可能在线测（全链路压测）；
    2）自己搭建环境测试
        a)线上服务器很多，不可能搭建完全真实的环境，采用等比缩放，测试出扩散系数
        b)能搭建出真实的环境测试，那就测吧

5、线网性能测试是在公网进行吗？
    看应用，具体情况具体分析

6、性能测试指标（重点）：
    1）并发数、在线用户数、注册用户数
        并发用户数              在线用户数              注册用户数
    12306同时买票的用户    12306同时登上去的用户   12306的注册用户数

    PS：并发用户数是用来压测的；注册用户数会根据这值来造数据；

    2）、响应时间
        响应时间是和一定的用户行为联系在一起的。对外说的时候：TPS多少的时候，响应时间是多少？
        响应时间一般越短越好，需要看具体测试对象的标准。
        响应时间组成（Web）:
        a)打开浏览器，在百度中输入：新浪； ---忽略，不用考虑；
        b)浏览器自身的处理；
        c)DNS的解析时间：host --- 本地DNS --- 国内DNS --- 国际DNS
        d)TCP建连时间：三次握手所需要花费的时间 
        e)请求在网络上传输的时间
        f)服务端接收时间
        g)服务端解析时间：OSI网络模型解封装到找到具体的业务程序解析所花费的时间；
        h)数据库处理时间
        i)数据发送给客户端的时间
        j)数据在网络上传输的时间
        k)客户端收到数据并呈现出来所需要的时间
        l)整个业务处理中经过的模块花费的时间都要考虑进来

7、TPS
    站在客户端的角度来说的；
    单位是个每秒：如200个/s
    测试登陆的性能：一个事务里面可能有很多的请求；

8、吞吐量：衡量网络性能的实际指标（带宽是理论指标）
    bit/s

9、思考时间

10、CPU、内存、网络、IO
    1）CUP：物理CPU：主板上实际插入的cpu数量，可以数不重复的 physical id 有几个
            cat /proc/cpuinfo| grep "physical id" | sort | uniq | wc -l

            逻辑CPU：一般情况下，逻辑cpu=物理CPU个数×每颗核数，如果不相等的话，则表示服务器的CPU支持超线程技术（HT：简单来说，它可使处理器中的1 颗内核如2 颗内核那样在操作系统中发挥作用。这样一来，操作系统可使用的执行资源扩大了一倍，大幅提高了系统的整体性能，此时逻辑cpu=物理CPU个数×每颗核数x2）
            cat /proc/cpuinfo| grep "processor" | wc -l

            CPU的核心数：单块CPU上面能处理数据的芯片组的数量，如双核、四核等 （cpu cores）
            cat /proc/cpuinfo| grep "cpu cores" | uniq

        
        关注具体指标，看整体是否够用，看具体要测试程序用掉多少CPU

    2）内存

   windows系统显示用了多少就是多少；
        Linux所有的内存都会被系统拿来用；
        关注具体指标；
        看整体是否够用；
        看具体要测试的程序用掉多少内存；
        有没有使用交换分区---如果使用了交换分区，也表明了系统的内存紧张；

    3）网络（连接客户端和服务端）
        关注：带宽，吞吐量是多少，丢包率是多少；
    4）IO
        关注：当前使用了多少，是谁在读在写他们各自用了多少。

11、性能测试理论模型
    拐点模型
    1）随着压力增大，响应时间会逐渐变大
    2）随着压力增大，吞吐量显示逐渐增大，维持一个较高水平，之后吞吐量会下降；
    3）随着压力增大，资源利用率先是逐渐增大，维持一个较高水平；
        
    理发师模型：http://blog.csdn.net/gzh0222/article/details/6792442
    重点，理解随着压力增大，系统会照顾客人体验（感受），他们会出来招呼客人，招呼的过程中，就会造成性能下降；

11、前端性能
    前端性能测试是一个用户的行为，而服务端性能测试，是很多用户并发起来的行为。
    前端性能测试工具：浏览器的开发工具（F12），httowatch,在线免费工具等；

12、识别性能瓶颈点：
    TPS -- 响应时间 ---> 初步性能数据是否满足预期，满足呢，看四大件（有没有潜在风险），有潜在风险呢，分析：
    初步性能数据是否满足预期，不满足呢，分析，看瓶颈点在哪里（看谁占用过多的资源，再进一步确认他占这么多资源不合理），如果合理，OK；如果不合理，开发介入优化吧。
    
13、如何设计负载？标准是什么？
    测试出满足产品需求的数据（假设是：50）
    开始设计负载测试：以大于50的压力，开始跑，比如：60,70,80......开始跑负载测试，直到系统挂掉（压力测试压挂掉系统时的压力）；
    实际上：
        更关注性能测试，更关注系统的稳定性。
        要知道系统能不能满足应用；
        要知道系统什么时间点开始不满足应用；
        什么情况下才会挂掉