テストデータの設計法：
テスト・データ構造は、データソース、一般的にはデータのソースを見る必要がある場合には、3つがあり、1としても知られている通常の操作、異常な状況、境界線と完全なデータを構築するために、他の情報、ために、テスト対象のシステムのニーズの分析に基づいています「作られた」データ。
これは、次のような最も基本的なデータだけでなく、含まれています：ユーザー、権限、設定、生データを、だけでなく、上記の業務データを含んでいます。比較的小規模なシステムと大規模システムのための実現可能な高いために複雑になることがあります。
テストデータの設計方法2：
第二の方法は、生産システムのアップグレードや追加機能に対するテストのための同様のシステムを持っている既存のシステムを、使用することです。この場合、データは既にエクスポートし、本番環境で実行されています。これに基づき、データを再編成し、
テスト・データの処理。
テストデータ設計法3：
ビジネスはまた、蓄積された試験データの検証を完了しながら、別の方法は、システムへの既存の非電子ビジネスデータエントリにあります。テスト側データ蓄積の側。しかし、このデータの蓄積があるため、一定の制限を持っている傾向があります
すでに、基本的なビジネスデータの発生により、一貫した、正しいこと、およびいくつかの特定のサービス（ビジネス不定期）のデータが欠落することができます。これは、テスト要件の分析を必要とし、業務を完全にカバーするために追加の新しいテスト・データ
タイプ。
テストデータアプリケーション：
チェックがある場合は1、データが空であってはなりません。
図2は、デフォルト値のデフォルト値のデータが正確です。
他の関数によって生成される3、基準データ、リアルタイムリフレッシュするかどうか;
4、ページダウン、システムの再起動またはシャットダウンした後、初期設定データなど
図5に示すように、データ長が、制御のタイプは、ID番号、文字が存在するであろう実際のビジネスのように、合理的であり、そして最終に表示されます
一つ
対応方法：
等価クラス、境界値、シーン方法
優先度の角度：ユーザー
設計とテストデータのメンテナンス：
<ignore_js_op>
テストデータの概要：
1だけでなく、「ダーティ」データの検証環境では、我々はクリーンな環境で検証する必要があります
2は、データ・タイプとビジネスシナリオの各々をカバーすることが必要です
図3は、アカウントに将来の製品の成長と変化を取る必要があります
4、だけではなく、何がないことを確実にするために何を同じにすることができることを保証するために、
図5に示すように、履歴データに追加、削除、変更の影響のデータ（追加、削除、変更、検索）
→→→→なしの変更があった削除せず→
→→→→なしの変更があった削除せず→
図6に示すように、簡略化されたテスト実行時間、テスト効率を向上させます
試験データの例：
<ignore_js_op>
http://www.bcbxhome.com/bcbx/forum.php?mod=viewthread&tid=29&fromuid=27
(出处: 编测编学软件测试)