做过了几天的
性能测试，听一位大师说，性能测试有一门很好的入门书籍，名曰《软件性能测试过程详解与案例分析》
特买回来拜读了一下。以我自己的
学习经验，
工作了之后，要学习什么，需要首先动手做，能做起来是关键，然后找一本基础的书籍打一下基础，这样入门就会很快，紧接着就是找些进阶的事情作，然后不断的循环，hoho。
下面是我读书的一些笔记，都是很基础的东西，重点记录了第一部分的内容，后面的详细案例准备有空的时候一个个的仔细的读一下，其实书里面的精华都在读者点拨，提示的地方，如果大家有些基础，读这个书会很快，我就是一个周末下午读掉的。
第一章 软件性能测试基本概念
1.1 用户视角的软件性能
响应时间，用户感觉到的系统反应的速度，这里需要注意从用户视角来看，整个响应过程是包含很多过程元素的，比如网络，应用系统各部分间的通信，这个对系统来说是个综合的响应时间。
1.2 管理员视角的软件性能
从管理员角度来看，更具有专业性，除了会关注系统的响应时间，同时还会对系统的各部分情况进行关注，包括服务器的指标，系统的运行情况，服务器资源的使用情况，系统的可扩展情况等等。
1.3 开发视角的软件性能
开发更加关注的是怎样优化自己的软件结构后能带来上述两个视角的好体验。
个人感受：这里作为一个质量保证人员，我们需要从各个视角进行关注，重点在体验情况良好的情况下，我们需要有能力定位出系统的性能瓶颈是什么，并对性能优化提出一定的建议。
1.4 软件性能术语
响应时间：呈现时间；系统响应时间
并发用户数：并发测试（concurrency testing）下常常关注的一个概念，需要区分两个场景。一个系统在同一时刻承受的用户访问数量；一个系统的一个功能在同一个时刻成熟的用户访问数量。这里就对应了我们经常听到的另外几个概念：并发用户数，系统用户数，同时在线人数。
并发用户数的算法： C=nL/T （C并发用户数，n login session，L login session的平均长度，T 考察时长） 峰值并发用户数算法 C^=C+3*C开方 （泊松分布）
B/S C/S： browse/service client/service
吞吐量：单位时间内相应请求的数量 tps 单位为秒 计算公式 f=Nvu*R/T （Nvu 用户数；R 请求数；T 考察时长）
思考时间：我们用来模拟用户点击的业务时间间隔。 R =T/Ts （R 请求数 T 考察时长 Ts 思考是间）
个人感受：我们进行性能测试指标计算的时候，有多少是经过计算得来的，我们的测试准确度有多高
1.5 RBI 快速识别性能瓶颈方法（Rapid bottleneck Identify）
80%的性能瓶颈都是由吞吐量制约
并发用户数和吞吐量存在一定关联
快速定位我们往往从吞吐量测试着手
个人感受：这个和我们的性能测试不谋而合，我们经常是固定以一定的并发用户数曲线进行性能定位；我们需要多了解测试领域的一些已成文的规约，这样让我们的入门测试更容易。
1.6 性能曲线下降分析法
通过并发用户数的增长，我们可以观测到系统性能拐点，这样进行快速定位。
个人感受：这个方法我们也经常使用，几个专业术语。单用户区；性能平坦区；压力区；性能拐点。
第二章 性能测试的应用领域
2.1 性能测试防范
性能测试（Performance Testing）：模拟生产环境压力和使用场景进行测试。验证系统是否有宣称的能力。
负载测试（Load Testing）：给被测系统不断增加压力，直到某一种或多种指标超出预先期望。找到系统的极限。多配合调优使用。
压力测试（Stress Testing）：让系统在一定的饱和情况下，观察系统的会话能力。检查系统在饱和情况下应用的能力。
配置测试（Configuration Testing）：调整系统的软硬件配置，找到系统的最优配置情况。
并发测试（Concurrence Testing）：在高并发的情况下观察系统的反应，包括是否有死锁或者系统资源使用释放情况。发现系统隐藏的并发问题。
可靠性测试（Reliability Testing）：给系统一定的压力后，观察系统在一段时间内的会话能力。通常在70%-80%的压力下。
失效恢复测试（Failover Testing）：多在有冗余备份，负载均衡的系统中，观测一部分系统故障后系统的会话能力和对客户的影响范围评估。
数据库的ha。
个人感受：多种性能测试方法之间也有交集，需要对性能领域的概念有深入的了解，同时在过程中根据自己测试的目标进行方案设计和调整。
2.2 性能领域的分析
能力验证
能力规划
性能调优
缺陷定位
个人感受：其实是一个对被测系统进行性能测试的一个过程
第三章 性能计数器及性能分析方法
3.1 性能计数器及性能分析防范
个人感受：性能计数器就是我们常说的那些性能指标，你的被测系统有那些指标来衡量性能情况，就是那些计数器。我们在测试的的时候需要充分了解这些指标，通过测试数据对系统性能进行分析。
3.2 unix操作系统主要计数器
Processor %Idle time ：cpu总空闲时间，如果这个值持续低于10%，可以定位瓶颈在cpu，基本需要增加cpu来解决问。
%IOwait time ：cpu消耗在等待IO处理上的时间，结合io进行分析，定位io问题。
3.3 内存分析方法
确定可用物理内存——》查看磁盘交换、读写、失败的频率——》查看Disk time
个人感受：这个是一个内存问题定位的思路，首先需要知道我们可用的内存有多少，那么在系统运行过程中磁盘的交换频率是怎么样的，如果非常高，需要关注系统对内存的使用策略，那么经常失败也有可能是内存出现物理问题；然后区定位是否是大量的磁盘读写带来的频繁的内存换页，是否出现
日志记录频繁，导致频繁记录日志的原因是什么来进一步定位。
3.4 处理器分析方法
查看现有的处理器利用率——》查看每个cpu的User time
个人感受：查看处理器利用率需要注意，目前我们很多服务器使用多核系统，直观看到的很多指标都是平均利用率，有的时候可能出现平均并不是很高，但是大部分消耗集中在一些cpu上的情况；User Time上面消耗的时间比较多，需要考虑对系统算法进行优化；需要查看processor queue length，当出现数量大于cpu的个数的时候，说明出现了cpu阻塞的情况。
3.5 磁盘IO分析方法
计算系统的磁盘io标称指标
个人感受：这个需要根据read的类型进行区分，每种公式都不一样；
3.6 进程分析方法
查看进程消耗处理器时间——》产看每个进程的共享字节数量
个人感受：查看进程占用的系统资源，包括cpu和内存，然后在进行针对性分析，比如是否会出现内存泄漏。
3.7 网络分析方法
个人感受：出现了大量的数据交换的系统，有可能会有网络的问题，相互之间的通信有可能让网络消耗成为瓶颈。
第四章 性能测试工具原理
4.1 性能测试工具架构
虚拟用户脚本产生器（virtual user generator）：一个proxy，来截取client和
server中间通信的全部内容，并记录下来。通常各个工具都是支持多个协议的通信的。
压力产生器（player）
用户代理 （agent）
压力调度和监控系统（conductor）
压力结果分析工具（analysis）
个人感受：了解各个性能测试工具每个部分的工作原理，针对不同的系统，可以尝试使用自己的方法来实现测试方案中的场景模拟。
4.2 性能测试工具的选择和评估
个人感受：需要和自己的使用场景和使用人员的习惯水平来选择性能测试工具，可以从一些角度出发。过程中结合成本分析的方法。
第五章 性能测试的组织
5.1 性能测试团队人员
测试经理
测试设计人员
测试开发人员
测试执行人员
测试分析人员
支持人员
个人感受：每种角色都有自己的工作，实际工作过程中这些角色不一定是区分了不容的自然人的，我们需要知道过程中都需要作什么事情就可以了。
5.2 性能测试过程模型 PTGM
测试前期准备
测试工具引入
测试计划
测试设计与开发
测似执行与管理
测试分析
个人感受：工作中有的时候会很关注测试设计与开发，其实
其他的环节都是相当重要的，有的是基础，计划也需要前期规划好，避免后期出现一些风险带来的进度delay，相对于
功能测试，这点也经常容易被忽略。
