ALTA-E-3.2.4 (K4) TASの実装、使用、保守要件の要素を分析する
テストケース自動化のアプローチ
テストケースを自動化するためのアプローチは、大きく4つに分けられます。
TAEが自動テストスクリプトに直接テストケースを実装する
特徴: 抽象化が低く、テストスクリプトとテストケースが密結合している。
メリット: シンプルで導入が容易。
デメリット: 保守性が低く、変更に弱いため、大規模なシステムには不向き。
TAEがテスト手順を設計し、それを自動テストスクリプトに変換する
特徴: テスト手順とテストスクリプトが分離されており、ある程度の抽象化が実現できる。
メリット: テスト手順の変更が比較的容易。
デメリット: テストスクリプトの生成が手動で行われるため、効率が悪い。
TAEがツールを使用してテスト手順を自動テストスクリプトに変換する
特徴: 抽象化と自動化の両方のメリットを兼ね備えている。
メリット: テスト手順の変更が容易で、テストスクリプトの生成も自動化できる。
デメリット: ツールの選定や設定が複雑になる場合がある。
TAEが自動テスト手順を生成するツールを使用する、モデルから直接テストスクリプトを変換する、またはその両方を行う
特徴: 自動化の度合いが最も高く、高度な抽象化が実現できる。
メリット: テストケースの生成が高度に自動化され、メンテナンスコストが低減できる。
デメリット: ツールの導入コストや学習コストが高い場合がある。
確立された自動化アプローチ
キャプチャ/プレイバックアプローチ
これは選択肢 1 で使用できる
構造化スクリプティングアプローチ、データ駆動アプローチ、キーワード駆動アプローチ
これらは選択肢 2 または 3 で使用できる
モデルベースドテスト（プロセス駆動アプローチを含む ）
これは選択肢 4 で使用できる
キャプチャ/プレイバックアプローチ
主な概念
キャプチャ/プレイバックアプローチは、ソフトウェアテストにおいて、テスト実行中のシステムとのやり取り（入力と出力）を記録し、後でその記録を再生することでテストを自動化する手法です。
キャプチャ: テスト実行中に、ユーザーの操作やシステムの応答を記録します。
プレイバック: 記録された操作を自動で再生し、システムの挙動を検証します。
利点
導入の容易さ: セットアップや使用が比較的簡単で、特別なプログラミングスキルがなくても導入できます。
GUIレベルとAPIレベルの両方に対応: グラフィカルユーザーインターフェースだけでなく、APIレベルでのテストも可能です。
欠点
変更への脆弱性: システムの変更（GUIのレイアウト変更など）に弱く、テストスクリプトの修正が必要になることが多いです。
テストケース作成のタイミング: システムが完成してからでないと、テストケースの作成を開始できないため、早期のテストが困難です。
線形スクリプティング
主な概念
線形スクリプティングは、手動で行っていたテスト手順を自動化するためのシンプルな手法です。テストツールがテストの実行を記録し、その記録を再生することで、テストを自動化します。
手動テストの記録: テストツールが、テスト実行者の操作を逐一記録します。
スクリプトの再生: 記録されたスクリプトを再生し、テストを自動実行します。
スクリプトの編集: 記録されたスクリプトは、必要に応じて編集することができます。
GUIテストの自動化: 主にGUIを持つソフトウェアのテストに適しています。
利点
手軽な導入: プログラミングスキルがなくても、簡単にテスト自動化を始めることができます。
準備作業が少ない: テストツールを習得すれば、すぐに記録と再生を開始できます。
欠点
保守性の低さ
テストケースの増加に伴う作業量の増加: テストケースが増えるほど、スクリプトの保守作業も増えます。
スクリプトの複雑化: 長いスクリプトは、理解や変更が難しくなります。
再利用性の低さ: 同じような処理が含まれるスクリプトでも、再利用が難しい場合があります。
専門知識の必要性: テストツールの独自言語を学ぶ必要があり、学習コストがかかります。
スクリプトの可読性の低さ: コメントが不足していると、スクリプトの内容を理解するのが困難です。
構造化スクリプティング
主な概念
構造化スクリプティングは、テスト自動化におけるスクリプティング手法の一つです。この手法の最大の特徴は、スクリプトライブラリの導入にあります。スクリプトライブラリとは、複数のテストで共通して利用できる、再利用可能なスクリプトの集まりです。例えば、システム（SUT）とのインタフェース操作など、頻繁に利用される一連の命令をスクリプト化し、ライブラリとして管理することで、テストスクリプトの作成効率を向上させることができます。
利点
保守性の向上: 共通の操作をスクリプトライブラリに集約することで、スクリプトの変更が必要になった場合、一箇所を修正するだけで済みます。これにより、保守作業の効率化と、人為的なミスによるエラーの減少が期待できます。
開発コストの削減: 新しいテストを作成する際、既存のスクリプトライブラリを再利用することで、スクリプトを最初から作成する手間を省くことができます。特に、複数のテストで共通する処理が多い場合、その効果は大きくなります。
テスト効率の向上: スクリプトライブラリを活用することで、より少ないスクリプトで多くのテストをカバーすることができます。
欠点
初期投資: 共通のスクリプトライブラリを作成するためには、プログラミングスキルが必要となり、初期の開発コストがかかります。
管理の複雑化: スクリプトライブラリは、適切に管理しないと、スクリプトのバージョン管理や、必要なスクリプトの検索が困難になる可能性があります。そのため、命名規則やドキュメント作成など、一定の管理体制を構築する必要があります。
データ駆動テスト
主な概念
データ駆動スクリプティング技法は、構造化スクリプティング技法をベースに、テスト入力をスクリプトから切り離し、データファイルに格納することで、テストの再利用性を高めたスクリプティング技法です。
制御スクリプト: テストを実行するための基本的な手順を記述したスクリプト。
データファイル: テストケースごとに異なる入力データを格納したファイル。制御スクリプトは、このデータファイルから入力を読み込み、テストを実行します。
利点
テスト作成コストの削減: テストケースの追加や変更が容易になり、テストの作成コストを大幅に削減できます。
テストカバレッジの向上: 多くのテストケースを自動化できるため、テストカバレッジを向上させることができます。
テストアナリストの負担軽減: テストアナリストは、データファイルを作成するだけで新しいテストケースを作成できるため、技術的な知識がなくてもテストの作成に参加できます。
欠点
データファイル管理の複雑さ: データファイルの管理が煩雑になる可能性があります。
否定テストケースの漏れ: テストデータに特化するため、否定的なテストケースが漏れてしまう可能性があります。
キーワード駆動テスト
主な概念
キーワード駆動スクリプティング技法は、データ駆動スクリプティング技法をベースに発展したテスト自動化の手法です。主な特徴は以下の通りです。
テスト定義ファイル: テストケースを、人間が理解しやすいキーワードを用いて記述します。データ駆動スクリプティングのデータファイルと異なり、高レベルな命令（キーワード）を含みます。
キーワード: テスト対象システムとの相互作用を表す抽象的な命令です。例えば、「注文の実行」や「アカウントの作成」などがキーワードに該当します。
テストケース: キーワードと関連するデータの組み合わせで構成されます。
テストアナリストの役割: キーワードファイルの作成・保守が主な役割となります。
利点
テスト作成の効率化: キーワードを定義することで、複雑なテスト手順を抽象化し、テストケースの作成を簡素化できます。
保守性の向上: テストケースがキーワードで記述されるため、可読性が高く、変更に強いテストを作成できます。
技術依存性の低減: テストアナリストは、詳細なプログラミング知識がなくても、キーワードを用いてテストを作成できます。
欠点
実装の複雑さ: キーワードの実装は、テスト自動化エンジニアにとって大きな負担となります。特に、ツールがサポートしていない場合は、独自に実装する必要があります。
キーワードの適切性: キーワードが適切に定義されていない場合、再利用性が低くなり、テストの品質が低下する可能性があります。
小規模システムへの適用: 小規模なシステムでは、実装のオーバーヘッドが大きくなり、コスト対効果が低い場合があります。
プロセス駆動スクリプティング
主な概念
キーワード駆動スクリプティングの拡張: プロセス駆動アプローチは、キーワード駆動スクリプティングをベースに発展した手法です。
シナリオベースのテスト: テストシナリオをスクリプトで記述し、パラメータや高レベルのテスト定義と組み合わせることで、より柔軟なテスト設計が可能になります。
アクション間の論理関係: テストアクション間の論理的な流れを定義することで、フィーチャテストやロバストネステストなど、さまざまな種類のテストに対応できます。
利点
ワークフローベースのテスト定義: ビジネスプロセスに沿ったテストケースを定義できるため、テスト設計が直感的になります。
高レベルワークフローの実現: 詳細なテスト手順をライブラリ化し、高レベルなワークフローで組み合わせることで、テスト効率を向上できます。
欠点
専門知識の必要性: テストアナリストがSUTのプロセスを深く理解している必要があるため、導入にはある程度の学習コストがかかります。
ツールのサポート: ビジネスプロセスのロジックをツールが十分にサポートしていない場合、実装が複雑になる可能性があります。
プロセスの品質が重要: プロセスの定義が不適切な場合、テストの信頼性や効率性に悪影響を与える可能性があります。
モデルベースドテスト
主な概念
モデルベースドテストは、従来のテストスクリプト作成とは異なる手法で、テストケースを自動生成するアプローチです。抽象的なモデルを基にテストケースを作成するため、テスト対象の本質的な部分に焦点を当てたテスト設計が可能になります。
モデル: テスト対象の構造や振る舞いを表現した抽象的な表現。
テストケース自動生成: モデルから、さまざまなテストシナリオを自動的に生成します。
抽象化: テスト対象の細かい実装の詳細から離れ、より高レベルな概念でモデル化します。
利点
テストの本質に集中: テスト対象のビジネスロジックやデータ構造など、重要な部分に集中してテスト設計を行うことができます。
再利用性: モデルを再利用することで、異なるシステムや技術のテストにも応用できます。
保守性: 要件変更が発生した場合、モデルを修正することで、すべてのテストケースが自動的に更新されます。
効率化: テストケースの生成が自動化されるため、人的なミスを減らし、効率的にテストを実行できます。
欠点
専門知識が必要: モデルの作成には、専門的な知識とスキルが必要となります。
ツールが未成熟: モデルベースドテストのためのツールはまだ発展途上であり、機能が限定的なものもあります。
プロセス調整: 従来のテストプロセスを調整する必要があります。例えば、テスト設計者の役割を明確化したり、モデルの品質管理を行う必要があります。
練習問題
Question #13 (3 point)
Question #14 (3 point)
【出典元】
ISTQBテスト技術者資格制度
Advanced Level シラバス
テスト自動化エンジニア
Version2016.J01
この記事が気に入ったらサポートをしてみませんか？