在应用程序的生命周期中，应尽早建立性能测试意识。
确保应用一切就绪
需要考虑的问题：
- 应用程序部署后需要支持多少最终用户？6个月后？1年后？3年后呢？
- 这些用户分布在哪里？他们是如何与系统建立连接的？
- 部署后有多少在线用户、并发用户？6个月后？1年后？3年后呢？ 引申出的问题：
- 对于每个应用程序，需要多少台服务器？这些服务器的配置是怎么样？是否需要集群？
- 我需要提供什么类型的网络基础设施？
性能测试重点关注的方面：
- 选择合适的性能测试工具；
- 设计一个合适的性能测试环境；
- 设置切合实际的性能测试目标；
- 确保被测应用程序足够稳定；
- 安排有足够的时间进行有效的性能测试；
- 做到代码冻结；
- 确定和编写关键业务脚本；
- 提供高质量、足够的测试数据；
- 确保准确的性能测试设计；
- 确定监控服务器和网络的关键性指标（KPI）；
- 安排有足够的时间进行有效的性能测试。
性能测试工具
性能测试工具要求：
- 协议支持（通信协议）；
- 认证模式（License）；
- 概念验证（Proof of concept，简称POC，证明其可行性，示范其原理）；
- 脚本效果（生成脚本的编辑程度）；
- 解决方案与负载测试工具（提供解决方案）；
- 外包性能测试or内部执行。
注意：制定替代方案。
预留足够时间
安排足够的时间确保有效的性能测试。 需要考虑的几个方面：
- 准备测试环境的时间
- 准备负载生成器环境
- 确定及描述业务事务的时间
- 识别和创建足够的测试数据的时间
- 部署测试环境的时间
- 准备和执行性能测试运行的时间
- 解决问题的时间
设计性能测试环境
理论上要与生产环境完全一致，但是很多原因导致不太可能，可能的原因：
- 服务器的数量和规模：真实环境难以复制，尽量保持规格一致或接近，以便提供基准；
- 带宽和网络基础设施：地理位置难以复制；
- 应用层数量：建议完全一致；
- 应用程序数据库规模：建议完全一致。
搭建性能测试环境，需要进行计划和规划，必要时候需要定期做评审。
性能测试环境的三个层次：
- 完全真实或者接近真实的环境；
- 生产环境的子集。使用少数的服务器，但部署的规模和应用层都与生产环境一致；
- 生产环境的子集。使用较少的和小规模的服务器（所有部署模式与生产一致，只是缩小规模）。
施压能力
负载生成器能力：确保负载生成器有足够的硬件资源（尽量保证硬件资源处于非饱和状态）。
针对虚拟用户需要注意以下几点：
- 负载均衡：应用程序根据传入的IP地址不同进行负载分配；
- 需要实施“IP欺骗”技术（选择测试工具时，需要注意）；
- 用户会话限制：每一个物理机器只能发起一个用户会话，如：mac验证等；
- 应用程序技术的中间件可能无法录制；
- 使用功能测试工具从表现层产生负载；
- 使用某种瘦客户端的部署形式，以使性能测试工具能够录制；
- 从应用层角度去衡量性能（通常性能测试是从中间层发起的，客户端没有进行性能测试选择测试工具时，可以选择负载测试脚本和功能测试脚本任意组合的性能测试工具）。
网络部署模式
不同的部署模式（网络环境）考虑如下几点：
- 可用带宽：局域网和广域网的带宽，需要作为性能测试模型的考虑因素；
- 网络反应时间：局域网和广域网的延迟，广域网的延迟高，会影响性能。
针对广域网的性能测试方法：
- 修改事务回放：性能测试工具通过修改事务的执行频率达到；
- 广域网的负载生成器：需要符合实际；
- 网络模拟：网络角度模拟广域网的网络环境。
环境检查信息
- 服务器数量；
- 负载均衡策略；
- 硬件信息；
- 软件清单；
- 应用程序组件（中间件）清单；
- 外部连接（其他内部或者第三方系统的情况）。
软件安装冲突
测试环境中安装的第三方软件是否会互相冲突，比如：安全软件。
设定合理的性能目标
制定切合实际的性能指标：制定明确清晰的性能指标，否则性能测试没有任何意义。
一致性
- 性能指标制定需要提早制定（项目的早期阶段）；
- 制定一致性的性能指标需要相关所有部门都参与进来，使所有成员对项目进程和交付等问题都有清楚的了解（促进专家评审和参与）；
- 商务人员：首席信息官（CIO）、首席技术官（CTO）、首席财务官（CFO）、部门负责人；
- IT：架构团队、开发人员、测试人员、运维人员、基础设施组（内部和外部）、终端用户。
关键性能指标
主要包含可用性、响应时间、吞吐量、并发、网络利用率和服务器利用率。
- 可用性或者正常运行时间：应用程序任何时候处于可用状态；
- 并发性和扩展性：根据80/20原则确定，考虑高峰时期，经验法则在并发数和吞吐量指标基础上增加10%；
- 吞吐量：考虑区分专家级和初级用户，专家级用户在单位时间内，创建的事务更多；
- 响应时间：确定基线值（无任何影响情况下，一个用户单独运行此事务的响应时间），根据差额确定响应时间变化当用户增加时，响应时间会增加，但是随着负载的增加不应该出现阻塞的情况；
- 网络容量：数据量（低带宽广域网下，带宽限制和网络延迟的影响）、数据吞吐量（是否能达到“节流”的情况）、数据错误率；
- 服务器容量：CPU、内存、I/O（磁盘和网络等）、磁盘空间等。
梳理关键业务用例和编写脚本
识别并确认关键业务的事务，确定性能测试业务范围。
确保在性能测试过程中应用程序足够稳定，系统稳定性是对于应用程序能够正确提供服务的信心，性能测试之前，代码的质量对于性能的好坏是至关重要的。
影响应用程序稳定性，可能出现的隐藏问题：
- 大数据量展现；
- 执行效率不佳的SQl语句；
- 大量的网络数据交互；
- 应用程序的未知错误。
做到代码冻结（保证测试版本稳定），对不断变化的对象进行性能测试是毫无意义的，保证代码版本的一致性，对于性能测试至关重要。
事务检查列表
- 定义每个执行步骤并形成文档，保证不出现具有歧义的路径；
- 确定所有输入数据的要求和预期结果；
- 定义事务涉及的用户类型：多用户操作同一事务，使用量各有不同；
- 事务的链接模式是什么：局域网、广域网、互联网；
- 主动型事务还是被动型事务。
事务回放验证
- 验证单用户回放；
- 验证多用户回放。
度量目标
要测量什么：关注事务的响应时间，及LR里面事务的概率。
登录还是不登录
用户是否反复登录（脚本中，是否重复登录）。
共存系统问题
资源共享（与其他应用共享服务器、网络带宽等）。
准备测试数据
提供高质量的足够的测试数据
- 输入数据：用户认证；搜索条件：不同的数据组成搜索条件；文档关联：上传下载测试，文档类型和大小多种；
- 目标数据：大小：确定数据库基础数据量；数据回滚：保证每次测试时，数据库的数据量一致，减少性能测试差异，考虑数据库恢复时间，并在性能测试计划中体现；
- 运行时返回数据：确认执行结果正确；
- 数据安全性：保证数据脱敏。
精确的设计性能测试
性能测试的基本类型
- 基准测试：基准测试是指建立一个可与进一步测试比较的点，通常用于衡量事务响应时间；通常是单用户在一段时间或一定的循环次数内执行单个事务，提供在“最好情况下”的测量；基准测试得到的值可用于评估，随着用户数或吞吐量的增长而导致系统响应性能的衰减；
- 负载测试：为达到性能目标而做的性能测试；最接近真实的使用场景；
- 压力测试：导致应用程序或部分支撑硬件的崩溃，这样做的目的是确定硬件的支撑大小和上限；压力测试的结果不仅可以衡量系统的性能，还可以衡量功能；重要的是了解到了应用程序的上限，为未来的做决策；
- 渗透或稳定性或可靠性测试：长时间下的负载测试；
- 冒烟测试：只关注发生改变的部分；
- 隔离测试：性能问题确定测试。
负载模型
负载生成策略：
- 爆炸式（同一时间加压）
- 递增式
- 逐步递增式
- 逐步递增式，逐步递减式
- 延迟启动
为每个事务设置虚拟用户数（混合场景性能测试）。
性能测试负载方式：
- 每个事务的基准测试：为每个事务建立一套性能数据基准；
- 每个事务的负载测试：确定每个事务需要的最大并发用户数或吞吐量；
- 单个事务的隔离测试：出现问题时，启动，直到问题解决；
- 混合事务负载测试：单事务达标，启动混合事务负载测试目的为了发现硬件能力或可能的冲突，比如数据库锁等资源的竞争负载生成策略：递增或递减；
- 混合事务隔离测试：混合负载不达标时，启动，确认诊断结果和解决方案，指导解决；
- 混合事务渗透测试：疲劳或稳定性测试单事务或者混合事务，发现在长时间运行情况下，才能出现的问题；
- 混合事务压力测试：峰值测试单事务或者混合事务，通过减少暂停时间和步进时间，创建比负载测试中更大的吞吐量查明应用程序容量的上限，并且确定在突然的业务高峰期系统的响应如何；
- 其他性能方面的测试：配置测试不同方式的负载均衡停掉应用程序的一个或多个服务来测试系统的容错行为为今后异常处理或者应急方案做决策，而做的非性能方面的测试。
用户负载仿真：创建的负载必须和真实的环境一致，考虑带宽的制约、资源的制约等。
思考时间&步进时间
思考时间和步进时间可以尽量让性能测试更真实。
思考时间：影响的是事务执行的频率（事务内部的等待时间）。
步进时间：影响的是事务的吞吐量（事务迭代之间的间隔时间）。
确定关键性能指标
服务器指标
- 通用指标
- CPU
- 内存
- I/O（磁盘和网络）
- 磁盘空间
- Web和应用服务层：OC4J、Weblogic、WebSphere、Jboss等；
- 数据库服务层：MSSQL、Oracle、DB2、MySQL、Sybase、Informix等；
- 主机层：Strobe（Compuware）、Candle（IBM）。
网络指标
- 数据包的响应时间；
- 数据展现；
- 大数据量引起的任何可能出现的错误。
参考文档
- 《应用程序性能测试的艺术》
