本篇文章主要介绍了" 有的放矢，你应该在性能测试报告中使用的 10 个微观指标"，主要涉及到方面的内容，对于软件测试感兴趣的同学可以参考一下：
在这篇文章中，你将会了解到为什么常见的主要测试指标是不完美的，以及十个新的测量指标 —— 它们可能会改进你未来的性能测试报告。性能测试是一项不可避免的任务，但问...
在这篇文章中，你将会了解到为什么常见的主要测试指标是不完美的，以及十个新的测量指标 —— 它们可能会改进你未来的性能测试报告。
性能测试是一项不可避免的任务，但问题是怎么保证测试的指标是正确且合理的？在这篇文章中，你将会了解到为什么常见的主要测试指标是不完美的，以及十个新的测量指标 —— 它们可能会改进你未来的性能测试报告。
在很多企业中，性能测试是定期进行的。作为这些测试的一部分，质量保证团队会收集各种指标并将其发布在性能测试报告中。性能测试报告中常用的一些分析指标是 CPU 利用率、内存利用率，关键事务或后端系统的响应时间以及网络带宽，具体取决于企业自身的情况。
我更愿意将这类指标归类为宏观指标，宏观指标当然很好，但它们有两个不可忽视的主要缺点：
- 不能在测试环境中捕获到性能问题
尽管在测试环境中进行了许多性能测试，但在生产环境中仍然会出现性能下降的情况。在测试环境中，你也许会注意到性能急剧下降的情况，但上面提到的宏指标并不能帮助你发现问题的根源。这些急剧的下降在生产环境中的体现就是主要的性能问题。下面讨论的微观指标会为这些下降的情况带来可见性。 - 宏观指标对解决问题没有帮助
在很大程度上，宏观指标不能帮助开发团队调试和排除故障。例如，如果宏观指标显示 CPU 消耗高，它不能表明这是由于垃圾收集活动、线程循环问题或其他编码问题而导致的 CPU 消耗增加。同样的，如果响应时间下降，也不会有任何指标显示是由于应用程序代码中的锁定还是后端连接问题而导致的下降。
因此，我的观点是应将宏观指标与微观指标一起搭配使用。在这篇文章中，将列出十项我认为最重要的微观指标，你可以考虑将其中的一些或全部添加到你的性能测试报告中。
与内存相关的微观指标
1. 垃圾回收机制的暂停时间
我们应该测量垃圾回收的暂停时间，因为应用程序会在 GC 暂停期间处于被挂起的状态。这意味着这段时间里不会执行 customer activity，很显然这是不好的。降低 GC 暂停时间的数量和长度可直接影响到性能。所以我们应始终力求实现最短的暂停时间。
2. 对象的创建/回收率
创建对象的速度会严重影响 CPU 的利用率。如果使用低效的数据结构或代码，会生成更多的对象来处理相同数量的事务。过高的对象创建率会导致出现频繁的垃圾回收行为，而频繁的 GC 则会增加 CPU 的消耗。
3. 垃圾回收的吞吐量
简单来说，吞吐量是指应用程序线程用时占程序总用时的比例。 例如，吞吐量 99/100 意味着 100 秒的程序执行时间应用程序线程运行了 99 秒， 而在这一时间段内 GC 线程只运行了 1 秒。我们应力求实现高吞吐量，即应用程序应运行更多的时间，并减少垃圾回收活动的时间。
4. 每一次生命周期的内存消耗
在 JVM、Android Runtime 和其他的平台中，内存会被划分为几个内部区域。我们需要知道分配的大小空间以及每个区域的峰值利用率大小。内存区域的分配不足会降低应用程序的性能，而超额的分配将增加托管服务器的成本。
如何获得与内存相关的微观指标？
所有这些与内存相关的微观指标都可以从垃圾回收日志中捕获。
与线程相关的微观指标
5. 线程的状态
线程会处于以下的其中一种状态：新建，可运行，运行中，睡眠，阻塞，等待，死亡。性能测试报告中应体现出每个状态的线程数量。如果线程长时间处于阻塞状态，则应用程序可能会无法响应。如果许多线程处于可运行状态，那么应用程序的 CPU 消耗就会变高。如果应用程序的线程在等待、有时间限制的等待和阻塞状态中花费更多的时间，这将会降低响应时间。
6. 线程组
线程组表示一组线程的集合。每个应用程序都会被归属于多个线程组。我们应该测量每个线程组的大小并记录在性能测试报告中。线程组大小的增加可能表示着某种类型的性能下降。
7. 守护进程 vs 非守护进程
有两种类型的线程状态：守护进程和非守护进程（如用户线程）。我们应该按状态来对线程进行报告。因为当非守护线程在运行时，JVM 将不会终止。
8. 代码执行路径
