I.背景と目的テスト
当初は研究のための需要が、テスターはテストの目的をクリアする必要があり、その後、プロジェクト自体は、最初のクリアケース、プロジェクトに応じて、プロジェクトの異なる目的のために別のがあるでしょうしなければならない、一般的に以下の6つのケースに分けることができます。
1、全く新しいシステム
全く新しいシステムがシステムを基準とし、ビジネスデータをテストしていないことを意味し、何の事業担当者が効果的にビジネスの推定量になることはできません、あなたはその後、我々は通常、以下の目的のためにテストし、トラフィックの指標値(TPS / QPS)に変換することはできませんがあります:
- ベストテストアプリケーションシステムの処理能力と需要側の開発と評価のための極端な処理能力。
- テストアプリケーションシステムが安定しています
- テストアプリケーションシステムは信頼性があります
- テストアプリケーションシステムのボトルネック、および助言や他の拡張を提供
2、新たなシステムの変換
一般的には新システムの変換は、運用スタッフと組み合わせて、古いシステム、ビジネスのボリュームで分析することができ、ビジネスの発展に基づいて評価しました。次のように一般的に目的のテスト:
- テストアプリケーションシステムは、現在の交通需要を満たしています。
- テストアプリケーションシステムは、N年後のトラフィック要件を満たしています
- テストアプリケーションシステムが安定しています
- テストアプリケーションシステムは信頼性があります
- テストアプリケーションシステムのボトルネック、および助言や他の拡張を提供
3、システムのアップグレード
アップグレードのシステムは欠陥修正のためにアップグレードすることができ、ビジネスニーズをアップグレードするための変更があるかもしれません。パフォーマンステスト、道の目的の変換に合わせて設定し、新しいシステムなどの前に行われていません。一般的に、次の目的のためにテストされ、既に行われた性能として:
- ベストテストアプリケーションや極端な処理能力と試験前の結果を分析しました。
- テストアプリケーションシステムが安定しています
4、オンラインシステムの操作
オンライン非機能テストを実行するためのシステム要件は、一般的にオンライン非機能テスト不良が発生している、再現が困難です。通常、テストオブジェクトを次のように
- 最適化された再検査の開発に欠陥を見つけるために、本番環境の操作、非機能テストをシミュレートします。
5、調達システム
調達システムが非機能テストは、一般にテスト用の製品の製造業者の数である必要は次のように、テスト結果の比較は、通常、テスト目的のために、与えられます。
、同時ユーザーの固定数を得ることが指数(TPS、応答時間、CPU使用率、誤り率、等)の比較をメーカー
6、ハードウェアとソフトウェアの選択
、主に他の例を維持式の場合には、状況の性能比較を非機能テストのハードウェアとソフトウェアを選択します。
サービスの状況に応じて、異なるハードウェアおよびソフトウェアの処理能力を獲得、最高の費用対効果の高いハードウェアとソフトウェアを選択します。
第二に、テストの範囲を確認します
試験範囲は、主に研究過程において、被試験システムは、グラフィカルな方法を示すために、隣接システムとの関係を確認し、試験中に有意なマークラベリングシステム及び方法トランザクションのテキスト記述は、特定の検査及びシステムは、相互作用にします。
第三に、テスト・システムアーキテクチャの分析
分析アーキテクチャの主な目的は、バックアップ機構(ホットスタンバイ/コールドスタンバイ)があるかどうか、データベースクラスタを使用するかどうか、クラスタ・アプリケーションを採用するかどうかをテストシステム/開発フレームワークを開発するために使用される言語、通信機構/プロトコル、ミドルウェア、データベースを確認する必要があります、メカニズムを負荷分散。土台を敷設手段を監視し、特定のフォローアップのテスト戦略、環境の展開を設定します。
第四に、ビジネスモデル分析
より現実的なシミュレーションを得るための主なビジネスモデルの分析は、このようにテストカバレッジを確保し、オンラインで実行されます。両方の場合において、システムによるサービスデータ(生産ロギング操作)なしサービスデータへの参照によって参照
第五に、参照データサービスがあります
サービスデータは、以下のようなビジネス・モデルを抽出するシステムを用いて分析することができます。
例
ケース号 | インタフェース名 |
取引の会計処理 |
1 |
create_instant_trade(プロンプト到着) |
6% |
2 |
create_ensure_trade(確保取引) |
5% |
3 |
create_split_trade(スプリット) |
3% |
4 |
create_settle(決済) |
5% |
5 |
create_refund(還付) |
0.5% |
6 | query_trade(トランザクション問い合わせ) | 80.5パーセント |
第六に、ノービジネスデータ
ビジネスユースケースに基づいて、ビジネスの人々を導くためにビジネスの人々や開発者とのコミュニケーションは、おそらくビジネスモデルを投影しました。次のように具体的な方法があります
- 確認検査業務の取引、ビジネストランザクション選択ルール次のように:
- トランザクションを頻繁に使用する(ビジネスの人々が利用状況に基づいて提供)
- しかし、頻繁に使用するには、トランザクションのトランザクション(提供使用状況に基づいて、開発者とのビジネスの人々)に関わるデータの量は特に大きくはありません
- (コード・ロジックに従って開発者)は、複雑なロジック高い取引を取引
- ビジネストランザクションを認識することを占めました。
- ビジネスの人々は、それぞれの用途に応じて選択したトランザクションの割合を推定しました
- あなたがサービスを使用しない場合は、(非機能テスターをして確認した事業の関連する行為に基づく勧告を行う)ピアに参照することができます
七、ユーザー分析
オンデマンドカテゴリ | 需要のハイライト | 説明パフォーマンス仕様要件 |
ユーザー分析 |
ユーザーの要求の数 |
システム分析のユーザの各カテゴリの数 |
ユーザーの需要カテゴリ | ||
システムは、ユーザーの同時操作の最大数をサポートしています | ユーザーの数は、システムおよび業務運営にログインし、同時に、同時ユーザーの数を指します。 | |
システム接続によってサポートされるユーザの最大数 | システムは、同時に接続しているユーザの最大数のアクセス(またはログ)することが可能です。 一般的には、すべてのアクセス(またはログ)リアルリアルタイム動作のユーザー、ユーザー・アクセスの一部(またはログ)システム、一時的に動作していない、テスト対象システムの動作要件に慣れているユーザーは、追加を提供するように、システムの同時アクセス機能を備えています。 |
八、テストインジケータ
パフォーマンステストは一般的に使用される指標は、次の点を確認してください。
カテゴリー |
インデックスエントリ |
インデックス値 |
リマーク |
ビジネスクラス |
システム容量(TPS) |
パレートルール |
TPSのピーク |
一般的なトランザクション応答時間 |
<3秒 |
エンドツーエンドの応答時間 |
|
複雑なトランザクション応答時間 |
<5秒 |
大きなテーブルのクエリのトランザクションのための |
|
トランザクションの成功率 |
> = 99.9% |
|
|
システムリソース |
CPUの使用率 |
<= 80% |
|
メモリ使用量 |
|
明確な上昇傾向ません。 |
|
安定 |
実行時間 |
24時間 |
CPU使用率、メモリ使用率、ディスクビジー率は、有意な変動は比較的安定していません。 |
- システム容量(TPS)分析方法:
コミュニケーションとS1の推定ピーク日の取引量(単位:T)、ピーク時間帯S2(単位:時間)を取得するために、運用能力のN年満たすために必要な場合には、後に、ビジネスは百パーセント刻みS3を付与する必要があります。
現在のサービス処理時間T1(単位:ペン/秒)を満たす能力=(S1 * 0.8)/(S2 * 0.2 * 36000)。
N T2のサービス処理能力(単位:ペン/秒)を満たす= T1×(1 + S3)^ Nと、
- 応答時間は入手します:
応答時間指標は、一般にサービスマンによるサービスに応じているシステム・モード・インターフェースは、クライアント・アクセス・カテゴリ、特定の時間インデックス及びクライアントアクセスクラスに基づいてクラスに分類され、指定された応答時間
通常、標準:1-3秒を通じて、慎重による3-5秒、5秒以上にすることはできません。一般的に応答時間インタフェースクラス条件:課金カテゴリ:単一のクエリ200ミリ秒:500ミリ秒
九、埋め込まれたデータ解析の量
データオブジェクト埋め込みデータの量は、一定量の場合には、それらのビジネス・トランザクション・パフォーマンス・データのデータベースのパフォーマンス、認証、製造条件及び交通データベーステーブルデータストレージに応じて埋め込まれています。一般的には独自の設定データや生産データからリード分け。
テスト・データベースに生産データ、より現実的なデータを主に生産派生脱感作。
主要構造は、ストレージ時刻表や統計的なラインモード(テーブルデータストレージを必要とする取引について知っておく必要があります)、基本的なデータ構造、データタイプの毎日の取引量の量を掛け、自分のデータの数に基づいており、注文の要件を満たす必要があり、避けるために、データホットスポット
query_balance
缶 | サービス | データベース | 数据表 | 操作 | 线上数据量 | 当前测试环境 |
下单 |
mag | |||||
ma-web | member库 | m_member_identity 会员查询 member_account 会员账户信息表 |
query | 5320w | 3053w | |
dpm | dpm库 | dpm_outer_account 外部户
|
query | 10450w | 5735w | |
vouch | vouch库 | trade_vouch 交易凭证 | insert | 11559w | 2722w | |
tss | tss库 | trade_order 交易订单 acq_trade_order_ext 收单交易扩展 split_party分账信息表 |
insert | 9152w 10670w 3181w
|
2491W 3200W 3260w
|