包含一个 Setup()方法/函数，tearDown()方法/函数，用例执行之前都会先执行 Setup()方法/函数主要是完成一些准备初始化的工作，比如创建临时的数据库，文件和目录，用例数据读取，浏览器的打开等，用例执行完成之后，会执行 tearDown()方法/函数，完成一些清理回收的工作，比如数据库断开，关闭浏览器。

(1)比如说在这个测试用例中需要访问数据库，那么可以在seUp()中建立数据库连接以及进行一些初始化，在 tearDown()中清除在数据库中产生的数据，然后关闭连接，注意 tear Down的过程很重要，要为以后的 TestCase留下一个干净的环境。

test case(测试用例)：

什么是测试用例呢?

就是一个完整的测试流程包括测试前准备环境的搭建( setUp)，以及测试后环境的还原( tearDown)，还有包括用例方法，每个用例方法都必须要以test开头。

test suite(测试套件)：

多个测试用例的集合就是 suite，一个 suite可以包含多个测试用例，也可以嵌套suite.可以通过 addTest()方法手动增加 TestCase，也可通过 TestLoader自动添加TestCase， TestLoader在添加用例时，会没有顺序。

test runner(运行器)：

用来执行测试套件中测试用例的，最终执行完成之后会生成一个测试结果。

TestLoader(加载器)：用来加载用例，把用例加载到测试套件中

Test Result(测试结果)：包括运行了多少测试用例，成功了多少，失败了多少等信息。

https://mp.weixin.qq.com/s/nLyx6PEOqGCEnF-1kc-IfAhttp://点我免费领取全套软件测试自动化测试资料

12.5 Unittest框架如何使用?

1. 导包

import unittest

from selenium import webdriver

import ddt

定义一个类继承 unittest.TestCase基类
重写 setUp(),tearDown()方法

setUp()方法实现一个初始化的准备工作，比如，实例化 webdriver对象，对 driver进行初始化配置，连接数据库.....

tearDown()方法实现释放资源的任务。

编写用例方法，用例方法必须以test开头

5. Unittest如何去运行多个文件或者整个目录

因为我们用例全部是放在 test_case目录下统一管理的，基本每个某块都是一个.py文件，要全量跑的话，需要调用 unittest.default.discover()函数，指定用例目录的路径，加载所有的.py文件，它会自动创建测试套件，井把用例加入测试套件中，然后利用unittest.TestRunner()创建一个执行器利用这个执行器去运行测试雷件中的所有用例。

12.6 如何生成自动化测试报告?

我们当时用的是 HtmIReport这个库来生成自动化测试报告的。

安装

pip install HTMLReport

使用方法

# 测试用例执行器

runner= HTMLReport.TestRunner(

Report_file_name='test’， #报告文件名，如果未赋值，将采用"test+时间戳"

Output_path='report’， #保存文件夹名，默认" report"

tite=’测试报告’， #报告标题，默认"测试报告"

description=’无测试描述’ #报告描述，默认"测试描述"

Thread_count=1， #并发线程数量(无序执行测试)，默认数量 1

Thread_start_wait=3， #各线程启动延迟，默认0s

Sequential_execution=False. #是否按照套件添加( addTests)顺序执行，

#会等待一个 addTests执行完成，再执行下一个，默认 False

#如果用例中存在 tearDownClass，建议设置为True，

#否则 tearDownClass将会在所有用例线程执行完后才会执行

# lang='e

lang='cn' #支持中文与英文，默认中文

）

#执行测试用例套件

runner.run(suite)

十三、 Pytest框架

13.1 自动化测试使用的那些库

1、selenium库 --web自动化测试工具 2. priest框架，运行用例 3. random随机，概率

4. xlrd --获取exell表数据 5. pymysql调用数据库 6. pytest-html --生成html文件

7. yagmanil --发送邮件 8. time-时间 9. Select包--下拉框 10. Keys 模拟键盘操作

11. Webdriverwait智能等待 12. Action Chains模拟鼠标操作

13.2 pytest框架如何使用

1. 安装 pytest框架

pip install pytest、在 pycham里安装 pytest、源码安装

2. 导入 pytest： import pytest

3. 编写主函数，后续代码，后面运行： if_name_=='_main_’;

4. 执行文件:

pytest.main(["要运行的文件的相对路径"]) ----例如(["../test_case/test_01.py"])

13.3 pytest框架如何去生成测试报告

1. 要安装 pytest-html

pip install pytest-html、在 pycharm里安装 pytest-html、或者源码安装

2. 在运行用例模块中执行用例时添加html路径： pytest.main(["要运行的文件的路径","--html=. /report/report.html"])

13.4 bytes如何去运行多个文件或者整个目录

1. 执行多个文件

pytest.main(["../test_case/test_01","../test_case/test_login"])

2. 执行整个目录

pytest.main(["../test_case/"]) --列表里是目录路径

13.5 pytest框架如何去运行上次失败的测试用例

1. pytest --lf运行用例的路径 --- 只运行上次失败的用例

2. pytest --ff运行用例的路径 --- 运行上次所有的用例，优先运行上次失败的用例

(如果没有写路径，则执行当前目录下所有的用例)

13.6 运行完成后，如何去自动发送邮件

#用例执行,无人值守的状态，如何才能知道已经运行完成，发送测试报告到邮箱里面查看运行完成

安装 yagman

pip installyagmail、在 pycharm中安装 yagmail

导入 yagmail: import yagmail
定义发送者邮箱服务，里面包括邮箱地址，授权码，smtp.126.com

yag = yagmail.SMTP("126邮箱地址"，"授权码"，"smtp.126.com")

自动发送邮件

yag.send(["接收邮件的邮箱地址"，"多个邮箱用列表包起来"]，"邮件主题"，"邮件正文内容","附件的地址../report/report.html")

13.7 fixture装饰器的作用与默认值

1. 装饰器：@pytest.fixture()

def open_l()： #不再用test开头，

ea = element_action() #实例化对象

ea.open_url() #打开浏览器 driver，被其他用例所调用

Yield ea 1，装饰器使用的返回值，类似于 return方法 2，前置与后置处理分开

ea.close_browser() #每次运行，关闭浏览器，闭环

设置了装饰器之后，可以被其他用例调用，有使每个用例都有打开网页和默认关闭网页的作用

13.8 yield的作用是什么

1. 装饰器使用的返回值，类似于 return方法

2. 使前置与后置处理分开

13.9 pytest运行用例，用例命名规则有哪些?

1. 文件名以test_*.py文件和 *_test.py命名 * 代表任意任何内容

2. def函数要以test_开头

3. class类要以test_开头.

4. 以test_开头的方法

13.10 allure报告生成

1，先安装一个allure包用 pip install allure-pytest

2，运行脚本-s,-d生成报告的目录，一般是一些json文件

3，下载allure生成工具，配置环境变量

4，运行命令: allure generate ./allurereport/-o ./reporthtml/--clean，

生成html的 allure报告

十四、性能测试

14.1 性能测试怎么测试

性能测试其实就是通过自动化工具模拟多种正常、峰值以及异常负载来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，二者可结合使用。

性能指标主要有平均响应时间、90%响应时间、吞吐量、吞吐率，每秒事务数，以及服务器的资源使用率(CPU占比，mem内存占比等)等。当并发用户数超过300时，为了让测试数据更准确，可以考虑分布式压测，通过司令机控制几台奴隶机进行测试。

性能测试要先调试好脚本，主要考虑对脚本的数据参数化和添加断言。因为有些接口需要对业务逻辑或参数格式进行校验，为了能让所有线程数跑起来，需要将数据参数化。

数据参数化有这几种做法：

可以将一些固定值改成随机函数;
利用JDBC从数据库读取数据并关联变量；
Excal数据参数化，
动态关联参数化，断言是为了判断用例是否

执行成功，并验证服务器的响应错误率。响应断言常用json断言，xml断言用的最少，

性能测试的目的是为了检验系统能否满足客户的性能需求，若性能需求无法满足时，则

要考虑对系统进行性能调优，一般用排除法：

1、首先考虑网络方面问题：使用ping命令查看与目标服务器的连接是否正常、传输速度的快慢。通过提升服务器的带宽，看响应时间是否相应降低。

2、考虑数据库的问题，可以单独去压测数据库，查看数据库的最大连接数和SQL语句的执行时间，索引命中率和sleep等待时间等

3、考虑 Apache中间件的问题，查看中间件设置的最大连接数是否合理，如果设置的连接数太小，会话数超过设定的最大连接数时会导致等待时间变长，出现响应超时情况

4、考虑服务器的硬件配置，如内存、CPU、men、磁盘读写速度等，可以用top命令来监控，也可以使用nmom工具来监控，nmom会把监控的数据形成表格形式，方便我们查看。

5、最后考虑开发代码写的好不好，处理时间长不长的问题。

举例：在我之前的公司，我们主要是会考虑用户操作使用比较频繁的模块，比如借贷，充值，投资模块，我们一般会通过增加并发数来压测，观察CPU、mem、磁盘读写、吞吐量和每秒事务数等性能指标，以前我老大要求我并发100个用户，我用 jmeter把线程数设为100，永久循环，持续时间半个小时，设置启动延退55，在Linux启用mmom工具监控服务器。

当我运行脚本的时候我看聚合报告90%的平均响应时间达到了6s，吞吐量也比较小，用top命令监控资源发现CPU差不多到了100%。于是我用 Navicat工具通过SQL命令show full processlist取当前运行的SQL语句，发现有许多语句用的是左关联，在查看了这条SQL语句的执行计划发现没有用索引，再查看了索引的命中率，命中率倒是还行看了下nmom生成的报告，发现CPU一直是处于爆满状态，其中主要是mysql的占比很大，这个时候我基本上判断数据库的问题。

于是我就照着前面的步骤再次压测，同样还是用nmom工具去监控CPU，mem网络等状态，这次我是主要在 Navicat上用命令去抓取SQL语句，还是一样有很多语句都是左关联，并发现很多空连接(sleep)，我就用 show global variable like"wait_time"命令查看了设置的休眠时间(等待时间)发现时间很长28800s，然后我就把这个休眠时间改成了20s，因为SQL语句使用了很多左连接，我就用 show variables like"tables_size"查看了临时表的空间大小、发现临时表只有16m，我将空间改成了1G再去压测了下，发现CPU只是降了10%左右，nmom报告上还是显示mysql占的CPU很大，然后运行的时候，用top命令监控，发现有的时候有很多mysq进程同时运行(因为没有设置连接池)，我就用命令查看了下mysql的最大连接数，因为SQL语句的执行速度还是挺快的，所以就把mysql的连接数调小到50，再去跑了一遍发现CPU降到了40%左右，并且其他的性能指标也都还不错。最后把聚合报告的数据以及nmom的数据整理成性能报告给老大，其实做接口性能主要就是用排除法个一个去排除，发现性能问题就要先解决了性能问题再压测，不然其他的问题也有可能是这个性能问题导致的所以接口性能基本上就是观察，各个性能指标都在范围之内就差不多了。

14.2 性能测试流程是怎么样的?

例外一种问法：简单介绍下你们公司的性能测试流程是怎么样的?

我们那个项目的性能做得不多，公司要求也不严格。

对于流程这块，首先就要对整个系统进行详细的分析，确定基本的测试范围，看下系统的哪些业务是需要做性能测试的，还有就是做那方面的性能测试，对于我们那个项目，当时就做了几个业务做了些简单的井发压测(稳定性)这块，像登录的，搜索查询，下单，还有就是购物车里面的几个接口都有做过，然后就是对各个业务场景进行详细的场景分析与设计，确定每个业务场景的并发数，是否需要设置集合点啊，压测时间是多长，还有各个业务场景的性能指标等等，场景设计这块基本上都是老大跟产品哪个一起弄的，我参与的不是太多。

上面把个场景设置好了之后，提交给我们，我们就是根据老大设置好的那些场景编写了基本的性能测试用例，其实做性能测试，我觉得前期最关键的还是业务场景一定要设计好，后期我们主要的任务就是准备各自任务需要用到的一些测试数据，搭建好测试环境，还有就是测试脚本设计与开发，执行，并生出测试报告，对于测试结果我们一般会简单的做个分析，如果没有什么问题，基本后期就写一个性能测试报告。流程大概就是这样的。

14.3 你们性能观察哪些指标，大概指标范围是怎么样的。

对于指标这块，业务方面的指标主要有：并发数，90%用户的平均响应时间

错误率，吞吐量/吞吐率这些，例外还需要关注服务器资源的使用情况，像：CPU的使用率、内存的占有率，磁盘IO，网络。

我们那个项目当时只针对，登录，搜索查询，下订单，购物车相关接口，支付等业务做了些简单的并发，压测这块，指标大概是这样的：

单基准业务并发测试登录，注册，查询1s以内，下订单，购物车相关接口，支付2s以内，混合业务性能：5s以内

响应时间：登录，注册业务<2s之内查询，下订单，购物车，支付业务<3s

充值，提现，查看充值日志，查看提现日志业务查询标的，<3s

投标，申请借款<5s

错误率：0

吞吐量/吞吐率：200左右请求/sec

CPU：80%以内

内存：80%以内

I/O： %util<=80%，%nowait<=20%

%util: 磁盘一秒中有百分之多少的时间用于I/O操作，

% nowait：磁盘等待处理时间占比

带宽：<=系统带宽的30%，无丢包，无延迟，无阻塞

14.4 这个测试的环境配置，如转速度

租用的服务器，一台数据库服务器，一台后端服务器

8核16G网络带宽100M，2.5GHZ磁盘15000pm转数

14.5 性能测试计划有哪些内容

写过，主要是时间进度安排与工作安排，主要是环境，测试任务，测试需求，测试方法与策略，测试环境准备，测试通过的标准。

比如说原来我们一个项目性能测试时做了5天，那我们计划是，测试策略与用例编写一天，测试准备需要1天，测试执行2天，报告总结1天。

14.6 有没有写过性能测试报告，具体包括哪些内容

性能测试报告，需要每次 Jmeter压测完成的html报告的数据跟nmon工具监控的数据，整理出一份性能测试报告，性能测试报告，主要包含：

1，测试资源(环境，测试数据，表里面需要多少数据，测试工具)

2，测试设计(测试业务，测试类型，测试时间，并发用户数)

3，测试分析(每一个场景都需要分析)

4，测试结论(能不能上线，不上线的原因)

5，优化和建议

6，测试通过的标准，平均响应时间<5s，资源利用率<75%，事务失败率<5%

14.7 什么是内存泄漏，什么是内存溢出？

内存泄漏：

是指程序在申请内存后，无法释放已申请的内存空间，导致系统无法及时回收内存并且分配给其他进程使用。通常少次数的内存无法及时回收并不会到程序造成什么影响，但是如果在内存本身就比较少获取多次导致内存无法正常回收时，就会导致内存不够用，最终导致内存溢出。

内存溢出：OOM

指程序申请内存时，没有足够的内存供申请者使用1M实际要占用2M内存，

就说分配的内存不够，导致内存溢出

给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据
长期出现内存泄漏，导致系统内存越用越少，最终导致内存不够用，导致系统崩溃，出现OOM

14.8 吞吐量，吞吐率

吞吐量：KB

指在一次性能测试过程中网络上传输的数据量的总和(单位应该KB)也可以这样说，

在单次业务中，客户端与服务器端进行的数据交互总量；对交互式应用来说，吞吐量指标反映服务器承受的压力。

并不是吞吐量越高越高，一个服务器的性能，要从多个方面去考虑：

90%用户的平均响应时间、错误率、吞吐量/吞吐量、CPU、内存、磁盘I/O、网络的占用情况，

还有服务器的配置。

吞吐率：

吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量网络性能的重要指标。

12s 800M数

800 * 1024 / 12 = 66666 KB/sec

通常情况下，吞吐率用“字节数秒”来衡量，当然，也可以用“请求数/秒”来衡量;

14.9 吞吐量与吞吐率跟负载有什么关系?

吞吐量/率和负载之间的关系:

1、上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比;

2、平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动;

3、下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比;

总结：吞吐量/率干不过负载!!！

14.10 当你服务器满了之后，你们吞吐量和响应时间怎么变化的

吞吐量会所有下降，响应时间会变长

14.11 你们的TPS的指标是什么估算的?

假设一个系统的业务有登录、浏览帖子、发送新帖、回复帖子，访问高峰是上午10点，日访问高峰PV约5208(含登录1300、浏览2706、发帖526、回帖676)，系统响应时间要求小于3秒，试计算此系统的TPS以及并发数。

如果分析业务量的数据是以PV来统计的，我们需要把PV转化为TPS。

PV的统计一般可以通过监控埋点或者统计访问日志统计得出。

说到PV还有个特殊的情况，叫 PeakY，指一天中PV数达到的高峰PV值。

通过一些监控系统，也可以直观看到统计数据。

实际上一个PV即一次对服务器的客户请求，可能还包含了很多资源请求，比如图片、样式JS信息、文字等。而浏览器具有资源缓存功能，下次访问同样资源将不会再从远程服务器上下载，这大大加快了响应速度。如果我们使用代理服务器访问外网资源时，多数代理服务器也会缓存这些静态数据。也就是说浏览器与服务器之间的动态数据的Size会小于静态数据。

所以浏览器是否缓存了静态数据对性能测试影响明显。我们在做性能测试时，其中就有许多用户可能是新用户，在他们的浏览器上还没有缓存这些静态数据，为了更准确的模拟用户请求，我们有必要不缓存这些静态内容.所以性能测试中是否缓存访问的静态资源要根据业务情况而定。

本例中，我们把一个请求放在一个事务中来统计服务器的响应时间。这么说，一个PV即是一个事务(每秒的PV量并不直接等同于TPS，因为一次客户请求可能包含了很多资源请求。如果我们不关心页面刷新时请求资源的耗时，此时我们就把每秒PV数等同于TPS)，比如一个功能页面(浏览帖子)每秒会有10个PV，那么此功能的TPS即为10。

估算TPS：

业务量一般要取系统业务高峰的值，才能代表系统的实际处理能力，系统在10点的访问高峰PV约5208，那么这个时段的TPS = 5208/3600 ≈ 1.45吗?

答案是否定的，因为在一小时内的吞吐量未必是平均的。

如果我们采集到的业务量数据能够细分到每分钟，TPS就越准确。如果不能，可以按照二八原则。即80%的业务在20%的时间内完成，TPS=(5208*80%)/(3600*20%)≈5.8

估算并发数：

1、由TPS进行估算 2、由在线活动用户数估算 3、根据经验估算

方法1：由TPS进行估算

因为TPS=事务数/时间，假设所有的事务都来自不同的用户，那么并发数=事务数=TPS * 时间。

具体如下：

Vu(业务名称)=TPS(业务名称)*( Runtime+ ThinkTime)

其中，Vu(业务名称)表示此业务的虚拟用户数，即并发数。 RunTime是测试程序/脚本运行一次所消耗的时间，包括事务时间+非事务时间。 ThinkTime是模拟用户思考或者填写表单消耗的时间。

下面是发帖动作的测试脚本伪代码(T、TT、AT表示时间，单位为秒，AT一般都是非常小的，包含在事务时间中，可以忽略).Runtime=T1+...+T7; ThinkTime=TT1+TT2。

Enter login page (进入登录页面)Tl=0.2

ThinkTime (思考时间)TT1=3

Declare login trans action (声明登录事务)T2=3

Commat formm (提交登录表单)

Assertlogin (检资登录是否成功)AT1

Enter default page(进入登录成功后的默认页)T3=0.2

Sender topic

Enter topic list (进入论坛列表)T4=0.2

Enter new page for topic (选入新帖编辑页面)T5=0.2

ThinkTime (思考时间)TT2=3

Declare newTopic transaction (声明新帖事务)T6=3

Commit fom (提交新帖)

Assert commit (查发帖是否成功)AT2

Enter topic list (提交新帖后进入论坛列表)T7=0.2

业内一般把 Think Time设为3秒。测试需求中要求响应时间小于3秒，我们就以3秒为阀值

可得 Vu=TPS (RunTime + ThinkTime)=5.8*(T1+TT1+T2+T3+T4+T5+TT2+T6+T7)≈76

如果只计算事务时间，Vu=TPS*(T2+T3)=34.8≈35

可以看到两者之间的Vu数量相差巨大。由于一次迭代的时间会大于事务的响应时间，如果在估算时不把非事务消耗的时间加入进去，计算出来的12个并发用户在测试执行时很有可能无法达到TPS=5.8的目标。

由于我们计算Vu时，使用的是系统TPS(登录、浏览、发帖、回帖合计)，其中又以发帖业务消耗时间最长，所以计算出来的76个并发数实际上是系统业务的总并发数，需要按比例分配到各个业务。

业务名称	高峰业务量	TPS	并发数	响应时间	事务成功率
登录	1300	1.44	20	<3秒	>99%
浏览	2706	3.0	40	<3秒	>99%
发帖	526	0.58	7	<3秒	>99%
回帖	676	0.75	10	<3秒	>99%
合计	5208	5.8	77	-	-

方法2：在线活动用户数估算

在线用户数的预估可以采取20%的系统用户数.例如某个系统的系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考。

在线用户数和并发用户数又存在着关系，即：平均并发用户数为C=NLTL为在线时长，T为考核时长例如考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n*2/8

n为登录系统的用户数，L为登录的时常。例如一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户则为C=400*2/8

答：我们系统的TPS当时是根据PV值来计算的，就是通过查看系统访问日志来获取每个业务功能每天高峰期的PV值(也就是每天高峰期的时间段，有多少服务器的客户请求)，

当时的PV值大概在5000多

然后按照二八原则，即80%的业务在20%的时间内完成，TPS=(P80%)/(时间20%)≈5.6。算出来大概在5.6。

[具体的指标都是SE跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算方式，差不多是这样的……]

14.13 每人说一个项目接口，你设置多少并发

首先涉及到并发用户数可以从以下几个方面去做数据判断

1.系统用户数(注册用户数量)

2.在线用户数(平均每天大概有多少个用户要访问该系统，可以从系统日志从获得)

3.并发用户数(高峰期的时候的在线用户数量)

三者之间的关系

在线用户数的预估可以采取20%的系统用户数。例如某个系统在系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考
在线用户数和并发用户数又存在着关系。即：平均并发用户数为C=NUTL为在线时长，

T为考核时长例如考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n2/8

n为登录系统的用户数，L为登录的时常，例如一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户则为c=400*2/8

答：就拿登录接口来讲吧

我们的并发数是根据注册用户数量及每天在线用户数综合来估算的，我们系统当时注册用户数量大概是在70多万的样子，不过这里其实有一些僵尸用户，真正的用户大概在60%的样子，也就是差不多，46万多一点，通过查看系统访问日志，高峰期的时候每天在线数,用户数量大概差不多在52000多点吧，按52000估算，每个用户停留时间大概在20分钟左右，大概平均每天同时在线用户数量在2145多。其中登录业务的占比大概在10%的样子，同时在登录的大概80%的比例计算，登录接口大概设置的并发数在172多的样子，查询业务的占比大概在30%，查询接口大概设置的井发数在510的样子，下单业务大概占比在20%，下单接口的井发数设定在345的样子。

[具体的指标都是SE跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算方式，差不多是这样的...]

14.14 你们吞吐量是多少，响应时间是多少，你设置了多少井发?

查询：吞吐量大概在36/sec响应时间<3s，设置的并发数500个并发数。

下单：吞吐量大根在25.6/sec响应时间<3s，设置的并发数350个并发。

14.15 做井发你们一般cpu和内存是多少?

cpu大概在60%多点，内存大概占比在65%的样子。

14.16 有没有做过稳定性测试

部分接口有做过稳定性测试。具体怎么做的?

稳定性测试主要就是看某个业务在高并发情况下是否能持续稳定运行嘛，当时大部分的核心业务都有做过稳定性的，这个需是把并发数设置为峰值，然后循环次数设置为永远，例外要开启调度器，调度器中的持续时间设定为3600秒，让它持续压测1个小时。看下接口的各项性能指标的变化，是否在预期的指标范围之内。

14.17 5000个人抢购，只能50个人能抢到，你怎么设计并发数的

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为4000

14.18 微信群里面发送红包，5000个人群，只能3000个人能抢到，你怎么设计并发数的峰值

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为4000

14.19 20并发40次循环怎么做？

线程数设置20个，循环次数40

14.20 我想从200慢慢加载到300，到400怎么做

这个需要用到自定义线程组，自定义线程组最大的好处就在于做压测的时候，可以设置一些复杂的业务场景，具体设置的话，就是.....

14.21 需要插入500条数据，你怎么插入

1、使用存储过程来实现

2、可以通过 JMeter来实现，调用注册接口，线程数设置为500，账号，密码可以通过 JMeter中的随机函数 randomString()，random()函数结合计数器来实现。

14.22 响应超时，你是怎么定位的

这里一般我会采用排查发，首先考虑软件优化问题，之后考虑硬件问题，思路大概是这样的

1、首先考虑中间件(tomcat，Apache的连接数的问题)，可以尝试增加连接数，看是否变化。

2、例外还有就是数据库的连接数问可题，也可以尝试增加，看是否有变化。

3、要不就是看数据库的访问效率问题，这里要考虑数据库的操作是否添加索引，如果没有添加索引，可以让开发优化下数据库的访问速度，添加索引，或者优化sql语句。

4、再一个就可以尝试考虑后台代码的架构设计是否合理，代码算法是否足够优化。

5、如果以上问题都不能解决，那么只能考虑增加服务器的CPU内存，或者增加网络带宽，看响应时间是否可以得到优化。

大概的思路差不多就是这样的吧。

14.23 压测返回数据报错，你怎么去定位的

1、如果是所有请求的数据报错，那肯定是脚本问题，认真检查脚本参数。

2、如果只是部分请求报错，那估计是性能可题了。

14.24 你理解的性能调优是什么?

响应时间过长(排除法) -用户体验不好

1，网络情况(提升带宽)

2，服务器资源情况

3，中间件类型

4，中间件的连接数

5，代码质量问题

6，数据库类型mysql--Redis

7，数据库连接数

8，sql语句执行时间

show full PROCESSLIST 查看哪些sql语句运行比慢

1、看表是否建立索引

2、运行sql语句是否需要sq优化

9，索引命中率

低于0.1%比较好，低于0.01%分配比校多，适当减少缓存空间大小

show GLOBAL STATUS like "key——read%"

Key_reads=568

Key_read_requests=1329114

Key_cache_miss_rate=key_reads/key_read_requests=0.000427=0.04%

show VARIABLES like "key_buffer_size" #查看缓存空间大小

set GLOBAL key_buffer_size=8000000 #设置缓存空间大小

10，sleep过多

show GLOBAL VARIABLES like "wait timeout%"

show GLOBAL VARIABLES like "interactive timeout%"

set GLOBAL interactive_timeout= 30

set GLOBAL wait_timeout=30

11，临时表空间大小

性能排优一些方面：

1，排除法

2，很多问题，都是同一个问题导致，需要一个个去排除优化，解决

资源使用率不足：(系统薄弱的位置)

1，用户量较少

2，网络问题

3，中间件连接数不够

4，代码质量问题

5，数据库问题

资源使用率过高：(系统会崩溃)

1，用户量比较大

2，中间件连接数太大

3，代码质量问题

4，数据库问题

14.25 如果要做万并发，你怎么做

那我们就需要考虑分布式压测，那需要准备几台测试机，

master机器要设置。。。。

奴隶机要设置。。。。。

也可以租用云测平台进行测试

14.26 如果用户并发要慢慢加载，你怎么设置的

设置并发数的时候，我们会设置启动时间，比如说设置50个并发用户数就是50个线程组，

启动时间会设置成10秒，让用户慢慢启动起来

14.27 并发用户数跟响应时间与吞吐的关系

1，并发用户数越多，响应时间越长

2，并发用户数越多，吞吐量会一直，增加，增加到一个临界点(系统瓶颈后)，不再增加，有少许的回落

文章到这里就结束了，各位铁汁如果有什么觉得不对的可以发在评论区咱们来讨论哈，
听说关注我并三连的铁汁都已经升职加薪暴富了哦！！！！

面经-软件测试面试常见面试题全套合集系列unittest框架面试题 pytest框架面试题 性能测试面试题 4-4

前言：

十二、 Unittest框架

12.1 你们自动化用例是怎么管理的?

12.2 Web UI自动化都用到过哪些库?

12.3 Unittest框架的原理?

12.4 Unittest框架有哪些组件?