性能测试针对系统的性能指标,建立性能测试模型,制定性能测试方案,制定监控策略,在场景条件之下执行性能场景,分析判断性能瓶颈并调优,最终得出性能结果来评估系统的性能指标是否满足既定值。
时间指标、容量指标和资源利用率指标。
模型是什么?它是真实场景的抽象,可以告诉性能测试人员,业务模型是什么样子。比如说,我们有 100 种业务,但不是每个业务都需要有并发量,可能只有 50 个业务有,那就要把这些有并发的业务统计出来,哪个业务并发多,哪个业务并发少,做压力时就要控制好这样的比例。这种做法需要的数据通常都是从生产环境中的数据中统计来的,很多在线上不敢直接压测的企业都是这样做的。
而随着互联网中零售业、云基础架构的全面发展,有些企业直接在线上导流来做性能测试,这种思路上的转变来源于架构的发展及行业的真实需要。但这并不能说明性能测试不需要模型了,因为这个模型已经从生产流量中导过来了。这一点,还是需要你认清的。
方案规定的内容中有几个关键点,分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。
监控范围很多,这个后面写
有人说,我们压力中也会动态扩展。没问题,但是动态扩展的条件或者判断条件,也是有确定的策略的,比如说,我们判断 CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时,就做动态扩展。这些也是预定的条件。
这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。要是展开来说,在场景执行之前,这些条件应该是确定的。
对性能场景中的“场景”比较正宗的描述是:在既定的环境(包括动态扩展等策略)、既定的数据(包括场景执行中的数据变化)、既定的执行策略、既定的监控之下,执行性能脚本,同时观察系统各层级的性能状态参数变化,并实时判断分析场景是否符合预期。
从性能市场的整体状态来看,在性能测试工程师中,可以做瓶颈判断、性能分析、优化的人并不多,所以很多其他职位上的人对性能测试的定位也就是性能验证,并不包括调优的部分。于是有很多性能项目都定义在一两周之内。这类项目基本上也就是个性能验证,并不能称之为完整的性能项目。而加入了调优部分之后,性能项目就会变得复杂。对于大部分团队来说,分析瓶颈都可能需要很长时间,这里会涉及到相关性分析、趋势分析、证据链查找等等手段。
对性能团队的职责定位有如下几种。
性能结果如何来定义呢?有了前面监控的定义,有了场景执行的过程,产生的数据就要整理到结果报告中了。这个文档工作也是很重要的,是体现性能团队是否专业的一个重要方面。并不是整理一个 Word,美化一下格式就可以了。测试报告是需要汇报或者归档的。
我们要知道,大部分老板或者上司关心的是测试的结果,而不是用了多少人,花了多少时间这些没有意义的数字。我们更应该在报告中写上调优前后的 TPS、响应时间以及资源对比图。
在性能测试的概念中,性能指标、性能模型、性能场景、性能监控、性能实施、性能报告,这些既是概念中的关键词,也可以说是性能测试的方法和流程。
而这些概念我们在实际的工作中,都是非常重要的。因为它们要抹平沟通的误解。让不同层级,不同角色的人,可以在同样的知识背景下沟通,也可以让做事情的人有清晰的逻辑思路,同时对同行间的交流,也有正向的促进作用。
原文:https://www.cnblogs.com/siguadd/p/14850352.html