Ces222的博客

python如何进行性能测试呢？其实原理就是对于接口进行加线程，打个比方就是当你有一个电梯，你同时可以搭载多少个人坐电梯那这个人数就是这部电梯的其中一个性能指标，那么对于接口来说每秒钟能有多少人成功发起请求后得到成功的响应就是性能测试的一个指标我们在做性能测试主要去看的就是以上四点：错误率，响应时间，tps和rps当我们使用Python去构建自动化测试框架时，我们用Locust来对接口进行压测，具体写法如下：安装好后我们可以通过命令：locust --version查看其安装的版本。

1、cpu指标要求建议CPU指标如下：对于每一个CPU来说运行队列不要超过3，例如，如果是双核CPU就不要超过6；如果CPU在满负荷运行，应该符合下列分布：User Time：65%～70%，us过大，说明有用户进程占用很多cpu时间，需要进一步的分析其它软硬件因素。System Time：30%～35%，sy过大，说明系统管理方面花了很多时间，说明该系统中某个子系统产生了瓶颈，需要进一步分析其它软硬件因素。

1、确认磁盘 I/O 存在性能问题对于随机负载，当遇到余下情况时，我们那通常认为存在 I/O 性能问题：平均读时间大于 15ms；在具有写 cache 的条件下，平均写时间大于 2.5ms；对于顺序负载，当遇到余下情况时，我们那通常认为存在 I/O 性能问题：在一个磁盘上有两个连续的 I/O 流；吞吐量不足（即远远小于磁盘 I/O 带宽）；

性能测试-内存瓶颈1、查看利用率(free)used：已使用多大。free：可用有多少。Shared：多个进程共享的内存总额。Buffers/cached：磁盘缓存的大小。所以空闲内存=free+buffers+cached=total-used2、查看页交换，swap交换（pi、po、so、si），磁盘IO(vmstat)si：每秒从交换区写到内存的大小so：每秒写入交换区的内存大小page in：分页(Page)从磁盘重新回到内存的过程被称作Page-In。

突然有一天！领导说：“小刘，今天把996福报系统压一下，下班前把压测报告发我邮箱。啥？压测？今天？报告？怎么压？怎么写？从来没做过啊，心里一万匹草泥马奔跑而过，别说996了，估计明天都下不了班了；好歹也像功能测试，给个压测需求吧！没法，你遇到了一个不懂性能测试的领导；一个完整的项目是怎么做性能测试的1、前期准备性能测试虽然是核心功能稳定后才开始压测，但是在需求阶段就应该参与，这样可以深入了解系统业务、重要功能的业务逻辑，为后续做准备。2、性能需求分析（评审）评审时，要明确性能测试范围、目标。

100个真实的用户1、一个账号模拟100虚拟用户同时登录和100账号同时登录区别：1个账号100个人用，同时登录；100个人100个账号，同时登录；相同：两个都是100人同时登录，具体看项目需求；2、账号来源利用“注册”或“创建”账号接口，创建100个用户；“查询”接口，保存100个账号的账号、密码到一个文件；3、提取100个账号、密码的文件Jmeter脚本整体布局。

什么是压力测试？压力测试的基本思路：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行软件压力测试的资源包括内部内存、CPU可用性、磁盘空间和网络带宽。压力测试涵盖，性能测试，负载测试，并发测试等等，这些测试点常常交织耦合在一起。压力测试存在哪些问题？操作系统默认安装，在未做任何优化的情况下实施压力测试。1、未考虑磁盘IO对软件的影响2、未考虑网络带宽对软件的影响3、网络软件测试，没有考虑到TCP特点4、各种超时参数优化。

业务量是不带时间单位。我们提到业务量的时候，一定会加一个时间单位。比如说，每天的业务量是 100 万笔，每年的业务量是 1 亿笔，等等。吞吐量是自带时间单位的。吞吐量是单位时间内处理的业务数量。业务量和吞吐量的关系那么问题来了，我们做性能测试的时候，用哪个词呢？业务量 or 吞吐量？事实上，这两个词我们都用。因为他们的内涵不同。业务部门的目标里，往往是一年业务量多少，一天业务量多少。而这些目标并不能勾勒出性能测试目标。因为性能测试要的是每秒的业务量有多少。

稳定性测试的要点1、长时间的以正常的业务负载进行运行（最低为用户实际使用时的负载量，如果用户实际负载量低于最优负载量，也可以使用最优负载量）。2、稳定性的测试数据（用户实际使用负载量）来源于运营数据。3、稳定性测试时，需要针对不同的业务操作，并且模拟不通的用户，进行长时间的稳定性测试（并行执行所有脚本，因为要模拟实际用户使用场景，不同的用户在线所做的动作肯定不一致）。性能测试的监控的关键指标1、系统指标：与用户场景和需求相关的指标用户并发数：某一物理时刻同时向系统提交请求的用户数。

性能测试中最容易被误解的部分之一就是负载测试。大多数人认为所有性能测试就是负载测试，但这是不准确的。有许多类型的测试组成性能测试。负载测试是许多并发用户运行同一程序，以查看系统基础结构是否在不影响功能或性能的情况下处理了负载。以下是准备进行负载测试时要考虑的N种策略。针对正确的测试量首先，不要在没有实际需要的情况下进行大规模测试。无需向软件施加超出实际预期的压力。当然产生环境比预期拥有更高的流量负载始终是一件好事，但要保持现实和高效，应该专注于评估应用程序在生产中将遇到的正确工作负载。

误区1：应用程序必须通过功能测试后才可以测试性能应该尽早的进行性能测试。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起后，才能检查一个系统的真正性能。性能测试从早开始，完成一个小模块，对小模块的接口进行性能测试，一般耗费资源很少，但可以防止问题在项目最后出现，花费很大的精力去修改。误区2：软件性能测试要向功能测试一样，覆盖到所有功能性能测试的主要目的是为了系统调优。不可能对所有的系统功能都进行性能测试。

在实际业务场景中，很多业务都需要先登录才能正常使用。在做接口性能测试的时候，需要测试登录后才能访问的接口肯定是无法避免的。那么，我们怎么才能完成先登录后发出请求的性能脚本呢？思路1、发出登录请求2、提取响应的认证内容3、后面的请求引用认证内容提出问题做性能测试，是模拟多个虚拟用户实现并发的，那我们的登录接口也需要重复发起吗？可以类比一个场景做UI自动化的时候肯定也需要登录的，一般我们会将登录放到全局前置来操作，所以整个测试流程下来只需要登录一次。关键点。

性能测试简而言之就是模仿用户对一个系统进行大批量的操作，得出系统各项性能指标和性能瓶颈，并从中发现存在的问题，通过多方协助调优的过程。而web端的性能测试应该注意的指标有：用户操作的响应时间、系统的吞吐量（TPS）、系统的硬件资源情况（CPU、硬盘、磁盘）、网络资源占用情况等。性能测试用例主要分为预期目标用户测试、用户并发测试、疲劳强度与大数据量测试、网络性能测试、服务器性能测试五大部分。具体编写用例时要根据实际情况去进行，遵守低成本、策略为中心，裁减、完善模型，具体化等原则。

monkey是一个命令，是发送伪随机用户事件的。这里特别要说明，既然是随机事件也就是说你没法控制ta点击哪里。如果你想控制那就去修改源码。monkey需要安装（好多人问这个问题）？其实都带着呢。。。。只需要通过adb就可以和手机进行交互了adb又是啥？其实就是电脑和手机建立通讯的桥梁。上面说的所有的一切只需要安装并配置好Android sdk就ok了！

压力测试只有在服务器处于高压状态时，才能真正反映各种设置暴露出来的问题。现在很多压力测试都需要自动化测试工具的帮助。通过测试工具执行测试命令，分析网站在用户增加情况下的承载能力。例如，可以使用程序对服务器进行访问压力测试。压力测试解决方案1、确定测试业务范围和场景；首先确定压力测试类别、测试数据库、测试用例设计等。压力测试一般对环境要求比较高，明确需要用到的技术工具和测试场景，准备好基础的软硬件环境。2、存量数据规模；制作足够的库存数据进行测试。3、确定运营用户数量、时间要求等；

性能测试用户概念系统用户数：指所有可能访问这套系统的用户数，也叫系统的全部用户数。在线用户数：指同时访问这套系统的用户数量。并发用户数：在一个时间切面上同时向这套系统发起请求的用户数。糟糕性能系统设计阶段缺少性能方面的考虑（考虑整体系统集成后的性能）;直到最后一刻才进行性能测试（性能测试越早越好）;对系统的容量或规模没有足够的考虑（最终用户的规模和分布）;对性能峰值预期偏低;性能测试还不规范，没有有效的方案参考或实施;没有使用性能测试自动化工具。

性能测试需求分析阶段根据用户使用习惯和实际业务的性能需求，生成性能测试需求调查表根据性能测试需求及系统重要业务调研，选取典型业务了解业务模型及业务架构性能测试设计阶段编写性能测试用例结合性能测试用例录制/修改/完善测试执行脚本结合用户应用场景设计性能测试执行场景测试环境部署完毕系统安装并调试成功，并经过相应优化，初始数据量满足测试要求应用软件安装成功，待测试版本已正确部署测试客户端机器到位，系统软件安装完毕网络配置正确，连接通畅，可以满足压力测试需求。

性能测试成熟度级别救火（Firefighting）：应用程序发布前很少或从来没有进行过性能测试的情况。所有性能缺陷（100%）都在生产环境上发现并解决。性能验证（Performance Validation）：公司为性能测试单独安排了一段时间，而不是在产品的后期才开始进行性能测试。因此，在研发过程中，仍然有相当多的性能缺陷被发现（ 30% ）。这是当前绝大多数公司的做法。性能驱动（Performance Driven）：在应用程序生命周期中的每一阶段都考虑了性能。

首先了解一个系统的架构，白各服务器之间是如何交互工作、系统的数据流向、系统的压力点，从而确定性能测试需求和指标，即那些功能需要考虑压力,能承担的压力是多大。比如一个购物网站，最典型的登陆功能、提交订单功能需要支持多少个用户并发，每个并发用户在几秒之完成操作，系统长时间在压力状态下的稳定性。性能标准关于性能好坏的行业标准，没有这样的指导标准存在。不过，业内倒有一个约定俗成的标准，即响应时间的临界点为2秒，尤其对于 B/S 应用。糟糕性能原因分析。

Locust中有两个非常重要的类：Locust类和Taskset类。了解这两个类的使用对于Locust工具的使用是非常有必要的。没有人会为了你的未来买单，你要么努力向上爬，要么烂在社会最底层的泥淖里，这就是生活。不是井里没有水，而是挖的不够深；不是成功来得慢，而是放弃速度快。得到一件东西需要智慧，放弃一样东西则需要勇气！每一天的努力，只是为了让远方变得更近一些。再苦再累，只要坚持往前走，属于你的风景终会出现。

Locust是使用Python开发的支持分布式的一款开源压力测试工具，Locust在测试时，会产生大量的用户对系统进行访问，每个用户的行为是通过Python代码控制的，并且整个测试过程可以在Web的UI界面实时观察测试数据。它用于对网站（或其他系统）进行负载测试，并确定系统可以处理多少并发用户。Locust完全基于事件，因此可以在一台计算机上支持数千个并发用户。Locust的特点：1、使用简单的python语言编写测试脚本，非常简单轻便，不需要笨重的UI和XML代码；