1.性能测试概念
作者：互联网
性能测试概念
我们经常看到的性能测试概念，有人或称之为性能策略，或称之为性能方法，或称之为性能场景分类
大概可以看到性能测试、负载测试、压力测试、强度测试等一堆专有名词的解释
针对这些概念的一个感觉很乱，延伸出了这么多的概念，并且概念之间的界限又非常模糊
性能测试应该是针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，
分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。
性能测试需要指标
如果没有指标，老板只说一句，系统压死为止。听起来很儿戏，但这样的场景不在少数。
如果把系统压死也算是一种指标。至于你用什么手段把系统“压死”，那就是实现的问题了。你可以采用很多种手段
指标 这个定义来说，理论上合理的，并且应该有的指标是：时间指标、容量指标和资源利用率指标。
性能测试需要有模型
模型是什么？它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。
比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，
哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。
随着互联网中零售业、云基础架构的全面发展，有些企业直接在线上导流来做性能测试，
这种思路上的转变来源于架构的发展及行业的真实需要。
但这并不能说明性能测试不需要模型了，因为这个模型已经从生产流量中导过来了
性能测试也要选择适合自己系统业务逻辑的方式，用最低的成本、最快的时间来做事情
性能测试要有方案
方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险
建议用项目管理工具单独画测试计划，比如用 Project 或 OmniPlan 之类的工具。
这是因为在方案中，写测试计划，基本上只能写一个里程碑，再细化一点，就是在里面再加几个大阶段的条目。
但是用项目管理工具做计划就不同了，它不仅可以细分条目，还能跟踪各个工作的动态进度，可以设置前后依赖关系，填入资源和成本以便计算项目偏差
性能测试中要有监控
这个部分的监控，要有分层、分段的能力，要有全局监控、定向监控的能力
性能测试要有预定的条件
这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。
要是展开来说，在场景执行之前，这些条件应该是确定的。有人说，我们压力中也会动态扩展。
但是动态扩展的条件或者判断条件，也是有确定的策略的，比如说，我们判断 CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时，就做动态扩展。
这些也是预定的条件。关于这一点，如果对软硬件资源、测试数据和执行策略分不清楚，甚至都不明白为什么要几分钟加几个线程。在这种情况之下，就不能指望这个场景是有效的了。
性能测试中要有场景
“性能场景”这个词在性能测试中占据着举足轻重的地位
对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，
执行性能脚本，同时 观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期
性能场景也要有分类
1.基准性能场景：这里要做的是单交易的容量，为混合容量做准备
几个线程跑三五遍脚本不叫基准测试，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类
2.容量性能场景：这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个
3.稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。
在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），
而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感
4.异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。这个异常的定义是很宽泛的
5.测试场景不等同于用例:如果只是叫法不同，是可以的，关键是内容也出现了很大的偏差，
这个偏差就是，把用例限定在了描述测试脚本和测试数据上，
并没有描述需要实时的判断和动态的分析。这就严重影响了下一个概念：性能结果
性能测试中要有分析调优
需不需要在性能测试项目中调优，或者说是不是性能测试工程师做调优，人们有不同的争论。
从性能市场的整体状态来看，在性能测试工程师中，可以做瓶颈判断、性能分析、优化的人并不多，
所以很多其他职位上的人对性能测试的定位也就是性能验证，并不包括调优的部分。
于是有很多性能项目都定义在一两周之内。这类项目基本上也就是个性能验证，并不能称之为完整的性能项目。
而加入了调优部分之后，性能项目就会变得复杂。对于大部分团队来说，分析瓶颈都可能需要很长时间，这里会涉及到相关性分析、趋势分析、证据链查找等等手段
性能项目分为如下几类：
- 新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。
- 旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。
- 新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好
性能团队的职责定位有如下几种:
- 性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。
- 性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。
- 性能测试 + 分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。
性能测试肯定要有结果报告
有了前面监控的定义，有了场景执行的过程，产生的数据就要整理到结果报告中
这个文档工作也是很重要的，是体现性能团队是否专业的一个重要方面。并不是整理一个 Word，美化一下格式就可以了。
测试报告是需要汇报或者归档的，大部分老板或者上司关心的是测试的结果，而不是用了多少人，花了多少时间这些没有意义的数字。
我们更应该在报告中写上调优前后的 TPS、响应时间以及资源对比图，性能测试需要对系统上线后的性能负责
总结
在性能测试的概念中，性能指标、性能模型、性能场景、性能监控、性能实施、性能报告，这些既是概念中的关键词，也可以说是性能测试的方法和流程
这些概念我们在实际的工作中，都是非常重要的。因为它们要抹平沟通的误解。让不同层级，不同角色的人，可以在同样的知识背景下沟通，
也可以让做事情的人有清晰的逻辑思路，同时对同行间的交流，也有正向的促进作用
标签：场景,容量,性能,系统,概念,调优,测试 来源： https://www.cnblogs.com/Mickey-7/p/16356734.html