现有一个ABC聊天应用程序 ，是一个聊天工作台，在公司的客户支持使用，这个聊天应用程序使用XMPP(Extensible Messaging and Presence Protocol)协议和Open fire服务器发送和接收即时消息。

公司对的聊天客户端进行了一些增强，如远程PC控制、PC诊断、维修工具、在线聊天等。

项目组决定使用JMeter进行性能测试，使用JIRA进行缺陷跟踪。

计划的第一页应该包含文档的标题和公司的版权。

第二页应该包含文档控制，包括文档版本历史，审核者和批准者列表以及贡献者列表。

第三页应包含目录，然后是以下主题。

简介

本文档的目的是定义/解释如何在 ABC 聊天应用程序的当前和未来状态下执行性能测试。

ABC 聊天应用程序是一个内部远程支持工作台。该工作台将用于满足客户请求。该工作台具有在线聊天、客户识别、远程PC控制、PC诊断和维修工具等功能。

性能测试的主要目标如下。

• 确信对现有聊天应用程序的更改符合定义的服务级别协议。
• 确保应用程序的性能、服务可用性和稳定性不会因为新的增强功能而受到影响。
• 事务响应时间在不断增加的负载情况下保持在可接受的范围内。
• JVMs在不断增加的负载曲线中显示出稳定的内存使用。

还需要加入项目的架构图。

范围

• 对系统关键业务处理进行详细研究后，构建负载分布模型。
• 确定性能测试的关键场景。
• 将之前的发布结果作为未来发布的基线。
• 验证和确认性能测试环境和性能/负载测试工具基础架构，是否需要测试机。
• 使用JMeter为已确定的场景准备性能测试脚本，模拟已确定的峰值负载。
• 在服务器上设置性能监控，用于监控测试，以便在测试执行阶段识别瓶颈。
• 发布性能测试结果。
• 解决识别出的性能问题。
• 为未来的版本设定性能水平的基线。

方法

ABC聊天的性能测试将使用Jmeter，通过编写自定义的XMPP插件，使用smack库进行XMPP连接。这些库用于设置连接、登录和向 XMPP 服务器发送聊天消息。

测试场景将使用JMeter工具编写脚本。脚本将根据需要进行定制。计划表将与所需的升压一起创建，以模拟真实世界的场景。

测试场景将在以下几个方面进行分解和测量。

a) 基线测试。以1个Vuser和多次迭代的方式运行每个场景，以确定应用性能是否符合业务服务水平协议。

b) 基准负载测试。为了满足负载测试下的业务基准，性能测试团队将执行基线负载测试，这将有助于识别任何系统性能问题，随着负载的增加，并创建下一级性能测试的基线。

c) 峰值负载/可扩展性测试。性能测试团队将对不断增加的用户进行多次测试，以满足预期的负载，并测量应用程序的性能，以建立性能曲线，并确定部署是否能在用户峰值负载下支持服务水平协议。

它有助于调整或规划各个Java虚拟机(JVM)所需JVM的总数以及处理器的容量。这将通过增加Vusers数量到峰值容量的50%、75%、100%和125%来实现。

d) 耐力测试。性能测试团队将在8小时/16小时/24小时内运行该测试，以确定内存泄漏、性能问题以及整体系统稳定性。在耐力测试期间，性能测试团队会监控关键性能指标，如事务响应时间和内存使用的稳定性。

性能指标:事务响应时间、吞吐量、点击次数/秒、成功率等。

测试数据

使用生产数据的副本。

进入和退出标准

• 访问环境中的所有应用程序。
• 环境准备完成。
• 性能测试数据准备就绪。
• 进入和退出标准

缺陷管理

JIRA中的缺陷管理模块将用于项目中的缺陷记录和跟踪关闭。
在测试执行阶段发现的缺陷识别将被记录在JIRA中，这些缺陷将由开发团队根据以下严重程度来解决。
缺陷评审会议将每天举行，测试、开发、质量分析师和业务团队都会参与。
随着项目接近上线日期，缺陷修复的标准会越来越严格。缺陷修复标准指南将在缺陷评审会议上公布。
缺陷严重性定义
严重性代码的定义如下。

测试工具

Jmeter

暂停和恢复标准

主要从测试环境、应用稳定性、测试数据等考虑。

测试交付

• 性能测试策略
• 性能要求文件
• 性能性能测试场景
• 性能性能测试脚本
• 性能性能测试结果

角色和责任

风险分析

假设

• 性能测试环境将是产品架构图的复制。
• 性能脚本重点在使用率较高的关键流程
• 基础设施问题应在性能测试开始前解决。
• 应用程序是稳定的。
• 硬件和软件资源可用。
• 更改都将通过一个更改控制流程，性能测试团队将评估时间表和资源的影响。
• 独立的服务器
• 启用必要的应用程序跟踪日志达到监控。

依赖关系

• 测试准备和执行阶段，需要来自不同功能、开发、数据库和基础设施团队的支持。
• 应用程序业务用户/主题专家将被用于功能澄清和业务交易签收。
• ABC聊天程序经理将审查和签收。

术语