記事ディレクトリ
序文
ソフトウェア テストはソフトウェア エンジニアリングの重要な部分であり、ソフトウェアの品質を保証する重要な手段です。ソフトウェアの複雑さの増大とソフトウェア業界の継続的な発展に伴い、ソフトウェア テストはますます注目を集めています。この記事では、ソフトウェア テストのさまざまな段階で使用される主要なテスト タスク、主要なテスト手法、および方法について詳しく説明します。を紹介し、テスト管理と組織のいくつかの側面について説明します。
1. ソフトウェアテストプロセスの概要
ソフトウェアテストプロセスは、ソフトウェアエンジニアリングの開発プロセスに相当しますが、第2章ではソフトウェア開発とソフトウェアテストの対応関係をV字型の図で表しましたが、スパイラル図でもこの関係を表すことができます。
2.単体テスト
1.単体テストの定義
単体テストとは、ソフトウェア設計の最小単位であるモジュールが正しいかどうかを確認するテスト作業で、主にモジュールの構文や形式、ロジックの誤りなどをテストします。一般に「ユニット」とは、ソフトウェア内で独立して記述できる最小単位のことを指しますが、単位の選択基準は次のとおりです。
• 単位は測定可能である必要があります。
• ユニットの動作または出力が観察可能です。
• 明確に定義可能な境界または境界がある。
ユニットを決定する最も基本的な原則は、「高凝集性、低結合性」です。単体テストでは、モジュール内のエラーを検出するために、モジュール内のすべての重要な制御パスをテストする必要があります。
2. 単体テストの重要性と単体テストの原則
-
単体テストの重要性(1)時間
の観点: 単体テストを適切に行うと、システムの統合や共同デバッグが非常にスムーズになり、時間を大幅に節約できます。
テスト結果: 過去のテスト経験によれば、単体テストの効果は非常に明白です。
(3) テストコストの観点: いくつかの問題は単体テスト中に発見されやすいですが、その後のテストでそれらの問題が発見された場合、コストは指数関数的に増加します。
(4) 製品の品質: 単体テストの良し悪しは製品の品質に直接影響します。 -
単体テストの原則
(1) 単体テストは早ければ早いほどよい
(2) 単体テストは「ソフトウェア詳細設計仕様書」に基づいて実施する
(3) 修正したコードに対して単体テストをやり直す見つかったエラーの修正にエラーがないことを確認する 新しいエラーを導入する
(4) テスト ケースのテスト結果が設計仕様上の期待結果と一致しない場合、テスターは実際のテスト結果を正直に記録する必要があります (5)
) 単体テストでは、テスト対象のソフトウェア ユニットのサイズに注意する必要があります
(6) 単体テストの完全な説明には、肯定的なテスト (ポジティブ テスト) と否定的なテスト (ネガティブ テスト) が含まれる必要があります
(7) ユニットの使用に注意してくださいテストツール
3. 単体テストの主なタスク
単体テストは各プログラム モジュールをテストします。単体テストの主なタスクは、図に示すように、テスト問題を 5 つの側面から解決することです。
4. 単体テスト環境の構築
通常の状況では、単体テストはコードを作成した直後に実行する必要があり、単体テストはプログラムを作成し、レビューし、文法上の正しさを検証した後に実行する必要があります。テストケースの設計とレビュー作業を組み合わせる必要があり、設計情報に基づいてデータを選択することで、上記のようなエラーを発見できる可能性が高まります。
5. 主要なテクノロジーと単体テスト データをテストする
-
単体テストの主な技術
単体テストの目的はソフトウェア設計の最小単位であるモジュールまたは機能であり、単体テストの基礎は詳細な設計の記述です。単体テストでは主にホワイト ボックス テスト テクノロジを採用し、ブラック ボックス テスト テクノロジを補完して、合理的および不合理な入力を識別して対応できるようにします。 -
単体テストで使用するデータ
通常、単体テストで使用するデータとして実際のデータは使用しません。テスト データを作成するときは、そのデータがユニットの境界条件を適切にテストしていることを確認してください。テスト対象のユニットが大量のデータを操作しており、多くのユニットでその必要がある場合は、実際のデータのより小さい代表サンプルを使用することを検討してください。
6. 単体テストツールの紹介
現在、単体テスト ツールにはさまざまな種類があり、テストの範囲と機能に応じて次のカテゴリに分類できます。
• 静的分析ツール。
• コード仕様レビューツール。
• メモリおよびリソースのチェック ツール。
• テストデータ生成ツール。
• テストフレームワークツール。
• テスト結果比較ツール。
• テスト指標。
• ドキュメントの生成および管理ツールをテストします。
7. ユニットテスター
単体テストは通常、開発者と設計者によって行われます。単体テストは通常、チームリーダーの監督の下で開発チームによって実行され、単体を作成する開発設計者は単体をテストして欠陥を修正するために必要なテストケースとテストデータを設計します。開発チームのリーダーは、適切なテスト技術を使用し、合理的な品質管理と監督の下で、適切なテストが確実に実行されるようにする責任があります。
3. 結合テスト
1. 結合テストの定義
統合テスト (アセンブリ テスト、ジョイント テストとも呼ばれる) は単体テストの論理的な拡張であり、最も単純な形式では、テストされる 2 つのユニットを 1 つのコンポーネントに結合し、それらの間のインターフェイスをテストします。
結合テストは主に、ソフトウェアユニットの組み合わせが正常に動作するかどうか、他のモジュールと統合できるかどうかをテストします。最後に、システムを構成するモジュールのすべての組み合わせが適切に動作することをテストする必要があります。
統合テストの前に単体テストが完了している必要があり、統合テストで使用されるオブジェクトは単体テスト済みのソフトウェア ユニットである必要があります。
2. 結合テストの主な作業
統合テストの主なタスクは、次の 5 つの側面でテスト問題を解決することです。
• モジュールを接続し、モジュールが相互に呼び出したときにインターフェイスを介してデータが失われるかどうかを確認します。
• さまざまなサブ機能を組み合わせて、各機能が期待される要件を満たせるかどうかを確認します。
• あるモジュールの機能が別のモジュールの機能に悪影響を与えるかどうか。
• グローバルデータ構造に問題はないか、異常な変更が発生するかどうか。
• 単一モジュールのエラーが蓄積され、許容できないレベルまで増幅されているかどうか。
3. 統合テストで従う原則
統合テストは、できるだけ早く全体的な設計の計画を開始する必要があります。統合テストを適切に実行するには、次の原則に従う必要があります
。
• 重要なモジュールは適切にテストする必要があります。
• 統合テストは一定のレベルで実行する必要があります。
• 結合テストの戦略選択は、品質、コスト、スケジュールの関係を総合的に考慮する必要があります。
• 統合テストは早期に開始し、全体的な設計に基づいて行う必要があります。
• モジュールとインターフェースの分割に関して、テスターは開発者と十分にコミュニケーションを取る必要があります。
• インターフェイスが変更された場合、関連するインターフェイスを再テストする必要があります。
• テストの実行結果は忠実に記録される必要があります。
4. 結合テスト実施計画
非増分統合テストと増分統合テスト、サンドイッチ統合テスト、コア統合テスト、階層型統合テスト、使用量ベースの統合テストなど、統合テストの実装は数多くあります。その中でも、非増分統合テストと増分統合テストがよく使用されます。
-
非増分統合テスト
要約すると、非増分統合テストは、テストへの 1 ステップのアプローチです。つまり、すべてのモジュールの個別の単体テストの後、各モジュールがプログラム構造図に従って接続され、接続されたプログラムが全体としてテストされます。 -
インクリメンタル統合テスト
インクリメンタル統合テストは、非インクリメンタル統合テストとは異なり、段階的にユニットの統合を実現し、統合テストも段階的に完了します。単体テストと結合テストを組み合わせたものとも言えます。増分統合テストはさまざまな順序で実装できるため、トップダウンの増分統合テストとボトムアップの増分統合テストの 2 つのアプローチがあります。
(1) トップダウンの増分統合テスト。トップダウンの増分統合テストとは、構造図に従って上から下にステップバイステップ統合とステップバイステップテストが実行されることを意味します。つまり、モジュール統合の順序は、最初にメイン制御モジュールを統合することです。 （メインプログラム）を作成し、ソフトウェア制御階層に従って統合します。メイン制御モジュールに従属するモジュールは、深さ優先戦略 (垂直) または幅優先戦略 (水平) に従って、徐々に構造に統合されます。
(2) ボトムアップの増分統合テスト。ボトムアップ増分統合テストは、最下位モジュールから開始され、構造図に従って下から上へ段階的に統合およびテストされます。統合は最下層から開始されるため、上位レベルのモジュールがテストされるとき、下位レベルのモジュールに必要な機能はすでに利用可能であるため、テストを支援するために呼び出されたシミュレートされたサブモジュールを使用する必要はありません。 -
その他の統合テストスキーム
(1) サンドイッチ統合テスト。サンドイッチ統合テストは、トップダウン テストとボトムアップ テストを有機的に組み合わせたもので、トップダウンとボトムアップの統合手法を並行して使用して、改良されたサンドイッチ手法を形成します。
(2) 最初にコア システムが統合され、テストされます。基幹システム先行統合テスト方式の考え方は、まず基幹ソフトウェアコンポーネントの統合テストを実施し、テストの合格に基づいて周辺ソフトウェアコンポーネントを一つずつ基幹システムに統合するというものです。
(3) 高周波積分試験。高頻度の統合テストとは、ソフトウェア開発プロセスと同期し、開発チームの既存のコードに対して定期的に統合テストを実行することを指します。
5. 結合テストのためのテスト技術と結合テストデータ
ソフトウェア統合テストの具体的な内容には、次のような側面が含まれます。(1) 機能テスト。
(2) 信頼性試験。ソフトウェア要件と設計で提示された要件に従って、ソフトウェアの耐障害性、回復の容易さ、およびエラー処理機能がテストされます。
(3) ユーザビリティテスト。ソフトウェア設計時に提示された要件に従って、ソフトウェアのわかりやすさ、学習しやすさ、操作性をチェックおよびテストします。
(4) 性能テスト。ソフトウェア要件と設計で提示された要件に従って、ソフトウェアの時間特性とリソース特性がテストされます。
(5) 保守テスト。ソフトウェアの変更の容易さは、ソフトウェア要件と設計に規定されている要件に従ってテストされます。
6. 統合テスター
統合テストは実環境ではなく開発環境または独立したテスト環境で行われるため、通常は開発チームから選ばれたテスターや開発者によって統合テストが行われます。一般に、統合テストの事前テストは開発者またはホワイトボックステスターによって行われ、事前テストに合格した後、テスト部門によって完了します。統合テスト作業全体は、テスト チーム リーダーのリーダーシップと監督の下で実行されます。テスト チーム リーダーは、合理的な品質管理と監督の下で、適切なテスト手法を使用して適切な統合テストが確実に実行されるようにする責任があります。
4. システムテスト
1. システムテストの定義
システム テストとは、コンピュータ システムの重要な部分として、コンピュータ ハードウェア、周辺機器、一部のサポート ソフトウェア システムなどの他のシステム要素と組み合わせた、統合テストに合格したソフトウェア システムのテストを指します。ソフトウェアがシステム定義に準拠していない、またはシステム定義に矛盾している箇所を見つけるためのシステム。システムテストは、ソフトウェアシステムの正確性とパフォーマンスが要件分析で指定された要件を満たしているかどうかを検証するために、統合ソフトウェアシステムを徹底的にテストします。
2. システムテスト前の準備
テストの前に、次の準備作業を行う必要があります。
• システム テストの基礎としてソフトウェア仕様を収集します。
• システムテストの参考として、各種ソフトウェアのマニュアルを収集します。
• ソフトウェア テスト計画を注意深く読んでください。システム テストの基礎として、独立したシステム テスト計画があるとよいでしょう。すでにコンパイルされたシステム テスト ケースがある場合は、それらをまとめて収集します。
上記のドキュメントをすべて読んでください。既製のシステム テスト ケースがない場合、テスト ケースを作成するのに多大な労力がかかります。上記の文書から、まず次の内容を見つける必要があります。
• システムのさまざまな機能の説明。
• システムに必要なデータ処理と伝送速度。
• システムパフォーマンスの要件。
• バックアップとリカバリの要件。
• 互換性の説明。
• 構成の説明。
• 安全要件など。
3. システムテストのテスト技術とシステムテストデータ
-
システムテストの主要なテスト技術
システムテストはブラックボックステスト技術を完全に採用しており、現時点ではコンポーネントモジュールの実装詳細を考慮する必要はなく、主にソフトウェアが機能、動作、性能、システム連携を満たしているかどうかを確認するためです。性的要求の分析中に決定された基準に従ってください。 -
システム テスト用のテスト データ システム
テストの主な目的は、ソフトウェア システムが受け入れテストに合格するという信頼を確立することであるため、システム テストに使用されるデータは、実際のデータを可能な限り正確かつ代表するものでなければなりません。
4. システムテスター
システム テストを効果的に実施するには、プロジェクト チームは生産的なシステム テスト チームを編成するように努める必要があります。システムテストチームのメンバーは主に以下のような人たちがいます。
• 政府機関の独立したテスト部門が存在する場合、その部門のテスター。
• このプロジェクトの開発者の一部。
• 他のプロジェクトの開発者をシステム テストに参加するよう招待します。
• 機関の品質保証担当者。
5. 受け入れテスト
1. 受け入れテストの定義
受け入れテストは、ソフトウェア開発が完了し、ユーザーがソフトウェア製品を実用化する前に実行される最後の品質検査活動です。開発されたソフトウェア製品が期待される要件を満たしているかどうか、またユーザーがそれを受け入れることができるかどうかという質問に答える必要があります。受け入れテストは主に、ソフトウェア機能の正確性と要件への準拠を検証することです。
2. 受け入れテストの主な内容
ソフトウェア受け入れテストが完了する必要がある主なテストタスクには、構成レビュー、合法性チェック、ドキュメントチェック、ソフトウェア一貫性チェック、ソフトウェア機能およびパフォーマンステスト、テスト結果レビューなどが含まれます。
3. 受入試験の試験手法と受入試験データ
-
受け入れテストの主なテスト技術 受け入れテストは
主にユーザー代表によって行われるため、ユーザー代表は主にシステム使用時の典型的なタスクを実行してソフトウェア システムをテストし、ソフトウェアが機能、動作、要件を満たしているかどうかを分析および検証します。ビジネス要件やシステム調整要件に応じたパフォーマンスを実現するため、受け入れテストではソフトウェアの内部詳細を気にする必要がなく、完全にブラックボックステスト技術を使用します。 -
受け入れテストで使用されるデータ
受け入れテストでは、可能な限り実際のデータを使用する必要があります。実際のデータに機密情報やセキュリティ情報が含まれており、そのデータが部分的または全体的な受け入れテストで表示される場合は、データを安全に保つための措置を講じる必要があります。
実際のデータが使用されない場合 (おそらく、実際のデータを使用する実際のシステムやその他のアプリケーションへのリスクのため、またはデータが機密であるため、または秘密保持の理由のため)、実際のデータのレプリカの使用を考慮する必要があります。複製されたデータの品質、精度、および量は、実際のデータを可能な限り正確に表現する必要があります。
4. α、βテスト
アルファテストは、ソフトウェア開発会社の模擬ソフトウェアシステムの動作環境下での一種の受け入れテストです。つまり、ソフトウェア開発会社が社内の人員を組織して、さまざまなユーザーの行動をシミュレートして、次期ソフトウェア製品（アルファバージョンと呼ばれます）をテストします。バグを見つけて修正する試み。
アルファ版のテストと調整が行われたソフトウェア製品をベータ版と呼びます。以下のベータ テストは、ソフトウェア開発会社の組織のあらゆる側面における一般的なユーザーによる日常業務におけるベータ バージョンの実際の使用を指し、一般に機能、安全性、安全性を含む異常な状況を報告し、批判を提出することをユーザーに要求します。信頼性、使いやすさ、拡張性、互換性、効率性、リソース占有率、ユーザードキュメントなどを考慮し、ソフトウェア開発会社がβ版を修正・改良します。
5. 受け入れテスター
受け入れテストは通常、テスト チームの支援を受けてユーザー代表によって実行されます。一部の組織では、受け入れテストは開発組織 (またはその独立したテスト グループ) とエンドユーザー組織の代表者によって実行されますが、他の組織では、受け入れテストは完全にエンドユーザー組織またはエンドユーザーによって実行されます。組織 実行する客観的かつ公平なチームを形成する人を選択します。
6. 回帰テスト
回帰テストとは、ソフトウェアシステムの機能拡張やバージョンアップなどの変更や拡張を行った後に、新たなエラーが生じていないかを確認するために繰り返しテストを行うことを指します。ソフトウェアに新しい機能が追加されたり、ソフトウェアの欠陥が修正されたりする場合、それらの変更はソフトウェア本来の機能や構造に影響を与える可能性があります。ソフトウェアの変更による予期せぬ副作用を防ぐためには、内容をテストするだけでなく、過去に実施したテストを繰り返して、変更によって予期せぬ結果が生じていないことを証明する必要があります。修正されたソフトウェアでも実際の要件を満たすことができます。
1.回帰テストのテスト手法と回帰テストのデータ
回帰テストでは、一般にブラックボックス テスト手法を使用して、ソフトウェアの実装の詳細を考慮せずにソフトウェアの高レベルの要件をテストします。また、システムの機能強化や拡張がパフォーマンスに影響を与えるかどうかを確認するために、いくつかの非機能テストを使用する場合もあります。システムの特性、他のシステムとの関係、相互運用性と互換性の問題。
回帰テスト データを設計および導入する際の重要な原則は、データ内のテストに影響を与える可能性のある要素が、変更や拡張されていない元のソフトウェアでテストするときの要素と可能な限り一致していることを確認することです。観察されたテスト結果がデータによるものであると判断するために必要ですが、変更は依然として困難です。
2.回帰テストの範囲
回帰テストの範囲を選択する場合、最も簡単な方法の 1 つは、問題の修正が正しく、他の機能に悪影響を及ぼさないことを確認するために、前のテスト段階で確立されたすべてのテストを回帰ごとに実行することです。明らかに、そのような返品のコストは高くつきます。もう 1 つの方法は、以前のテスト ケースを選択的に実行することです。現時点では、回帰中に前のテスト ケースのサブセットのみが実行されますが、このサブセットの選択が合理的かつ代表的であるかどうかは、回帰テストの効果と効率に直接影響します。一般的に使用されるユースケースの選択方法は、以下の3種類に分類できます。
(1) 改造範囲に限定した試験。
(2) 影響を受ける機能の範囲内での回帰。
(3) 特定のカバレッジ指標に従って回帰テストを選択します。
3.回帰テスター
回帰テストは一般にシステム テストと受け入れテストに関連付けられているため、適切な手法が選択および使用されていること、および適切な回帰テストが合理的な品質管理のもとで実行されていることを確認するのはテスト チーム リーダーの責任です。
7. システムのトラブルシューティング
システムのトラブルシューティングのタスクは、テスト中に見つかったエラーの原因と具体的な場所を特定し、修正することです。トラブルシューティングは、テストの成功と密接に関連しています。テストの成功とは、エラーの発見です。エラーの兆候に基づいてエラーの原因と正確な位置を特定し、それらを修正することは、主にトラブルシューティング手法に依存します。デバッグ作業は主にプログラム開発者によって行われます。つまり、プログラムの開発者がデバッグの責任を負います。
一般的に使用されるトラブルシューティングの方法と戦略は次のとおりです。
- プリミティブ クラスのトラブルシューティング
- 後戻り
- 帰納的と演繹的
要約する
以上が今日のお話ですが、この記事ではソフトウェアテストの基本的な考え方を簡単に紹介するだけですので、読んでいただいている方の参考になれば幸いです。ソフトウェアのテストにも興味がある場合は、私に従って学んでください。
私の文章が悪くないと思っていただけましたら、ぜひ「いいね！」や励ましをお願いします。同時に、この記事を友達と共有して一緒に学ぶこともできます。最後に、誰もが一緒に進歩できるように、学習プロセスで遭遇した問題についてプライベート メッセージやコメントで私と話し合うことを歓迎します。