【ソフトウェアテスト】ソフトウェアテストの基本概念と開発モデル

1 はじめに

ソフトウェア テストについて学習する前に、ソフトウェア テストのいくつかの基本概念を理解する必要があります. これらの基本概念は、作業の目標とソフトウェア テストが実際に何をするかを明確にするのに役立ちます.

2. ソフトウェアテストの基本概念

ソフトウェア テストには、要件、テスト ケース、バグという 3 つの基本的な概念があります

2.1 要件

ここでの要件は、ユーザー要件とソフトウェア要件に分けることもできます. ユーザー要件: 当事者 A によって提案された要件として単純に理解されます. ソフトウェア要件: 開発者が達成したいソフトウェア機能. ソフトウェアは開発の基礎としても使用されます.テスト. 一般的に言えば,
ユーザーの要件は、ソフトウェアの要件として直接使用することはできません. 私たちは、ユーザーのニーズを分析する必要があります. ここでの分析は、技術的な分析かもしれません (技術が実現可能かどうかを見る). 市場分析から (市場の需要), コスト分析から (コストと収益シェア) 比較)。

2.2 テストケース

テストケースの意味は、何をテストし、どのようにテストするかであり、テストする要素が明確になっている テストケースの要素には、タイトル、テスト環境、操作手順、テストデータ、および期待される結果が含まれます。

  • タイトル: このテスト ケースの機能を簡単に説明してください
  • テスト環境:異なる環境でのテスト結果は異なる場合があります
  • 操作手順: 異なる操作手順の結果も異なる場合があります
  • テスト データ: テスト環境とテスト手順に従って得られた結果
  • 期待される結果: 期待される結果

2.3 バグ

製品仕様(要求ドキュメント)と一致していなくても、それはバグであり、
主なポイントは次のとおりです。

  • 製品仕様 (要求文書) が存在し、正しいが、プログラムによって実装された機能が製品仕様 (要求文書) の要件と一致しない場合にのみ、それはソフトウェア エラーです。
  • 製品仕様書 (要求文書) に提案された機能が含まれていない場合は、ユーザーが優先し、プログラムがユーザーの合理的な期待に応えていない場合 (テスト担当者に優れた製品思考が要求される場合)、これもソフトウェア エラーです。

3. 開発モデル

開発モデル (ソフトウェア開発モデル) は、ソフトウェア開発のプロセス、アクティビティ、およびタスク全体の構造的フレームワークを指します。

3.1 ソフトウェア/ソフトウェア開発ライフサイクル

ソフトウェア/ソフトウェア開発のライフ サイクルは、一般に次の 6 つのフェーズに分けられます。需求分析->计划->设计->编码->测试->运行维护

  • 需要分析:ここでの分析は前のものと一致しています.市場分析、技術分析(技術がそれをサポートしているかどうかを技術的な観点から)、コストと収入の割合分析を行う必要があります.
  • 計画: いつ開始し、いつ終了するか。
  • 設計: 大きな要件を実行可能な小さなタスクに分割する
  • コーディング: 開発者は、テスト ドキュメントと開発ドキュメントを参照して機能を実装します。
  • テスト: テスターがテストを実施
  • 運用と保守: 運用と保守は完全で、修復可能で、予防的でなければなりません.製品が発売されると、ユーザーはそれを使い始めます.ユーザーがテスターが見つけられなかったバグを見つけた場合、後でテスト開発者がバグを修正し、発生の可能性をチェックします.対処すべきバグ

ソフトウェア テストは、ソフトウェアのライフ サイクル全体を通じて実行されます。

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

软件测试分为以下几个阶段: 需求分析->测试计划->测试设计与开发->测试执行->测试评估

  • 要件分析: 1. ユーザーの視点から考える:ソフトウェア要件が合理的かどうかを判断する 2. 技術の視点から考える:技術的に実現可能かどうか、最適化の余地があるかどうか 3. テストの視点から考える問題: 現在のビジネス ロジックに冗長性/競合があるかどうかを判断する
  • テスト計画: いつテストを開始するか、いつテストを終了するか、テストにかかる時間
  • テストの設計と開発: 1. テスト ドキュメントを作成し、テスト メソッド、テスト ツール、テスト フォームなどを明確にマークします。 2. テスト ケースを作成します。
  • テストの実行: テスト ケースやその他のツールを最大限に活用して、プロジェクト全体を可能な限りテストします。
  • テスト評価:製品に他の品質上の問題があるかどうかを評価し、機能のデモンストレーションを行います

プロジェクトのテストが完了したら、プロジェクトを開始する必要があります.プロジェクトが開始された後、テスターは製品に間に合うように問題があるかどうかにも注意を払う必要があります.問題がある
場合:

  1. この問題を再現して、この問題が一般的なものか単独のものかを判断してください。
  2. 問題の原因を突き止め、開発者ができるだけ早く問題を突き止め、問題を解決できるようにします。
  3. 問題を振り返る: なぜ問題が発生したのか、どのように解決するのか、今後問題を回避する方法を考えます。

3.3 ウォーターフォールモデル

ウォーターフォール モデルは、ソフトウェア エンジニアリングにおいて重要な位置を占めており、他のすべてのモデルの基本的なフレームワークですウォーターフォール モデルの各段階は1 回だけ実行されるため、直線的に進行するソフトウェア開発モデルです。

ウォーターフォール モデルのフローチャート:
ここに画像の説明を挿入
主に次の手順:
ここに画像の説明を挿入
ウォーターフォール モデルの特徴:

  1. 線形構造、各構造は 1 回だけ実行されます
  2. 他のすべてのモデルの基本フレームワークです

ウォーターフォール モデルの短所:

  1. 事後テスト (1) テスト前の各段階で残されたリスクは、テスト段階まで発見されず、プロジェクトの大規模な手直しにつながり、早期に問題を発見して解決する機会を失います (2)テスト段階では、テストが十分でないと、欠陥がユーザーに公開されます。
  2. サイクルが長すぎると、製品が表示されて使用されるのが非常に遅くなり、要件が陳腐化する可能性があります。

ウォーターフォール モデルの適用シナリオ:要件が固定された小規模プロジェクト

3.4 スパイラルモデル

スパイラル モデルのフローチャート:
ここに画像の説明を挿入
上の図はあまり見栄えがよくありません. 次に, ウォーターフォール モデルを使用してこの図を理解します. この図を見てください: ウォーターフォール
モデル
ここに画像の説明を挿入
と比較して, スパイラル モデルはリスク分析とプロトタイプを増やします. 需要分析では, 計画と設計の後にリスク分析が必要であり、リスク分析のたびに新しいプロトタイプが得られます. 設計後のリスク分析の後に実行可能なプロトタイプが得られます.

スパイラル モデルの機能: リスク分析とプロトタイピングの追加

スパイラル モデルの短所:

  1. プロジェクトに存在する可能性のあるリスクは、リスク管理担当者のスキルレベルに直接関係しています
  2. 人員、資金、時間のコストが増加して投資され、プロジェクトのコストが高すぎる

スパイラル モデルの適用シナリオ: 大規模で複雑性が高くリスクの高いプロジェクト

3.5 増分モデル

増分モデルのフロー チャート:
ここに画像の説明を挿入
増分モデルは、大きな需要を独立して開発および起動できる機能に分割します.
たとえば、プロジェクトで多くの機能を実装する必要がある場合は、最初に機能の一部を開発し、その後オンラインにすることができます.開発が完了し、他の開発が完了してから他の機能を立ち上げる、というのがインクリメンタルモデルのプロセスです。

3.6 反復モデル

ここに画像の説明を挿入
反復モデルは、最初に基本機能を完成させ、次にこれらの基本機能を必要に応じて継続的に改善および最適化することです。

3.7 アジャイルモデル

アジャイル開発には多くの方法がありますが、その中でもスクラムが最も人気があります。

スクラム モデルには、プロダクト マネージャー、プロジェクト マネージャー、R&D チームの 3 つの役割があります. 5 つの
重要な会議: リリース計画会議、イテレーション計画会議、毎日の会議、デモ会議、ふりかえり会議

  • リリース計画会議: 最終要件の決定
  • イテレーション企画会議:タスク分解、責任者特定、工数評価
  • デイリーミーティング:現在のプロジェクトの進捗状況を把握し、デイリーミーティング後に「成果物ソフトウェア」を渡す
  • デモ セッション: ユーザー要件の生成
  • ふりかえり会議: 現在の反復サイクルの欠点を要約し、次の反復で最適化する

アジャイル モデルの特徴: 1. 軽いプロセス 2. 軽いドキュメント 3. 重い目標 4. 重いアウトプット

4. テストモデル

上記はすべて開発モデルであり、テストモデルにはVモデルとWモデルがあります。

4.1 V モデル

ここに画像の説明を挿入
Vモデルの特徴: 1.テストプロセスにはさまざまなタイプのテストがあります 2.テスト段階の参照標準は、前の対応する段階の対象となります

短所:テスト投稿(以前と同じ)

4.2Wモデル

W モデルは「ダブル V モデル」とも呼ばれ、
ここに画像の説明を挿入
ソフトウェアの各開発段階で同時に行うべき検証と確認の作業が増えます。
Wモデルの特徴:テストの対象はプログラムだけではなく、要求や設計なども対象とし、テストと開発を同時に行う
Wモデルのメリット: 1.問題の早期かつ網羅的な発見に資する. 2. 要件のテストは、プロジェクトの難しさとテストのリスクをタイムリーに理解し、対策を早期に策定するのにも役立ちます。これにより、テスト全体の時間が大幅に短縮され、プロジェクトの進行がスピードアップします。
Wモデルの短所: 1. Wモデルはプロセスに焦点を当て、アジャイルモデルに適応しない. 2. テストと開発活動も直線的な前後関係を維持し、前の仕事を引き継ぐことしかできない.前の仕事が終わったらアウト。

5. まとめ

この記事では、主にソフトウェア テストの 3 つの基本概念、開発モデルとテスト モデルの特徴、欠点、および適用シナリオについて説明します. 概念が多く、退屈に思えますが、基本概念を習得することによってのみ、ソフトウェア テストをよりよく学ぶことができます.

ご覧いただきありがとうございます! この記事がお役に立てば幸いです!
コラム: 「ソフトウェア テスト」は常に更新されています。購読を歓迎します!
「あなたを励まし、一緒に働きたい!」
ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/m0_63463510/article/details/129974147