|
一、了解性能需求 PS：从我个人的了解来看，对大部分测试人员来说，遇到的性能需求大体都是这种范围不明确，指标不清楚的性能需求，这个时候就要求我们从需求入手，了解项目的具体性能需求和典型场景。 下面例子作参考： 1、业务场景： 问卷调查的功能模块：然后产品和业务会不定时通过前端界面去根据筛选条件查询相关问卷问题的答案明细，但是觉得很慢，让测试这边给出一个指标。 2、系统架构： MySQL数据库，所有问卷问题相关的数据都存储在同一张表，单台服务器，无缓存，通过一个查询接口去查询返回数据。 3、数据量： 每天大概新增3000张问卷调查，每张问卷30个问题，每个问题下面还有具体的答案，答案的数据类型、大小不清楚。 二、测试场景建模与分析 1、场景建模 和产品业务沟通，明确他们的操作场景，比如查询的条件（时间范围、问卷类型、分数范围、用户类型等），操作时间（具体到每天哪个时间段有多少人进行这些操作）。 2、确定指标 明确了业务场景后，确认不同的操作下，用户（这里是产品和业务人员）的可接受值（比如每天早晨9:00-9:10，100个人进行查询操作，查询条件是最近一周A类型用户的B类型问卷，分数在80分以上）， 可接受的最大响应时间不超过5S。 三、设计与执行性能测试 确认测试范围和具体的性能指标后，接下来就需要进行测试方案设计、测试用例设计等一系列的计划了，这个阶段是最耗费时间也是最麻烦的。 1、环境确认与搭建 首先需要确认测试的执行环境，是生产、UAT还是独立的测试环境。测试环境对测试结果的影响是很大的，大体如下： 生产：在执行测试的过程不能对其他用户访问造成影响（时间选择很重要），测试数据污染要解决（数据隔离：线程标记、用户白名单、挡板、mock对象、测试数据落入影子库）； UAT：作为验收环境，一般来说数据的准确性和系统版本都是最新和相对稳定的，但要考虑对其他业务的影响，理由同上； 测试：数据预埋、基础数据准备、测试数据准备、每次执行迭代后的数据初始化、服务器配置和生产是否可以等量代换等； 2、脚本开发 上面的工作做完之后，你需要考虑测试执行工具和脚本开发的工作。需要做的事情如下： ①、和开发沟通，获取业务功能对应的接口文档（如果没有，想办法），参数字段的含义，对应的数据库表字段，造成的影响； ②、和运维沟通，确确认服务器的部署，配置（这里可能需要进行基准测试和配置测试）； ③、和DBA沟通，确认测试数据预埋、基础数据准备、迭代后的数据初始化工作； ④、测试人员本身，需要准备测试数据，开发测试脚本，进行脚本调试，执行和监控分析等工作； 3、数据准备 ①、主数据准备：主数据包括系统正常运行时需要的配置参数及基础设置等数据； ②、采取一定的数据制作方法：如使用工具、sql数据库存取过程来构造数据，当然也可以使用脚本构造数据。 4、执行测试并监控 执行测试一般就是跑压测脚本，并且观测各项压测指标 ①、监控系统资源占用：CPU 内存 硬盘 JVM 等 ②、监控应用性能状态：SQL慢查询 Tomcat连接数 线程池状态等 四、分析结果并产出测试报告 ①、分析过程是要结合需求来分析的，首先观测各种性能指标，例如当前例子，我们可能会发现某个查询进程响应时间很长，sql查询很慢，和开发人员要沟通找寻问题出现在哪里，代码可以优化，还是优化连接池配置等 ②将测试结果汇总成报告形式，提交给干系人 五、回归问题本身 回到问题本身，说说我对这个性能需求的一些优化建议吧，仅供参考： 1、数据库优化 问题点：从上面描述的情况来看，每天产生的数据大概有10W+条，且只有一张表存储； 解决方案：分库分表，表可以拆分为问卷主表、问卷对应的问题表、问题对应的答案明细表等，长期来说数据量不小，可以考虑分库，主从分离等，查询添加索引等方法。 2、处理逻辑优化 问题点：一次性查询的数据过多，导致前端展示较慢； 解决方案：查询结果分批次展示（比如有100W条数据，分为100个批次，每个批次10000条数据）。 3、存储优化 问题点：没有缓存，直接从DB单表读取，容易造成超时和表锁； 解决方案：将数据放入缓存服务器（比如Redis），设定查询次数或者有效时间，多级缓存，提高缓存命中，防止缓存穿透和同时失效带来的瞬间DB压力。 4、业务优化 问题点：多人短时间内查询大量数据，对服务造成巨大压力； 解决方案：和产品业务沟通，让查询操作时间在业务平缓期，拉长查询操作的时间线等。 5、服务优化 问题点：单台服务器； 解决方案：做服务集群和负载均衡，增加监控，设定阈值，超过阈值则临时增加新的服务器，分流。 |
|
|
来自： 昵称11935121 > 《未命名》
