最近、一部の学生は、企業がパフォーマンステストを行うために、リーダーがパフォーマンステストプログラムを書くように求め、パフォーマンス関連のテスト計画についての質問をするために私に来て、私は、何の開始を前に、関連する仕事をしていない苦しむことはありませんでした。
このブログは、私の個人的な経験と教訓の一部と併せて、より包括的なパフォーマンスのテスト計画を開発する方法について話しています。。。
まず、背景をテスト
まず、ユーザーがどのような特性を持っているため、テスト対象システムの種類を、である。この性能試験の背景を設定するには、なぜパフォーマンステストを実施する必要があり、より多くを期待指標の一部。
例：「ダブル10月」大きなプロモーション期間を確保するために、システムは安定した動作とサービスの可用性、パフォーマンステストを保証することができます。
コア：、業績動向、リスク測位システムのボトルネックを分析し、システムのパフォーマンスを評価する計画システムの能力を支援します。
テストの第二に、目的
試験の目的は、次のような試験背景、に従って分析するように設定されています。
アプリケーションの一部にリンクされている高トラフィックのオンラインサービスによる1は、それがテストの目的である：ポジショニングボトルネック解析のチューニングの確認。
2、事業者は新しい、新しいチャネルの開発を引っ張っていた、そしてそれは、テストの目的である：ビジネスの新しいラインを満たすシステムの性能を評価するために、
図3に示すように、マイクロ技術クラスターサービスのシステムアーキテクチャ、即ち、試験の目的である：オンラインサービス拡張のために安定性、可用性、容量の単一のインスタンス、容量計画データを確認します。
第三に、テスト範囲
需要の研究により、定量分析のためのトラフィックデータの増加傾向とピークのアクティブユーザーや他のデータの利用者の使用シナリオの分析は、このような順序+カート+商品+支払いサービスとして、テスト中のシステムの適用範囲を決定します。
| 権利確定モジュール | ビジネスシナリオが含ま |
| オーダーフォーム | 注文を作成します。 |
| 注文をキャンセル | |
| ショッピングカート | ショッピングカートを追加 |
| カートを削除します | |
| 商品 | 製品一覧 |
| 製品の詳細 | |
| 支払います | 国際収支 |
| アリペイ | |
| マイクロチャネルの有料 |
第四に、用語は、合意されました
用語はを参照：これはテストのパフォーマンスを示すために、関連する技術用語の数を含み、目的は理解の性能試験に参加する関係者を容易にするための説明をするために、1つの音声で話すことです。次のように一般的な用語は、以下のとおりです。
| 用語の名前 | 用語の解釈 |
| によって複雑 | クライアントの単位時間あたりの要求の数（S）は、アナログを開始します |
| 安定 | 性能検証システム（24時間/ 48時間）長く負荷 |
| ハイアベイラビリティ | サービス検証システムのダウンタイムの後半では、通常のサービスとサービス回収率を提供することができます |
| TPS | 秒あたりのトランザクション数、要求処理能力、すなわち、システムの単位時間（S） |
| RT | 撮影した応答時間、プロセスの要求とシステム時間 |
| 要求の成功率 | 試験中、リクエストの割合は成功し、合計の要求を処理しました |
PS：実際の状況に長期契約の対象とするだけでなく、性能試験の範囲を理解するために観客のためのパフォーマンス・テスト・プログラムを検討し、この合意は、通信コストを削減し、説明口径を統一することを目指しています。
V.環境説明
一般的な、性能テスト環境で、または別個のUAT性能テスト環境であるが、正確な構成や環境の種類、およびテストおよび本番環境との間の差を説明するために、それは、製造及び試験環境に推奨される比較が記載されています。
1、生産環境
①、システムアーキテクチャ
PS：図は、唯一のマイクロアーキテクチャのサービス・タイプの概略図では、概略的にのみ、理解することができます。
②、サービス構成
| サービス名 | 数量 | コンフィギュレーション | リマーク |
| ゲートウェイサーバ | 10 | 2C3G | ゲートウェイサービス、認証、および要求を転送 |
| Webサーバ | 3 | 2C3G | |
| アプリケーションサーバー | 5 | 2C3G | |
| Redisの | 3 | 4G | センチネルモード、2からマスター |
| DB | 2 | 8C16G | マスタースレーブ |
2、テスト環境
①、システムアーキテクチャ
②、サービス構成
| サービス名 | 数量 | コンフィギュレーション | リマーク |
| ゲートウェイサーバ | 5 | 2C3G | ゲートウェイサービス、認証、および要求を転送 |
| Webサーバ | 2 | 2C3G | |
| アプリケーションサーバー | 2 | 2C3G | |
| Redisの | 2 | 4G | センチネルモード、マスタースレーブ |
| DB | 2 | 8C16G | マスタースレーブ |
3、負荷設定
負荷機械（マシン）クライアントは、通常の状況下では、負荷ユニットのハードウェア構成の説明を要求、すなわちアナログ機を送信、番号、IPは、圧力ポリシーを作ることができます。
4ネットワーク
その負荷条件とネットワークパフォーマンステスト環境は、このような国内の公共/ VPC同一ネットワーク内でのように、ファイアウォールポリシーのように。
第六に、分析を必要とします
ニーズの分析は、一般的にいくつかの段階があります。ニーズを収集要件は→が→分析、以下の重要な要素を必要とするアクセスします。
1、ビジネスモデル
以下は、ログホーム、商品、ショッピングカート、支払い、共有モジュールを含む、一般的なビジネスプラットフォームのコアビジネスリンク計画です。
2、パフォーマンス指標
ここでは、2つのパフォーマンス指標には、次のものが含まれています。
①、業績指標
それが期待されているTPS、RT、要求の成功率（通常はデフォルトの要求成功率≥99.99％）。
②、ハードウェアのパフォーマンス指標
そのサーバーのリソース消費の指標、資源指標の定期的なモニタリング：CPU使用率、メモリ使用率、システムIO、IOおよび他のネットワーク。
七つのテスト戦略
性能試験の試験計画のような、使用します。
屈曲検出システム性能、ニーズは、圧力測定値を階段;
許容可能な性能の最大処理能力を有する検出システムは、負荷容量の試験戦略を必要とします。
システムの安定性と可用性を確認し、安定性を必要とする、可用性テスト戦略。
異なる構成で検証システムの性能、テスト戦略の一般的な構成。
1、テスト戦略とシナリオ
①、能力テスト
| シーン名 |
01_ログイン 02_ホーム |
| 実行時 |
10分 |
| ビジネス比 |
100％ |
| テスト戦略 |
容量試験 |
| テストの目的 |
不断增加负载，验证系统单节点的最大性能表现 |
②、稳定性测试
| 场景名称 |
混合场景 |
| 执行时间 |
24h |
| 业务配比 |
按生产业务配比，等比缩放 |
| 测试策略 |
稳定性测试 |
| 测试目的 |
验证系统长期运行的稳定性以及是否存在OOM之类的问题 |
PS：如上表格描述，依然作为一个示例来说明，主要内容包括：场景编号、测试类型、涉及业务场景、业务配比、执行时间、测试目的。
2、测试监控策略
| 监控对象 | 指标范围 | 监控工具 |
| CPU | ≤90% | nmon、zabbix |
| Memory | ≤70% | |
| 网络IO | 无明显IO瓶颈 | |
| JVM | 无频繁FGC情况 | jmap、jstat |
八、准备工作
准备工作主要包含如下几项：
| 准备事项 | 准备内容 | 责任人 | 预计完成时间 |
| 工具准备 | 负载工具、监控工具、分析工具 | 测试/运维 | 0.5工作日 |
| 脚本准备 | 测试脚本 | 测试 | 0.5工作日 |
| 环境准备 | 机器配置、服务部署联调、脚本调试 | 运维/开发 | 1工作日 |
| 数据准备 | 铺底数据、测试数据、参数化数据、缓存数据 | DBA/开发/测试 | 1工作日 |
九、组织架构
组织架构即本次性能测试涉及到的团队各角色成员，主要包含这些：PM角色、测试、开发、运维、DBA、网络、基础架构。示例：
十、风险分析
罗列开始执行前会影响本次性能测试工作开展的风险项以及应对方案，比如：
| 风险类型 | 风险描述 | 风险级别 | 应对方案 |
| 交付风险 | UAT阶段发现较严重的功能缺陷 | 高 | 测试时间顺延，或增加对应人员 |
| 变更风险 | 临时需求变更、新增需求 | 高 | 需求评审是否加入本次测试范围，阶段性交付 |
| 数据风险 | 数据脱敏耗时较长、测试数据不可用 | 中 | 重新拟定数据准备方案，小范围数据验证 |
| 环境风险 | 部署出现问题，联调进度缓慢、网络带宽瓶颈 | 中 | 更换环境、增加资源配置、扩展带宽 |
十一、交付清单
在性能测试计划中，需要说明本次性能测试各阶段的交付物，主要包含这几项：性能测试计划&方案、测试脚本、性能缺陷统计、轮次小节、性能测试报告。
十二、阶段进度
这里主要指的是从需求阶段到结束，各个阶段的工作进展以及资源安排，建议采用看板的方式，及时更新进度，方便推进工作的开展。示例如下：
| 阶段 |
事项 |
开始时间 |
结束时间 |
状态 |
责任人 |
| 需求阶段 |
需求评审 |
|
|
完成 |
多方参与 |
| 系统架构图 |
|
|
完成 |
开发 |
|
| 需求调研 |
|
|
完成 |
性能测试人员 |
|
| 准备阶段 |
环境交付 |
|
|
完成 |
运维、开发 |
| 应用部署 |
|
|
完成 |
运维、开发 |
|
| 数据准备 |
|
|
完成 |
开发、DBA、测试 |
|
| 脚本开发 |
|
|
完成 |
性能测试人员 |
|
| 实施阶段 |
执行压测 |
|
|
未完成 |
性能测试人员 |
| 服务监控 |
|
|
未完成 |
运维、测试 |
|
| 数据收集 |
|
|
未完成 |
性能测试人员 |
|
| 结束 |
报告评审 |
|
|
未完成 |
多方评审 |
如上，就是一个较为完整的性能测试计划内容，当然，完成性能测试计划并评审通过后，就可以进入测试执行阶段了。。。