性能测试笔记一

1、需求分析

通过必要性评估判断系统是否需要进行性能测试，对此可以设定不同条件、不同权重，将评估项分为关键评估项和一般评估项两种，
只要有一项关键评估项符合，则必须展开性能测试，而一般评估项通过甲醛计算，超过60分，则需要开展性能测试。
关键评估项：
	1、被测对象需经过主管部门或监管单位审查、认可，需提供性能测试报告。
	2、涉及财产、生命安全的系统。通常情况，电商系统，金融业务系统
	3、首次投产的大型系统，具有大量用户使用的核心业务；
	4、系统核心数据库、业务逻辑、软硬件升级。与历史系统对比，系统核心数据库、业务逻辑跳转、软件硬件设备升级，同样需要实施性能测试。
	5、历史版本存在重大非功能缺陷或风险较大的未评估项。
	6、业务量、用户量、节点增长30%以上。
	7、系统架构发生重大变化。不同的系统架构可能存在较大的性能差异，因此在系统架构发生变化后，必须实施性能测试。并且在此过程中，无法通过类推的思路推断架构变化后的系统性能。
	8、生产环境非功能严重缺陷修复后。生产环境再使用过程中产生重大非功能性缺陷成功修复后，需重新开展性能测试活动，以验证修复活动是否对生产环境造成不良影响。
	
一般评估项：
	1、是否在平台中处于核心位置（15分）；
	2、是否有升级系统，且升级内容中包含了外部系统对接接口、支付接口、WebService调用接口等与其他系统关联接口（20分）；
	3、是否存在部署方式调整或优化（15分）；
	4、是否增加了性能发现较高的调整（20分）；
	5、是否存在用户要求必须测试的组件或业务流程（20分）；
	6、是否涉及多个功能缺陷的修复，且流程发生较大变化（10分）；
	如果上述评估项，总计分值超过60分，则需进行性能测试；
	
业务用户：
1、用户频繁使用，且存在大量使用的业务流程；
2、交易占比较高，日常占比在80%以上甚至更高的业务流程；
3、特殊交易日或峰值交易占比80%以上甚至更高的业务流程；
4、性能较差且有过调整的业务流程；
5、特殊业务场景；
6、核心业务发生中重大流程调整的业务流程；

再次性能测试：
1、曾经测过性能后调整了架构设计业务；
2、逻辑复杂，关键业务；
3、可能消耗大量资源的业务；
4、与外部系统存在接口调用，且有大量数据交互的业务；
5、调用第三方业务组件，逻辑复杂的业务；

2、性能测试工具选型

1、开源的Jmeter；
2、商业的LoadRunner；

3、性能测试需求评审

1、可测性
	软件可测性，通常理解为软件本身是否具备实施测试的条件，是否便于发现缺陷及定位缺陷；
	功能测试与性能测试差异：实施功能测试时，只要被测对象能够在合理的运行环境中正常运行即可，即使测试环境与生产环境可能存在较大的差异；
	性能测试则不同，一定要尽可能的模拟真实的运行环境，如果在性能测试实施过程中，无法单间相对的测试环境，即可认为被对象不具备性能测试的可能性；
2、一致性
	性能测试需求一致性，主要关注用户需求、生产需求、运营需求几个方面。通过对性能测试需求的分析，判断本次测试需求是否满足用户需求规格说明书明确列出的性能需求项，
	生产需求，则是关注被测对象运行的真实性，从而在测试结束后能够提供相对准确的数据依据，运营需求，需以历史数据或者现今运营数据为基础，规划未来业务发展的可能性，
	从而使得被测对象性能指标具有一定的冗余性；
3、正确性
	在可测性与一致性得到保证的基础上，需针对性能测试指标进行验证，从而保证后续实施活动中所关注的各个项目需求、场景及指标的正确性，从而尽量减少返工，重新设计的风险；

4、 性能测试工作实施

1、需求分析与定义；
2、指标分析与定义；
3、测试模型搭建；
4、场景用例设计；
5、脚本用例设计；
6、测试数据构造；
7、测试脚本开发；
8、场景设计与实现；
9、场景执行与结果收集；
10、结果分析与报告输出；
11、性能调优与回归测试；

当未指明性能测试需求时：
1、从用户角度考虑，测试用户常用业务性能；
2、测试系统占比超过80%的业务；

指标分析与定义；性能测试关注被测对象的时间与资源利用特性及稳定性；
	1、时间特性：被测对象实现业务交易过程中所需的处理时间，时间越少越好；
	2、资源利用特性：服务器的：CPU、内存、网络带宽、磁盘等（根据被测对象架构设计，还可分为Web服务器、中间件、数据库、负载均衡等）；
	3、稳定性：关注被测对象在一定负载情况下，持续稳定提供服务的能力；
主要指标：
	1、并发性：单位时间内服务器接受请求的数量；
	2、响应时间：I、用户通过客户端（如浏览器）发出业务请求（网络传输时间T1），服务器接受并处理该请求（服务器处理时间T2），服务器返回处理结果（网络返回数据时间T3），
		客户端展示处理结果（客户端处理展示时间T4）；T1+T2+T3即为系统响应时间，从用户角度来讲响应时间为：T1+T2+T3+T4，从服务器角度来讲，服务器接收到客户端发来的请求，
		并给出结果的响应，这个过程所消耗的时间记录为响应时间，即T2；
		响应时间一般指客户端发出请求到接收到服务器端的响应数据所消耗的时间；
	3、吞吐量
		单位时间内系统处理用户请求的数量
	4、系统资源耗用
	5、业务成功率
	6、TPS
		单位时间内服务器处理的事务数
		
从测试经验的角度来看，测试最好不要在公网进行性能测试，原因有二：
一、可能影响现网用户，实施性能测试过程中，可能产生大量的压力与垃圾数据，从而破坏市场环境，导致缺陷的产生，影响实际的业务；
二、压力模拟可能无法真实体现，在实施性能测试时，利用测试工具模拟了大量的并发数，产生了大量的业务数据，但因负责生成器所在的网络与服务器所在网络不同，
	或者服务器的网络安全设置，导致压力数据无法到达被测服务器，整个网络环境不可控，从而导致失败；

5、场景用例设计

1、性能测试过程中，首先应该设计测试场景，模拟真实业务发生的情景，然后根据场景设计基本；
	性能测试场景通常包括：
		1、单业务基准测试；
		2、单业务压力测试；
		3、单业务负载测试；
		4、综合业务基准测试；
		5、综合业务压力测试；
		6、综合业务负载测试；
		7、综合业务稳定性测试；
		
	1、单业务基准测试：
		测试某个具体业务是否满足系统设计或用户了期望的性能指标，如用户期望系统支付接口支持50个用户并发支付，如果满足则认为基准测试完成，否则失败，基准测试过程中，
		性能指标的任何一项均需成功，才认为基准测试完成，基准测试可分为并发基准和业务量基准两种，其目的都在于验证是否满足预期目标设定；
	2、单业务压力测试：
		测试某个具体业务在最大负载下，持续服务时长，并以此验证被测业务的稳定性。压力测试过程中所涉及的负载是以系统基准负载为基准，如系统基准负载为50个，则压力测试的负载为50个，
		通过运行时长的验证，验证服务器在系统预设负载下持续服务的压力，具体的时长从需求分析、运行日志、系统设计规划等来源获取；
	3、单业务负载测试：
		测试某个具体业务能够承受的最大负载，验证被测业务能够承受的最大负载数，如系统基准负载为50个，则通过多次测试，逐步加大负载，最终获得被测业务的最佳负载，
		在最佳负载下，系统仍需满足各项性能指标；
	4、综合业务基准测试：
		与单业务基准测试类似，但综合业务需考虑业务与业务间的练习，如相互之间存在资源争用，则需单独组合测试；假设系统需测试的业务有三个：A、B、C，综合业务基准测试是将ABC一起运行
		纳闷加上A、B、C三个基准测试，共计4个基准测试场景，分别是：ABC、A、B、C，但A与C存在资源争用，则需单独将A与B组合，构成一个单独的测试场景，则一共为：ABC、A、B、C、AB等
		5个基准测试场景；综合业务测试中的数据分配根据实际业务、用户需求、运行日志、运营规划等分析确定；