软件性能测试（连载3）

1.5性能测试环境

性能测试对环境是非常重要的，特别是网络环境。

图3-13 测试环境与工作环境在一起

图3-14 测试环境各个客户端不在一个网下

在图3-13中，测试环境与工作环境在一起，既使得别人的正常工作不能进行，也使得测试的数据不准确。在图3-14中，测试环境各个客户端在两个不同的网段下进行（这里是C类网），大家都知道跨网段是需要路由的，路由里面有软件，会干扰性能测试的数据，从而也会造成测试数据不准确。图3-15的环境是正确的。所有的性能测试机器都在一个网段下，且与工作环境相隔离。

图3-15 正确的性能测试环境

1.6 观察性能的四个维度

图3-16展示的是通过终端用户、系统运维人员、软件设计开发人员和性能测试人员四个维度来观察系统的性能。

图3-16 观察性能的四个维度

1.从终端用户角度看性能

对于最终用户，性能主要体现在响应时间，第4.1节介绍性能响应时间包括响应时间=用户响应时间+前端响应时间+网络响应时间+服务器端响应时间+数据库响应时间。而这里面的过程对用户来说是透明的，用户只关心按下鼠标到页面出现所希望的信息之间的时间越短越好。

2.从系统运维人员角度看性能

从运维人员的角度来看，软件性能除了包括单个用户的响应时间外，更要关注大量用户并发访问时的负载，以及可能的更大负载情况下的系统健康状态、并发处理能力、当前部署的系统容量、可能的系统瓶颈、系统配置层面的调优、数据库的调优，以及长时间运行的稳定性和可扩展性。比如一个产品有两种设计方案，这两种设计方案体现了两种不同的性能。

•方案一。最多支持100万个在线用户，平均响应时间为3秒。

•方案二。最多支持500万个在线用户，平均响应时间为5秒。

作为技术人员可能比较看重方案一，因为平均响应时间为3秒，比方案二5秒要快2秒。但是方案一仅能支持100万个在线用户，而方案二是它的五倍，可以支持500万个在线用户。所以作为系统运维人员肯定会选择方案二的。

3.从软件设计开发人员角度看性能

软件设计开发人员角度需要从以下5个维度来看性能。

1）算法设计

•核心算法的设计与实现是否高效。

•必要时，设计上是否采用buffer机制以提高性能，降低 I/O。

•是否存在潜在的内存泄露。

•是否存在并发环境下的线程安全问题。

•是否存在不合理的线程同步方式。

•是否存在不合理的资源竞争。

2）架构设计

•站在整体系统的角度，是否可以方便地进行系统容量和性能扩展。

•应用集群的可扩展性是否经过测试和验证。

•缓存集群的可扩展性是否经过测试和验证。

•数据库的可扩展性是否经过测试和验证。

3）性能最佳实践准则

•代码实现是否遵守开发语言的性能最佳实践。

•关键代码是否在白盒级别进行性能测试。

•是否考虑前端性能的优化。

•必要的时候是否采用数据压缩传输。

•对于既要压缩又要加密的场景，是否采用先压缩后加密的顺序。

4）数据库

•数据库表设计是否高效。

•是否引入必要的索引。

•SQL 语句的执行计划是否合理。

•SQL 语句除了功能是否要考虑性能要求。

•数据库是否需要引入读写分离机制。

•系统冷启动后，大量缓存命不中的时候，数据库承载的压力是否超负荷。

5）软件性能的可测试性

•是否为性能分析（Profiler）提供必要的接口支持。

•是否支持高并发场景下的性能打点。

•是否支持全链路的性能分析。

4.从测试人员角度看性能

由于性能牵扯到代码、系统架构、数据库、硬件、操作系统、中间件等几乎涵盖计算机知识的方方面面，所以性能测试工程师如在第2.2.2节所述，应该是一专多能的T型人才的集合体。性能测试人员对软件性能需要做到以下几点。

•根据性能测试目标以及线上数据收集，精准的性能测试场景设计和计算能力。

•性能测试场景和性能测试脚本的开发和执行能力。

•测试性能报告的分析解读能力。

•性能瓶颈的快速排查和定位能力。

•性能测试数据的设计和实现能力。

•面对互联网产品，全链路压测的设计与执行能力，能够和系统架构师一起处理流量标记、影子数据库等的技术设计能力。

•深入理解性能测试工具的内部实现原理，当性能测试工具有限制时，可以进行扩展二次开发。

•极其宽广的知识面，既要有“面”的知识，比如系统架构、存储架构、网络架构等全局的知识，还要有大量“点”的知识积累，比如数据库 SQL 语句的执行计划调优、JVM 垃圾回收（GC）机制、多线程常见问题等等。