（8、9、10、11）性能测试的基本概念

思维要改变

功能测试、自动化测试，你们都是模拟一个人所使用的某个功能，看实际结果与预期结果是否一致。
性能测试：是模拟N多个人，同时使用某个功能

• 查看多久时间能收到结果（结果是否正确与否，这个不是性能的重点）。
• 多少人能正常收到结果（成功率）
• 服务器在多个人使用时资源消耗多少

性能测试：是在接口的功能测试完成之后，才开始做的。
性能测试的接口参数，一般默认全部参数。（非必传参数也要写）。

例：100次请求，其中有5次请求失败

• （如果按照功能测试的思维：就会问为什么这5次是失败的，失败是我测试哪里出现的问题）。
• 性能测试的思维：是5%的失败率，分析失败率的原因（原因是：我发起方的原因？网络原因？服务器原因？）

性能测试是多个人同时操作，所以这个使用场景是很复杂的，但是我们来分析这个复杂场景的时候，要从最简单场景开始，逐步复杂化。（由易而难）

软件性能测试

通过工具，找出或获得系统在不同工况下的性能指标值。

• 工具：性能测试工具、代码
• 工具，它是来模拟多个人的

相同的请求，同一时间发出，到达服务器时，其实已经有时间差异了。
到达服务器后，服务器处理相同的请求，也会出现有的时间长，有的时间短，处理时间长短也有差异。
关键词：工具、找出、获得

• 接口性能测试，人数要大于1

输出：性能指标值（性能测试报告）
性能测试时间，一般是几十秒到几十分钟。

那么性能测试，具体应该用多少人来测试？
	- 负载测试：通过逐步增加并发用户数，测试系统性能变化，并最终确定系统所能承受的最大负载量。
		- 通过逐步增加并发用户数，找出服务器最大可接受的并发用户数区间
		- 最大并发用户数
		- 最大"可接受"并发用户数
			- 在人为定义的标准：如"在这个标准线下，我们能接受的最大并发用户数"
			- 比如一个杯子最大容量是1L、但你人为觉得他800ml就已经很危险了，1L是最大并发数，800ml就是可接受最大并发数"
				- 行业中接口的性能测试标准线：
					- "平均响应时间为<=1.5秒"
					- "错误率为<=0.1%"
					- 总体标准还是优先按照"客户所制定的平均响应时间和错误率"

				- 用不同的并发用户数，进行的测试时间，不需要很长时间，一般几十秒到几分钟即可。
			- 关键词：逐步增加并发用户数
			- 输出：最大可接受的并发用户数	
		

执行性能测试的基本思路：

• 一个性能测试需求，我们要先做负载测试，找到这个需求中每个接口的（最大可接受并发用户数），然后用这个最大可接受的并发用户数，去做性能测试，得到性能指标值。如果再判断性能指标值，是否有性能问题。如果没有，则可以书写性能测试报告，性能测试就可以结束。如果有性能问题，那么久需要定位、分析、调优性能问题。

 - 压力测试
 	- 用较大的并发用户数，持续运行比较长的时间，看系统的服务和资源利用情况，是否存在稳定性问题
 	- 关键词：较长的运行时间，要看服务器的稳定性问题	
 		- 现在企业中，压力测试的时间标准（较长时间），已经变为了以"小时为单位"
 	- 压力测试，是在有不稳定因素的时候，我们才需要去做压力测试。

容量测试

• 容量测试，与数据库的数据量级有关系
• 在一定的软、硬件条件下，在数据库不同数量级，数据量的情况下，对系统的读\写比较多的业务进行测试，从而获得不同数据数据量级的性能指标值。
• 关键词：数据库表数据量级不一样

稳定性测试

• 在一定量的并发用户数下，持续请求一段时间，看服务器是否存在稳定性问题
  稳定性测试的时候，不需要压力测试那么长时间