テストアーキテクトが従事するのは、純粋なテスト技術の仕事ではなく、図1に示すように、製品、コミュニケーションと調整、文章表現などの組み合わせが必要な総合的な技術です。
図 1 ソフトウェア テスト アーキテクトに必要な能力
テスト テクノロジに関しては、ソフトウェア テスト アーキテクトは次のテスト テクノロジ機能を備えている必要があります。
ソフトウェア製品の品質モデル
テストの種類
試験方法
探索的テスト
自動テスト
1 ソフトウェア製品品質の 6 つの特性
図 2 ソフトウェア製品品質の 6 つの属性
1.1 機能
表 1 機能サブ属性
適合性: Windows 電卓の場合、ソフトウェア製品がユーザーに提供するすべての「計算」関連の機能が適合します。
精度: Windows 電卓の場合、電卓自体の計算結果の正確さが電卓ソフトウェアの精度を表します。
相互運用性: Windows 電卓の場合、電卓内のさまざまな機能が相互に正しく連携できるかどうかが電卓の相互運用性を表します。さらに、Windows 7 のさまざまなバージョンのサポート (さまざまなパッチを含む) など、さまざまなオペレーティング システムのサポートも含まれます。バージョン）やさまざまな動作モード（セーフ モード、ネットワーク接続を使用したセーフ モードなど）のサポートも相互運用性の表れです。
セキュリティ: Windows 電卓の場合、電卓には悪用可能なセキュリティ ホールや、「管理者とゲストの両方が同じ使用権限を持つ必要がある」などの「ユーザー権限」に関連するコンテンツが含まれていてはなりません。
機能準拠: Windows 電卓の場合、機能準拠とは、電卓としての計算ルール (二乗演算、統計演算など) が数学の関連ルールと一致している必要があることと理解できます。
1.2 信頼性
次の 3 つの進歩的な文は、ユーザーの信頼性要件を理解するのに役立ちます。
レベル 1: 機器を誤動作させないことが最善です。
レイヤ 2: 機器に障害が発生しても、主要な機能やサービスは影響を受けません。
レベル 3: 主要な機能とサービスが影響を受けた場合、システムをできるだけ早く特定して復元できます。
表 2 信頼性のサブ属性
成熟度: Windows 電卓の場合、成熟度は製品の機能が失敗する確率として理解できます。たとえば、電卓を一定期間実行し続けると、計算エラーが発生します。通常、この種のエラーはソフトウェアの再起動やデバイスの再起動などで回復できます。
フォールト トレランス: Windows 電卓の場合、フォールト トレランスはユーザーの「エラー入力」を処理する製品の能力として理解できます。
回復性： Windows 電卓の場合、回復性とは、製品自体が予期できない異常（無応答、再起動など）が発生した場合に、電卓が回復する能力として理解できます。
信頼性コンプライアンス: Windows 電卓には、信頼性コンプライアンスに関する厳密かつ明確な基準はありませんが、潜在的な規則がいくつかあります。たとえば、電卓は、すべての数学演算に対する異常な入力を識別できる必要があり、その入力に関するヒントを提供する必要があります。エラーの原因。通信製品には、システムの故障率が一定値を超えてはいけない、障害回復時間が一定値を超えてはいけないなど、信頼性やコンプライアンスに関して比較的厳しい基準が定められています。
1.3 移植性
適応性: Windows 電卓の場合、適応性は、電卓のレイアウト、サイズ、明瞭さ、キーの配置などが、異なるサイズのディスプレイ上で正常に表示できるかどうかとして理解できます。
インストール可能性: Windows 電卓の場合、インストール可能性は、電卓がさまざまな Windows オペレーティング システムに正常にインストールされ、正常に実行できるかどうかとして理解できます。
共存: Windows 電卓の場合、共存とは、電卓と他のソフトウェアが Windows 内で同時に共存でき、リソース (CPU、メモリなど) をめぐる競合が発生しないと理解できます。
置き換えの容易さ: Windows 電卓の場合、置き換えの容易さは、新しい電卓が開発され、新しい電卓が古い電卓をうまく置き換えることができると仮定すると理解できます。(これは「製品のアップグレード」を指すものではありませんが、「新しい」電卓と「古い」電卓が同時に存在する場合があることに注意してください。)
移植性への準拠: Windows 電卓の場合、移植性への準拠は、Windows 製品の移植性に関するいくつかの規則として理解できます。たとえば、電卓は特定のオペレーティング システム用に開発されていないため、すべての Windows オペレーティング システムをサポートする必要があります。
2種類のテスト
テストの種類は、テストのために考慮する必要があるさまざまな観点を指します。ソフトウェア製品品質モデル (以下、「品質モデル」と呼びます) を使用すると、テストの種類を迅速に定義して理解できます。
図 3 品質属性とテストの種類の関係
表 5 一般的なテストの種類と品質属性との関係
3 試験方法
3.1 製品テストホイールの図
テストの種類、つまり製品をテストする角度によってテストの考え方が決まります。次に議論したいのは、それをどのように行うか、つまり具体的なテスト方法です。
図4 製品テストホイールの図
図 4 に示されている品質属性の 6 つのカテゴリとテスト タイプの関係は、各品質サブ属性と各サブ属性に対応するテスト タイプには含まれていません (「品質サブ属性」のホイールを描画することもできます)。自分で撮った写真）。
製品テストにおける 2 つの重要な問題は、「ホイール ダイアグラム」から分析できます。
1つ目は、テスト検証の「網羅性」をどう確保するかという問題だ。明らかに、私たちが使用するテスト方法が 6 つの品質属性をカバーできる限り、テストに一般的な方向性の省略はありません。
2つ目は、テストの「深さ」をどうやって決めるかという問題です。一般に、テスト チームが使用するテスト方法が増えるほど、製品はより深くテストされます。
これらは試験の効果や試験による製品の品質評価に影響を与えます。さらに、「ホイール ダイアグラム」は、テスト チームの能力を評価するのにも役立ちます。ソフトウェア テスターが習得できるテスト方法が多ければ多いほど、テスト能力は強化されます。
3.2 機能試験方法
機能テストの方法には次のようなものがあります。
シングルラン正常値入力方式。
シングルラン境界値入力方式。
複数の実行シーケンスの実行方法。
マルチランインタラクション方式。
意味：
実行: ソフトウェアテストにおいて、テスターによってシミュレートされるユーザーの「操作」または「動作」。
シングルラン: ソフトウェアテストでは、テスターはユーザーの「1 つの操作」または「1 つの動作」をシミュレートします。
マルチラン: ソフトウェアテストでは、テスターはユーザーの「複数の操作」または「複数の動作」をシミュレートします。
つまり、「実行」とは、ユーザーの視点から見て意味のある操作や動作を指します。機能レベルから見ると、図 5 に示すように、「実行」によって「入力」と「出力」の可能な状況が決まります。
図 5 機能レベルでの動作の概略図
場合によっては、デザインの観点から機能を分割し、「ユーザーがメールサーバーとの新しい接続を確立した」「メールサーバーがユーザーとの接続を削除した」など、完全で意味のある動作をユーザーに提供できていないことがあります。細かい粒度の関数のようなものは、入力と出力が決まっていても「実行」としてカウントされません。現時点では、図 6 に示すように、この関数がユーザーにとって完全で意味のある動作を提供できるようになるまで、複数の関数を組み合わせることができます。
図6 機能と動作の関係
3.2.1 単回正常値入力方法
テスト時に入力される「A1」と「A2」をシステムが許容する「正常値」とするテスト方法です。
3.2.2 シングルラン境界値入力方法
テスト時に入力した「A1」と「A2」をシステムの「境界値」とするテスト方法です。
3.2.3 マルチランシーケンスの実行方法
複数の「単一実行」操作を一緒に考えると、結果は「複数実行」操作になります。テストに複数実行の順次実行方法を使用する場合、各実行間のシーケンスを分析することがこの方法を使用する鍵となります。
マルチランシーケンス実行方式は、ユーザーの操作習慣に関わる場面で非常に有効です。
さらに、マルチラン逐次実行方式は、機能構成テストでの使用にも適しています。
表 6 複数の実行シーケンスのシナリオ
シリアル番号を持つ複数の実行シナリオは、複数の実行シーケンスに関連付けられます。
1 ユーザーは最初に電子メールを送信し、次に電子メールを受信します。 いいえ いいえ
2 ユーザーがメールを受信し、受信したメールを送信した後、
3 ユーザーがメールを受信した後、別の任意のメールを送信します。 No No
3.2.4 マルチランインタラクション手法
マルチラン相互作用法とは、図 7 に示すように、機能テスト中に相互に関連する複数の実行を組み合わせてテストする方法を指します。
図 7 マルチランインタラクション手法
マルチランインタラクション方式は、複数の実行間の順序を重視するマルチラン逐次実行方式とは異なり、複数の実行間の関係性を重視しており、その関係性は、ある業務の円滑な進行など、外部的な関係となる場合があります。相互に連携することもできますが、同じリソース (メモリやその他のハードウェア リソースなど) を使用して実行するなど、本質的な関係になることもあります。
特に注意が必要なのは、これらはすべて「1 人のユーザーに対する」操作シナリオであり、「2 人の異なるユーザーが同時にメールを送信する」または「1 人のユーザーがメールを送信し、1 人のユーザーがメールを受信する」というものではないということです。実際、前者は機能テストのカテゴリに属し、後者は信頼性テストのカテゴリに属します。
3.3 信頼性試験方法
3.3.1 外れ値の入力方法
外れ値入力法は、システムがユーザーに入力を許可していない値（つまり外れ値）をテスト入力として使用する信頼性試験方法です。
3.3.2 欠陥注入法
障害埋め込み法は、システムを問題のある環境に置いてテストする信頼性テスト方法で、テストできる主な品質特性はフォールト トレランスと成熟度です。
外れ値入力方法とは異なり、外れ値入力方法では、システムが間違っていてサポートされていないとみなされる値が直接入力されますが、障害埋め込み方法ではシステムが問題のある環境に置かれますが、入力は依然として正常な値です。
ユーザーのビジネス環境にはどのような不具合、エラー、または問題がありますか? これらのシナリオをリストアップし、システムをこれらのシナリオに組み込んで通常のビジネスを実行し、現時点でのシステムの応答が妥当かどうかを分析します。
システムをユーザーのハードウェア環境に導入する場合は、システムが必要とする CPU、メモリ、ストレージ容量などのハードウェア リソースと、不足した場合のシステムの応答が妥当かどうかを考慮します。「ユーザーがメールを送信する」という例を見てみましょう。ネットワーク障害は、切断、断続的なネットワーク、パケット損失など、ユーザーにとって一般的な障害です。
システムがユーザーのシステムにインストールされている場合は、ソフトウェアの競合やドライバーの間違いなどが発生した場合のシステムの応答が妥当かどうかを検討してください。
システムが独立したデバイスの場合は、主要なコンポーネント (シャーシ、シングル ボード、プラグイン カード、ハード ドライブ、チップなど) で問題が発生したときのシステムの応答が妥当かどうかを検討してください。
3.3.3 安定性試験方法
安定性試験方法は、ある業務を長期間にわたって大容量で稼働させる信頼性試験方法であり、システムの「成熟度」を非常に効果的に試験することができ、非常に重要な信頼性試験方法です。
特に、安定性試験方法、ストレス試験方法、性能試験方法の間には一定の関係があり、この関係が製品仕様となることに注意してください。
製品仕様: 製品が処理できると約束されている最大容量または機能。たとえば、システムは最大 100 人のユーザーの同時ログインをサポートし、最大 100 のセキュリティ ポリシーの確立をサポートします。これは製品仕様です。
性能試験の目的は、製品の実際の仕様がマニュアルで約束された要求仕様と一致しているかどうかをテストすることです。明らかに、私たちが測定した最終的なパフォーマンス値は、システムが実際に処理できる最大容量または能力です。
安定性テストは性能値を下回って実行されます。実際、ユーザーがシステムを使用するとき、常にシステムを極限状態で実行させるわけではありませんが、テスト中はユーザーの実際の使用状況にできるだけ近づけるようにテストの負荷を制御することができます。より正確に、より価値のあるものにすることができます。
ストレステストは性能値よりも高い値で実行されます。テスト時の負荷がシステムの最大能力を超えましたが、この場合にシステムの機能が停止するわけではなく、実際の状況に基づいてシステムのパフォーマンスが妥当であるかどうかを分析する必要があります。たとえば、システムは最大 100 人のユーザーの同時ログインをサポートしますが、この時点で 110 人のユーザーが同時にログイン操作を開始すると、システムはこれら 110 人のユーザーのうち 100 人が正常にログインできることを保証する必要があり、これは合理的です。すべてのユーザーがログインできなくなるのではなく、10 人のユーザーがログインできなくなります。
ここで、このセクションの主題である安定性テストに戻りましょう (パフォーマンス テスト方法とストレス テスト方法については、次の記事で紹介します)。方法論的な観点から見ると、安定性試験方法はすべての試験方法の中で最も興味深いものであり、倍数、和集合、複素数、差分という「4 文字の公式」として要約できます。
「複数のワード」の本質は、テスト中に関数に対するユーザー操作の数を増やすことによってシステムの安定性をテストすることです。
「Ming Zi Jue」の本質は、システムがまだ安定しているかどうかをテストするために、テスト中に複数のユーザーがこの機能を同時に操作できるようにすることです。このテストを同時実行テストと呼ぶこともあります。
「Fu Zi Jue」の本質は、システムが安定しているかどうかをテストするために、テスト中に 1 人以上のユーザーが作成、更新、削除、同期、バックアップなどの操作を繰り返し実行できるようにすることです。
「異なる言葉」の本質は、システムが合理的な応答を継続できるかどうかを検証するために、テスト中に 1 人または複数のユーザーが異常な操作を繰り返し実行できるようにすることです。異常入力法や故障埋め込み法と比べて、『易子覚』は「継続」と「蓄積」を重視します。実際には、「別の単語」を使用してテストするほうが効果的であることがよくあります。これは、コードを開発するときに、正しい状況下でのリソースの適用と回復を考慮し、異常な状況下でのリソースの回復を無視する傾向があるためです。
3.3.4 ストレス試験方法
ストレス試験は、システムの仕様を超える負荷を一定期間継続して使用する信頼性試験方法です。
製品は仕様を公表しており、仕様範囲内で安定した信頼性の高い機能を提供することのみを約束し、システム仕様を超えた場合に正しい機能を提供することを約束するものではありませんが、ストレステストは依然として意味があります。重要な理由は、ビジネス上の緊急事態、つまりユーザーのビジネス負荷が平均的ではないためであり、図 9 に示すように、非常に短期間に負荷を超える可能性がありますが、平均して仕様を超えることはありません。
図 8 ビジネス上の緊急事態
緊急時に砂上の楼閣のように脆弱ではなく、システム仕様を超える負荷を扱わない、ユーザーが緊急事態の原因を分析できるようにログを記録するなど、現実的な対策を講じることを期待します。 。緊急時にクラッシュや再起動を繰り返すなどの致命的な問題が発生しないことが、ストレステストの本当の目的です。このテスト目標を達成するには、図 9 に示すように、ストレス テストを実行するときにバースト ロード モデルを使用する必要があります。
図9 バースト負荷モデル
製品の問題を明らかにするために、システム仕様の負荷を継続的に超えるテスト方法を使用することはお勧めできません。しかし、試験においては仕様を継続的に超える負荷モデル試験を行うことは全く無意味ではなく、当社のもう一つの信頼性試験手法である回復試験手法と一体となっています。
3.3.5 回復試験方法
回復試験法とは、図10に示すように、仕様を超えた負荷を継続して試験し、その後負荷を仕様内に下げる試験方法を指します。
図10 回復試験方法
仕様を超える負荷テストを継続的に実行する場合、許容仕様内のビジネスは 100% 正しいわけではありません。負荷が仕様値内に低下した場合、ビジネスは 100% の精度に回復できなければなりません。
ストレス テスト方法とリカバリ テスト方法についての理解をさらに深めるために、図 11 に示すように、異なる負荷の下での 2 つのモデルの「ビジネス」結果の期待値を比較するとよいでしょう。
図11 バーストロードモードと継続ロードモードによるビジネス効果の期待
2 つのテスト方法の最大の違いは、図の「黒い」部分にあることがわかります。ストレステストでバーストロードモードを使用した場合、図の黒い部分はビジネス障害を許容しませんが、連続ロードモードでリカバリテストを使用した場合、図の黒い部分はビジネス障害を許容します。
3.4 性能試験方法
性能試験の目的は、製品の実際の仕様がマニュアルで約束された要求仕様と一致しているかどうかをテストすることであり、実際に測定する性能値は、システムが実際に処理できる最大容量または能力です。
一般に、製品の要求仕様によって性能の期待値が得られ、テスターは製品が仕様を満たしているかどうかを確認するだけで済みます。要求仕様書の製品性能仕様が非常に単純で大まかな場合は、図 12 に従って性能テストを行うことができます。
図 12 テストプロセス
最初のステップは、システムの最高のパフォーマンス値をテストすることです
パフォーマンス テストを実行するときは、まずシステムの最高のパフォーマンス値をテストすることができます。性能仕様で要求される性能値をテスト項目として使用して、システム内のこれらの指標の限界をテストできます。
製品ごとに性能仕様は大きく異なりますが、一般に次の 2 つのカテゴリに分類できます。
1) 新しいビジネスを適切に処理するためのシステムの最大限の能力
新しいビジネスを正しく処理するシステムの最大の能力。これを「新しい」とも呼びます。たとえば、システムが 1 秒あたりにログインを許可できる新規ユーザーの数、システムが 1 秒あたりアクティブに開始できる新しい接続の数などです。
パフォーマンス テストはシステムの新機能に対して行われ、新しいビジネスの処理プロセスを完了するためにシステムがリソースを割り当てる速度がテストされます。ビジネス処理プロセスとリソースの総量は、システムの新しい機能に影響します。システムは「解体」せずに「構築」できないことに注意してください。完了したサービスまたは異常なサービスは適時に解体する必要があり、占有されたリソースはリサイクルして新しいサービスに使用する必要があります。
2) システムが同時に正しく処理できる最大ビジネス容量
システムが同時に正しく処理できる最大のビジネス能力は、「同時実行性」とも呼ばれます。たとえば、システムがサポートできる同時オンライン ユーザーの最大数、システムが同時に開始できる接続の最大数などです。
図 13 に示すように、「新規」と「同時実行性」の間には関係があることに特に注意してください。
図13 新規作成と同時テストの状況
注: 新規作成と同時実行の 2 つの指標は相互に影響します。たとえば、同時実行の最大容量は 4000 です。テスト中は「ビルド」のみが行われ、「破棄」はされません。1 秒あたり 150 個の新しいアイテムが作成される場合24 秒間、並列数は最大同時実行容量を超え、4000 となり、新規作成数の減少につながります。
したがって、システムの最高のパフォーマンス値をテストするときは、テスト指標間の内部関係に注意を払う必要があり、1 つの指標をテストするときに、他の指標がこの指標に影響を与えることはできません。
2 番目のステップは、パフォーマンス値に影響を与えるさまざまな要因を分析し、それらがパフォーマンスに及ぼす影響をテストすることです。
「構成」と「ビジネス」の両方がパフォーマンス指標に影響します。想像してみてください。1 ユーザー ポリシーを構成した場合と 1000 ユーザー ポリシーを構成した場合のパフォーマンスは異なるはずです。システムは 1 バイトのメールを受信する場合と、1,000 万のメールを受信する場合のパフォーマンス値は異なります。このステップでは、システム内のどの要因がパフォーマンスに影響を及ぼしているか (パフォーマンス低下) を分析し、テストを実行して、パフォーマンス低下が期待どおりかどうか、および最悪のケースが発生しているかどうかを分析する必要があります。シナリオはまだ許容可能です。妥当です。
表 7 サンプルポイントで正しく処理できる電子メールの最大数
表 8 さまざまなフィルタリング戦略で正しく処理できる電子メールの最大数
これらのパフォーマンス値をテストすると、次のことが簡単に得られます。
どの要因がシステム パフォーマンスに大きな影響を与え、どの要因がシステム パフォーマンスにあまり影響を与えないか。
パフォーマンスに対するさまざまな要因の影響の傾向。テストサンプルを選択し、数学の「カーブフィッティング」技術を使用すると、要因の影響曲線が得られ、この曲線を使用して、この減少傾向が妥当であるかどうかを分析できます。
各要因におけるパフォーマンスの最悪の値。この最悪の値が妥当かどうか、またシステムのパフォーマンスの「ボトルネック」になるかどうかを分析します。
多くの場合、パフォーマンス指標に影響を与える要因は 1 つではなく、複数の要因が存在する場合があります。このステップでは、パフォーマンスに対する 1 つの要素の影響のみをテストできます。パフォーマンスに対する複数の要素の影響を一般的なシナリオに配置し、一般的な構成とサービスをパフォーマンス テスト用に選択できます。
3 番目のステップは、シナリオに基づいてパフォーマンスをテストすることです。
最後に、「シナリオ」を単位として使用し、このシナリオでの典型的な構成と典型的なサービスのパフォーマンス値をテストします。
「ユーザーが電子メールを送信する」を例に、一般的な構成が「200 のフィルタリング ポリシー」で、電子メールのサイズが 1KB、10KB、2MB が 1:2:1 で混在していて、電子メール システムが受信できると仮定します。毎秒、最大数のメッセージを正しく処理します。
3.5 使いやすさのテスト方法
3.5.1 適合性試験方法
適合性テスト方法は、テスト中の製品のユーザー インターフェイスに焦点を当てます。
スタイル、レイアウト、要素が一貫していて統一されているかどうか。
レイアウトの合理性、操作の合理性、プロンプト等がUIのデザイン仕様に準拠しているか。
コンフォーマンステスト手法は、分かりやすさや使いやすさのコンプライアンスの観点から製品の能力をテストできますが、製品の機能が正しいかどうかは問わないため、製品のUIデザインのプロトタイプを直接テストできます。
3.5.2 ユーザビリティテスト方法
ユーザビリティテスト手法のテスト対象もユーザーインターフェイスですが、ユーザビリティテストでは、製品が提供する機能がユーザーにとって学びやすく、理解しやすく、使いやすいかどうかに重点を置くため、ユーザビリティテストと機能性テストを組み合わせる必要があります。テスト、テスト粒度としてシナリオを使用、ユーザーの観点からテスト。
表 9 ユーザビリティテストの焦点と基準
4 テスト設計テクニック
表 9 「ユーザーがメールを送信する」のテスト ポイント
4.1 テストポイントはテストケースと等しくない
テストのためにテストポイントを取得すると、私たちを不幸にし、混乱させる多くの問題が見つかるでしょう。
問題 1: これらのテスト ポイントには重複したコンテンツがあり、冗長です。
たとえば、テスト ポイント 1 とテスト ポイント 4 は両方とも「電子メールを正しく送信する」ことをテストします。
問題 2: 一部のテスト ポイントのテスト入力が不明瞭で、テスト中に何をテストすればよいかわかりません。
たとえば、テスト ポイント 1 をテストする場合、どのような「通常の入力データ」をテストしたいのかわかりません。同様の問題がテスト ポイント 5 にも存在します。
問題 3: 常に同様の環境で動作し、同様の操作を実行します。
いくつかのテスト ポイント間には特定の実行シーケンスがあり、これらのテスト ポイントをまとめてテストする必要があります。たとえば、最初にテスト ポイント 6 を実行し、次にテスト ポイント 11 を実行すると、前のテスト環境とテスト結果を最大限に活用できます。
質問4: テストのポイントの説明が雑すぎて、テストが正しいかどうかわかりません。
いくつかのテストポイントは非常に大胆に書かれており、テストの目標が何であるか、どこに焦点を当てるべきかわかりません。たとえば、テスト ポイント 4 では、「ユーザーが電子メールを送信する」と「ユーザーが電子メールを受信する」という 2 つの操作を一緒にすると、それらの「インタラクション ポイント」はどこにあるのかわかりません。
4.2 4 段階のテスト設計法
テストポイントをテストケースに加工することをテスト設計といい、その際に用いられる手法をテスト設計法といいます。パス分析、デシジョンテーブル、直交分析、同値クラス、境界値などはすべて一般的なテスト設計方法です。
テスト分析では、テスト対象をテスト方法に従って考えることでテストポイントを獲得できるため、図14に示すようにテスト分析は「発見」のプロセスですが、テスト設計は異なります。
図 14 テスト分析は「発見」プロセスです
このような実験を行い、2 人のテスターに「ホイール ダイアグラム」に基づいて同じテスト オブジェクトを分析させることができます。得られるテスト ポイントはそれほど変わりませんが、最終的に生成されるテスト ケースは大きく異なります。テストポイントからテスト設計に至るまで、テストポイントの処理、結合や分割、テストデータの選択などを行う「クリエイティブ」なプロセスだからです。
図 15 4 ステップのテスト設計法の 4 つの主要なステップ
ステップ 1: モデリング
実際、このステップでは、全員にテスト ポイントごとにオリジナルのテスト モデルを作成してもらうのではなく、テスト ポイントの特性に応じて、その後のテスト ポイントのテスト設計に適したモデルを選択します。おそらく、このステップを「モデル選択」と呼ぶのがより適切かもしれません。
「モデル選定」ではテストポイントの特性を参照する必要があるため、テストポイントを調査し、特性を分析し、分類することが重要です。現在、それらを 4 つのカテゴリに分類しています。
タイプ 1: 「プロセス」;
タイプ 2: 「パラメータ」;
タイプ 3: 「データ」;
タイプ 4:「複合」。
テスト ポイントのタイプごとに、最も適切な「モデリング」方法をいくつか示しました。
「プロセス」クラスでは、「フローチャート」を描くことでテストモデルを構築できます。
「パラメータ」クラスの場合、「入出力テーブル」を通じてテスト モデルを確立できます。
「データ」クラスについては、「等価クラス分析テーブル」を通じてテストモデルを確立できます。
「組み合わせ」クラスの場合、「因子テーブル」を通じてテスト モデルを確立できます。
ステップ 2: 基本的なテスト ケースを設計します。
このステップでは、このテスト モデルをカバーするために、すでに確立されているテスト モデルの基本的なテスト ケースをいくつか設計します。
テストケースと基本テストケースの最大の違いは、テストケースがテスト条件（「○○の環境下で、○○テストを行う」のような記述）とテストデータ（つまり、入力される「パラメータ値」や"数値" )、基本テスト ケースはテスト条件を決定するだけです。
ステップ 3: テスト データを補足します。
このステップでは、基本テスト ケースのテスト入力を決定し、テスト データを補完し、基本テスト ケースを実際のテスト ケースにアップグレードします。
ステップ 4: 展開します。
モデルは特効薬ではなく、設計のテストに関するすべての問題を解決できるわけではありません。また、システムの有効性を高めるために、経験に基づいていくつかのテスト ケースを追加する必要があります。特に、システム内の欠陥が発生しやすい箇所を理解する必要があります。
テストポイントを分類する
4 段階のテスト方法を使用する前に、まずテスト ポイントを分類する必要があります。分類の基準は、テストポイントが「プロセス」タイプの特徴、「パラメータ」タイプの特徴、「データ」タイプの特徴、および「組み合わせ」タイプの特徴を有するかどうかを見ることである。
