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）机制、多线程常见问题等等。
