ソフトウェアは完全に完璧なものではありません。 しかし、それはゴミを作成するためのライセンスですか？ 不足している成分は、品質を定量化するために私たちの不本意です。 品質を向上させるためには、ソフトウェアアプリケーションの効果的なパフォーマンスを確保することが非常に重要です。 アプリケーションが障害なしに実行されるようにするには、ソフトウェアテストが必要です。 このソフトウェアテストチュートリアルでは、私はあなたがテストの側面について知っておく必要があるすべてを教えてくれます。 ソフトウェアテストとは何かについての以前のブログに続き、ここで私はより深く掘り下げ、以下のトピックをカバーします。
- ソフトウェアテストの概要
- ソフトウェアテストの基本
- ソフトウェア開発ライフサイクル
- 検証と検証モデル
- ソフトウェアテスト方法
- ソフ
- バグライフサイクル
- 手動テストが直面する課題
- 自動テストと手動テスト
ソフトウェアテストトレーニングの専門家が概念を説明したソフトウェアテストチュートリアルの記録を参照することもできます 深さで。
初心者のためのソフトウェアテストチュートリアル/マニュアル&自動化テスト
このビデオでは、手動テストと自動テストのアプローチなど、さまざまなタイプのテストについて説明します。
ソフトウェアテストの概要
今日の技術の世界は完全に機械によって支配されており、その動作はソフトウェアによって制御されています。 ソフトウェアテストはすべての私達の心配に費用効果が大きい解決を提供します。 ソフトウェアテストとは何ですか？ ソフトウェアテストは、ソフトウェアのバグを見つけるためにソフトウェアアプリケーションの機能を評価するプロセスです。 開発されたソフトウェアが指定された要件を満たしているかどうかを確認し、高品質の製品を達成するためのソフトウェアの欠陥を特定します。 基本的には、実際の要件に反して、ギャップ、エラー、または不足している要件を識別するためのシステムを実行しています。
ソフトウェア製品を検証および検証するプロセスとしても記載されています。 これは、ソフトウェア製品かどうかをチェックします:
- は、その設計と開発を導いたビジネスおよび技術的要件を満たしています
- 要件に従って動作します
- は同じ特性で実装できます
さて、ソフトウェアテストのチュートリアルの記事でさらに移動し、ソフトウェアテストの基本についていくつかの洞察を得てみましょう。
ソフトウェアテストの基礎
まず、ソフトウェア開発のライフサイクルとは何かを教えてくれますか？
Software Development Life Cycle
(SDLC)は、ソフトウェア開発ライフサイクルと略され、高品質のソフトウェアを設計、開発、テストするためにソフトウェア業界で使用されるプロセ それは顧客の期待に応えるか、または超過し、時間および費用の見積もり内の完了に達する良質ソフトウェアを作り出すことを向けます。 以下の図は、SDLCに関与する様々な段階を示しています。
Fig: ソフトウェア開発ライフサイクル-ソフトウェアテストチュートリアル
要件フェーズ
要件の収集と分析は、ソフトウェア開発ライフサイクル Business analystは、クライアントのビジネスニーズに応じて顧客/クライアントから要件を収集し、ビジネス要件仕様の要件を文書化します（文書名は組織によって異
分析フェーズ
要件が収集され、分析されたら、次のステップは、製品要件を定義して文書化し、顧客によって承認されることです。 これは、SRS（ソフトウェア要件仕様）文書を通じて記録されます。 これは、プロジェクトライフサイクル
設計フェーズ
中に設計および開発されるすべての製品要件で構成されていますこのフェーズには2つのステッ:
- HLD–高レベル設計-開発するソフトウェア製品のアーキテクチャを提供し、アーキテクトと上級開発者によって行われます
- LLD–低レベル設計–上級開発者 ここでは、製品の各機能がどのように機能するか、およびすべてのコンポーネントがどのように機能するかについての洞察を提供します。
このフェーズからの結果は、次のフェーズへの入力として機能する高レベル文書と低レベル文書です。
開発フェーズ
すべてのレベル（先輩、後輩、新入生）の開発者がこのフェーズに関与しています。 これは、ソフトウェアのコードの構築を開始する段階です。
テストフェーズ
ソフトウェアの準備が整うと、テスト部門に送信され、さまざまな欠陥がないか徹底的にテストされます。 ソフトウェアのテストは、手動または自動テストツールを使用して実行され、ソフトウェアの各コンポーネントが正常に動作することを確認します。 ソフトウェアがエラーフリーになると、実装である次の段階に進みます。
展開&メンテナンスフェーズ
製品にエラーがないと、製品は顧客に配信/展開され、使用されます。 展開は、展開/実装エンジニアによって行われます。 顧客が開発したシステムを使用し始めると、実際の問題が出てきて、時々解決する必要があります。 顧客が見つけたこれらの問題を検出し、解決することは維持段階に来ます。
これはすべてソフトウェア開発のライフサイクルに関するものでした。 ソフトウェアテストプロセスに関わるさまざまな段階について知りたい場合は、ソフトウェアテストライフサイクルに関するこのブロ これを理解したら、このソフトウェアテストチュートリアルでさらに進み、V&Vモデルが何であるかを見てみましょう。
Vモデルは現在、最も広く使用されているソフトウェア開発プロセスの一つです。 Vモデルの導入は、実際には要件段階からのテストの実施を証明しています。 検証と検証モデルとも呼ばれます
ソフトウェアテストにおける検証と検証とは何ですか？
検証:検証は静的解析手法です。 ここでは、テストはコードを実行せずに行われます。 例には、レビュー、検査、およびウォークスルーが含まれます。
検証：検証は、コードを実行することによってテストを実行する動的分析のプロセスです。 例には、機能的および非機能的な試験技術が含まれる。
Vモデルでは、開発とQA活動が同時に行われます。 ここでは、テストは要件段階から開始されます。 検証活動と検証活動は同時に行われます。 Vモデル
一般的な開発プロセスでは、左側が開発活動を示し、右側がテスト活動を示しています。 開発段階では、検証と検証の両方が実際の開発活動と一緒に行われると言っても間違ってはいけません。
LHS
先に述べたように、左側の活動は開発活動です。 通常、私たちは開発段階でどのようなテストを行うことができますか？ しかし、これがこのモデルの本質であり、開発活動のすべての段階でテストを行うことができることを示しています。
RHS
テスト活動または検証フェーズは、モデルの右側で実行されます。
これについていくつかの洞察を得たので、このソフトウェアテストチュートリアルをさらに進め、ソフトウェアをテストできるさまざまな方法が何であるかを見てみましょう。
ソフトウェアのテスト方法
ソフトウェアのテストには三つの方法があり、それらは次のとおりです:
- ブラックボックステスト
- ホワイトボックステスト
- グレーボックステスト
ブラックボックステスト：テストされている項目の内部構造/設計/実
ホワイトボックステスト：テストされているアイテムの内部構造/設計/実装がテスターに知られているソフトウェアテストの方法です。
グレーボックステスト:システムの内部機能に関する限られた情報で実行されるテスト手法です。
ソフトウェアテストのさまざまな方法に関する重要な指針を理解していただければ幸いです。 さて、このソフトウェアテストチュートリアルの記事でさらに移動し、ソフトウェアテストレベルを理解してみましょう。
ソフトウェアテストレベル
ソフトウェアテストのレベルは、ソフトウェア/システムのすべてのユニットまたはコンポーネントがテストされているプ ソフトウェアテストの動作とパフォーマンスをチェックするのに役立つさまざまなテストレベルがあります。 これらのテストレベルは、不足している領域を認識し、ライフサイクル状態の開発間の調整を行うように設計されています。 ソフトウェア開発ライフサイクルモデルでは、要件の収集、分析、設計、コーディングまたは実行、テスト、展開などの特徴づけられた段階があります。
これらのフェーズはすべて、ソフトウェアテストレベルのプロセスを経ます。 主に四つのテストレベルがあり、それらは次のとおりです:
- 単体テスト
- 統合テスト
- システムテスト
- 受け入れテスト
基本的には、単体テストフェーズから始まり、受け入れテストで終了します。
このソフトウェアテストチュートリアルの次のセクションでは、次のトピックに深く入り込み、ソフトウェアテストにおけるさまざまなドキュメ
ソフトウェアテストドキュメントアーチファクト
テストケースを文書化することで、テストカバレッジと追跡とトレースの要件とともに必要なテス ソフトウェアテストに関連する一般的に適用される文書成果物には、次のものがあります:
- テスト計画
- テストシナリオ
- テストケース
- トレーサビリティマトリックス
それぞれについて簡単に説明しましょう。
- テスト計画：アプリケーションをテストするために実装される概要戦略を提供します。
- テストシナリオ:テストシナリオは、アプリケーションが実験される領域を通知する単一行のステートメントと見なすことができます。 このアーティファクトは、最初から最後までテストされた全体的な手順を確実にするために必要です。
- テストケース:テストケースは、テスト対象のシステムが要件を満たすか、正しく動作するかをテスターが判断する条件または変数のセットに過ぎません。 以下のテストケースは、テスト中にチェックされています。
- 機能テストケース
- ネガエラーテストケース
- 論理テストケース
- 物理テストケース
- UIテストケース
- トレーサビリティマトリックス:要件トレーサビリティマトリックス(RTM)とも呼ばれます。 製品のSDLCモデルが作成されるときの要件をスケッチする表が含まれています。 これらの文書化された成果物は、設計からコーディングに移行する順方向トレースに適用することができ、または順方向トレースの逆である逆方向トレーシングのために実装することができる。
これにより、ソフトウェアテストドキュメントアーチファクトが終了します。 さて、このソフトウェアテストチュートリアルの記事でさらに移動し、欠陥管理とは何かを学びましょう
欠陥管理プロセスとは何ですか？
欠陥管理は、バグを検出して修正するプロセスです。 バグはソフトウェア業界の一部であるため、ソフトウェア開発の過程で常に発生します。 チームメンバーは毎日大量のコードを書かなければならず、通常はバグを避ける方法について考える時間がありません。 したがって、すべてのソフトウェア開発プロジェクトには、欠陥を検出して修正するのに役立つプロセスが必要です。
欠陥管理プロセスは、製品テストの段階で行われます。 これを実現しなければ、欠陥管理の性質を理解するのは難しいでしょう。. 通常、開発者は製品を自分でテストします。 また、ユーザーの関与に基づいたタイプのテストもあります。 最終的なユーザーには、特定したバグを報告する機能が提供されることがよくあります。 それにもかかわらず、ユーザーがすべてのバグを見つけることができない可能性があるため、これはテストの最良の方法ではありません。
欠陥管理プロセスには、通常、四つのステップが含まれています。
- 最初のステップは、欠陥検出の段階です
- 第二のステップは、バグレポートの策定に専念しています
- 第三のステップは、バグを修正することです。
- 最後のステップでは、バグリストが作成されます
さて、ソフトウェアテストチュートリアルの記事でさらに進み、バグライフサイクルの助けを借りてバグ検出プロセスを理解しましょう。
バグのライフサイクル
欠陥のライフサイクルは、欠陥がその寿命全体の間に様々な段階を経るプロセスです。 これは、欠陥が見つかったときに開始され、欠陥が再現されないことを確認した後、欠陥が閉じられたときに終了します。 欠陥のライフサイクルは、テスト中に発見されたバグに関連しています。
バグまたは欠陥のライフサイクルには、次の図に示す手順が含まれています:
- 新しい: このステップでは、欠陥が初めてログに記録されて転記された場合、その状態はnewとして与えられます。
- 割り当て:テスターがバグを投稿した後、テスターのリードはバグが本物であることを承認し、対応する開発者と開発者チームにバグを割り当てます。 Assignedとして指定された状態です。
- Open:この状態で、開発者は欠陥修正の分析と作業を開始しました。
- 修正：開発者が必要なコードの変更を行い、変更を確認すると、バグステータスを”修正”にしてバグをテストチームに渡すことができます。
- テスト：この段階で、テスターは、欠陥が修正されたかどうかを確認するために、開発者が彼に戻って与えた変更されたコードのテストを行います。
- 検証済み：ここでは、テスターは開発者によって修正された後にバグを再度テストします。 ソフトウェアにバグがない場合、彼はバグが修正されたことを承認し、ステータスを”検証済み”に変更します。
- 再オープン:開発者によってバグが修正された後でもバグがまだ存在する場合、テスターはステータスを”再オープン”に変更します。 この状態では、バグは再びライフサイクルを通過します。
- Closed:バグが修正されるとすぐに、テスターによってテストされます。 バグがソフトウェアに存在しなくなったとテスターが感じた場合は、バグのステータスを”closed”に変更します。 これは、バグが修正され、テストされ、承認されていることを意味します。
- Duplicate:バグのライフサイクルで、バグが二度繰り返されるか、二つのバグがバグの同じ概念を言及した場合、一つのバグステータスが”duplicate”に変更されます。
- 拒否:開発者がバグが本物ではないと感じた場合、開発者はバグを拒否します。 その後、バグの状態は”拒否”に変更されます。
- Deferred:バグがdeferred状態に変更された場合、バグは次のリリースで修正されることが期待されていることを意味します。
これはすべてバグのライフサイクルと欠陥管理プロセスに関するものでした。 さて、手動テストの課題は何かを見てみましょう。
手動テストの課題
QAテスターによるアプリケーションの手動テストは、手動テストと呼ばれます。 ここでは、すべてのテストは、異なるデータセットを使用して、すべての環境で手動で実行する必要があり、すべてのトランザクションの成功/失敗率を記
上の図では、記録されたトランザクションを手動で検証する男を見ることができます。 あなたは簡単に彼が直面している課題を通知することができますので、手動の努力の疲労、退屈、仕事の遅延、ミスやエラーを引き起こす可能性がありま これは、自動化テストの出現につながりました。
さて、ソフトウェアテストチュートリアルの最後のトピックの記事を掘り下げ、自動テストが手動テストにどのように勝るかを見てみましょう。
自動化テストと手動テスト
自動化テストは毎回手動テストを克服します。 どうして？ それは超高速であるため、人的資源への投資が非常に少なく、エラーが発生しにくいため、テストの頻繁な実行が可能であり、回帰テストと機能テストを
例を挙げて、これを理解しましょう。 ログインページがあり、すべてのログイン試行が成功したかどうかを確認する必要があるとすると、すべてのトランザクション/ログイン試行が成功したかどうかを検証するコードを書くのは本当に簡単です（自動テストケースの実行）。
これらのテストはすべて、さまざまな環境やwebブラウザでテストされるように設定できます。 それだけでなく、日中の特定の時間にスケジュールすることで、結果ファイルの生成を自動化することもできます。 次に、これらの結果に基づいてレポートの生成を自動化することもできます。
ここで重要な点は、自動化テストはテスターの仕事をはるかに簡単にするということです。 同じテスターが働いているよりリラックスした環境を示す上のイメージを参照して下さい。 自動化テストと広く使用されている自動化テストツールSeleniumについてもっと知りたい場合は、このSeleniumチュートリアルを参照してください。
これは、ソフトウェアテストの分野で自動化テストがどのように輝いているかについてのすべてでした。 これは、ソフトウェアテストチュートリアルの記事の最後に私たちをもたら 私はあなたがそれが有益であり、それがあなたの知識に価値を加えるのに役立ったことを願っています。
この”ソフトウェアテストチュートリアル”が関連していることがわかった場合は、世界中に250,000人以上の満足している学習者のネットワークを持つ信頼