ソフトウェアは、オンラインにする前にテストを受ける必要があります。これにより、ソフトウェアが使用要件を満たしているかどうかを検証し、ソフトウェア内のバグや欠陥を可能な限り減らし、ソフトウェアの品質を保証します。
分類#
開発段階による分類#
- 単体テスト (Unit Testing)：プログラムコードモジュール（関数など）が正常に動作するかをテストし、通常は開発者自身が行います。
- 統合テスト (Integration Testing)：ユニットテストを通過したモジュールを組み合わせてテストし、それらのインターフェースが正しいかを検証します。（協調動作時に問題がないことを確認）
- システムテスト (System Testing)：全体のシステムを一体としてテストし、その機能と非機能要件（互換性テスト、性能テスト、安全性テストなど）を包括的に検証します。通常、内部文書に基づいて実行されます。
- 受け入れテスト (Acceptance Testing)：実際のユーザーまたは顧客によって行われるテストで、システムがビジネス要件を満たしているかを確認します。形式的には、内部テスト（アルファテスト）、公開テスト（ベータテスト）に分かれます。通常、公開テストの形式で、製品がリリース前に可能な限りプロジェクトの欠陥を発見し、ユーザーの期待をより良く満たし、オンライン後のリスクを減らします。
単体テストはモジュール内部のテストです；統合テストは複数のモジュール間のテストです。
コードの可視性による分類#
- ブラックボックステスト (Black Box Testing)：ソースコードは見えません。UI 機能は見えます。実装の詳細には関心がなく、入力と出力のみを重視します。主にユーザーの視点からシステムの機能と性能を検証します。（機能面、互換性、ユーザー体験に関するテストなど）
- ホワイトボックステスト (White Box Testing)：テスト担当者は内部構造と実装の詳細を完全に理解し、ソースコードを直接テストします。主に開発者がホワイトボックステストを行います。一般的には単体テストで使用されます。
- グレーボックステスト (Gray Box Testing)：ブラックボックステストとホワイトボックステストの折衷です。テストはユーザーの視点から行われますが、内部の実装ロジックについても一定の理解があります。主に統合テストで使用され、インターフェーステストなどに利用されます。
評価：ソフトウェア品質モデル#
8 つの品質次元がすべて基準を満たす場合、それは優れたソフトウェアです。
- 機能性 (Functionality) ：ソフトウェアが提供する機能がユーザーのニーズを満たしているかを主に考慮します。機能の数と完全性、機能が正しく実装されているか（ログイン機能の正確性とエラーハンドリング）、エラーハンドリングの状況（誤ったパスワード入力時のメッセージなど）を含みます。
- 性能 (Performance)：ソフトウェアが高負荷下でどのように動作するかを主に考慮します。サーバーが 1 秒あたりに処理できるリクエスト数、既存のハードウェア構成が要件を満たしているか（CPU、メモリなど）、期待されるユーザー数を満たすための最適化（例えば、20 万人のオンラインユーザー）を含みます。
- 互換性 (Compatibility)：ソフトウェアが異なるソフトウェアおよびハードウェア環境でどのように動作するかを主に考慮します。ブラウザの互換性（Chrome、Firefox、Safari、IE、Edge などの主要 5 ブラウザ）、オペレーティングシステムの互換性（Windows 7/8/10/11、macOS、Linux など）、モバイルデバイスの互換性（解像度、ブランド、OS バージョン、ネットワークタイプなど）、および他のアプリケーションとの互換性（Alipay、WeChat など）を含みます。
- 使いやすさ (Usability)：ソフトウェアが使いやすいかどうかを主に考慮します。インターフェースのシンプルさ、ユーザーフレンドリーさ（操作のスムーズさ、文字の明瞭さ）、美観（インターフェースデザインなど）を含みます。
- 信頼性 (Reliability)：さまざまな条件下でのソフトウェアの安定性と無故障運用能力を主に考慮します。無応答（ログイン時に反応がない）、カクつき（ゲーム中のカクつき）、フリーズ（ソフトウェアのクラッシュなど）を含みます。
- 安全性 (Security)：データの送信と保存の過程でのソフトウェアの安全性を主に考慮します。データ送信の暗号化（ログイン時のパスワード送信）、データ保存の暗号化（データベース内の機密情報など）を含みます。
- 保守性 (Maintainability)：ソフトウェアの後期保守と更新の便利さを主に考慮します。コードの整然さとコメント、コードのモジュール化と分離、ネットワークとハードウェアのラベルと整理を含みます。
- 移植性 (Portability)：異なるプラットフォームや環境でのソフトウェアの移行能力を主に考慮します。データ移行の便宜性（サーバーのアップグレード時のデータ移行）、異なるハードウェアでのソフトウェアのインストールと実行を含みます。
機能性、性能、互換性、使いやすさ、安全性は最も重要であり、通常は必ずテストされる内容です。
テストプロセス#
- 要件レビュー (Requirement Review)：プロジェクト開始時に、製品、開発、テストチームが共同で要件文書をレビューし、各方面が要件の理解を一致させ、コア機能と重要な要件を特定します。
- 計画作成 (Test Planning)：要件レビューの結果に基づいて、詳細なテスト計画を作成します。どの機能をテストする必要があるか、誰がこれらのテストを行うか、どのようにテストを行うか（どのテスト戦略を採用するか、例えば互換性、性能など）、テストのスケジュールなどを含みます。
- テストケース設計 (Test Case Design)：テスト計画に基づいて具体的なテストケースを設計します。各テストケースにはテスト手順、入力データ、期待結果が含まれます。テストケースはすべての要件と機能ポイントをカバーする必要があります。テストの包括性と再現性を確保するためです。
- テストケース実行 (Test Case Execution)：設計されたテストケースに従って実際のテストを行い、実際の結果を記録します。ソフトウェアの機能と性能が要件を満たしているかを検証し、同時に欠陥を発見し記録します。
- 欠陥管理 (Defect Management)：発見された欠陥を管理し追跡し、開発者に返し、修正されるまで追跡します。発見されたすべての欠陥が迅速に処理され、検証されることを保証します。
- テスト報告 (Test Report)：テストプロセスと結果をまとめ、テスト報告書を生成します。報告書にはテストカバレッジ、欠陥の統計と分析、テストの結論と提案が反映される必要があります。プロジェクトの全体的なテスト状況を提供し、意思決定者にソフトウェアのリリース可否を評価するための根拠を提供します。
テストケースの作成#
テストケース作成の目的
- 漏れ測定を防ぐ：すべての要件ポイントがカバーされていることを確認し、見落としを避けます。
- 標準化：明確なテスト手順と期待結果を提供し、テストプロセスの一貫性と再現性を確保します。
フォーマット#
- ケース ID (Case ID)
フォーマット：プロジェクト略称_モジュール略称_番号（例：ProjectName_ModuleName_001）
目的：各テストケースを一意に識別し、管理と追跡を容易にします。 - ケースタイトル (Title)
フォーマット：期待結果 + 機能説明
目的：このケースのテスト目標を簡潔に説明し、レビュー担当者が迅速に理解できるようにします。 - プロジェクト / モジュール (Project/Module)
内容：このケースがどのプロジェクトまたはモジュールに属するかを示します。
目的：テスト範囲を明確にし、分類管理を容易にします。 - 優先度 (Priority)
レベル：P0 (最高) から P4 (最低)
目的：テストケースの実行順序を決定し、コア機能（ユーザー使用頻度が最も高い）を通常 P0 に設定します。 - 前提条件 (Preconditions)
内容：このケースを実行する前に満たす必要がある条件。
目的：テスト環境と状態が正しいことを確認し、環境問題によるテスト失敗を避けます。 - 操作手順 (Steps)
内容：詳細なテスト手順、各ステップの具体的な操作を含みます。
目的：明確な操作ガイドを提供し、テスト担当者が同じ手順でテストを実施できるようにします。 - テストデータ (Test Data)
内容：テスト中に使用される具体的なデータ。
目的：テストデータの一貫性と正確性を確保し、問題の再現を容易にします。 - 期待結果 (Expected Result)
内容：テスト実行後に達成されるべき結果。
目的：実際の結果と期待結果を比較し、テストが合格したかどうかを判断します。
テストケース設計#
同値クラス分割法#
ブラックボックステスト技術に属します。入力データを異なる同値クラスに分割します。代表的なデータを選択してテストします。テストケースの数を減らし、テスト効率を向上させます。
同値クラス分類
- 有効同値クラス：要件を満たすデータ集合。
- 無効同値クラス：要件を満たさないデータ集合。
同値クラスの分割方法
- 要件を明確にする：要件を理解し、分割基準を特定します（性別、年齢など）。
- 同値クラスを分割する：要件に基づいてデータを有効と無効の同値クラスに分割します。
- データを抽出する：各同値クラスから代表的なデータを選択します。
- テストケースを作成する：抽出したデータに基づいてテストケースを作成します。
ケース 1
QQ アカウントの合法性を検証する要件があり、QQ アカウントは 6 から 10 桁の自然数である必要があります。以下は同値クラス分割法を使用してテストケースを設計する方法です：
- 有効同値クラス：
8 桁の自然数（例：12345678）【長さ検証】 - 無効同値クラス：
6 桁未満の自然数（例：123）【長さ検証】
10 桁を超える自然数（例：12345678901）【長さ検証】
8 桁の非自然数（例：1234567a）【タイプ検証】
QQ 番号が空【タイプ検証】
境界値分析法#
次の点を考慮する必要があります：
- 上点（On Point）：境界値とちょうど等しいデータ。
- 離点（Off Point）：境界値に最も近いデータ、境界値よりちょうど大きいデータとちょうど小さいデータを含みます。
- 内点（In Point）：区間内のデータ、通常は中央の値を取ります。
ケース 2
ある数が - 99 未満または 99 を超えるかどうかを判断する要件があり、条件を満たす場合はエラーメッセージを表示します。
- 上点：-99、99
- 離点：-100、-98、100、98
- 内点：0（または他の区間内の値、例えば 50）
それからそれぞれのテストケースを設計します。
判定表法#
判定表は、複数の条件とその組み合わせに対する対応する操作結果を表形式で列挙するブラックボックステスト技術です。これにより、テストケースを設計するのに役立ちます。【条件依存問題の解決】
重要な用語
- 条件スタブ（Condition Stubs）：すべての条件を列挙します。
- アクションスタブ（Action Stubs）：すべての可能な操作または結果を列挙します。
- 条件項（Condition Entries）：各条件の具体的な値（通常は「はい」または「いいえ」）。
- アクション項（Action Entries）：条件項の組み合わせに基づいて決定されたアクション結果。
手順
- 要件を明確にする：要件内の条件と結果を理解します。
- 判定表を描く：
- 条件スタブとアクションスタブを記入します。
- 条件スタブに基づいて条件項を記入します。
- 条件項の組み合わせに基づいてアクション項を記入します。
- テストケースを作成する：判定表に基づいてテストケースを生成します。
ケース
ユーザーが料金未払いかどうかとユーザーの携帯電話がオフかどうかの 2 つの条件に関する要件があると仮定します。具体的なルールは以下の通りです：
ユーザーが料金未払いで携帯電話がオフの場合、電話をかけることはできません。
ユーザーが料金未払いだが携帯電話がオフでない場合、電話をかけることができます。
ユーザーが料金未払いで携帯電話がオフの場合、電話をかけることができます。
ユーザーが料金未払いで携帯電話がオフでない場合、電話をかけることができます。
| ユーザーが料金未払いか（条件スタブ） | 携帯電話がオフか（条件スタブ） | 電話をかけることができるか（アクションスタブ） |
|---|---|---|
| はい | はい | 不可 |
| はい | いいえ | 可 |
| いいえ | はい | 可 |
| いいえ | いいえ | 可 |
その後、判定表に基づいてテストケースを設計します。
シナリオ法#
ユーザーがソフトウェアを使用する実際のプロセスをシミュレートしてテストケースを設計します。この方法は通常、ビジネスプロセス図や使用ケースに基づいて、全体のビジネスプロセスがスムーズに実行されることを保証します。
目的
- ビジネスプロセスをカバーする：すべての重要なビジネスプロセスが正しく実行されることを保証します。
- ユーザー体験を向上させる：ユーザーの視点から、ソフトウェアが実際の使用要件を満たしていることを確認します。
手順
- 要件を明確にする：ビジネスプロセスの具体的な要件を理解します。
- フローチャートを描く：開始、終了、判断、処理ステップを含みます。
- テストケースを作成する：フローチャートに基づいてテストケースを生成し、すべてのビジネスパスをカバーします。
ケース
シンプルなログインシステムがあり、ユーザーはユーザー名とパスワードを入力して検証する必要があります。具体的なルールは以下の通りです：
ユーザー名が admin でパスワードが 123456 の場合、ログイン成功。
それ以外の場合、ログイン失敗。
まずフローチャートを描く必要があります。（省略）
その後、テストケースを作成します。
エラー推測法#
エラー推測法は、経験と直感に基づいてテストケースを設計する方法です。テスト担当者の経験と類似プロジェクトの理解に依存し、システムに発生する可能性のある問題を推測します。
- 欠陥を迅速に発見する：経験を通じて、存在する可能性のある問題を迅速に特定します。
- 他の方法を補完する：他のテスト方法の補完として使用し、テストのカバレッジをより広範囲にします。
主要な考え方
- 問題リストを列挙する：経験に基づいて発生する可能性のある問題を列挙します。
- 問題の原因を分析する：各問題に対して分析を行い、可能な原因を特定します。
- 欠陥を発見する：分析結果に基づいてテストケースを設計し、検証して欠陥を発見します。
使用シーン - 時間がない、タスクが多い：プロジェクトの時間が厳しく、タスクが重い場合、全面的で詳細なテストを行うことができません。
- プロジェクトの後期：すべての計画内のテストケースが実行され、既知の欠陥が修正されたが、リリースまでにまだ時間がある場合、エラー推測法を使用して最後の再テストを行うことができます。
ケース
ある e コマースプロジェクトが間もなくオンラインになる予定で、すべての計画内テストケースが実行され、既知の欠陥も修正されました。この時、リリースまで数時間の時間があるため、エラー推測法を使用して最後のチェックを行うことができます。
テスト手順
- 経験を振り返る：過去の類似プロジェクトで遭遇した問題を思い出します。
- 問題リストを列挙する：
a) ユーザーのログインプロセスでの可能な異常（パスワード入力エラー回数制限、確認コードの無効化など）。
b) ショッピングカート機能の境界条件（大量の商品を追加した後の応答）。
c) 支払いプロセス中のネットワーク中断や支払い失敗の状況。 - テストケースを設計する：上記のリストに基づいてテストケースを設計します。
- テストを実行する：設計されたテストケースに従ってテストを実施し、これらの問題が存在するかどうかを検証します。
ソフトウェア欠陥管理#
ソフトウェア欠陥とは、使用中に存在する問題を指し、コードのエラーだけでなく、機能の欠如、性能の問題、使いやすさの問題なども含まれます。
発生原因
- 要件段階：要件の記述が不明確または曖昧である。
- 設計段階：設計の誤りまたは不合理。
- コーディング段階：コードを書く際のエラー（論理エラー、構文エラー、その他のプログラミングエラーなど）。
- 実行段階：互換性の問題やその他の環境問題（特定のシステムの特定のバージョンでプログラムがクラッシュするなど）。
評価基準
- 要件仕様書に明示的に要求された機能が実装されていない：ソフトウェアが顧客または製品文書に明示的に要求された機能を実装していない場合、欠陥と見なされます。
例えば、契約で 10 の機能が規定されているが、実際には 8 の機能しか提供されていない場合、これら 8 の機能が完璧であっても、欠陥があります。 - 要件仕様書に明示されていないエラーが発生する：これには、機能に関する論理エラー（計算エラーや期待される動作に合わないもの）が含まれます。
例えば、1+1=3 と要求されているが、ソフトウェアが 1+1=2 を実装した場合；または、身分証明書番号でのみログインできると要求されているが、ソフトウェアが電話番号でのログインを許可した場合。 - 要件仕様書に明示されている範囲を超える：追加機能であっても、これらの機能が要求されず、悪影響を及ぼす可能性がある場合、欠陥と見なされます。
例えば、e コマースソフトウェアが要求されていない機能を提供し、ユーザーが自由に返品できるようにするが、実際には厳格な承認プロセスが必要である場合。 - 要件仕様書に明示されていないが実装すべき要件：暗黙の機能を指し、要件文書に明示的に記載されていなくても、常識やユーザー体験に基づいて実装されるべき機能です。
例えば、期待結果に含まれるいくつかの非機能的要件（ユーザーフレンドリーさやインタラクション体験など）。 - ソフトウェアが理解しにくい、使いにくい、動作が遅い：
テスト担当者の専門的な観点から、ソフトウェアが理解しにくい、使いにくい、または動作が遅い場合も欠陥と見なされます。
テスト担当者は、ユーザーの視点からソフトウェアの使いやすさとユーザー体験を考慮する必要があります。
欠陥管理プロセス
- 欠陥を発見する：テストプロセス中に上記基準に合致しない問題を発見します。
- 欠陥を記録する：ツール（JIRA、Bugzilla など）や Excel を使用して欠陥を記録し、欠陥の説明、再現手順、重大度などを含めます。
- 欠陥を割り当てる：欠陥を修正するために該当する開発者に割り当てます。
- 欠陥を修正する：開発者が欠陥を修正し、修正後のバージョンを提出します。
- 欠陥を検証する：テスト担当者が修正後のバージョンを検証し、欠陥が解決されたかを確認します。
- 欠陥を閉じる：欠陥が解決された場合、欠陥を閉じます；そうでない場合は、再度割り当てて修正を続けます。
欠陥ライフサイクル
- 欠陥の注入：要件、設計、コーディングなどの段階で、さまざまな理由（要件が不明確、設計エラー、コーディングエラーなど）により導入された欠陥。
- 欠陥の発見：テスト担当者がテストケースを実行することで、欠陥を発見し記録します。
- 分類と優先度の分割：欠陥の重大度と影響範囲に基づいて、欠陥を分類し優先度を分けます。
- 割り当てと修正：欠陥を該当する開発者に割り当てて修正します。
- 欠陥の検証：テスト担当者が修正された欠陥を検証し、解決されたかを確認します。
- 欠陥の閉鎖：欠陥が解決された場合、欠陥を閉じます；そうでない場合は、再度割り当てて修正を続けます。
- 回帰テスト：欠陥を修正した後、新たに修正されたコードが新しい欠陥を引き起こしていないことを確認するために回帰テストを行います。
ツール
欠陥管理ツール：JIRA、Bugzilla、Mantis、TestRail など。
電子スプレッドシート：Excel も簡単な欠陥追跡に使用できます。
どの段階の問題もプロジェクト全体の品質に影響を与える（木桶効果） ため、各段階で厳格に管理する必要があります。
欠陥報告と提出#
ソフトウェア欠陥の説明方法
- 欠陥タイトル：欠陥の核心的な問題を簡潔に明確に説明します。例：「ユーザーがログイン時にパスワード入力ボックスが星印を表示しない。」
- 前提条件：欠陥を再現する前に満たす必要がある条件を説明します。例：「ユーザーはアカウントに登録されており、未ログイン状態である。」
- 再現手順：欠陥を再現するための具体的な手順を詳細に列挙します。例：「1. ログインページを開く；2. ユーザー名を入力する；3. パスワードを入力する；4. ログインボタンをクリックする。」
- 期待結果：上記の手順を実行した後に得られるべき結果を説明します。例：「ユーザーがシステムに正常にログインする。」
- 実際の結果：上記の手順を実行した後に実際に得られた結果を説明します。例：「ユーザーがログインできず、ページに「パスワード形式エラー」と表示される。」
- 添付ファイル（オプション）：欠陥を理解し再現するのに役立つ追加情報を提供します。例：ログインページのスクリーンショットやエラーログを添付します。
欠陥の提出
通常、欠陥管理ツールを使用して記入します。通常、以下の情報も含める必要があります。
- 欠陥番号：各欠陥には一意の番号があり、追跡と管理が容易です。
- 重大度：通常、S1（非常に重大）、S2（重大）、S3（一般）、S4（軽微）などに分かれます。例：主機能モジュールの問題は通常 S1 または S2、二次機能モジュールの問題は S3 または S4 になる可能性があります。
- 優先度：通常、P1（緊急）、P2（高）、P3（中）、P4（低）などに分かれます。例：P1 レベルの欠陥は 24 時間以内に解決する必要があり、P2 レベルの欠陥はリリース前に解決する必要があります。
- 欠陥タイプ：コードエラー、互換性問題、設計欠陥、性能問題などが含まれます。例：「コードエラー」を選択するとプログラミング上の問題を示し、「互換性問題」は異なる環境での問題を示します。
- 欠陥状態：一般的な状態には、新規（New）、オープン（Open）、クローズ（Closed）、延期（Deferred）などがあります。例：新規は新たに提出された欠陥を示し、オープンは処理中の欠陥を示し、クローズは修正された欠陥を示します。
欠陥タイプ
- 機能エラー：ソフトウェアの機能が期待通りに動作しない場合。例：特定のボタンをクリックしても反応がない。
- インターフェース / UI エラー：ユーザーインターフェースの問題、レイアウトが正しくない、画像が完全に表示されないなど。例：ログインページのロゴが不完全に表示される。
- 互換性問題：ソフトウェアが異なるオペレーティングシステムやブラウザで一貫して動作しない場合。例：Chrome では正常だが、Firefox では使用できない。
- データ問題：データベース関連の問題、データの損失や不整合など。例：ユーザーデータがデータベースに正しく保存されていない。
- 使いやすさの問題：ソフトウェアのユーザー体験の問題、操作が複雑、ナビゲーションが直感的でないなど。例：ユーザーが特定の機能の入口を見つけにくい。
- 提案的問題：ソフトウェアの機能やインターフェースの改善提案。例：夜間モードの追加を提案。
- アーキテクチャ設計欠陥：ソフトウェアのアーキテクチャ設計上の問題で、全体の性能や安定性に影響を与える可能性があります。例：データベース接続プールの設定が不合理で性能のボトルネックを引き起こす。
欠陥管理ツール
DevOps ツールを使用することができます。例えば禅道やその他のソフトウェア。
製品管理、プロジェクト管理、品質管理を統合しており、製品、開発、テスト、プロジェクト管理の役割と責任を明確にします。
DevOps という用語は、Development と Operations の組み合わせから来ており、ソフトウェア開発者と運用担当者のコミュニケーションと協力を重視しています。自動化プロセスを通じて、ソフトウェアの構築、テスト、リリースをより迅速、頻繁、信頼性の高いものにします。