i. 原則の問題
さまざまな視点からソフトウェアのテストは、2つの異なるテストの原則を導出する、ユーザーの視点から、ソフトウェアのテストは完全に製品が受け入れられるかどうかを検討するように、ソフトウェアの問題や欠陥を公開することができます希望である、ビューの開発者の観点から、テストは、ソフトウェア製品がエラーを持っていないことを示すことができる希望である、正しくユーザーのニーズを実装されている、人々のソフトウェアの品質を確立するためにソフトウェアの品質への信頼。これらの原則を達成するために、次の点に注意する必要があります：
- 「テストは早めに、そして何度も」が開発者のモットーであるべきです。
- プログラマーは自分自身のプログラムをチェックすることを避け、テストは独立したプロのソフトウェアテスト組織によって行われるべきです。
- テストケースの設計は、正当な入力と不正な入力、さまざまな境界条件、および異常なネットワーク遮断や停電などの極端で予期しない状態を作り出すための特別なケースを考慮に入れる必要があります。
- プログラマーのプログラミング・レベルや癖に大きく関係する、テストにおけるエラー集中の現象に必ず注目してください。
- テストエラーの結果の確認プロセスがなければなりません。一般的にエラーのうちAのテストがあり、確認のためにBがなければなりません。
- 厳密なテスト計画を作成し、テストのスケジュールはできるだけゆるやかに立てましょう。
- すべてのテストプロセスを適切に文書化することの重要性は自明であり、テストの再現性は、しばしばテスト文書に依存します。
第二に、ソフトウェアテスト戦略
- ソフトウェアのテスト戦略：テストプロジェクトの特定の環境制約とソフトウェアテストの原則、方法と手段のコレクションに基づいて、特定のソフトウェアテストの標準、テスト仕様の指導の下で。一般的にテストの実施段階で完了します。一般的に、テスト計画の作成後にテスト計画を通じて要件の見直しは、テスト戦略だけでなく、環境要件、リソース要件、人員の組織構造、作業負荷の見積もり、リスクの見積もり、テストの合格基準、テストの失敗/ハング基準、製品の配信のテスト完了などが含まれています。
- ソフトウェアテスト戦略の基礎 2.1 戦略とソフトウェアテスト戦略
- 戦略：特定の政治路線の指導の下で、闘争の原則、方法と手段の特定の条件に応じて。
- ソフトウェアテスト戦略：特定のソフトウェアテスト標準の指導の下で、テストプロジェクトの特定の環境制約とソフトウェアテストの原則、方法と手段のコレクションに基づいて、仕様をテストします。2.2ソフトウェアテスト戦略の重要性
- 完全な、または網羅的なテストのいずれかの作業負荷は、実際には、実現不可能な巨大であるため、実際のテストは、テスト対象のプログラムがエラーや欠陥を見逃していないことを保証することはできません；
- このような見落としを最小限にし、可能性のあるエラーを最大限に発見するためには、テストを実施する前に、適切なテスト方法論とテスト戦略を決定し、これに基づいて詳細なテストケースを作成することが重要です。
2.3 ソフトウェアテスト戦略に影響を与える要因
ソフトウェアテスト戦略は、ソフトウェアライフサイクル、ソフトウェアテスト方法、技術、およびツールの変更に伴って変化します。これは、テスト戦略を開発するときに、テスト戦略の影響因子とその依存関係を考慮する必要があります。これらの影響要因には、テストプロジェクトのリソース要因、プロジェクトの制約、テストプロジェクトの特別なニーズが含まれます。
2.4 ソフトウェアテスト戦略の策定プロセス 必要なハードウェアおよびソフトウェアリソースの詳細な説明の入力。
- テストに必要な人材の役割と責任、スケジュールの制約；
- 試験方法、試験基準、完了基準；
- 対象システムの機能的・技術的要件
- システムの制限など承認され署名されたテスト戦略文書、テストケース、テスト計画書の出力、解決策を必要とするテスト項目、プロセス
2.4.1 検査の必要性の判断
- テスト要求事項が定義するのは、テストの内容、すなわちテストの具体的な対象です。テスト要求事項を分析する際には、以下の一般的なルールを適用することができます：
- テスト要件は、観察可能で測定可能な動作でなければなりません。テスト要件が観察または測定できない場合、要件が満たされているかどうかを判断するために評価することはできません。
- 各ユースケースやシステムの補足要件とテスト要件の間には、一対一の関係はありません。通常、ユースケースには複数のテスト要件があります。1 つ以上のテスト要件を導き出す補足要件もあれば、テスト要件を導き出さない補足要件もあります。
- テスト要件の情報源は、ユースケースモデル、補足要件、設計要件、ビジネスユースケース、エンドユ ーザインタビュー、ソフトウェアアーキテクチャ文書など、数多くあります。テスト要件を決定するために使用できる情報を収集するために、これらすべての情報源を調べる必要があります。
2.4.2 リスクの評価とテストの優先順位付け
- テストを成功させるには、リソースの制約やリスクなどの要因を、テスト作業においてうまく秤にかけることが必要です。そのためには、最も重要で、意味のある、あるいはリスクの高いユースケースや成果物を最初にテストするように、テ スト作業の優先順位を決めるべきです。テスト作業の優先順位を決定するために、リスクアセスメントと実施概要を実施し、テストの優先順位決定 の基礎として使用する必要があります。2.4.3 テスト戦略の決定
- 良いテスト戦略には、実施するテストの種類やテストの目的、テストを実施するフェーズ、テクニック、テストの結果やテストが完了したかどうかを評価するために使用するルーブリックや基準、テスト戦略に記載されているテストの取り組みに影響を与える特別な事項などを含める必要があります。良いテスト戦略は、どのようにして決められるのでしょうか？この質問には、テスト技法に基づくテスト戦略と、テストシナリオに基づくテスト戦略の2つの側面から答えることができます。テスト技法に基づくテスト戦略のポイント よく知られたテスト専門家は、様々なテスト技法を用いた包括的な戦略を示しています。プログラムの機能仕様に入力バーの組み合わせが記述されていれば、因果関係ダイアグラム法を開始。テストシナリオに基づくテスト戦略 テスト手法に基づくテスト戦略では、一般的に以下の点を考慮する必要があります：プログラムの重要性と失敗した場合に発生する損害に応じて、プログラムのテストレベルとテストフォーカスを決定すること、過剰テストと過小テストを避け、できるだけ多くのプログラムエラーを見つけるために、慎重に検討し、できるだけ少ないテストケースを使用すること！2.4.4 テスト戦略へのアプローチ
- 静的手法と動的手法
- いわゆる静的アプローチとは、テスト対象のプログラム自体を実行することなく、ソース・プログラムの文法、構造、手続き、インターフェースなどを分析または検査することによって、プログラムの正しさをチェックすることです。静的アプローチでは、プログラムの静的な特性を分析し、パラメータの不一致、ループや分岐の不適切な入れ子、許可されていない再帰、未使用の変数、NULLポインタ参照、疑わしい計算などの欠陥や不審な点を特定します。静的テストの結果は、さらなるエラーチェックやテストケースの選択に利用することができます。
- 動的アプローチとは、テスト対象のプログラムを実行し、その実行結果と期待される結果との差異を確認し、 実行効率や頑健性などの性能を分析することであり、テストインスタンスの構築、プログラムの実行、 プログラムの出力結果の分析の3つの部分から構成されます。2.4.5 機能テストと構造テスト 機能テストとは、プログラムの機能抽象度に基づいてプログラムを機能単位に分割し、テスト用データ抽象度に基づいて各 機能単位のテストデータを生成することです。この方法でテストを行う場合、テスト対象のプログラムは開けることのできないブラックボックスとして扱われるため、内部構造を把握することができず、ブラックボックステストとも呼ばれます。いわゆる等価クラスとは、入力ドメインの集合体であり、その集合体の各入力は、プログラムの誤りを暴露するために等価であり、プログラムの入力ドメインをいくつかの部分に分割し、それぞれの部分から代表的なデータをいくつか選んでテストケースとするのが等価クラス分割法です。機能テストの基本的な手法です。b. 因果関係図法 因果関係図とは、自然言語で記述された仕様書を形式言語に変換したもので、この形式言語は、実際には簡略化された記法で数値論理図を表現したものです。因果関係図法は、効率的なテストケースのセットを体系的に選択するのに役立つ手法であり、さらに、プログラム仕様の不完全性や二項対立を指摘します。c. 限界分析 ソフトウェアは、入出力領域の境界付近でエラーが発生しやすいことが証明されています。 限界分析は、境界条件を考慮してテストケースを選択する機能テスト手法です。いわゆる境界条件とは、入力と出力の等価クラスが、これらの状態条件の境界の少し上と少し下にある、その端に直接ある相対的なものです。エッジ解析は、同値クラスの定義を補完する有用な方法です。構造テスト（Structural Testing） 構造テスト（Structural Testing）は、テスト対象のプログラムの内部構造に基づいてテストケースを設計 するテストの一種で、ホワイトボックステスト（White Box Testing）とも呼ばれます。ホワイトボックステストは、構造テストまたは論理駆動テストとも呼ばれ、製品の内部動作が仕様書に従って正しく実行されているかどうかを検出するためにテストすることができる製品の内部動作プロセスを知ることであり、プログラムの内部構造に従って手順をテストし、プログラムの各パスがその機能に関係なく、所定の要件に従って正しく動作する能力を持っているかどうかをチェックすることです。主な方法は、ロジック・ドリブンテスト、ベースパス・テストなどで、主にソフトウェアの検証に用いられます。ホワイトボックス法では、プログラムの内部論理構造を包括的に理解し、すべての論理パスをテストします。ホワイトボックス方式は、網羅的パステストです。このオプションを使用する場合、テスト者は、テストデータを導き出すためにプログラムの論理を調べることから始め、プログラムの内部構造を調べる必要があります。プログラムを通る独立したパスの数は天文学的な数字になります。しかし、すべてのパスをテストしたとしても、エラーが発生する可能性があります。第一に、網羅的なパス・テストでは、設計仕様に違反するプログラム、すなわち本質的に間違っているプログラムを特定することはできません。第二に、網羅的なパス・テストでは、パスの欠落によるプログラムのエラーを発見することはまずできません。第三に、網羅的なパステストでは、データに関連するエラーを検出できない可能性があります。機能テストとは異なり、構造テストはプログラムの内部構造を扱います。ユーザは、プログラムの仕様に基づく機能テストを好みますが、構造テストは、機能テストではしばしば発見されない潜在的な論理エラーを検出することができます。両者には長所と短所があり、しばしば組み合わせて使用されます。ソフトウェアテストの焦点
- テストケースの設計 テストケースの設計は、ソフトウェアテストプロセス全体の中核です。テストケースは、テスト対象の品質要件を反映し、テスト対象の品質評価を決定します。
- テスト作業の管理 特に、複数のサブシステムを含む大規模なソフトウェアシステムでは、テスト作業に多くの人的・物的リソースが必要となり、効果的なテスト作業を行うためには、効果的なテスト作業の管理が必須条件となります。
- テスト環境は実際のテスト環境と一致している必要があります。
- ブラックボックステストとは、機能テストやデータドリブンテストとも呼ばれ、プログラムの内部論理構造を考慮することなく、各機能が要件を満たしているかどうかを検出するテストを通じて、ソフトウェアの機能要件/実装をテストすることです。
- ブラックボックステスト手法 機能分割 等価クラス分割 境界値分析 原因と結果図 エラー推測 など
V. ホワイトボックステスト
- ホワイトボックスのテストは、また、構造テストやロジック駆動型のテストとして知られている、通常の操作の設計に従ってソフトウェアの内部要件かどうかを検出するためにテストを通じて、ソフトウェアの内部の作業プロセスを認識する必要があります。
- ホワイトボックステストの主な方法は、プログラムの主な構造の一部に対応しています：ステートメント、ブランチ、論理パス、変数、ホワイトボックステストの主な方法は次のとおりです：ステートメントカバレッジの方法ブランチカバレッジの方法論理カバレッジの方法VI.手動テストと自動テストa.手動テストの欠点は、テストの作業負荷が大きく、反復的であり、回帰テストを達成することは困難であることです。作業：管理、設計、実装、および報告、テストのオーバーヘッドの多くを保存するには、手動テストの一部を完了することができますテストを達成することはできません。
- 全試験工程を手作業で行うことは、試験の科学的厳密性を保証するものではありません。
- 不具合を修正すればするほど、回帰テストは難しくなります。
- 現在の仕事の進捗状況や生産性を測定するための正確なデータを意思決定者に提供できる人はいません。
- 度重なるテストによる燃え尽きやその他の人的要因によって、テスト基準が一貫性を欠くことになります。
- テストに時間がかかればかかるほど、テストの厳しさは低くなります。
- 自動化されたテストにより、テスト担当者は繰り返しの退屈なテスト実行から解放され、テストの設計や結果の分析により多くの時間を費やすことができます。
- ソフトウェアテストは完全に自動化できません
- すべての手動テストタスクを完了できない場合
- 創造性がなく柔軟性に欠け、テストの妥当性を向上させません。
- 特にソフトウェアが不安定な場合、予期せぬ問題が発生する可能性があります。
- テストスクリプトのメンテナンス
- 単体テスト
- 単体テスト
- 統合テスト
- システムテスト
- ユーザー受入テスト
