在测试执行过程当中，并不清楚现在测试到的结果到底能不能满足活动的需求，本次需求涉及到的模块和接口也不清楚，这种性能测试方式，就是没有做性能测试目标分析，虽然说做了性能测试，但是基本是无效的性能测试，因为：没有做目标分析的性能测试，会与真实的活动场景相差甚远
例如在使用前的测试和使用中的实际情况完全不一样，原因因为一个低访问量的接口没有纳入测试范围，性能测试目标是性能测试的重要先决条件指定目标可以确定范围内需要达到的测试结果，指定目标后才能对本次性能测试的核心目标有清晰的认知，并指导你做后期的测试活动，包括测试所需要的资源以及测试的停止条件等，在回答如何指定性能测试指标之前，要搞清楚我们衡量性能测试指标对于什么，TPS,报错率等需要有深入的了解，不仅仅知道各自代表的含义，还要知道是如何制定出来的
第一个衡量指标TPS，很多人都说是并发，并发是指同一时间节点发生的事情，但同一时间节点并不是一个标准的度量，也不是性能测试直接测试来的结果，性能测试往往是通过在工具中增加虚拟用户数得到的接口每秒调用量去衡量，在实际生产中，不管是网关还是服务，通常都是记录一定时间内的访问请求次数，所以在业内，性能测试往往以TPS作为最重要的度量指标，因为它具有可度量性和通用性的特质，可度量行是指TPS是真实、客观且明确的衡量指标，通用性指无论在运维角度还是测试角度，TPS都可以达成一致的定义
响应时间和用户体验密切相关，一个请求从客户端发出，到返回客户端的时间作为响应时间，在实际工作中，会以TPS的量级来限制响应时间必须在多久之内，
从响应时间过程图可以看出，从最左侧的客户端到最右侧的数据持久化，在返回到客户端，这样一次完整的过程就是一次完整的请求响应时间，这样的响应时间在正常情况下是这样的，在有了一定的性能测试实践之后，会发现这样的过程不是绝对的，比如有的业务在第一次请求数据库之后，应用层会把本地缓存放在应用服务器上，也就是接下来的缓存有效期内，不会去数据库取数据，而是在应用层取数据后会直接返回，所以响应实践会比第一次低很多，这也是随着性能测试的进行，响应时间变低的原因之一
报错率的计算方式是在统计时间范围内不符合返回期望的请求数/总共的请求数，在测试过程中，这一指标不符合期望的话，一般体现在对结果的校验上，一般分为三个层面去校验
1、状态码的校验
2、业务层面的校验（业务返回数据的正确性）
3、数据库校验（不建议在性能测试过程中校验，会影响性能，在测试后，做统计数据数量和状态）
以简单的登陆为例：
如果用户名密码不匹配则直接返回错误报文，不需要走正确流程的逻辑校验和数据库操作，存在很大的性能差别
列举了最重要的三个指标TPS、响应时间和报错率，那我们如何定制测试目标呢？有人说根据28原则，老板说我们百万日活，80%的用户在20%的时间里去访问，响应时间根据业内的258来制定；还有人说竞品，业务定；实际上没有性能测试可以参考的有效信息，基本可以判断一个同学是否做过性能测试，那么说了半天，如何做呢？一般可以分为4种。
以衡量系统处理能力为核心目标的性能测试一般是性能测试的主要目标，用来评估当前系统的处理能力和容量规划，评估这个目标最重要的是对数据的客观分析，那我们需要什么样的数据呢？对于每个接口都会有访问统计，这是目前业内比较常见的，也是衡量接口访问能力最准确的指标之一，一般会有自己的监控工具或者一些开源或商业工具，有了工具后，我们要从哪些维度去统计数据呢，通常我们会通过时间维度和服务维度来统计
按照经验，我们一般会考虑大于当天的访问量来测试，当从分析的角度，一般前后半个月的时间都会考虑在测试范围内，首先我们需要根据大出前后哪些天数的访问量是比较高的，以天为单位，根据经验选择合适的时间范围，对最高峰和次高峰进行分析
当我们选了某一天，在以小时为维度进行分析，发现晚上的访问量大于白天，最高是晚上几点到几点，这样一来获取到我们在时间上所需要的数据，然后是服务维度
什么是服务维度，以目前比较流行的电商微服务架构为例，会做微服务的拆分
网关是请求进入应用层的第一个入口，也是统计网站入口访问量的方式之一，当我们请求通过网关之后，下发到各个应用服务，我们会按照确定的时间节点统计各个服务的访问量数据，完成服务级访问量的统计，应该继续按照时间维度统计服务下接口的访问数据，你可以看到每个接口的调用比例都不一样，很多同学使用jmeter写性能测试脚本时，是用接口串联的方式进行，比如从登陆到浏览商品到添加购物车这样的添加方式，也就默认了用户登陆后就得浏览商品之后就得到购物车，这是典型的自动化测试思维,在性能中不存在这这样的同等分布，一般来说在同一个时间节点都会有不同的比例，比如早8点有1w次登陆请求，3w次浏览商品的请求，而下午就会产生变化，而下午这个数据又会产生变化，所以要根据服务入口，把接口调用统计起来，结合时间维度和服务维度做出性能测试的常见模型，说到这里会出现两个问题，1、这么多时间节点，或产生多个比例模型，每个比例模型都要测试吗？答案是确实会产生多个比例模型，而且每个都需要测试，因为线上存在这样的访问趋势，那我们应该覆盖到；2、上边那么多步骤，多少时间干完得？流量复制能一键解决吗，其实流量复制是不能解决指标制定问题的，并且在落地过程中还会花费大量时间成本，所以关于目标的制定和分析需要一步步的进行，花费的成本难以避免，未来线上的访问趋势，只可能覆盖，并不能完全预测到，
一个系统刚刚上线，用户的访问量不会很高，这时候我们会更关心系统的健壮性，例如内存泄漏，并发死锁、超卖等，而且这些测试不需要在生产环境进行，可以提早的发现问题
性能测试场景的稳定性至少包含两个方面
1、正确率
这个不一定是在高并发下完成，但是我们要保证业务在长时间的运行情况下正确率依然在99.99999%以上
2、处理能力
这一方面应该选用性能测试场景中的混合场景来执行，我们要观察处理能力是否稳定，会不会出现处理能力下滑的情况；接口之间的比例是否稳定，会不会随着时间的进行，
刚刚例举的是以业务接口为测试目标，其实在实际压测过程中也存在中间件甚至硬件的性能测试，这部分性能测试基本上是用来判断当前的环境配置的节点数，以及配置所能达到的最大处理能力，为全链路性能测试提供数据支撑（Nginx、Kafka、EMQTT）
在性能测试领域最直接的指标是TPS、 响应时间和报错率，三者相互分析不能单独分析
我们要熟悉指定的方法，一切以数据作为基础，拒接靠感觉排版
分析的颗粒度越细越好
