听了破冰的分享后，对性能测试有了初步的了解，今天补了下空白区域
性能测试概述
一提到性能测试，就会涉及到另外两个密切相关的概念——压力测试、负载测试。这三者有密切的关系，又有区别。三者的测试目的是不一样的，但使用的手段和方法在一定程度，通常会使用相同的测试环境和测试工具，而且都会监控系统所占用资源的情况以及其他相应的性能指标，这也造成了很多人容易产生概念混淆的主要原因。
性能测试是为了获得系统在某种特定条件下（包括特定的负载条件下）的性能指标数据，致力于提供系统性能指标方面的数据。对加载有非常严格、明确的要求，而且事先所定义的性能指标也很明确。
如果系统性能测试的实际结果不符合指标要求，那么就需要进一步分析、优化，最终使系统的性能指标达到要求。
而负载测试、压力测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。
定义
（1）负载测试 是通过模拟实际软件系统所承受的负载条件、改变系统负载大小和负载方式来发现系统中所存在的问题。
例如：逐渐增加模拟用户的数量来观察系统的响应时间和数据吞吐量、系统占用的资源（CPU、内存等），以检验系统的行为和特性，发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。
负载测试 更多地体现了一种方法或一种技术，可以为性能测试、压力测试所采用。
（2）压力测试（强度测试） 是在强负载情况下（如大数据量、大量并发用户连接）对稳定性进行测试，查看应用系统在峰值（瞬间使用高峰）使用情况下的行为表现，更有效的发现系统稳定性的隐患和系统在负载峰值的条件下的功能隐患，确认系统是否具有良好的容错能力和可恢复能力。
可分为 高负载下的长时间（如24小时以上）的稳定性压力测试 和极限负载情况导致系统崩溃的破坏性压力测试
如12306网站，8月30日可购买国庆10月1日的票，购买时间一到可能有上亿用户与系统在同一时间产生交互
CPU内存100%使用，系统在处理新的会话时会不会出现新的错误
针对上述负载测试、压力测试举个例子：一个人背X斤
负载测试：200斤情况下，是否能坚持5分钟。
压力测试：200,300,400斤... 情况下，他的表现，什么时候失败，失败之后什么表现，重新扛200是否正常。
容量测试：在坚持5分钟的情况下，他一次最多能扛多少斤
Web前端性能
取决于浏览器的实现机制，Web页面上的JS文件的执行等，它与服务端的负载和压力无关。比如图片、CSS、JS等资源的下载
Web服务端性能
在确保功能实现正确的前提下，考察服务端应用程序的各项性能指标，以及服务器硬件资源的使用情况。
做性能测试基础知识
- HTML 语言基础：用来显示数据
参考教程：http://www.w3school.com.cn/html/index.asp
（元素、属性、表单、链接、URL） - C 语言基础知识
了解分支循环、变量、函数定义 - HTTP 协议
接口性能会涉及到；请求（post、get、delete、put）；状态码含义（200、302、404、500等） - XML：用来传输和存储数据
参考教程：http://www.runoob.com/xml/xml-tutorial.html
与html类似，树形结构 - JSON：轻量级的文本数据交换格式
1）全拼：JavaScript Object Notation（JavaScript 对象表示法）
2）存储和交换文本信息的语法，类似 XML，比 XML 更小、更快，更易解析
3）现在很多http的post请求都在用 Json 格式传输数据，最常见的用法之一是从 web 服务器上读取 JSON 数据（作为文件或作为 HttpRequest），将 JSON 数据转换为 JavaScript 对象，然后在网页中使用该数据。
参考教程：http://www.runoob.com/json/json-tutorial.html - 数据库
主要是数据的增删改查操作
多角度看待性能测试
- 用户角度
软件对用户操作所产生的响应时间，用户不关注是什么原因引起的性能问题 - 运维角度
系统是否能够提供给用户一个可靠可持续的服务，必须关注系统资源使用的情况 - 开发角度
如何调整设计代码的实现
比如银行软件，并不要求多快的速度，只要求系统的稳定运行，要保证数据不出错
性能测试主要术语
1、并发数：同一时间点内跟系统交互操作的数量
狭义并发
用户在同一时刻做同一件事情或操作。
例如：首页并发、加入购物车等广义并发
用户在同一时间点内发出的请求或操作，这些请求或操作可以是相同的，也可以是不同的。
例如：首页、促销页、商品列表、商品详情等同时访问
一般来说，广义并发更接近用户的实际使用情况。
对性能测试而言，两种并发都需要测试（先狭义后广义）。
狭义并发发生在使用较为频繁的模块中，一旦有问题通常都是程序问题。
一般通过测试工具模拟虚拟用户（Virtual User）来体现
比如：12306网站，100个人8点都登录网页抢票，那并发数就是100
在这里，我们要解除两种误区
1）认为系统所有的用户都是并发用户
注册用户数（系统所有用户）：当前系统中全部注册的用户数量
如公司员工2000人，每个人都会用到OA系统，但并不代表这2000人都同时在使用OA系统
2）认为所有在线的用户都是并发用户
在线用户数：当前时间段内有多少用户登录了，并不一定与系统产生交互，有些用户只是登录了而已 或者查看网上上的一些信息
如何计算并发用户数？
很大程度上市根据经验和行业的一些标准来计算的，像12306网站并发用户数量就会比较多，而OA系统一般是在线用户的5%-20%
2、事务
比如登录网站，输入用户名密码，点击登录，这三个操作我们就可以称为登录事务
TPS：服务器每秒处理的事务数，衡量系统处理能力的重要指标
3、吞吐量：被测系统产生的数据流量
直接体现服务器的承载能力，衡量服务器处理能力的重要指标，在分析时一定要注意分析吞吐量
比如说点击网页（10M），打开，100个人同时点击网页，100*10M就是吞吐量
4、吞吐率：单位时间内服务器处理用户提交的请求数
吞吐率=吞吐量/测试时间
5、点击率（每秒点击率）：客户端每秒真正发给服务端后端请求的数量
比如每秒向接口发送多少次请求，这不能反映系统的性能，只能反映出客户端向服务端发送的请求数量
注意点：用户点击一次，并不代表客户端只向服务器端发送一个HTTP请求，可能会发出多个请求。
6、思考时间：用户在进行操作时，每个请求之间的时间间隔
如：输入用户名和密码后，看下输入的对不对，这个等待时间就是思考时间
7、资源利用率：服务器系统不同硬件资源被使用的程度
分析服务器出现瓶颈和对服务器进行调优的主要依据
主要包括CPU占有率、内存使用率、IO使用率和时间（需要后台监控）
8、响应时间(Time to laster byte)
从客户端发送一个请求开始，到客户端接收到从服务端返回的响应结果结束时所经历的时间，它是影响用户体验的及其重要的一个指标。
从用户角度来说，当用户单击一个按钮，发出一条指令或在web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。
响应时间=网络传输时间+服务器处理时间+浏览器显示时间（呈现给用户的时间）
响应时间的标准
- 在3秒钟之内，页面给予用户响应并有所显示---“很不错的”；
- 在3~5秒钟内，页面给予用户响应并有所显示---“好的”；
- 在5~10秒钟内，页面给予用户响应并有所显示---“勉强接受”；
- 超过10秒就让人有点不耐烦了，很可能不会继续等待下去---“差评”；
写性能测试脚本步骤
1、需求分析
2、测试点提取：对哪些功能进行测试（指标评估）
参考历史数据
客户方提出
参与同行业同项目性能指标
业界通用规则
自己测试决定
3、制定测试计划
4、测试计划评审
5、测试设计（搭建环境、准备数据、编写用例）
6、执行用例（一次加载和逐步加载）
如：一个加载30个并发数 和 每次加载10个，逐步加载到30个
7、分析测试结果
8、提交性能测试报告
如何选择性能测试工具
web service：SOUPUI，不用编写代码
http接口：Jmeter
界面功能性能测试（打开、下载图片）：LR
常见的性能问题
1、资源泄漏
包括内存泄漏，系统占用的资源（如内存、CPU等）随着运行时间不断增长，从而降低系统性能。系统响应越来越慢，甚至出现混乱。只有重启系统才能恢复到最初水平。
这类问题 产生的主要原因 是 有些对象（如GDI使用、JDBC连接）没有及时被销毁、内存没有释放干净、缓存区回收等。
内存泄漏
在进程执行过程中，如果一块内存区域，进程失去了对其的引用，也就是所该块内存区域永远都不会被进程使用到了，而操作系统又不知道进程失去了对其的引用，所以不能进行回收，这就会导致操作系统认为进程保留了很多内存空间，但进程本身却没办法去使用这些内存空间。
2、资源瓶颈
内部资源（线程、放入池的对象）变得稀缺，随着负载越来越慢，甚至系统挂起或出现异常错误。
这类问题产生的主要原因是线程过度使用或资源分配不足等造成的
3、CPU使用率达到100%，系统被锁定
代码中可能存在无限循环、缺乏保护（如对失败请求不断的重试）、频繁对数据库存取、没有使用数据高速缓存等
4、线程死锁、阻塞
可能因为程序对事物并发处理上的错误、资源争用引起锁阻塞和死锁等
如：线程获得顺序的算法不对，造成死锁、线程同步点上备份过多而造成通信阻塞
5、数据库连接成为性能瓶颈
可能是因为数据库存取交互过多、未使用连接池 或 连接池配置参数不当、单个SQL请求的数据量过多等问题
6、查询速度慢 或 列表效率低
主要原因是列表查询未使用索引、过于复杂的SQL语句、分页算法效率低
也可能是查询结果集过大或不规范的查询，如返回全部数据，查询全部字段而不是所需字段
7、受外部系统影响越来越大
主要原因有 向后端系统发出太多的请求、页面内容过多、经第三方系统认证比较复杂、网络连接不稳定或延迟
