ソフトウェアシステムテストの知識ポイントの概要

システムテスト

コンセプト

ソフトウェアテストは、指定された要件を満たしているかどうかを確認したり、期待される結果と実際の結果の違いを明確にしたりすることを目的として、手動または自動の手段を使用してソフトウェアシステムを実行または測定するプロセスです。

コンテンツ

MCP

ミニマルコンセプトの原則

ソフトウェアのライフサイクル

プラン

開発目標を決定する: 小さなソフトウェアを開発する

プロジェクトの実現可能性調査を完了する: それが実行できるかどうか、そしてそれを行うことに意味があるかどうか

プロジェクトの進捗状況を見積もり、調整する: 人員、時間の予算

実施計画の策定

需要分析

プロジェクト要件の分析と整理：開発が必要な機能、詳細な機能

整理した要件をもとに、要件仕様書（SRS：Software Requirement Supplement）を作成します。

製品のプロトタイプを作成する

デザイン

プロジェクトの概要設計を完了する

完全な詳細設計

コーディング

概要設計仕様書と詳細設計仕様書に従ってコードを完全に記述します

テスト

単体テスト：プログラムの最小単位（クラスの関数やコード）

統合: モジュール間のインターフェースのテスト

システム: コンパイルされたシステム全体をテストするプロセス

受け入れ: 顧客とのテストを完了する

運用・保守

製品の導入

運用・保守

機能アップグレード

パフォーマンスの向上

共通テストモデル

伝統的なウォーターフォールモデル

短所: 開発完了後のテスト後、修正コストが膨大になる

Vモデル

特徴: テストプロセスは洗練され、単体テスト、統合テスト、システムテスト、受け入れテストの 4 つの異なる段階に分かれています。

短所: テスト後のリスク問題は解決されない

Wモデル

アドバンテージ

①テスト活動と開発を同時進行

②テスト対象はプログラムだけでなく要件や設計も対象

③ソフトウェアの不具合を早期に発見することで開発コストを削減できる

欠点がある

柔軟なバージョンの反復をサポートできない

アジャイル開発モデル

特徴

アジャイル開発およびテストモデルは、主に、現代のインターネット企業の「短く、平坦で、速い」開発リズムに適応するように設計された開発およびテストモデルです。

コンテンツ

①イテレーション：各イテレーションをスプリントと呼び、各スプリントで実装するために選択された要件がスプリントバックログに整理されます。各スプリントは通常 1 か月をサイクルとします。

②プロダクトオーナー：プロダクトマネージャーに相当します。プロジェクト全体のすべての要件を整理し、優先順位に従って要件をプロデュースバックログに配置します。

③ デイリーミーティング: デイリーミーティング。通常はスタンドアップミーティングの形式で行われます。一人の発言は原則1分以内で、主な内容は昨日完了した作業、今日行う作業、直面するリスクや問題点の3点です。

④ スプリントバーンダウン: 残りのワークロードを記録するための反復バーンダウンチャート

⑤スプリントレビューミーティング：イテレーションレビューミーティング。主にこのイテレーションでどのような問題があったのか、どう改善するかなどを検討します。

⑥スクラムマスター：チームリーダーに相当し、チームメンバーを統一的に管理する。

ソフトウェア品質モデル

意味

ソフトウェア品質モデルは、さまざまな側面から製品の品質特性を考慮するための基礎を提供します。

コンテンツ

機能性、信頼性、使いやすさ、パフォーマンス効率、互換性、セキュリティ、保守性、移植性

移植性と互換性の違い:

移植性は製品の内部品質であり、コードがさまざまなプラットフォームに正しくインストールおよび構成できるかどうかに重点が置かれます。

互換性は製品の外部品質であり、エンドユーザーが認識できるさまざまなブラウザ、さまざまな解像度、さまざまなデバイスの正しい使用と表示にさらに関係します。

試験方法

ブラックボックステスト

ブラックボックステストとは、テスト対象のソフトウェアのコード構造を知らずに、製品の要件と仕様に基づいてエンドユーザーの観点からソフトウェアの入出力をテストするプロセスを指します。これはブラックボックステストと呼ばれます。

ホワイトボックステスト

テスト対象のソフトウェア自体のコードと構造に基づいて、テスト対象のソフトウェアのコードと構造をテストするプロセスを指し、ホワイトボックステストと呼ばれます

グレーボックステスト

ホワイトボックスとブラックボックスの間では、一般的に、グレーボックスはインターフェイスをテストします。たとえば、関数名、パラメーター、関数の戻り値のみがわかりますが、関数の内部実装構造はわかりません。

統合テスト

ユニットがテストされ、根本的なソフトウェアの欠陥が見つかって修復された後、それらは統合され、モジュールの組み合わせの統合テストが行われます。これには主にインターフェイスのテストが含まれます。

確認テスト

スモークテストとも呼ばれ、基本的な機能が実装されているかどうかを確認しますが、通常は正式なテストプロセスとしては使用されません。

システムテスト

システムのすべての機能をテストし、すべてのソフトウェアユーザーの操作をシミュレートします。

回帰試験

新しいバージョンのソフトウェアをテストする場合は、以前のテストケースを繰り返します。

目的

①以前の不具合が修正されていることを確認する

② 不具合の修復により新たな不具合が発生しないことを確認する

受け入れテスト：需給関係者と第三者によるテストであり、実行テーマに応じてαテスト（社内）、βテスト（パブリックβ）、γテストに分けられます。

プロジェクト関連書類

開発段階の主なドキュメント

要求仕様

概要設計

きめ細かなデザイン

テスト段階での主なドキュメント

テスト計画とシナリオ

テストケース

不具合報告

テストレポート

方法

テストプロセス

分析する

要件レビュー (要件レビューチェックリスト)

需要はどこから来るのか、需要がなかったらどうするのか?

要件の評価をどのように評価するか?

テスト要件の分析

なぜテスト要件分析を行う必要があるのでしょうか?

テスト要件分析プロセス

テストポイントを取得する

計画: テスト計画とソリューション文書の作成

テスト設計の概念

ユースケースの作成

テスト番号: TC TestCase

テストタイトル: このユースケースがテストしているテストポイントを 1 文で説明します。

優先順位: 高、高、低。プロジェクト時間が不足している場合や人員が不足している場合に、主要なテストケースを優先的にテストできる機能です。

プリセット条件: このユースケースを実行するときにシステムが事前に到達する必要がある状態または条件。オプション。存在する場合は書き込みます。存在しない場合は書き込まないでください。

テスト手順: このユースケースをテストするときにどのような操作を実行する必要があるかを詳しく説明します。

期待される結果: ニーズから生じ、達成する必要がある結果。

実際の結果: 実際のオペレーティングシステムの後に得られた結果。

テスト結果: 合格/不合格/NA 合格期待される結果は実際の結果と同じです。失敗期待された結果と実際の結果が異なります。 N/A は、現在のユースケースが適用できない、または操作できないことを意味します

設計: テストケースの設計

テストケースの設計方法

同値クラスメソッド

入力フィールド: すべてのユーザーが内容を入力できる領域

同値クラスの設計手順

同値クラス表を作成し、入力ごとに同値クラスを分割し、同値クラス表を取得して、各同値クラスに固有の番号を指定します。

まだカバーされていない有効な同値クラスをできるだけ多くカバーするテストケースを設計します。すべての有効な等価クラスがテストケースでカバーされるまで、この手順を繰り返します。

無効な同値クラスを 1 つだけカバーするようにテストケースを設計します。無効な同値クラスがすべてカバーされるまで、この手順を繰り返します。

同値クラス分割原理

入力条件が値の範囲または値の数を指定している場合、1 つの有効な同値クラスと 2 つの無効な同値クラスを決定できます。

入力年齢が 18 ～ 25 歳である必要がある場合、18 ～ 25 は有効な同等クラスとなり、18 歳未満と 25 歳以上は 2 つの無効な同等クラスになります。

関数には 3 つのパラメーターが必要です。その場合、3 つのパラメーターは有効な同値クラスであり、3 つを超えるパラメーターと 3 つ未満のパラメーターは無効な同値クラスになります。

入力条件では、入力値のセットを指定するか、満たす必要がある条件を指定します。これにより、有効な同値クラスと無効な同値クラスを決定できます。

たとえば、学歴の値を入力する必要があり、学歴に大学、学士号、修士号、博士号、およびポスドクが含まれる場合、学歴内のこれらの値は有効な同等クラスであり、同等の値に該当する値はすべて有効です。この学歴セットに属さない場合は、同等クラスとして無効です。

入力条件がブール値の場合、有効な同値クラスと無効な同値クラスを判定できます。

たとえば、入力の性別が女性の場合、女性は有効な等価クラスとなり、男性は無効な等価クラスになります。

すでに分割された同値クラスの各要素がプログラム内で別々に処理されることが確実にわかっている場合は、同値クラスをさらに分割する必要があります。

入力データが準拠する必要があるルールが指定されている場合、有効な同値クラス (ルールに従う) といくつかの無効な同値クラス (さまざまな観点からルールに違反する) が確立される可能性があります。

必要な入力データは正の整数である必要があり、その正の整数は有効な同値クラスであり、無効な同値クラスは 0、負の数、および小数です。

境界値法

意味

1. プログラムの入力境界と出力境界をテストするブラックボックスユースケース設計手法。現時点では、そのユースケースは等価クラスの設計手法と組み合わせて使用されます。

2. 境界値解析手法の理論的基礎は、ほとんどのエラーはさまざまな入力条件の境界で発生すると仮定することです。境界付近の値であればプログラムエラーは発生しません。したがって、他の値がプログラムエラーにつながる可能性も非常に低くなります。

3. 境界値の使用条件（強調：測定可能）

入力条件は、値の範囲を明確にしたり、値の数を指定したりします。

入力条件は順序付きセットを指定します

関連概念

上の点: 境界上の点

オフポイント: 境界に最も近いポイント

内部点: 値の範囲内の任意の点

各ポイントは異なる番号でなければなりません。1 つのポイントがアッパーポイントとアウェイポイントの両方になることはできません。

上部の点: 範囲内に表示される 2 つの点が上部の点である必要があります。

ユースケースのステップ

入力パラメータのタイプを分析する: テスト仕様書から入力パラメータのタイプを分析します。

同値クラス分割 (オプション): 入力同値クラス分割メソッドの場合、同値クラスを分割して境界を決定します。ドメインテスト分析メソッドを使用して、ドメイン範囲の境界 (上部点、離れた点、および内部点) を決定します。

テスト項目を形成する: これらの上部点、オフポイント、内部点、またはこれらの点の組み合わせを選択してテスト項目を形成します

分析原理

入力（出力）条件が値の範囲を指定している場合、範囲の境界内および境界付近の値をテストケースとして使用する必要があります。

入力（出力）条件が値の数を指定している場合、最大数、最小数、最小数より 1 少ない数、および最大数より 1 多い数をテストケースとして使用します。

プログラム仕様で言及されている入力または出力が順序セットである場合、順序セットの最初と最後の要素をテストケースとして選択するように注意する必要があります。

プログラム内で内部データ構造が使用されている場合、内部データ構造の境界上の値をテストケースとして選択する必要があります。

使用シナリオ: 入力条件を複数の異なるサブ条件に分割します。条件は比較的独立しており、制限的な関係はありません。

デシジョンテーブル方式

定義（かどうか）

デシジョンテーブルは、複数の入力条件下でシステムによって実行されるさまざまなアクションを分析および表現するためのツールであり、複数の条件の複雑な論理関係や組み合わせを具体的かつ明確に表現できます。

コンディションパイル

システムへのすべての入力をリストします。リストされた入力の順序は影響しません。

条件付きアイテム

左の列に入力条件の値、考えられるすべての状況における true 値と false 値をリストします。

アクションパイル

システムが実行できるアクションを任意の順序でリストします。

アクションアイテム

入力のさまざまな値に対して実行する必要があるアクションをリストします。

設計ステップ

ルールの数を決定します。たとえば、ここには 3 つの条件があり、各条件には 2 つの値があるため、2*2*2=8 個のルールが存在する必要があります。

すべての条件パイルとアクションパイルをリストする

条件項目を入力してください

アクションパイルとアクションアイテムを埋める

同様のルールを簡素化してマージする

各ルールをユースケースに変換する

プロセス分析

意味

プロセス分析手法（シナリオ設計手法とも呼ばれます）は、ソフトウェアシステムのあるプロセスをパスとみなして、テストケースを設計する手法です。プロセスのすべての分岐に到達できるように、プロセスの順序に従ってそれらを順番に組み合わせます。ホワイトボックステストにおけるパスカバレッジ解析手法をブラックボックステストに拡張したテスト解析手法です。

コンセプト

基本フロー: すべての操作が正しく行われる主要なプロセスを指します。

代替フロー: 一部の操作が正しくないプロセスブランチを指します。

設計ステップ

ビジネスプロセス図を描く

関数パスの優先順位を設定する

テストパスを決定する

テストデータの選択

テストケースを構築する

例: 組み込みシステムでは、送信するデータを CA プロトコルに準拠したフレーム形式にパッケージ化した後、送信バッファに書き込んで自動的に送信できます。

1. 送信サブルーチンに入る

2. システムは、空き送信バッファがあるかどうかを判断し、空きがない場合は送信失敗メッセージを表示します。

3. 空きバッファがある場合は、データパケットを空き送信バッファに書き込みます。

4. システムは書き込みが成功したかどうかを判断し、失敗した場合は送信失敗メッセージを表示します。

5. 書き込みに成功したら、送信コマンドを開始します。

6. 成功メッセージを返す

間違った推測

意味

エラー推測方法は、経験に基づいて問題の原因を推測し、それに応じてテストケースを設計することです。

エラーテスト方法はテスト設計の補足としてのみ使用でき、テストケースの設計に単独で使用することはできません。そうしないと、テストが不十分になる可能性があります。

間違った推測は、盲目的な推測でも、根拠や目的のない推測でもありません。システムの弱点の理解と開発者の盲点の理解に基づいている必要があります。

例

a = [3,5,8,9,2,4]

繰り返す

[1,1,1,1,1,1,1]

数字ではありません

[1,2,3,a,7,6,5]

リストが空です

: [] [67]

順序の問題

[1,2,3,4,5,6] [6,5,4,3,2,1]

ビジネスへの精通しさとプログラミング経験の豊富さ

テストケース設計の概要

テストケースを設計するにはさまざまな方法がありますが、それぞれの方法の使用方法だけでなく、各方法が使用されるシナリオについても知る必要があります。

等価クラスと境界値は他のテスト設計アプローチの基礎であり、最初に等価クラスと境界値を使用したユースケース設計を考慮する必要があります。

入力領域と入力領域との間に制約関係がある場合には、デシジョンテーブルを用いて結合する必要がある。

すべてのテストケースの設計方法を検討した後、見逃さないようにエラー推測方法でそれらを補うことも必要です。

特定のフィールドをテストするときは、他のフィールドの値が通常の値であることを確認する必要があります。

実装: テストケース、テストスクリプトなどを作成します。

テストポイントの分析と抽出

テストを受ける前に考えるべき質問

テストしたいシステムが何をするか知っていますか?

システムの特徴を理解していますか？

このシステムにはどのような機能があるかご存知ですか？

システムのビジネスプロセスが何であるか知っていますか?

このバージョンのシステムでは、何がテストされる必要があり、何がテストされないのでしょうか?

システムにはパフォーマンスとセキュリティの要件がありますか?

テスト要件分析プロセス

1. 製品要件に従ってシステムテストポイントを抽出します

1. まずインターフェイス要素が正しく表示されているかどうかを確認します

2. ページの基本機能をテストします。ページにフォームとリストの両方がある場合は、フォームの機能が正常であるかどうかのテストを優先してください。

3. フォームをテストするときは、フォーム内の各フィールドを順番にテストする必要があります。ユーザーが入力できるすべての入力フィールドは、同値クラスと境界値を使用してフィールドの制約に従って考慮される必要があります。

4. 複数のフィールド間に相関と制約がある場合は、単一フィールドの同値クラスと境界値をテストした後、結合テスト用のデシジョンテーブルなどのテスト方法を引き続き使用する必要があります。

5. フォームをテストした後、リスト内の関数をテストします。

6. 単一ページのコンテンツをテストした後、プロセス分析手法 (シナリオ手法) を使用してプロセス関連コンテンツをテストします。

7. プロセスの分析とテストが完了したら、最後にエラー推測方法を使用して、テストポイントの欠落がないことを確認します。

8.例

2. 要件追跡マトリックスを作成する

要件追跡マトリックスとは、製品要件、テストポイント、およびテストケースに基づいて 3 つのマッピングのリストを確立することを指します。このテーブルは要件追跡マトリックスと呼ばれます。

要件追跡マトリックスの役割

製品要件、テスト要件、テストケース間のマッピング関係を確立して、ユースケース要件カバレッジ統計を容易にします。

要件が変更された場合は、要件追跡マトリックスに基づいて、どのテストケースを更新する必要があるかをすぐに特定できます。

3. 適切なテストケース設計方法を使用して、テストポイントに基づいてテストケースを設計する

実行: テスト環境をセットアップし、テストスクリプトを実行し、欠陥レポートを実行します。

テスト環境をセットアップする

サーバー環境のセットアップ

JDKのインストール

JDK のインストールは主に JAVA の実行環境を提供するために行われます。 (TOMCAT サーバーは Java で書かれているため、Tomcat を実行するには、まず JAVA オペレーティング環境をセットアップする必要があります)

JAVA_HOME: JDK をインストールしたパス

CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar

Path 環境変数に、2 つのパス %JAVA_HOME%\jre\bin と %JAVA_HOME%\bin を追加します。

TOMCATのインストール

Tomcat はメイン Web サーバーとして機能し、クライアントから送信されたすべてのリクエストを処理します。

Tomcat 圧縮パッケージを中国語や特殊文字が含まれないパスに解凍します。

CATALINA_HOME: Tomcat パッケージを解凍した場所へのパス

Path 環境変数に、%CATALINA_HOME%\bin パスを追加します。

bin ディレクトリにあるstartup.batファイルをダブルクリックして、tomcatを起動します。

MYSQLデータベースのインストール

Mysqlデータベースは主にシステムデータの管理に使用されます

wampserver ツールキットを使用して mysql アプリケーションをインストールし、wampserver を使用して mysql サーバーと Apache サーバーを起動します。

テスト対象システムに関する設定

テスト対象システムの war パッケージを Tomcat で指定されたパスに配置します。

データベースに対応するSQLファイルをデータベースにインポートし、mysqlデータのデフォルトパスワードを変更します

サーバーを起動し、テスト対象のシステムにアクセスします。アドレスは http://localhost:8080/mms/login.html です。

環境変数

環境変数は実際にはシステム設定であり、これらの設定を通じて、実行するターゲットファイルがどこにあるかをコンピューターに伝えることができます。

不具合報告

欠陥の定義

このソフトウェアには、製品マニュアルに記載されている機能は実装されていません。

本ソフトウェアには、製品マニュアルに記載すべきではない機能が実装されています。

ソフトウェアが製品マニュアルに記載されていない操作を実行しました。

このソフトウェアには、製品マニュアルに記載されていないが実装する必要がある機能は実装されていません。

ソフトウェアテスターの観点から見ると、ソフトウェアは理解するのが難しい、使いにくい、遅い、またはその他の点でエンドユーザーにとって適切とはみなされません。

欠陥管理

ソフトウェア欠陥のライフサイクルをマスターする

高品質な欠陥レポートの記入方法をマスターする

完全なテストレポート

欠陥番号

前提条件

欠陥タイトル

テスト手順

重大度

優先度

再現性

不良状態

ソフトウェアの欠陥に関連する属性を習得する

欠陥の重大度

重大度

名前が示すように、ソフトウェアの欠陥がソフトウェアの品質に与える影響の程度、つまり、このソフトウェアの欠陥の存在がソフトウェアの機能やパフォーマンスにどのような影響を与えるかを指します。

致命的

たとえば、ソフトウェアが予期せず終了したり、オペレーティングシステムがクラッシュしたりして、データが失われます。

深刻な

たとえば、単一の関数の失敗により、関連する複数の関数が失敗する場合などです。

一般的に

たとえば、ソフトウェアの単一の機能が失敗した場合、

ヒント

ソフトウェアインターフェイスの軽微な欠陥。たとえば、特定のコントロールが整列していない、特定の句読点が欠落しているなど。

欠陥状態の分類

ソフトウェア欠陥管理のための一般的なツールについて学ぶ

欠陥競合におけるいくつかの一般的な問題を理解する

再現できない欠陥にはどう対処すればよいですか？必ず欠陥管理ライブラリに提出してください。

1. 不具合が発生したプロセスと関連する環境構成を必ず詳細に説明してください。ログがある場合は、該当する操作ログまたはシステム動作ログを必ず添付してください。

2. 再現性のない欠陥については、再発率をできるだけ明確に記載してください。

3. 再現不可能な欠陥の場合、検証中に欠陥を 1 つのバージョンでのみ検証することはできません。欠陥を解決するには、少なくとも 3 つ以上のバージョンで検証する必要があります。

テスト実行のプロセス全体

回帰テストの目的: 1. 欠陥が実際に修正されたかどうかを確認します。 2. プログラマは欠陥を修正する過程で新たな欠陥を導入しましたか?

回帰テストと受け入れテスト

回帰試験

意味

コードを変更した後、再テストします

目的

不具合が実際に修正されたかどうかを確認する

プログラマーが欠陥を修正する際に新たな欠陥を持ち込むかどうか

プロセス

1. テスト戦略策定段階では回帰テスト戦略を策定する

2. 回帰テストが必要なバージョンを決定すると、バグが修正されたバージョンが返されます。

3.回帰テストバージョンをリリースし、回帰テスト戦略に従って回帰テストを実行します。

4. 回帰テストに合格し、欠陥レポートが閉じられます。

5. 回帰テストが失敗した場合、欠陥レポートは開発者に返され、開発者は問題を再修正して、回帰テストのためにテスターに再度送信されます。

戦略

全額返却

初期のテスト段階で作成されたすべてのテストケースを再実行して、問題の修正の正確さと修正の局所的な影響を確認します。

選択的回帰

つまり、初期のテスト段階で作成されたテストケースの一部を選択的に再実行して、変更されたプログラムをテストします。

方法

変更を上書きする

変更された部分については、テストケースを選択または再構築して、ケース選択方法を使用してエラーが発生しないことを確認します。

周囲の影響

これには、カバレッジ変更方法によって特定されたユースケースが含まれており、変更の拡散影響を分析して、他の部分が影響を受けるかどうかも検証します。

目標を達成

受け入れテスト

意味

内部システムテストに合格したら、受け入れテストを開始できます

受け入れテストはユーザー中心のテストであり、受け入れチームはプロジェクトチームのメンバー、ユーザーの代表者などで構成される必要があります。

受け入れテストは原則としてユーザー先で実施しますが、ユーザーの同意があれば社内でユーザー環境を模擬したテストを実施することも可能です。

受入試験：契約書「要求仕様書」または「受入試験計画書」に基づいた完成品の受入試験

製品型プロジェクトの場合、受け入れテストは一般的にアルファテスト（社内テスト：開発環境で実施）とベータテスト（公開テスト：実際の利用環境でのテスト）に分けられます。

ライフサイクルテスト手法の比較

テストレポートを書く（各社テンプレートあり）

目的

概要

テスト対象

テスト機能

テストの結論

時間、場所、人

環境

テストネットワーク図

ハードウェア環境

ソフトウェア環境

総括評価

関連概念

上の点: 境界上の点

オフポイント: 境界に最も近いポイント

内部点: 値の範囲内の任意の点

各ポイントは異なる番号でなければなりません。1 つのポイントがアッパーポイントとアウェイポイントの両方になることはできません。

上部の点: 範囲内に表示される 2 つの点が上部の点である必要があります。

ユースケースのステップ

入力パラメータのタイプを分析する: テスト仕様書から入力パラメータのタイプを分析します。

同値クラス分割 (オプション): 入力同値クラス分割メソッドの場合、同値クラスを分割して境界を決定します。ドメインテスト分析メソッドを使用して、ドメイン範囲の境界 (上部点、離れた点、および内部点) を決定します。

テスト項目を形成する: これらの上部点、オフポイント、内部点、またはこれらの点の組み合わせを選択してテスト項目を形成します

分析原理

入力（出力）条件が値の範囲を指定している場合、範囲の境界内および境界付近の値をテストケースとして使用する必要があります。

入力（出力）条件が値の数を指定している場合、最大数、最小数、最小数より 1 少ない数、および最大数より 1 多い数をテストケースとして使用します。

プログラム仕様で言及されている入力または出力が順序セットである場合、順序セットの最初と最後の要素をテストケースとして選択するように注意する必要があります。

プログラム内で内部データ構造が使用されている場合、内部データ構造の境界上の値をテストケースとして選択する必要があります。

使用シナリオ: 入力条件を複数の異なるサブ条件に分割します。条件は比較的独立しており、制限的な関係はありません。

デシジョンテーブル方式

定義（かどうか）

デシジョンテーブルは、複数の入力条件下でシステムによって実行されるさまざまなアクションを分析および表現するためのツールであり、複数の条件の複雑な論理関係や組み合わせを具体的かつ明確に表現できます。

コンディションパイル

システムへのすべての入力をリストします。リストされた入力の順序は影響しません。

条件付きアイテム

左の列に入力条件の値、考えられるすべての状況における true 値と false 値をリストします。

アクションパイル

システムが実行できるアクションを任意の順序でリストします。

アクションアイテム

入力のさまざまな値に対して実行する必要があるアクションをリストします。

設計ステップ

ルールの数を決定します。たとえば、ここには 3 つの条件があり、各条件には 2 つの値があるため、2*2*2=8 個のルールが存在する必要があります。

すべての条件パイルとアクションパイルをリストする

条件項目を入力してください

アクションパイルとアクションアイテムを埋める

同様のルールを簡素化してマージする

各ルールをユースケースに変換する

プロセス分析

意味

プロセス分析手法（シナリオ設計手法とも呼ばれます）は、ソフトウェアシステムのあるプロセスをパスとみなして、テストケースを設計する手法です。プロセスのすべての分岐に到達できるように、プロセスの順序に従ってそれらを順番に組み合わせます。ホワイトボックステストにおけるパスカバレッジ解析手法をブラックボックステストに拡張したテスト解析手法です。

コンセプト

基本フロー: すべての操作が正しく行われる主要なプロセスを指します。

代替フロー: 一部の操作が正しくないプロセスブランチを指します。

設計ステップ

ビジネスプロセス図を描く

関数パスの優先順位を設定する

テストパスを決定する

テストデータの選択

テストケースを構築する

例: 組み込みシステムでは、送信するデータを CA プロトコルに準拠したフレーム形式にパッケージ化した後、送信バッファに書き込んで自動的に送信できます。

1. 送信サブルーチンに入る

2. システムは、空き送信バッファがあるかどうかを判断し、空きがない場合は送信失敗メッセージを表示します。

3. 空きバッファがある場合は、データパケットを空き送信バッファに書き込みます。

4. システムは書き込みが成功したかどうかを判断し、失敗した場合は送信失敗メッセージを表示します。

5. 書き込みに成功したら、送信コマンドを開始します。

6. 成功メッセージを返す

間違った推測

意味

エラー推測方法は、経験に基づいて問題の原因を推測し、それに応じてテストケースを設計することです。

エラーテスト方法はテスト設計の補足としてのみ使用でき、テストケースの設計に単独で使用することはできません。そうしないと、テストが不十分になる可能性があります。

間違った推測は、盲目的な推測でも、根拠や目的のない推測でもありません。システムの弱点の理解と開発者の盲点の理解に基づいている必要があります。

例

a = [3,5,8,9,2,4]

繰り返す

[1,1,1,1,1,1,1]

数字ではありません

[1,2,3,a,7,6,5]

リストが空です

: [] [67]

順序の問題

[1,2,3,4,5,6] [6,5,4,3,2,1]

ビジネスへの精通しさとプログラミング経験の豊富さ

テストケース設計の概要

テストケースを設計するにはさまざまな方法がありますが、それぞれの方法の使用方法だけでなく、各方法が使用されるシナリオについても知る必要があります。

等価クラスと境界値は他のテスト設計アプローチの基礎であり、最初に等価クラスと境界値を使用したユースケース設計を考慮する必要があります。

入力領域と入力領域との間に制約関係がある場合には、デシジョンテーブルを用いて結合する必要がある。

すべてのテストケースの設計方法を検討した後、見逃さないようにエラー推測方法でそれらを補うことも必要です。

特定のフィールドをテストするときは、他のフィールドの値が通常の値であることを確認する必要があります。

テストポイントの分析と抽出

テストを受ける前に考えるべき質問

テストしたいシステムが何をするか知っていますか?

システムの特徴を理解していますか？

このシステムにはどのような機能があるかご存知ですか？

システムのビジネスプロセスが何であるか知っていますか?

このバージョンのシステムでは、何がテストされる必要があり、何がテストされないのでしょうか?

システムにはパフォーマンスとセキュリティの要件がありますか?

テスト要件分析プロセス

1. 製品要件に従ってシステムテストポイントを抽出します

1. まずインターフェイス要素が正しく表示されているかどうかを確認します

2. ページの基本機能をテストします。ページにフォームとリストの両方がある場合は、フォームの機能が正常であるかどうかのテストを優先してください。

3. フォームをテストするときは、フォーム内の各フィールドを順番にテストする必要があります。ユーザーが入力できるすべての入力フィールドは、同値クラスと境界値を使用してフィールドの制約に従って考慮される必要があります。

4. 複数のフィールド間に相関と制約がある場合は、単一フィールドの同値クラスと境界値をテストした後、結合テスト用のデシジョンテーブルなどのテスト方法を引き続き使用する必要があります。

5. フォームをテストした後、リスト内の関数をテストします。

6. 単一ページのコンテンツをテストした後、プロセス分析手法 (シナリオ手法) を使用してプロセス関連コンテンツをテストします。

7. プロセスの分析とテストが完了したら、最後にエラー推測方法を使用して、テストポイントの欠落がないことを確認します。

8.例

2. 要件追跡マトリックスを作成する

要件追跡マトリックスとは、製品要件、テストポイント、およびテストケースに基づいて 3 つのマッピングのリストを確立することを指します。このテーブルは要件追跡マトリックスと呼ばれます。

要件追跡マトリックスの役割

製品要件、テスト要件、テストケース間のマッピング関係を確立して、ユースケース要件カバレッジ統計を容易にします。

要件が変更された場合は、要件追跡マトリックスに基づいて、どのテストケースを更新する必要があるかをすぐに特定できます。

3. 適切なテストケース設計方法を使用して、テストポイントに基づいてテストケースを設計する

テスト環境をセットアップする

サーバー環境のセットアップ

JDKのインストール

JDK のインストールは主に JAVA の実行環境を提供するために行われます。 (TOMCAT サーバーは Java で書かれているため、Tomcat を実行するには、まず JAVA オペレーティング環境をセットアップする必要があります)

JAVA_HOME: JDK をインストールしたパス

CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar

Path 環境変数に、2 つのパス %JAVA_HOME%\jre\bin と %JAVA_HOME%\bin を追加します。

TOMCATのインストール

Tomcat はメイン Web サーバーとして機能し、クライアントから送信されたすべてのリクエストを処理します。

Tomcat 圧縮パッケージを中国語や特殊文字が含まれないパスに解凍します。

CATALINA_HOME: Tomcat パッケージを解凍した場所へのパス

Path 環境変数に、%CATALINA_HOME%\bin パスを追加します。

bin ディレクトリにあるstartup.batファイルをダブルクリックして、tomcatを起動します。

MYSQLデータベースのインストール

Mysqlデータベースは主にシステムデータの管理に使用されます

wampserver ツールキットを使用して mysql アプリケーションをインストールし、wampserver を使用して mysql サーバーと Apache サーバーを起動します。

テスト対象システムに関する設定

テスト対象システムの war パッケージを Tomcat で指定されたパスに配置します。

データベースに対応するSQLファイルをデータベースにインポートし、mysqlデータのデフォルトパスワードを変更します

サーバーを起動し、テスト対象のシステムにアクセスします。アドレスは http://localhost:8080/mms/login.html です。

環境変数

環境変数は実際にはシステム設定であり、これらの設定を通じて、実行するターゲットファイルがどこにあるかをコンピューターに伝えることができます。

不具合報告

欠陥の定義

このソフトウェアには、製品マニュアルに記載されている機能は実装されていません。

本ソフトウェアには、製品マニュアルに記載すべきではない機能が実装されています。

ソフトウェアが製品マニュアルに記載されていない操作を実行しました。

このソフトウェアには、製品マニュアルに記載されていないが実装する必要がある機能は実装されていません。

ソフトウェアテスターの観点から見ると、ソフトウェアは理解するのが難しい、使いにくい、遅い、またはその他の点でエンドユーザーにとって適切とはみなされません。

欠陥管理

ソフトウェア欠陥のライフサイクルをマスターする

高品質な欠陥レポートの記入方法をマスターする

完全なテストレポート

欠陥番号

前提条件

欠陥タイトル

テスト手順

重大度

優先度

再現性

不良状態

ソフトウェアの欠陥に関連する属性を習得する

欠陥の重大度

重大度

名前が示すように、ソフトウェアの欠陥がソフトウェアの品質に与える影響の程度、つまり、このソフトウェアの欠陥の存在がソフトウェアの機能やパフォーマンスにどのような影響を与えるかを指します。

致命的

たとえば、ソフトウェアが予期せず終了したり、オペレーティングシステムがクラッシュしたりして、データが失われます。

深刻な

たとえば、単一の関数の失敗により、関連する複数の関数が失敗する場合などです。

一般的に

たとえば、ソフトウェアの単一の機能が失敗した場合、

ヒント

ソフトウェアインターフェイスの軽微な欠陥。たとえば、特定のコントロールが整列していない、特定の句読点が欠落しているなど。

欠陥状態の分類

ソフトウェア欠陥管理のための一般的なツールについて学ぶ

欠陥競合におけるいくつかの一般的な問題を理解する

再現できない欠陥にはどう対処すればよいですか？必ず欠陥管理ライブラリに提出してください。

1. 不具合が発生したプロセスと関連する環境構成を必ず詳細に説明してください。ログがある場合は、該当する操作ログまたはシステム動作ログを必ず添付してください。

2. 再現性のない欠陥については、再発率をできるだけ明確に記載してください。

3. 再現不可能な欠陥の場合、検証中に欠陥を 1 つのバージョンでのみ検証することはできません。欠陥を解決するには、少なくとも 3 つ以上のバージョンで検証する必要があります。

回帰テストと受け入れテスト

回帰試験

意味

コードを変更した後、再テストします

目的

不具合が実際に修正されたかどうかを確認する

プログラマーが欠陥を修正する際に新たな欠陥を持ち込むかどうか

プロセス

1. テスト戦略策定段階では回帰テスト戦略を策定する

2. 回帰テストが必要なバージョンを決定すると、バグが修正されたバージョンが返されます。

3.回帰テストバージョンをリリースし、回帰テスト戦略に従って回帰テストを実行します。

4. 回帰テストに合格し、欠陥レポートが閉じられます。

5. 回帰テストが失敗した場合、欠陥レポートは開発者に返され、開発者は問題を再修正して、回帰テストのためにテスターに再度送信されます。

戦略

全額返却

初期のテスト段階で作成されたすべてのテストケースを再実行して、問題の修正の正確さと修正の局所的な影響を確認します。

選択的回帰

つまり、初期のテスト段階で作成されたテストケースの一部を選択的に再実行して、変更されたプログラムをテストします。

方法

変更を上書きする

変更された部分については、テストケースを選択または再構築して、ケース選択方法を使用してエラーが発生しないことを確認します。

周囲の影響

これには、カバレッジ変更方法によって特定されたユースケースが含まれており、変更の拡散影響を分析して、他の部分が影響を受けるかどうかも検証します。

目標を達成

受け入れテスト

意味

内部システムテストに合格したら、受け入れテストを開始できます

受け入れテストはユーザー中心のテストであり、受け入れチームはプロジェクトチームのメンバー、ユーザーの代表者などで構成される必要があります。

受け入れテストは原則としてユーザー先で実施しますが、ユーザーの同意があれば社内でユーザー環境を模擬したテストを実施することも可能です。

受入試験：契約書「要求仕様書」または「受入試験計画書」に基づいた完成品の受入試験

製品型プロジェクトの場合、受け入れテストは一般的にアルファテスト（社内テスト：開発環境で実施）とベータテスト（公開テスト：実際の利用環境でのテスト）に分けられます。

ライフサイクルテスト手法の比較

ソフトウェア システム テストの知識ポイントの概要

ソフトウェア システム テストの知識ポイントの概要

ソフトウェアシステムテストの知識ポイントの概要

ソフトウェアシステムテストの知識ポイントの概要