在《负载测试应由开发完成 - Jeff Tian的文章 - 知乎 》中，介绍了如何使用 k6 进行负载测试，掌握了工具的使用方法之后，还需要知道怎么查看和分析结果，即需要找一些指标来衡量系统在负载测试中的表现。为了方便记忆，不妨将这些指标的英文首字母连起来，当做单词来记忆。它们分别是： RED 和 USE。
RED
Rate 请求速率
Error 错误率
Duration 时延
USE
USE 指标用来监控系统的资源消耗情况，比如数据库、缓存等等。
Utilisation 使用率
被使用的资源占所有资源的百分比。100% 意味着系统不能再接受额外的工作请求了。
Saturation 饱和率
指资源额外的工作量超出其能力范围的程度；通常可以用队列的排队长度来衡量。
Errors 错误数
资源侧的错误数量。
负载测试小提示
负载测试通过大量的 HTTP 请求打向系统，来尝试暴露一些平时发现不了的问题。为了事后分析方便，建议：
特殊的 HTTP 标头
通过为每一个发出的 HTTP 请求中添加一个特殊的 HTTP 标头，可以在事后分析时，非常简单地筛选出哪些请求是负载测试发出的，哪些不是。一般不太建议单独构造一个环境仅让负载测试的流量进来，更常见的做法是在 QA 环境进行，那么在负载测试时，也可能会有普通的测试流量，所以添加这个标头非常有用！
用户的准备
通过一个用户名、密码列表准备的用户数量（比如只有几十个）可能远远不足以模拟真实的流量峰值。尽管可以为同一个用户反复生成相同的大量请求，但是和用户相关的缓存可能会造成潜在问题不会被暴露出来。
因此建议每一个测试用例都通过真实的注册流程或者某种方式生成新用户，这样会更贴近真实情况。
资源压力
如果观察到负载测试中，数据库的 CPU 或者内在使用率没有突增，就需要想各种办法来压到它。
负载测试的时间长度
最好能够适当延长，比如几个小时等等。10 秒钟或者 1 分钟之类的，可能会造成一些诸如内在泄露的问题不会被暴露出来。
总结
这篇文章总结了使用 k6 或者其他工具进行负载测试时需要注意的关键指标。重点包括 RED 和 USE 指标。RED 指标用于监控 HTTP 请求（请求速率、错误率、时延），而 USE 指标用于监控系统资源的消耗情况（使用率、饱和率、错误数）。
在进行负载测试时，还提供了一些建议，包括添加特殊的 HTTP 标头以便后续分析、准备足够数量的用户、观察资源压力以及延长测试时间等。这些建议可以帮助更好地模拟真实环境中的负载情况，以便发现潜在的问题。
总的来说，通过这些关键指标和建议，可以更全面地评估系统在负载测试中的表现，及时发现潜在问题，并提供了实用的解决方案。