【ソフトウェア品質とソフトウェアテスト】

第 1 章 ソフトウェアの品質とテストの背景

1.1 ソフトウェアの機能とソフトウェアエンジニアリング

ソフトウェアの定義 (IEEE)

• ソフトウェアは、コンピュータ システムを操作するために必要なコンピュータ プログラム、手順、および場合によっては関連する文書やデータです。

• ソフトウェアは、ソフトウェア システムの動作に必要なコンピュータ プログラム、手順、文書、データの 4 つの部分で構成されます。

コンピュータハードウェアとコンピュータソフトウェア

• ソフトウェアは物理的な製品ではなく論理的な製品であるため、ソフトウェアはハードウェアとはまったく異なる特性を持っています

ソフトウェアはハードウェアとは全く異なる特性を持っています

• ソフトウェアは開発されるものであり、従来の方法を使用して製造されるものではありません。
• ソフトウェアはハードウェアのように消耗しません。
• 多くのソフトウェアは既存のコンポーネントを使用して組み立てることはできず、それ自体でのみ定義できます。

ハードウェアとソフトウェアの故障曲線

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-GBoZpE6v-1684854031351)(D:\Typora Img\image-20230523191933514.png)]

​

1.1.1 ソフトウェアの分類

現在のコンピュータ ソフトウェアは、大きく 7 つのカテゴリに分類されます

• システムソフトウェア
• 応用
• Webアプリケーションソフト
• 工学および科学ソフトウェア
• 組み込みソフトウェア
• 製品ライン ソフトウェア
• 人工知能ソフトウェア

新しい挑戦

• ユビキタスコンピューティング
• インターネットリソース
• オープンソースソフトウェア
• 新しい経済

​

1.1.2 階層型ソフトウェアエンジニアリング

• ソフトウェア開発プロセスのエンジニアリング管理を実現するために、ソフトウェアのライフサイクルをいくつかの段階に分解し、各段階で特定のアクティビティを実行することを指します。

ソフトウェア工学

• (1) ソフトウェアの開発、運用、保守のプロセスに体系的かつ標準化された測定可能な手法を適用する、つまりソフトウェアにエンジニアリングを適用する。
• (2) (1)の方法に関する研究

ソフトウェアエンジニアリングの視点

• これは、ソフトウェアをより適切に管理および開発するために、システムのさまざまな要素 (コード、モジュール、インターフェイス、データなど) をさまざまな観点から整理することによって、ソフトウェア システムのさまざまな側面を記述、理解、分析することを指します。

3つのビュー

• 「何をするか」のフェーズを定義する
• 開発フェーズは「ハウツー」に焦点を当てます。
• 維持フェーズは「変化」をターゲットにする

1.1.3 ソフトウェアパラダイムの変化

• これは、ソフトウェア エンジニアリングの継続的な発展に伴い、ソフトウェア パラダイムも常に変化していることを意味します。ウォーターフォール モデルなどの従来のソフトウェア開発モデルは、アジャイル開発や DevOps などの新しいモデルに徐々に置き換えられています。

1.1.4 最新のソフトウェア開発

• これは、ユーザー中心のソフトウェア開発手法を指し、グローバリゼーション、組織間連携、および配布の文脈において、迅速な反復、高品質、革新性を重視します。

1.2 ソフトウェアの品質

1.2.1 品質概念

• 意図した要件を満たす特性や特性の全体的な発現を指します。

1.2.2 質量運動

• 品質を中心とした管理・改善プロセス全体を指します。

トータル品質管理の4つのステップ

1. 計画：品質目標とプロセスを決定し、品質保証システムを確立します。
2. 実装: 計画段階で決定された品質保証システムを実装し、プロセス管理、継続的改善、トレーニングなどの活動を実行します。
3. 検査: プロセスと製品が品質基準と要件を満たしているかどうかを確認するために監視および測定します。
4. 改善: テスト結果と継続的改善を分析することで製品とプロセスの品質を向上させ、改善のための新しい機会と方法を模索します。

1.2.3 ソフトウェア品質の概念

• ソフトウェア品質の IEEE 定義: ソフトウェア品質は

• システム、コンポーネント、またはプロセスが指定された要件をどの程度満たしているか。

• システム、コンポーネント、プロセスが顧客やユーザーのニーズや期待をどの程度満たしているか。

この定義は比較的客観的であり、製品（またはサービス）と顧客/社会のニーズの一貫性を強調しています。

6つの主な特徴

• 機能性: ソフトウェアによって実装される機能が、要求および暗黙のユーザー ニーズおよび設計仕様をどの程度満たしているか。
• 信頼性: ソフトウェアが指定された条件下で指定された期間にわたってパフォーマンスを維持する度合い。
• 使いやすさ: ソフトウェアを使用するためにユーザーが費やす学習努力、
• 効率: 指定された条件下で、ソフトウェアの機能と占有リソースの比率。
• 保守性: エラーの発見、動作環境の変更、または顧客の要件の変更時にプログラムを簡単に修正できること。
• 移植性: ソフトウェアをある環境から別の環境に簡単に移動できること

ソフトウェアの品質保証とテストの関係

• QA + テスト = 優れたソフトウェア

1.2.4 ソフトウェアの品質評価制度と基準

• ソフトウェアの品質を評価および測定するために使用される標準、モデル、およびフレームワークを指します。

ソフトウェア品質保証 (SQA)

• ソフトウェア品質保証は、ソフトウェア製品と関連する作業プロセスが期待される基準と品質要件を満たしていることを確認し、ソフトウェアの品質を向上させるための方法とサポートを提供することを目的とした一連の計画と活動です。

1.3 ソフトウェアテストと信頼性の概要

1.3.1 ソフトウェアテストの意義

• ソフトウェアの欠陥を見つけて修復し、ソフトウェアの品質と信頼性を向上させることです。

1.3.2 ソフトウェアテストの定義

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

1.3.3 ソフトウェアのテスト方法

• 静的メソッドと動的メソッド
• ブラックボックステスト、ホワイトボックステスト、グレーボックステスト
• ソフトウェア開発段階に応じたテスト方法

1.3.4 ソフトウェアテストの自動化

• ツールとテクニックを使用してテストを自動化するプロセスを指します。
  • ホワイトボックステストツール
  • 機能テストツール
  • 負荷応力試験ツール
  • テスト管理ツール

1.3.5 ソフトウェアの欠陥に対する修理費用

• ソフトウェアの欠陥を修正するコストは時間の経過とともに増加する

ソフトウェアテストエンジニアの資質

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-qvgflCDx-1684854031352)(D:\Typora Img\image-20230523194608519.png)]

1.4 ソフトウェア品質保証と人材テストの特徴

1. 技術的能力を持っている: ソフトウェアの品質保証およびテスト担当者は、ソフトウェア開発技術、テストツールと方法などの知識を含む、優れた技術的能力を持っている必要があります。
2. 詳細指向: ソフトウェアの品質保証とテスターは詳細指向であり、問​​題を見つけて文書化し、問題を正確に説明し、解決策を追跡できる必要があります。
3. コミュニケーションとコラボレーション: ソフトウェアの品質保証およびテスト担当者は、開発者、プロジェクト マネージャー、その他の関連担当者と協力し、プロジェクトに積極的に参加し、タイムリーなフィードバックを提供し、問題を解決するために、優れたコミュニケーションおよびコラボレーション スキルを必要とします。
4. 分析と判断: ソフトウェアの品質保証とテストの担当者は、鋭い分析と判断能力を持ち、独立して考え、問題の根本原因を迅速に見つけることができる必要があります。
5. 継続的な学習: ソフトウェアの品質保証およびテスト担当者は、継続的に学習し、新しいテクノロジーやツールに注意を払い、それらを日々の業務に積極的に適用して作業効率と品質を向上させる意欲と能力を備えている必要があります。
6. 強い責任感: ソフトウェアの品質保証およびテスト担当者は、強い責任感とプロフェッショナリズムを持ち、自らの作業に着手し、プロジェクトの品質と進捗を保証できる必要があります。

1.5 章の概要

• ソフトウェア品質保証とは、提案された標準、手順、実践、および方法がすべてのプロジェクトに正しく採用されていることを管理者が保証するための、計画的かつ体系的なアプローチの確立です。
• ソフトウェアテストとは、テスト計画とプロセスに従ってテストツールを使用して製品の機能と性能をテストし、必要に応じて異なるテストツールを作成し、テストシステムを設計および保守し、製品の潜在的な問題を分析および評価することです。テスト計画。

第2章 ソフトウェア品質エンジニアリングシステム

2.1 ソフトウェアの品質管理の基本方法

2.1.1 ソフトウェア品質管理の基本概念

• ソフトウェア品質管理とは、ソフトウェア開発プロセスの各リンクを追跡および監視し、問題を時間内に発見して解決し、ソフトウェアの最終品質が期待される要件を満たしていることを確認することを指します。

2.1.2 ソフトウェア品質管理の基本方法

• ターゲットの質問指標

  • 目標を設定する: プロジェクトの各側面 (製品、プロセス、リソース) に具体的な目標を設定します。これは非常に明確で、望ましい品質と目標を反映している必要があります。
  • 質問する: 目標ごとに一連の質問をして、目標が達成されているかどうか、または何を改善する必要があるかを明らかにします。
  • 定量的目標: 質問に対する回答をソフトウェア品質レベルの指標にマッピングし、その指標に基づいてソフトウェア目標が達成されたかどうかの結論を導き出します。あるいは、どれがうまく機能し、どれがまだ改善の必要があるかを確認します。
  • データの収集: データの収集と分析の計画を立て、収集したデータを長期的に使用できるように保存して、長期的かつ継続的な目標の改善を達成します。

• リスク管理法

  • リスク要素を経験的に特定する
  • リスクを評価する
  • リスクを分類してランク付けする
  • リスクを制御し、計画を立てるための手法を選択する
  • 計画を実行し、進捗状況を監視する
  • リスク状況を継続的に評価し、是正措置を講じます

• SEI リスク管理モデル: 一連の標準的なリスク管理プロセスを定義します。

  • リスクの特定
  • リスク分析
  • リスク計画
  • リスク管理
  • リスク追跡

  リスク管理手法

  • リスク回避
  • リスクの弱体化
  • 露出
  • リスク移転

2.2 ソフトウェア品質管理モデルとテクノロジー

2.2.1 ソフトウェア品質管理モデル

• ソフトウェアの品質を定量的に説明するために使用されるモデルを指します。PDCAに基づく総合統計的品質管理（TSQC）モデルは、我が国で実際に採用されているモデルの一つです

2.2.2 ソフトウェア品質管理モデルパラメータ

• 製品、プロセス、リソース、その他の側面が含まれます。これらのパラメータは、ソフトウェアの品質と信頼性を測定するために使用できます。

2.2.3 ソフトウェア品質管理の実施プロセス

• 開発前フェーズ、開発フェーズ、保守フェーズ

2.2.3 ソフトウェア品質管理技術

• 静的分析、動的テスト、コードレビュー、パフォーマンステスト、セキュリティテスト、その他の方法が含まれます。これらの手法により、ソフトウェアの品質と信頼性を効果的に向上させることができます。

2.3 ソフトウェア品質保証体制

• ソフトウェア品質保証 (SQA) は、提案された標準、手順、実践、および方法がすべてのプロジェクトに正しく採用されていることを管理者が保証するための、計画的かつ体系的なアプローチの確立です。ソフトウェア品質保証の目的は、ソフトウェア プロセスを管理者が見えるようにすることです。

2.3.1 ソフトウェア品質保証の内容

能力成熟度モデル (CMM)

• これは、ソフトウェアプロセスの定義、実装、測定、制御、改善を実践するソフトウェア組織の開発のさまざまな段階を説明したものです。
• 中核：ソフトウェア開発をプロセスとして捉え、この原則に従ってソフトウェア開発と保守に関するプロセスの監視と研究を実施し、ソフトウェア開発をより科学的かつ標準化し、企業がビジネス目標をより良く達成できるようにすること

CMMの基本的な考え方

• ソフトウェア制作プロセスの品質を段階的に管理および改善し、それによってソフトウェア開発組織の成熟度と制作品質を向上させます。

三次元測定機の必要性

• 要件エンジニアリングの観点から見ると、CMM は、システム アナリストが問題を理解したり、製品の外部動作を説明したりするのに役立ち、要件エンジニアリングの効率と品質を向上させることができます。
• ソフトウェアの再利用という点では、CMM は既存のエンジニアリングの知識と手法を使用して、既存のシステムから新しいシステムを構築し、ソフトウェア製品の品質と生産性を向上させることができます。
• 他の側面では、CMM は、ソフトウェア検査、ソフトウェア測定、ソフトウェアの信頼性、ソフトウェアの保守性、ソフトウェア ツールの評価と選択などを通じて、ソフトウェア開発組織が成熟度と生産品質を向上させるのにも役立ちます。

2.3.2 ソフトウェア品質保証 SQA

• SQA（Software Quality Assurance、ソフトウェア品質保証）とは、ソフトウェア開発プロセス中に一連の計画、アクション、および制御を実装することによって、ソフトウェアが期待される要件と品質基準を満たしていることを保証するプロセスを指します。
  • SQAの背景には、ソフトウェア製品の品質問題が多発しており、これらの問題を解決するためにSQAが誕生しました。
  • SQA の目標は、ソフトウェア開発プロセスの品質基準が確実に満たされていることを確認し、それによってソフトウェア製品の品質を向上させ、顧客満足度を高め、開発コストと時間を削減することです。
  • SQA のタスクには、SQA 計画の策定、SQA 活動の実行、SQA 効果の監視、SQA 効果の評価、SQA プロセスの改善が含まれます。
  • ソフトウェア開発のさまざまな段階で SQA を実装する目標は異なります。
    • 要件定義段階における SQA の目的は、要件仕様の正確性、完全性、一貫性をレビューして確認することです。
    • 設計段階における SQA の目標は、ソフトウェア設計が仕様に準拠し、設計の信頼性と保守性を確保することです。
    • コーディングとテストの段階での SQA の目標は、コードの品質が信頼でき、テスト ケースが適切にカバーされ、結果が正しいことを確認することです。
  • 一般的な SQA 活動には、ソフトウェア開発活動の計画、レビュー、監査が含まれます。
    • 計画の面では、SQA は SQA 計画とさまざまな活動の計画を作成する必要があります。
    • レビューに関して、SQA はソフトウェア文書 (要件仕様書、設計文書、テスト ケースなど) をレビューして、その品質と標準への準拠を確認する必要があります。
    • 監査に関しては、SQA はコード監査、テスト監査、構成管理監査を実施して、すべての開発活動の一貫性、管理性、追跡可能性を確保する必要があります。
  • SQAを実践する過程では、SQA組織の設立、SQA方針・計画の策定、SQA研修の実施、SQA指標・測定方法の確立、品質基準・工程基準の設定など、これらの取り組みを通じてさまざまな作業が必要となります。ソフトウェア開発の品質、効率、信頼性を向上させます。

2.4 概要

• ソフトウェア品質管理は、指定された資本投資と時間の制約内で、顧客の品質要件を満たすソフトウェア製品を提供し、開発プロセスと開発組織自体を継続的に改善するために、開発組織が使用する一連の手順と方法です。将来的には高品質のソフトウェア製品を作成します。
• ソフトウェア管理には、一般的に「対象問題計測手法」「リスク管理手法」「PDCA品質管理手法」の3つの手法があります。その中でも、我が国で最もよく使われているモデルは、PDCAに基づく総合サービス品質管理（TSQC）モデルです。
• ソフトウェア品質保証 (SQA) は、提案された標準、手順、実践、および方法がすべてのプロジェクトに正しく適用されていることを管理者が保証するための計画的で体系的なアプローチを確立することです。

第 3 章 ソフトウェアの品質測定と構成管理

3.1 概要

3.1.1 メトリクス

• メトリクスは、エンティティのプロパティを数値で表現するプロセスです。ソフトウェア品質保証では、ソフトウェアの品質とプロセスを評価するために測定が有効な手段です。

3.1.2 ソフトウェアのメトリクス

• ソフトウェア測定は、ソフトウェア製品およびソフトウェアプロセスの特性を定性的および定量的に分析する方法です。

3.1.3 ソフトウェア指標の役割

• ソフトウェアメトリクスを通じて理解が深まります。
• ソフトウェア メトリクスを通じてソフトウェア プロジェクトを管理します。主に計画と見積もり、追跡と確認が行われます。
• 主に理解、評価、パッケージ化などのソフトウェア測定を通じて、ソフトウェア プロセスの改善を導きます。ソフトウェアメトリクスには、実装オブジェクトごとに異なるユーティリティがあります

3.2 ソフトウェア品質指標

3.2.1 ソフトウェア品質とソフトウェア品質要素

• ソフトウェアの品質とは、ユーザーのニーズと期待の両方を満たすソフトウェア製品の能力です。
• ソフトウェアの品質要素には、機能、信頼性、使いやすさ、効率、保守性、移植性が含まれます。

3.2.2 ソフトウェアの品質に影響を与える要因

• 人々
• プロセス
• テクノロジー

3.2.3 品質保証モデル

• マッコールモデル: ソフトウェアの品質は、「ソフトウェアの特性や特徴がユーザーのニーズや期待をどの程度満たしているか」と定義されます。このモデルは、ソフトウェアの品質を正確性、信頼性、効率、保守性、柔軟性、使いやすさなどを含む 11 の側面に分類します。これらの側面はソフトウェアの品質要素とみなされ、ソフトウェアの品質を評価するための重要な指標となります。
• ベーム モデル: ソフトウェアの品質は「あらかじめ決められた目標への準拠度」として定義されます。品質要因に関しては、6カテゴリー75個の品質特性要因を提示し、コストや進捗状況などを組み合わせて総合的に評価する、比較的包括的なソフトウェア品質評価手法です。
• FURPS モデル: ソフトウェア品質は、「使用中にユーザーのニーズを満たすソフトウェア システムの能力」と定義されます。このモデルは、ソフトウェアの品質を機能、使いやすさ、信頼性、パフォーマンス、サポートの 5 つの側面で表しており、開発者がユーザーのニーズをより深く理解し、ユーザーの期待に応えるソフトウェア製品を設計するのに役立ちます。
• ISO9126: ソフトウェア品質を「ソフトウェア製品が関連する規格や手順の指定された特性および要件を満たす程度」と定義しています。このモデルは、ソフトウェアの品質を機能性、信頼性、使いやすさ、効率性、保守性、移植性の6つの特性に分類し、標準化されたソフトウェア品質評価手法です。

3.2.4 欠陥除去効率

• 欠陥除去効率とは、ソフトウェア開発ライフサイクルにおける欠陥の発見と修正にかかるコストと時間を指します。

3.3 ソフトウェアプロセスの測定

3.3.1 ソフトウェアプロセス計測の概念

• ソフトウェアプロセス測定とは、ソフトウェア開発プロセスの各リンクを定量的に分析する方法を指します。

3.3.2 ソフトウェアプロセス測定に関するよくある質問

• 測定が多すぎる、頻繁すぎる
• 測定が小さすぎる、遅すぎる
• 間違った物や属性が測定される
• メジャーの定義が不正確です
• 収集されたが使用されていないデータ
• 指標の間違った解釈
• 自動化ツールの欠如

3.3.3 目標ベースのソフトウェアプロセス測定方法

• GQM モデルは階層構造になっており、最上位層がターゲットであり、問​​題層を構成するターゲットを絞り込むことでいくつかの質問が得られます。これらの質問は、懸念される領域をいくつかの部分に分割します。

目標は主にいくつかの要因によって制御されます

• ISSUES (焦点): 測定対象の品質への焦点。
• VIEWPOINT（立場）：情報の使い手。
• OBJECT: 測定するオブジェクト。
• PURPOSES（目的）：測定対象を一般的に理解し、制御し、改善する

ソフトウェア品質管理にGQMモデルを使用する場合の質問の取得方法とデータ項目の選択方法

1. 特定の目的を表明するオブジェクトについては、定量化可能な特性を捕捉する必要があります。たとえば、ピアレビューの効率を評価する場合、ピアレビューの欠陥検出率やレビュープロセスのコンプライアンスなどの定量化可能な特性に焦点を当てることができます。
2. モデルの強調と組み合わせて、これらの特性を記述し、測定対象のこれらの特性を評価する必要があります。たとえば、査読の効率を評価する場合、査読の効率の偏差や傾向、一人あたりの欠陥発見数の変化などを計算できます。
3. データ項目を選択する際には、既存のデータを可能な限り利用する必要がありますが、データの有効性や安定性も考慮する必要があります。成熟した安定した測定対象物については、客観的な測定をより活用する必要がありますが、未熟で不安定な対象物については、主観的な判断を組み合わせてデータを取得できます。
4. ソフトウェア品質管理に GQM モデルを使用する場合、これは段階的なプロセスであることを認識する必要があり、選択された測定項目は測定対象を評価するだけでなく、モデル自体の信頼性と品質も反映することができます。

3.4 ソフトウェア構成管理

3.4.1 ソフトウェア構成管理の目的

• ソフトウェア構成管理の目標は、ソフトウェア製品の正確性、完全性、およびトレーサビリティを確保することです。

3.4.2 ソフトウェア構成管理の役割の責任

• プロジェクトマネージャー（プロジェクトマネージャー、PM）
• 構成制御ボード (CCB)
• 構成管理責任者 (CMO)
• システムインテグレーションオフィサー (SIO)
• 開発者 (開発者、開発者)

3.4.3 ソフトウェア構成管理プロセスの説明

• プロジェクト計画段階では、CCB はまずプロジェクト開発計画に従って各マイルストーンと開発戦略を決定します。次に、CMO は CCB の計画に従って詳細な構成管理計画を策定し、レビューのために CCB に提出します。レビューに合格した場合、CCB は構成管理計画をプロジェクト マネージャーに提出して承認を求め、実装のためにリリースします。
• プロジェクトの開発および保守フェーズでは、ソフトウェア構成管理作業は主に CMO によって完了します。具体的には、SIO と DEV がソフトウェア構成管理戦略を実行し、CMO がプロセス全体を管理および保守します。この段階では、変更プロセスが重要な役割を果たします。これは、チームが変更要求にタイムリーかつ効率的に対処し、ソフトウェア構成の正確さと一貫性を確保するのに役立ちます。

3.4.4 ソフトウェア構成管理の主なアクティビティ

• ソフトウェア構成管理の主な活動には、構成項目の識別、構成項目の制御、変更制御、バージョン管理、監査が含まれます。

3.4.5 一般的なソフトウェア構成管理ツール

• 最初のレベルはエントリーレベルのツールで、主に Concurrent Version System (CVS) や Visual Source Safe (VSS) などの単純なバージョン管理に使用されます。これらのツールの機能は比較的シンプルで、小規模なプロジェクトや個人的な使用に適しています。
• 2 番目のレベルはプロジェクト レベルの構成管理ツールで、PVCS や MKS などの中小規模のプロジェクトの管理に適しています。これらのツールは、要件管理、欠陥管理、タスク管理などのより複雑な構成管理機能を提供し、共同開発とチームワークをサポートします。
• 3 番目のレベルは、強力なプロセス管理機能を備えたエンタープライズ レベルの構成管理ツールです。たとえば、CCC Harvest と ClearCase は、大規模で複雑なソフトウェア開発プロジェクトを処理し、要件管理、バージョン管理、ビルド管理、テスト管理、リリース管理を含む完全なプロジェクト ライフ サイクル管理を提供できます。

3.5 概要

• 測定により、管理者と開発者はソフトウェア プロセスを改善し、ソフトウェア プロジェクトの計画、追跡、および制御を支援し、結果として得られる製品 (ソフトウェア) の品質を評価できます。
• プロセス メトリックにより、組織はソフトウェア プロセスの有効性について戦略的な洞察を得ることができます。
• ソフトウェア構成管理はソフトウェア開発プロセス全体をカバーするため、ソフトウェア プロセスを改善し、プロセス能力の成熟度を向上させるための理想的なエントリ ポイントです。

第 4 章 ソフトウェアの信頼性の測定とテスト

4.1 ソフトウェアの信頼性

4.1.1 ソフトウェア信頼性開発の歴史

• ソフトウェア信頼性の概念は 1960 年代に初めて登場し、コンピュータ技術の急速な発展とソフトウェアの複雑さの継続的な改善に伴い、ソフトウェア信頼性は徐々に人々の注目を集めるようになり、さまざまなソフトウェア信頼性モデルや手法が次々に提案されてきました。

4.1.2 ソフトウェアの信頼性の定義

• ソフトウェアの信頼性とは、与えられた条件下で、指定された機能を指定された時間内に完了するために必要な度合いを指します。簡単に言うと、ソフトウェアの信頼性とは、ソフトウェアが一定期間内に障害やエラーなく正常に動作する能力のことです。

4.1.3 ソフトウェアの信頼性の基本的な数学的関係

• ソフトウェアは動作を開始してから時間の経過とともに故障確率が徐々に増加し、長期間の運用では故障確率が1になる傾向にありますが、信頼性は徐々に低下して0になる傾向があります。

4.1.4 ソフトウェアの信頼性とハードウェアの信頼性の違い

• ハードウェアには経年劣化や損失という現象がありますが、ソフトウェアには物理的な変化はありません。ハードウェア障害は物理的な障害ですが、ソフトウェア障害は入力データに関連するソフトウェア エラーです。
• ハードウェアの場合、予防保守技術を使用して故障を防止したり、故障したコンポーネントを切断することで故障を診断したりできますが、ソフトウェアではこれらの技術を使用できません。
• 事前の信頼性テストや段階的な信頼性の向上などの手法は、ソフトウェアとハ​​ードウェアに対して異なる影響を及ぼします。
• ハードウェアの信頼性に関しては成熟した製品市場がありますが、ソフトウェア製品市場は比較的新しいです。

4.1.5 ソフトウェアの信頼性に影響を与える要因: ソフトウェアの信頼性に影響を与える要因には次のものがあります。

• 要件分析定義エラー。たとえば、ユーザーが提出した要件が不完全である、ユーザー要件の変更が時間内に消化されていない、ソフトウェア開発者とユーザーが要件について異なる理解を持っている、などです。
• 設計ミス。構造的エラーとアルゴリズム的エラーの処理、特殊なケースとエラー処理の考慮の欠如など。
• エンコードエラー。構文エラー、変数初期化エラーなど。
• テストエラー。データ準備エラー、テストケースエラーなど。
• ドキュメントのエラー。不完全なドキュメント、一貫性のないドキュメント関連コンテンツ、一貫性のないドキュメントのバージョン、完全性の欠如など。

4.1.6 ソフトウェアのエラー、誤動作、障害

• ソフトウェアのバグとはコード内のエラーを指します
• 障害とは、特定のシナリオにおけるソフトウェアの動作上の問題を指します。
• 障害とは、ソフトウェアが望ましい機能を実行できない状態です。

4.2 信頼性モデルとその評価基準

4.2.1 ソフトウェア信頼性モデル

• ソフトウェア信頼性モデルとは、ソフトウェアを分析し、ソフトウェアの運用中に起こり得る故障や不具合を予測することで、ソフトウェアの信頼性を向上させる手法のことを指します。一般的に使用されるソフトウェア信頼性モデルには、ワイブル分布、指数分布などが含まれます。

4.2.2 ソフトウェア信頼性モデルパラメータ

• ソフトウェア信頼性モデルのパラメータには、故障率、故障率、信頼性、故障までの平均時間が含まれます。

4.2.3 ソフトウェア信頼性モデルとその応用

• Musa 基本モデル: ソフトウェア信頼性モデルの古典的なモデルの 1 つで、ソフトウェアの故障/障害の数と故障率を推定するために使用されます。このモデルでは、故障の発生時間間隔がパラメータラムダの指数分布に従うと仮定しており、故障が検出されると、故障部分の修復と再テストが、新たな故障が見つからなくなるまで繰り返されます。このモデルの利点は、理解しやすく、ほとんどのソフトウェア開発プロセスに適していることですが、欠点は、長期的な信頼性の予測が難しいことです。
• Musa対数モデル：基本モデルをさらに発展させたもので、故障発生時間間隔の対数をとった後、ガウス分布に従うと仮定され、故障数と故障率をより正確に推定できます。 、時間に対する故障率の傾向も考慮に入れることができます。ただし、このモデルにはより多くのデータとより複雑なパラメーター推定方法が必要であり、使用するのがより困難です。
• Goel-Okumoto モデル: ポアソン過程とマルコフ連鎖理論に基づいた、ソフトウェアの故障率の変化を説明するために使用される、もう 1 つの一般的に使用されるソフトウェア信頼性モデルです。このモデルでは、故障率が特定の数学的分布形式を満たすと仮定しながら、各故障が独立して発生し、故障発生率も時間とともに変化すると仮定します。このモデルの利点は、故障率の変化傾向を正確に推定できることですが、欠点は、より多くの信頼性データと複雑なパラメータ調整プロセスが必要であることです。

4.2.4 ソフトウェア信頼性モデルの評価基準

• モデルフィット
• モデルの予測の妥当性
• モデルバイアス
• モデルのバイアス傾向
• モデルノイズ

4.3 ソフトウェアの信頼性テストと評価

4.3.1 ソフトウェアの信頼性評価

• ソフトウェア信頼性評価とは、ソフトウェアをテストし、問題点や欠陥を発見し、改善提案を行うことでソフトウェアの信頼性を評価するプロセスを指します。

4.3.2 ソフトウェア信頼性テストの具体的な実施プロセス

• ソフトウェアの信頼性試験には、テスト計画の策定、テスト環境の構築、テストデータの準備、テストケースの設計、テストの実行、テスト結果の分析が含まれます。

4.4 ソフトウェアの信頼性を向上させる方法とテクニック

4.4.1 信頼性を核とした品質基準の確立

• ソフトウェアの信頼性を向上させるには、信頼性を核とした品質基準を確立することが重要です。ソフトウェアの開発プロセスでは、ソフトウェアが安定して動作するために、ソフトウェアの信頼性が最優先されます。

パーティションの開発プロセスごとの品質基準の決定

• 要件分析の品質指標
• 設計結果の品質指標
• テスト結果の品質指標
• 合格結果の品質指標

4.4.2 開発方法の選択

• 適切な開発手法を選択することも、ソフトウェアの信頼性を向上させる重要な要素です。たとえば、アジャイル開発手法を採用すると、開発者はフィードバックや修正をより迅速に行うことができます。

4.4.3 ソフトウェアの再利用

• ソフトウェアの再利用とは、ソフトウェア開発プロセスにおける既存のソフトウェア モジュールまたはコードの再利用を指します。ソフトウェアを再利用することで、コードの記述を削減し、生産効率を向上させ、ソフトウェアの信頼性も向上させることができます。
• ソフトウェアの再利用とは、ソフトウェア自体だけでなく、ソフトウェア開発のアイデア、ドキュメント、さらには環境やデータなども指します。これには、次の 3 つの側面の再利用が含まれます。
  • 開発プロセスの再利用とは、開発仕様書、各種開発手法、ツールや標準などを指します。
  • ソフトウェアコンポーネントの再利用とは、文書、プログラム、データなどを指します。
  • 関連分野の専門知識の再利用など、知識の再利用

4.4.4 開発管理ツールの使用

• 開発管理ツールを使用すると、プロジェクト管理とコード管理が向上し、ソフトウェアの信頼性が向上します。

4.4.5 強化されたテスト

• テストはソフトウェアの信頼性を向上させる鍵となります。単体テスト、統合テスト、システムテスト、その他のリンクを含むソフトウェアテストは、開発プロセス中に強化する必要があります。

4.4.6 フォールトトレラント設計

• フォールトトレラント設計とは、ソフトウェアの設計段階でプログラムに障害が発生した場合の対策を検討することを指します。フォールトトレラント設計により、プログラム障害によるユーザーへの影響を軽減し、ソフトウェアの信頼性を向上させることができます。

4.5 ソフトウェア信頼性研究における主な問題点

• ソフトウェア信頼性研究の主な問題には、モデルの妥当性、パラメータの選択、テスト方法、信頼性評価基準などが含まれます。

4.6 概要

• この章では、ソフトウェア信頼性の定義、開発の歴史、影響要因、信頼性モデルと評価基準、ソフトウェア信頼性試験と評価、ソフトウェア信頼性を向上させる手法と技術など、ソフトウェア信頼性の基本概念を紹介します。ソフトウェアの信頼性の研究と応用を強化することにより、ソフトウェアの品質と信頼性を向上させ、ソフトウェアシステムの安定した動作を保証することができます。
• ソフトウェアの信頼性とは、指定された条件下および指定された期間内にシステム障害を引き起こさないソフトウェアの能力を指します。
• ソフトウェアの信頼性は、ソフトウェアの欠陥だけでなく、システム入力やシステムの使用状況にも関係します。
• ソフトウェアの信頼性は、ソフトウェアの品質特性における重要な固有の特性および重要な要素です。
• ソフトウェアの信頼性はユーザーの品質に対する見方を反映します

第 V 章 ソフトウェアの品質基準

5.1 ソフトウェア品質基準の概要

5.1.1 国際規格

• 各国の参考のために国際機関が定めて公表する規格を国際規格といいます。
• 1960年代初頭、国際標準化機構はコンピュータ関連の標準作業を担当する「コンピュータおよび情報処理技術委員会」を設立した。

5.1.2 国家基準

• 政府または国家機関によって策定または承認され、その国に適用される基準を国家基準といいます。好き
• GB（国彪） 中華人民共和国国家技術監督局は中国の最高位の標準化機関であり、同局が発表・実施する標準を略して「国家標準」と呼びます。
• ANSI (米国規格協会) 米国規格協会。米国の一部の非政府標準化団体の主導的な団体であり、一定の権限を持っています。

5.1.3 業界標準

• 業界標準は、一部の業界団体、学術団体、または防衛機関によって開発され、特定のビジネス分野に適用される標準です。
• 中華人民共和国国家軍事規格 (GJB)。これは我が国の国防科学技術産業委員会によって承認されており、国防省および軍による使用に適した規格です。たとえば、1988 年に発行および実装された軍事ソフトウェア開発仕様 GJB473-88 です。
• 電気電子学会 (IEEE) は、ソフトウェアの標準化活動を行うためにソフトウェア標準技術委員会 (SESS) を設立しました。
• 国防総省標準 (DOD-STD)。米軍規格 (Military-Standards、MIL-S)。
• さらに、私の国のいくつかの省庁（情報産業省など）もソフトウェアの標準化作業を実施し、その部門の業務ニーズに適したいくつかの仕様を策定して発表しました。
• これらの仕様の策定には、国際規格および国内規格が参照されます。これらの標準の確立は、それぞれの業界でソフトウェア エンジニアリングを促進する上で強い役割を果たしてきました。

5.1.4 エンタープライズ仕様

• 一部の大企業や会社では、ソフトウェアエンジニアリング業務の必要性から、この部門に適用できる仕様を策定しています。
• 例えば、米国IBM社の汎用製品部門は1984年に「プログラム設計開発ガイド」を策定した。

5.1.5 プロジェクトの仕様

• 一部の大企業や会社では、ソフトウェアエンジニアリング業務の必要性から、この部門に適用できる仕様を策定しています。
• 例えば、米国IBM社の汎用製品部門は1984年に「プログラム設計開発ガイド」を策定した。

5.2 ソフトウェアにおける ISO9001 および 9000-3 の適用

• ISO 9001 は、品質管理のための一連の特定の要件を提供します。
• 一方、ISO 9000-3 は、ソフトウェア開発プロセスにおける特別な要件に対処します。この 2 つを組み合わせることで、ソフトウェア開発のための完全な品質管理システムを確立できます。

5.3 能力成熟度モデル CMM&CMMI

5.3.1 CMM の品質に関する考え方

• CMMは、ソフトウェア開発プロセスの各段階や活動を5つの能力レベルに分け、段階的に能力レベルを上げていくことでソフトウェア開発プロセスの品質を確保する、ソフトウェア開発プロセスを総合的に管理・改善する手法を提供します。

5.3.2 CMM キーフィールド

• 初期レベル
• 再現可能なグレード
• 定義されたクラス
• 管理された
• 最適化レベル

5.3.3 PSP と TSP

• PSP（Personal Software Process）とは、SEIが提唱する個人向けソフトウェア開発プロセスモデルです。
• TSP（Team Software Process）とは、チーム向けに提案されたソフトウェア開発プロセスモデルです。

5.3.4 CMMI - ソフトウェア機能成熟度統合モデル

• CMMI は CMM の後継であり、ソフトウェア開発プロセスを改善するだけでなく、ソフトウェア開発を企業の戦略目標と組み合わせることに重点を置いています。

5.3.5 CMM の品質フレームワーク

CMM の品質フレームワークには、プロセス改善、プロジェクト管理、サポート プロセス、組織レベルのプロセスなどが含まれます。

5.4 IEEE ソフトウェアエンジニアリング標準

5.4.1 IEEE 730:2001 の構造と内容

ソフトウェアテスト計画にどのような内容を含めるべきか、およびそれらの内容の構成構造を定義します。

• 目的
• 参照文書
• 管理
• 書類
• 基準、慣行、慣例、および指標
• ソフトウェアのレビュー

5.4.2 IEEE/EIA Std 12207 - ソフトウェアライフサイクルプロセス

要件、設計、実装、テスト、保守などの側面を含む、ソフトウェアのライフサイクルの 13 のプロセスを定義します。

• メインプロセス: 5 つのプロセスが含まれます。これらのプロセスは、ソフトウェア製品の開発、運用、保守に参加または完了するときに、主要当事者 (需要側、サプライヤー、開発者、オペレーター、保守者など) によって使用されます。
• 8 つのプロセスが含まれており、それぞれのプロセスには他のプロセスをサポートし、ソフトウェア プロジェクトの成功と優れた製品品質の達成を支援するという明確な目的があります。

5.4.3 IEEE Std 1012 — 検証と検証

ソフトウェアの検証と妥当性確認の活動を定義し、関連する標準とガイドラインを提供します。

• 検証は、システムまたはコンポーネントを評価して、特定のフェーズの製品がそのフェーズの開始時に課された条件を満たしているかどうかを判断するために使用されるプロセスです。
• 検証は、開発プロセス中または開発プロセスの終了時にシステムまたはコンポーネントを評価して、指定された要件を満たしていることを確認するプロセスです。

5.4.4 IEEE Std 1028 - レビュー

ソフトウェアレビューの活動を定義し、関連する標準とガイドラインを提供します。

5.5 その他の品質基準

5.5.1 ISO/IEC 15504-2:2003 ソフトウェアプロセス評価基準

これは、企業がソフトウェア開発プロセスの効率と品質を評価するのに役立つプロセスベースの評価モデルです。

5.5.2 ITにチェックを入れる

これは、欧州コンピュータ アプリケーション技術研究所 (ECAT) によって開発された中小企業向けの一連のソフトウェア品質認証標準です。

5.6 概要

• 一般標準の概念とレベルから始まり、ソフトウェア品質標準の導入に焦点を当て、ソフトウェア業界標準の構造と内容を全体として理解します。
  • CMM はソフトウェア プロセス改善のフレームワークを提供し、ソフトウェア改善プロセス全体を 5 つの成熟度レベルに分割し、組織のソフトウェア プロセスの成熟度を測定し、ソフトウェア プロセス能力を評価するための秩序ある尺度を定義します。
  • 各レベルでは、そのレベルのプロセス管理を達成するために取り組むべき主要な問題と主要領域が定義されます。
• CMM の成功は、組織内の関係者の積極的な参加と創造的な活動から切り離せませんが、CMM はサブプロセス実現領域に必要な特定の知識やスキルを提供しません。
  • そこで、個別ソフトウェアプロセスとグループソフトウェアプロセスが誕生しました。

第 6 章 ソフトウェアのレビュー

6.1 ソフトウェアレビューが必要な理由

• ソフトウェアレビューは、ソフトウェア開発プロセスと製品の品質を保証するための重要な方法です。レビューを通じて、潜在的な問題を発見して修正することができ、ソフトウェアの品質を向上させ、リスクとコストを削減することができます。同時に、レビューによってチームのコラボレーションとコミュニケーションが促進され、チームメンバーが要件と標準を理解できるようになり、開発効率と顧客満足度が向上します。
• プロジェクトの生産性を向上させます。これはバグの早期発見によるもので、再作業時間と場合によってはテスト時間も削減されます。
• レビューに合格すると、ソフトウェア開発の段階が完了したことになります。
• メンテナンスが容易なソフトウェアを作成します。主な理由は、レビュー担当者はレビュー対象のソフトウェアに精通している必要があること、同時にレビュー プロセス中に多くの証明ドキュメントが生成され使用されるため、レビューによって開発者は多くの有用なドキュメントを作成する必要があること、

6.2 ソフトウェアレビューの役割と機能

• ソフトウェアのレビューは通常、ソフトウェア製品およびプロセスの問題を特定して修正することを主な任務とする専門のレビュー チームまたは専門家によって実施されます。レビュー担当者は、関連する技術的な知識と経験を持ち、ソフトウェア製品の開発担当者や保守担当者から独立している必要があります。
• モデレータ
• 読者
• レコーダー
• 著者
• 査読者（査読者、査察官）
• レビューの内容をよく理解し、レビューの準備をしてください。
• 検討会議は個人的なものではなく、問題に焦点を当てたものである必要があります。
• 重大な問題と軽微な問題は個別に議論できます。
• 会議の前後に、既存の問題について建設的な意見や提案を提出することができます。
• 自分の役割と責任を明確にします。
• 間違いを受け入れる準備をしておく

6.3 レビュー内容

• レビューには通常、マネジメントレビュー、技術レビュー、文書レビュー、プロセスレビューの 4 つの側面が含まれます。

6.3.1 マネジメントレビュー

• マネジメントレビューは主に、ソフトウェアプロジェクトの計画、スケジュール、財務などの側面をレビューして、プロジェクトが予定通りに完了し、期待される品質と効果が達成できることを確認することです。
• 入力
  • 最近の内部および外部監査の結果。
  • 顧客情報のフィードバック。
  • 利害関係者にとって懸念される問題。
  • 仕事のパフォーマンスと既存の問題。
  • 是正措置および予防措置の実施。
  • 前回の経営レビューでの関連決定と措置の実施。
  • 経営体制の変更に影響を与える可能性のある事情（法令の変更、組織構造や製品、活動の変更、外部環境の変化等）
  • 経営方針、目的・目標の適切性とその達成状況
• 出力
  • マネジメントレビューの目的、時期、参加者および内容
  • 管理システムとプロセスの適用性、適切性、有効性と必要な改善の包括的な評価。
  • 経営方針、目標、指標の適切性の評価および必要な変更。
  • リソース要件の決定とアクション。
  • マネジメントレビューにより改善策を決定、担当部署と完了日

6.3.2 技術レビュー

• 技術レビューは主に、ソフトウェア製品が標準と仕様に準拠し、良好な保守性と拡張性を備えていることを確認するために、ソフトウェア製品の設計、コード、テスト、実装の技術的側面をレビューすることです。
• 技術レビューの主な目的は、機能、ロジック、および実装におけるソフトウェアのエラーを発見し、ソフトウェアが要件仕様を満たしていることを確認し、ソフトウェアが事前に定義された開発仕様および標準を満たしていることを検証し、ソフトウェアが適切であることを確認することです。統合モードで開発され、プロジェクト管理が容易になります。
• 技術レビューの入力: レビューの目的、レビューの内容、レビューのチェックリスト、その他の必要な文書が含まれます。レビューの内容には通常、要件文書、ソースコード、テストケースなどが含まれます。
• 技術レビューの出力: 技術レビュー レポート。これには、会議の基本情報、既存の問題と提案された対策、レビューの結論と意見、問題追跡表、および技術レビューの質問と回答の記録が含まれます (レポートには付録）。技術レビューレポートを通じて、開発チームはソフトウェアに存在する問題点と改善の方向性をより深く理解し、ソフトウェアの品質と効率を向上させることができます。

6.3.3 文書のレビュー

• ドキュメントレビューは主に、さまざまなソフトウェアドキュメント（要件、設計、テスト計画など）をレビューして、ドキュメントの完全性、正確性、一貫性、理解しやすさを確認することです。

• ドキュメントレビューの主な目的は、ソフトウェア開発プロセス中に作成されたドキュメントが標準と仕様に準拠していることを確認し、ドキュメントの内容が正確、完全、一貫しているかどうかを確認し、起こり得るエラーや抜け穴を回避して、ソフトウェア開発プロセスを検出することです。問題を早期に修正し、ソフトウェアの品質と効率を向上させます。

• ソフトウェア開発プロセスでは、主に要件レビュー、設計レビュー、コードレビュー、品質検証レビューなど、レビューが必要なドキュメントが多数あります。

6.3.4 プロセスのレビュー

• プロセスレビューは主にソフトウェア開発プロセス全体をレビューし、プロセスのすべての段階が標準と規範に従っていることを確認し、ソフトウェアの品質と効率を確保します。
• プロセスレビューの主な役割には、主要な品質保証プロセスの評価、レビュープロセスで見つかった不適合問題への対処方法の検討、良い経験の要約と共有、さらに改善する必要がある部分の指摘が含まれます。そして改善されました。プロセスレビューは、チームがワークフローをより深く理解し、問題を特定して解決し、全体的な開発効率と品質を向上させるのに役立ちます。

6.4 方法とテクニックをレビューする

6.4.1 評価方法

• レビュー方法には、実現可能性調査、コードウォークスルー、コードレビュー、テストレビューなどが含まれます。その中でもコードレビューはよく使われるレビュー手法であり、静的解析ツールや手動検査によって潜在的な問題を発見することができます。
• 特別検査（臨時審査）
• パスアラウンド
• ウォークスルー
• グループレビュー
• 検査（検査）

6.4.2 レビューのための手法

• レビューされたテクニックには、会議スキル、アプリケーションケース、テストテクニックが含まれます。会議スキルはレビュー担当者がコミュニケーションと意思決定のスキルを向上させるのに役立ち、ケースを使用するとレビュー担当者が要件と基準をより深く理解できるようになり、テスト スキルはレビュー担当者が潜在的な問題を発見するのに役立ちます。
• 欠陥チェックリスト
• ルールセット
• レビューツールの使用
  • ゲリット
  • 木星
  • ソースモニター
• さまざまな角度から製品を理解する
• シーン解析技術

6.5 会議プロセスの確認

• 検討会議のプロセスには、検討会議の準備、検討会議の開催、検討結果の追跡と分析の 3 つのステップが含まれます。検討会議の準備段階では、検討対象、検討基準、検討計画を決める必要があります。検討会を開催する段階では、あらかじめ定められた計画に沿って検討を実施し、検討結果を記録する必要があります。レビュー結果を追跡・分析する段階では、レビュー結果を分類・分析し、それに対応した改善計画を策定する必要があります。

6.5.1 検討会議の準備

検討会のタイミング

• プロジェクトの進行状況やレビュー資料の複雑さなどの要因に基づいて、合理的な手配を行う必要があります。一般的にレビュー会議は、プロジェクト開発の中期または後期に開催され、レビュー資料の完成度や使いやすさを一定程度確保します。同時に、レビュー会議のタイミングは、レビューメンバーの通常の作業の進捗に影響を与えないよう、時間の配置やレビューメンバーの作業量も考慮する必要があります。レビューチームリーダーは、レビュー会議の開催時期を決定する際、事前にレビュー会議メンバーに通知し、レビュー活動が円滑に進むようレビュー会議とプロジェクトの進捗との関係を調整する必要があります。

どの復習教材を選ぶべきか

• 材料の重要性や複雑さなどの要素に応じてスクリーニングし、最も重要、危険、困難な部品を選択してレビューする必要があります。レビュー資料には通常、成果物と文書、予備文書、レビュー担当者が必要とするフォームとツール、およびテスト文書が含まれます。

レビュー資料の梱包と配布

• レビューが必要なすべての部品が含まれていることを確認し、レビュー担当者が欠陥を見つけるのに役立つツールとドキュメントを提供する必要があります。

レビュー活動のプロセスを合理的に調整する

• レビューチームのリーダーは、同じ人が 1 日に複数のレビュー会議に参加することを避けるために、十分な準備時間を確保し、活動スケジュールを策定し、会議室を手配し、レビュー会議メンバーに事前に通知し、メンバー間の関係を合理的に調整する必要があります。プロジェクトの進捗とレビューミーティング。

6.5.2 検討会の開催

• レビューの準備やレビューの決定などのステップが必要です。
• レビューの準備には、レビューの開始、メンバーの紹介、プレゼンテーションや説明を行う査読者、不明瞭な点や疑わしい点について著者とコミュニケーションをとる査読者、会議中に議事録を作成するメモ作成者が含まれます。
• 審査決定段階では、審査結果を審査会議のメンバーで議論し決定します。
• レビュー会議の最後には、レビュー結果を要約し、次の作業計画を決定する必要があります。
• レビューのプロセスでは、客観性と公平性、誠実さ、品質の重視、安全性への配慮、事実からの真実の追求など、いくつかの原則を把握する必要があります。

6.5.3 レビュー結果の追跡と分析

• 追跡
  • 条件付きで受け入れられた欠陥追跡
  • 許容できない欠陥の追跡
• 分析する
  • 効果
  • 効率とコスト

6.6 概要

• ソフトウェア レビューは、マネジメント レビュー、技術レビュー、ドキュメント レビュー、プロセス レビューなど、ソフトウェアの品質と効率を確保するための重要な手段です。レビューの方法や手法は非常に多様であり、ソフトウェア開発の品質と効率を効果的に向上させるためには、レビュー会議のプロセスも厳密に実施する必要があります。
• 人間の認識は客観的な現実と 100% 一致することはできないため、ソフトウェアのライフサイクルの各段階で人為的な欠陥が発生する可能性があります。
  • ある段階で発生した欠陥は、時間内に修正されないと、後続の開発段階に広がり、その後の段階でさらに多くの欠陥が発生することになります。
• 製品のテストに提出されたバグの数が多いほど、テストに同じ時間を費やした後でも、より多くのバグが製品に潜んでいます。
• 欠陥の発見作業を進め、開発期間の各段階で厳格なソフトウェアレビューを実施し、欠陥が次の段階に波及するのを防ぐ必要があります。

コードレビュー

コードレビューの主な仕事

• コード内のバグを見つけてコードの品質を検査し、修正を提案します。具体的には、Java開発仕様やコードレビューチェックリストに準拠しているかどうかを確認する必要があります。

コードレビュープロセス

• 重要性、活性化レベル、チェック項目など、さまざまな側面が含まれます。その中でも重要度、活性化レベル、チェック項目がポイントとなります。一般的な検査項目には、命名規則、コードのコメント、宣言、空白、インデント、文の形式、関数の分散、規模、信頼性、保守性などが含まれます。

Java コードレビューでよくある間違い

• よくある間違いには、文字列を複数回コピーする、返されたオブジェクトのクローンを作成しない、自分で作成したコードで配列をコピーする、新しい操作の結果が null であることを確認しない、catch ブロックでクリーンアップしない、不要な catch ブロックを追加するなどがあります。

第7章 ソフトウェア総合品質管理

7.1 総合品質管理の概要

7.1.1 品質管理理論の発展段階

品質管理理論は、簡易統計法、管理図法、抜き取り検査法、品質保証法、総合品質管理法などの発展段階を経てきました。

7.1.2 関連問題に関する議論:

総合品質管理において解決すべき問題には、品質概念の定義、品質管理目標の決定、品質管理手法の選択、品質管理組織の確立などが含まれます。

7.1.3 総合品質管理と ISO9000 の比較:

ISO9000は、品質マネジメントシステムの標準化とシステム文書の管理に重点を置いた国際規格です。総合品質管理では、品質管理の包括性と継続的改善にさらに重点を置いています。

7.1.4 総合的な品質管理と統計技術:

総合的な品質管理は、管理図、抜き取り検査、SPC手法などの統計手法と密接に関係しています。

7.2 6σ プロジェクト管理:

7.2.1 6σ 管理手法の簡単な紹介:

6σ管理手法とは、データに基づいた継続的改善を重視した管理手法であり、工程の不良率を100万回当たり3.4回以下に低減することを目的としています。

7.2.2 6σ管理方法とゼロ欠陥：

6σ管理手法の目標は不良率を最小化することであり、不良品をゼロにすることを意味するものではありません。

7.2.3 6σ管理の特徴:

6 σ マネジメントは、データに基づいてプロセス改善に重点を置き、変化とリーダーシップのサポートを重視するという特徴があります。

7.2.4 6σ管理の利点:

6σ経営は、製品やサービスの品質向上、コスト削減、顧客満足度の向上、企業競争力の向上に効果的です。

7.2.5 DPMO と 6σ の関係:

DPMO は 100 万回の機会あたりの欠陥数であり、目標値 6σ に相当します。

7.2.6 6σ経営の人員組織体制：

6σ管理には、6σ軍団、6σブラックベルト、6σグリーンベルトなどのさまざまなレベルの人員を含む6σ専門チームの設立が必要です。

7.2.7 6σ と他の管理ツールの比較:

6σはTQMやISO9000などの管理ツールとは異なり、主に経営目標、手法、実施方法に反映されます。

7.3 品質機能の展開設計:

7.3.1 品質機能展開の概念:

品質機能展開とは、まずユーザーのニーズを特定し、それに基づいて製品やサービスを設計する方法です。

7.3.2 品質関数拡張の分解モデル:

品質機能展開では、住宅構造の分解モデルを用いてユーザーニーズを多層に展開し、機能設計を行います。

7.3.3 高品質の家の構成:

品質の高い家は、要求壁、機能壁、特徴壁、そして構造全体を支える基礎壁から構成されます。

7.3.4 品質機能展開の特徴:

品質機能の導入には、包括性、体系化、顧客志向、継続的改善という特徴があります。

7.4 DFSS プロセスと主要な設計ツール:

7.4.1 DMAIC と DFSS の概要:

DMAIC は 6σ プロセス改善手法の略で、DFSS は Design for Six Sigma の略で、設計段階での欠陥の防止を重視しています。

7.4.2 DFSS プロセスと主要な設計ツール:

DFSS には DMADV と IDOV の 2 つのプロセスが含まれており、主な設計ツールには品質機能の展開、QFD、TRIZ などが含まれます。

7.4.3 DFSS と DMAIC の違い:

DFSS は製品やサービスの設計段階で欠陥が回避されていることを強調しますが、DMAIC は既存の問題に直面して改善することを目的としています。

7.4.4 DFSS の重要性と意味:

DFSSは設計段階で顧客のニーズを考慮し、発生源からの不良率を管理する効果的な品質管理手法です。

7.4.5 DFSS 統合フレームワーク:

DFSS では、目標を確実に実現するための統合フレームワークを形成するために、さまざまな部門や役職間の緊密な協力が必要です。

7.4.6 6σ の実装において注意すべき問題点:

6σを導入するには、従業員の教育、データの正確性の確保、効果的な人事評価制度の確立が必要です。

7.4.7 DFSS の開発の方向性

DFSS はさらに拡張され、自動化、インテリジェンス、デジタル化などの側面に適用されます。

7.5 要約:

本章では、総合品質管理、6σプロジェクト管理、品質機能展開設計、DFSSプロセスの概念、特徴、利点、他の管理ツールとの比較と主な設計ツールを紹介します。これらの方法とツールは、組織が品質レベルを向上させ、ユーザーの満足度を向上させ、ビジネス目標を達成するのに役立ちます。

• 総合的品質管理とは、社会全体の原動力のもと、企業内の全部門、全組織、全従業員が製品品質を核とし、専門技術、管理技術、数理統計技術を統合し、科学的、厳格かつ効率的な品質保証システムは、生産プロセスにおける品質に影響を与える要因を管理し、ユーザーのニーズを満たす製品のすべての活動を高品質の作業と最も経済的な方法で提供します。
• これに基づいて、6σ管理とゼロ欠陥を紹介し、6σ設計プロセスと主要な設計ツールを紹介します。6σ管理手法は統計的評価手法であり、その核心は欠陥ゼロ生産の追求、製造物責任リスクの防止、コストの削減、生産性と市場シェアの向上、顧客満足度とロイヤルティの向上です。
• 6σ経営では、製品やサービスの品質だけでなく、プロセスの改善にも重点を置きます。p
• 同時に、6σ管理とBRPおよび総合品質管理を比較します。続いて、DMAIC管理、DFSS管理、QFDの概念、分解モデル、品質の家などが紹介されます。

第 9 章 ソフトウェアのテスト

9.1 ソフトウェアテストの目的と原則:

9.1.1 ソフトウェアテストの目的

ソフトウェア テストとは、プログラム内のエラー、欠陥、問題を見つけて修正するために、プログラムを実行またはリリースする前に体系的に検査および分析することを指します。ソフトウェアテストの主な目的には、プログラムのエラーの発見と修正、ソフトウェアの品質と信頼性の向上、開発コストと保守コストの削減、ユーザー満足度の向上、セキュリティと安定性の確保が含まれます。

9.1.2 ソフトウェアテストの原則

ソフトウェア テストの原則には次のものが含まれます。

• テストは要件から開始し、すべての機能とシナリオを完全にカバーする必要があります。
• テストは、最終段階だけでなく、製品ライフサイクル中に常に実行する必要があります。
• テストはできるだけ早い段階で行う必要があり、単体テストは開発プロセスの早い段階で行う必要があります。
• 効率を高め、人的エラーを減らすために、テストは完全に自動化される必要があります。
• テストでは、ユーザーのプライバシーとデータを保護するために、セキュリティと安定性に重点を置く必要があります。
• テストは、テスト結果の評価とテスト戦略を改善するためのフィードバックを伴う、継続的な改善プロセスである必要があります。

9.2 ソフトウェアテストの種類:

ソフトウェア テストの種類は、主に次のようなさまざまな分類基準に従って分類できます。

• テスト目的に応じて：機能テスト、パフォーマンステスト、セキュリティテスト、互換性テストなど。
• テスト方法によると: ブラック ボックス テスト、ホワイト ボックス テスト、グレー ボックス テストなど。
• テストフェーズに応じて：単体テスト、統合テスト、システムテスト、受け入れテスト、回帰テストなど。
• テスト方法に応じて: 手動テスト、自動テストなど。

9.3 ソフトウェアテストプロセスの概要:

9.3.1 単体テスト

単体テストとは、単一のプログラム モジュールまたは機能をテストして、その正確性と信頼性を確認することを指します。通常、開発者はコードを記述するときに、ソース コードに基づいてテストするホワイト ボックス テストのアプローチを使用して実行します。

9.3.2 統合テスト

結合テストとは、複数のユニットを組み合わせて、各ユニット間のインターフェースや相互作用が正常であるか、設計要件や仕様を満たしているかを検証するテストを指します。

9.3.3 システムテスト

システムテストとは、ソフトウェアシステム全体をテストし、システムの機能や性能がユーザーのニーズを満たしていることを確認するとともに、システムの安全性、使いやすさ、保守性などをテストすることを指します。

9.3.4 受け入れテスト

受け入れテストは、ソフトウェア システムがユーザーの要件を満たし、確実に動作できるかどうかを判断する、所定の環境で実行されるソフトウェア システムのテストです。

9.3.5 回帰テスト

回帰テストとは、ソフトウェア システムの機能またはモジュールが変更された場合、元のシステム機能が影響を受けているかどうかを確認するために、関連するテスト ケースを再実行する必要があることを意味します。

9.4 ソフトウェアテストとソフトウェア開発の関係:

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

ソフトウェア テストはソフトウェア開発と密接に関係しており、ソフトウェア開発ライフ サイクル全体を通じて実行されます。提供されたソフトウェアがユーザーのニーズを満たし、高い品質と信頼性を備えていることを確認するには、ソフトウェア開発のさまざまな段階で対応するテストが必要です。

9.4.2 ライフサイクルテストと V モデル

ライフサイクルテストとは、ソフトウェア開発のライフサイクル全体で実施されるテストのことで、主に単体テスト、結合テスト、システムテスト、受け入れテストが含まれます。V モデルは、ソフトウェアのテスト プロセスとソフトウェア開発プロセスを組み合わせ、ソフトウェア開発プロセスを開発フェーズとテスト フェーズに分割し、各テスト フェーズを対応する開発フェーズと対応付ける手法です。

9.4.3 ソフトウェアテストの現在のステータス:

コンピュータ技術の急速な発展に伴い、ソフトウェアテストの分野は常に革新と進歩を続けており、多くの課題にも直面しています。テストのコストと効率の問題をどう克服するか、テストカバレッジと品質レベルをどう向上させるかは、現在のテスト分野において解決しなければならない難しい問題です。

9.5 テストツールの選択:

9.5.1 ホワイトボックステストツール

ホワイトボックス テスト ツールは、ソース コードに基づくテスト ツールで、主に単体テストと統合テストに使用され、開発者がテスト プロセス中に欠陥を迅速に特定して修復するのに役立ちます。一般的なホワイトボックス テスト ツールには、Junit、NUnit、PHPUnit などが含まれます。

9.5.2 ブラックボックステストツール

ブラックボックステストツールは機能指向のテストツールで、主にシステムテストと受け入れテストに使用され、ソフトウェアシステムがユーザーの要件を満たしているかどうかを検証できます。一般的なブラックボックス テスト ツールには、Selenium、Appium、JMeter などが含まれます。

9.5.3 テスト設計および開発ツール

テスト設計および開発ツールは、主にテスト スクリプトとテスト ケースを作成し、自動テストを実装するために使用されます。一般的なテスト設計および開発ツールには、TestLink、TestRail、Xray などが含まれます。

9.5.4 テスト実行および評価ツール

テスト実行および評価ツールは、主にテスト ケースを実行し、テスト結果を評価するために使用されます。これには、テスト管理ツール、テスト レポート ツールなどが含まれます。一般的なテスト実行および評価ツールには、TestNG、JUnitReport、ExtentReports などが含まれます。

9.5.5 テスト管理ツール

テスト管理ツールは主に、テスト計画、テストの進行状況、テスト リソースの管理に使用されます。一般的なテスト管理ツールには、Jira、TestLink、TestRail などが含まれます。

9.5.6 機能とコスト

テスト ツールを選択するときは、ツールの機能とコストを考慮する必要があります。さまざまなタイプのテストやテストのニーズに適したツールが異なるため、実際のニーズと予算に応じて選択する必要があります。

9.6 要約:

この章では、主にソフトウェア テストに関連する概念、分類、原則、プロセス、およびソフトウェア開発との関係を紹介し、テスト ツールの選択とテストの現状についても説明します。ソフトウェア開発過程において、ソフトウェアテストはソフトウェアの品質と信頼性を確保するための重要な手段であり、実際の状況やニーズに合わせて効果的なテスト計画と実施を行う必要があります。

人々がソフトウェアの品質にますます注目するようになっているため、ソフトウェア開発においてソフトウェア テストの役割はますます重要になっています。

ソフトウェアテストは現在、ソフトウェアが期待された機能を実行できるかどうかを検証する唯一の効果的な方法です。

第 10 章 ブラックボックステスト

10.1 同値クラスの分割:

10.1.1 同値クラスの分割

等価クラスは、同じテスト結果または同じ応答を持つすべてのデータのグループです。同値クラス分割は、入力データを複数の同値クラスに分割するプロセスです。

10.1.2 同値クラスの分割方法

同値クラスの分割方法には主に以下のようなものがあります。

• 特殊値法: 同値クラスの代表値として特殊な値を選択します。
• 範囲法: 入力値の範囲に従って分割します。
• 組み合わせ: 2 つ以上の入力値を組み合わせて同値クラスを形成します。

10.1.3 テストケースの設計

テスト ケースを設計するときは、各等価クラスをカバーする必要があり、システム全体をカバーするためにできるだけ少数のテスト ケースを選択する必要があります。例外とエラー処理も考慮する必要があります。

10.2 境界値分析

10.2.1 境界条件

境界条件とは、入力データの最大値と最小値を指します。

10.2.2 二次境界条件

サブ境界条件は、最大値と最小値の間の値です。

10.2.3 その他のいくつかの境界条件

その他の境界条件には、無効なデータ、空の文字列、不正な文字などが含まれます。

10.2.4 境界値の選択方法

境界値を選択するときは、基本的な境界値と同等の値を選択する必要がありますが、特殊な状況や異常な状況を考慮する必要があります。

10.3 ボックステスト

ボックステストとは、境界値と同値クラス分割を組み合わせたテスト手法で、プログラムの欠陥や問題点を効果的に発見することができます。

10.4 因果関係図

10.4.1 因果関係図の設計方法

因果関係図は、入力と出力の関係を矢印で表現したグラフです。特性要因図の設計方法には次の手順が含まれます。

• テストする必要がある関数を定義します。
• すべての入力と出力を特定します。
• 入力と出力間の論理関係を確立します。
• 因果関係図を描きます。

10.4.2 因果関係図のテストケース

因果関係グラフに従ってテスト ケースを生成する場合、すべての入力条件をカバーする必要があり、システム全体をカバーするためにできるだけ少数のテスト ケースを選択する必要があります。テスト ケースでは、入力のすべての組み合わせだけでなく、例外的なケースやエラー処理も考慮する必要があります。

10.5 ファンクションダイアグラム法

10.5.1 機能図の設計方法

機能図は、システムまたはモジュールのすべての機能をブロック図で示すグラフィック表現方法です。各ボックスは機能を表し、各矢印はデータ フローと制御フローを表します。関数図の設計方法には次の手順が含まれます。

• テストする必要がある関数を定義します。
• すべての入力と出力を特定します。
• 機能マップを描きます。

10.5.2 関数図によるテストケースの生成

機能図に従ってテスト ケースを生成する場合、すべての入出力条件をカバーする必要があり、システム全体をカバーするためにできるだけ少数のテスト ケースを選択する必要があります。テスト ケースでは、入力のすべての組み合わせだけでなく、例外的なケースやエラー処理も考慮する必要があります。

10.6 比較と選択

ソフトウェアシステムの種類やテスト要件によって適したテスト方法が異なるため、実際の状況や予算に応じて選択する必要があります。テストプロセスでは、テストカバレッジとテストの品質を確保するために、複数のテスト方法を包括的に使用する必要があります。

10.7 ブラックボックステストツールの概要

10.7.1 WinRunner の概要

WinRunner は、主にデスクトップ アプリケーションや Web アプリケーションのテストに使用される GUI ベースの自動テスト ツールです。VBScript や JavaScript など、複数のスクリプト言語をサポートしています。

10.7.2 LoadRunnerの使用

LoadRunner は Web アプリケーション用の負荷テスト ツールで、Web アプリケーションにアクセスするときに実際のユーザーによって生成される負荷をシミュレートして、システムのパフォーマンスとスケーラビリティを検証できます。

10.7.3 QuickTest Pro の使用

QuickTest Pro は、主にデスクトップ アプリケーションと Web アプリケーションのテストに使用される GUI ベースの自動テスト ツールです。VBScript や JavaScript など、複数のスクリプト言語をサポートしています。

10.8 概要

この章では主に、同値クラス分割、境界値分析、因果関係図、関数図、およびブラックボックス テスト ツールの関連する概念、原理、および応用を紹介します。ソフトウェアテストのプロセスでは、テスト効率やテスト品質を向上させるために、実情やニーズに応じて適切なテスト手法やツールを選択する必要があります。

第 11 章 ホワイトボックステスト

11.1 ホワイトボックステストの概要:

ホワイトボックステストは、コードの内部構造に基づいたテスト方法です。つまり、テスターがソースコードに直接アクセスして、コードロジックやプログラムフローなどのテストを実行できます。

11.2 制御フローのテスト:

制御フローテストはホワイトボックステストの手法で、主にステートメントカバレッジ、判定カバレッジ、条件カバレッジ、判定条件カバレッジテスト、パスカバレッジ、ループテストなどがあります。

11.2.1 ステートメントの対象範囲:

ステートメント カバレッジとは、各ステートメントの実行中にエラーが発生しないように、各ステートメントを少なくとも 1 回実行することを指します。

11.2.2 決定範囲:

判定カバレッジとは、各判定ステートメントが少なくとも 1 回実行され、各判定ステートメントの結果が true と false であることがカバーされることを意味します。

11.2.3 条件範囲:

条件カバレッジとは、各条件ステートメントの各条件が少なくとも 1 回実行され、条件の true と false の両方の結果がカバーされることを意味します。

11.2.4 決定条件カバレッジテスト:

決定条件カバレッジ テストとは、各決定と条件の結果がカバーされていることを確認するために、各決定と条件の間の関係が少なくとも 1 回実行されることを意味します。

11.2.5 パスの適用範囲:

パス カバレッジとは、考えられるすべてのエラーが確実にカバーされるように、プログラムの考えられるすべての実行パスをカバーすることを指します。

11.2.6 いくつかの一般的なロジック カバレッジの比較:

ステートメント カバレッジ < 判定カバレッジ < 条件カバレッジ < 判定条件カバレッジ テスト < パス カバレッジ

11.2.7 ループテスト:

ループ テストとは、ループの開始条件、終了条件、ループ本体、ループ時間などのループ構造を含むコードをテストすることを指します。

11.3 基本的なパステスト:

基本パス テストは、プログラム内のすべての実行可能なパスをテストすることでソフトウェアの品質を向上させるホワイト ボックス テストの方法です。

11.3.1 プログラムの制御フロー グラフ:

プログラムの制御フロー グラフは、プログラム構造を記述する有向グラフを指します。ノードはステートメントまたは基本ブロックを表し、エッジはプログラム内の制御転送を表します。

11.3.2 プログラム構造の要件:

プログラム構造の要件には、制御フローグラフで表現できる線形構造、分岐構造、ループ構造などが含まれます。

11.3.3 分析例:

プログラムの制御フロー グラフを分析することにより、プログラム内のすべての可能なパスを見つけてテストし、プログラムの正確性を確認できます。

11.4 プログラムのインストルメンテーション/プログラムの変更テスト:

プログラム インストルメンテーション/プログラム突然変異テストは、プログラムのソース コードを変更してエラーを生成し、ソフトウェア プログラムのエラー耐性を検出するテスト方法です。

11.5 ホワイトボックステストツール:

一般的に使用されるホワイトボックス テスト ツールには、C++Test や JUnit などがあり、テスターがコード カバレッジ分析、パス分析、その他の操作を実行するのに役立ちます。

11.6 ソフトウェアの欠陥分析:

ソフトウェア欠陥分析とは、ソフトウェア内で見つかった欠陥を分析および処理するプロセスを指します。これには、欠陥のカテゴリ、レベル、原因、コンポーネントの分析が含まれます。

11.6.1 はじめに:

ソフトウェアのバグとは、ソフトウェアの開発および使用中に発見されるエラーまたは問題です。

11.6.2 ソフトウェアの欠陥の種類:

ソフトウェア欠陥のカテゴリには、論理欠陥、インターフェイス欠陥、パフォーマンス欠陥、セキュリティ欠陥などが含まれます。

11.6.3 ソフトウェアの欠陥の分類:

ソフトウェアの欠陥のレベルには、致命的レベル、重大レベル、一般レベル、即時レベルなどが含まれます。

11.6.4 ソフトウェアの欠陥の原因:

ソフトウェアの欠陥の原因には、不明瞭な要件、設計エラー、コーディングの問題、不十分なテストなどが含まれます。

11.6.5 ソフトウェア欠陥の構成:

ソフトウェア欠陥の構成には、欠陥の詳細、欠陥追跡、および欠陥レポートが含まれます。

11.7 要約:

この章では、制御フロー テスト、基本パス テスト、プログラム インストルメンテーション/プログラム変更テストなどを含む、ホワイト ボックス テストの概念、方法、テクニックを紹介します。同時に、ホワイト ボックス テスト ツールとソフトウェアの欠陥分析に関する関連知識も紹介します。

• この章では、ホワイト ボックス テストの基本概念、分類、ホワイト ボックス テストにおける境界値技術、ステートメント カバレッジ テスト、分岐カバレッジ テスト、条件カバレッジ テスト、分岐条件カバレッジ テストなど、ホワイト ボックス テストの基本的な概念と手法を主に説明します。 , 条件組み合わせカバレッジテスト、パスカバレッジテスト。
• また、一般的に使用されるホワイト ボックス テスト ツール C++Test ソフトウェアと、ソフトウェアの欠陥の理由、コンポーネント、および危険性についても紹介します。 ホワイトボックステストは「箱」の内部を観察できるが、ブラックボックステストとは異なり、内部構造を理解することなくシステムを「見えない箱」として理解する。
• ソフトウェアを完全にテストするには、両方のテストが不可欠です。
• 製品は多くの場合、最終的にユーザーに提供されるまでのコンセプト分析段階で、さまざまな静的、動的、ホワイトボックス、ブラックボックスのテストを受けます。

第 12 章 欠陥パターンに基づくソフトウェアテスト

12.1 概要:

12.1.1 関連定義:

ソフトウェアの欠陥とは、ソフトウェアの開発プロセス中またはソフトウェアの使用中に発生し、その結果、ソフトウェアが適切に動作しなくなる、または期待どおりに動作しない問題を指します。

12.1.2 ソフトウェアの欠陥の原因:

ソフトウェアの欠陥の原因には主に、不明瞭な要件、設計エラー、コーディングの問題、不十分なテストなどが含まれます。

12.1.3 欠陥を減らすための重要な要素:

ソフトウェアの欠陥を減らすための重要な要素には、標準化された開発プロセス、効果的な品質保証、効率的なテスト戦略、簡潔なコードの実装、厳格なコードレビューなどが含まれます。

12.1.4 ソフトウェアの欠陥の特徴:

ソフトウェアの欠陥の特徴には、多様性、複雑性、隠蔽性、破壊性、連鎖反応などが含まれます。

12.2 ソフトウェア欠陥の属性:

12.2.1 欠陥の種類:

ソフトウェア欠陥の種類には、論理欠陥、インターフェース欠陥、パフォーマンス欠陥、セキュリティ欠陥が含まれます。

12.2.2 欠陥の重大度:

不具合の重大度には、致命レベル、重篤レベル、一般レベル、即時レベルなどが含まれます。

12.2.3 ピアレビューエラーの重大度:

査読エラーの重大度には、重大な問題、一般的な問題、即時の問題が含まれます。

12.2.4 欠陥の優先順位:

欠陥の優先順位には、高、中、低レベルがあります。

12.2.5 欠陥ステータス:

欠陥ステータスには、新規、オープン、解決済み、クローズ済み、その他の状態が含まれます。

12.2.6 欠陥の原因:

欠陥の原因には、要件、設計、コーディング、テスト、その他のリンクが含まれます。

12.2.7 欠陥の原因:

欠陥の原因には、内部要因と外部要因の両方が含まれます。

12.2.8 欠陥の根本原因:

欠陥の根本原因には、人、プロセス、テクノロジーの 3 つの側面が含まれます。

12.3 ソフトウェアの欠陥の重大度と優先度:

12.3.1 欠陥の重大度と優先度の関係:

欠陥の優先順位は欠陥の重大度によって決まり、重大度が高いほど優先順位も高くなります。

12.3.2 欠陥の重大度と優先度を扱う際によくある間違い:

欠陥の重大度と優先度を扱う際によくある間違いには、欠陥の重大度と優先度を合理的に評価できないことや、実際の状況に応じて欠陥の優先度を適時に調整できないことが含まれます。

12.3.3 欠陥の重大度と優先度の表示と決定:

欠陥の重大度と優先度は通常、数字または文字で示され、その決定は重大度、影響範囲、修復の難易度、ユーザーのニーズなどの要素に基づいて行われます。

12.4 ソフトウェア欠陥管理と CMM の関係:

12.4.1 初期レベルでの欠陥管理:

初期レベルの欠陥管理には、主に欠陥管理計画の作成と基本的な欠陥管理プロセスの確立が含まれます。

12.4.2 再現性レベルでの欠陥管理:

再現可能レベルでの欠陥管理には、主に欠陥の分類とレポート、欠陥分析、欠陥追跡が含まれます。

12.4.3 定義されたレベルでの欠陥管理:

定義されたレベルでの欠陥管理には、主に欠陥の予防とプロセス制御が含まれます。

12.4.4 定量的管理レベルでの欠陥管理:

定量管理レベルでの欠陥管理には、主に欠陥測定と欠陥測定分析が含まれます。

12.4.5 継続的な最適化レベルの欠陥管理:

継続的最適化レベルでの欠陥管理には、主に管理プロセスの改善と欠陥管理レベルの向上が含まれます。CMM モデルでは、ソフトウェア欠陥管理はソフトウェア欠陥を最小限に抑え、ソフトウェア品質を向上させることを目的としたソフトウェア品質保証の一部です。

12.5 ソフトウェアのバグの報告:

12.5.1 ソフトウェアの欠陥を報告するための基本原則:

ソフトウェアの欠陥を報告する基本原則には、適時性、正確性、明確性、簡潔性などが含まれます。ソフトウェアの欠陥を報告する場合は、欠陥の種類、発見時刻、発見場所、再現手順、影響範囲などを含めて、欠陥をできるだけ詳細に説明する必要があります。

12.5.2 IEEE ソフトウェア欠陥レポートテンプレート:

IEEE ソフトウェア欠陥レポート テンプレートには、レポート タイトル、欠陥の簡単な説明、再現手順、期待される結果、実際の結果、欠陥の種類、重大度、優先度などが含まれます。

12.6 ソフトウェアの欠陥管理:

12.6.1 欠陥管理の目標:

欠陥管理の目標は、ソフトウェアの欠陥を最小限に抑え、ソフトウェアの品質を向上させることです。欠陥管理を通じて、ソフトウェアの欠陥を発見して適時に修復することができ、欠陥によるソフトウェアの品質やユーザー エクスペリエンスの損傷を回避できます。

12.6.2 職員の責任:

欠陥管理チームは、プロジェクト マネージャー、ソフトウェア開発者、テスターで構成されます。プロジェクト マネージャーは欠陥管理計画を作成する責任があり、ソフトウェア開発者は欠陥を修正する責任があり、テスターは欠陥を見つけて報告する責任があります。

12.6.3 欠陥のライフサイクル:

欠陥ライフサイクルには、新規、オープン、解決済み、クローズの 4 つの状態が含まれます。欠陥が発見された後、評価と確認の後、オープン状態に入り、確認された欠陥は対応する開発者に割り当てられて修理され、修復された欠陥は解決状態に入り、最終的にテスターの確認でクローズされます。

12.6.4 欠陥管理システム:

ソフトウェア欠陥管理システムは、ソフトウェア欠陥を管理するためのソフトウェア ツールです。これにより、チームが欠陥をより適切に追跡、記録、処理し、チームのコラボレーション効率を向上させることができます。市場には、JIRA、Bugzilla など、成熟した欠陥管理システムが多数存在します。

12.7 ソフトウェアの欠陥分析:

12.7.1 欠陥分析方法:

一般的なソフトウェア欠陥分析手法には、根本原因分析、特性要因図分析、特性要因図分析、5W1H 分析などが含まれます。これらの方法は、チームが欠陥の根本原因を洞察し、将来同様の欠陥を回避できるようにするのに役立ちます。

12.7.2 欠陥分析指標:

一般的に使用される欠陥分析指標には、欠陥密度、故障密度、欠陥率、平均修復時間、平均テスト サイクルが含まれます。これらの指標は、チームがソフトウェアの品質を評価し、タイムリーに適切な修正措置を講じるのに役立ちます。

12.8 要約:

ソフトウェアの欠陥管理は、ソフトウェアの品質を確保するための重要な手段です。効果的な欠陥管理により、ソフトウェアの品質とユーザー エクスペリエンスに対する欠陥の影響を最小限に抑え、チームのコラボレーション効率を向上させることができます。同時に、ソフトウェアの欠陥分析は、チームが欠陥の原因を深く理解し、効果的な是正措置を講じるのにも役立ちます。

• 今日のソフトウェア業界の継続的な発展に伴い、ソフトウェアの品質に対する要求はますます高まっており、ソフトウェア製品の競争力は技術の進歩だけでなく、ソフトウェアの品質が安定しているかどうかにも左右されます。
• したがって、ソフトウェア欠陥管理および管理ツールの欠陥追跡システムに関する研究はますます注目を集めており、今日のソフトウェア工学分野における重要な研究方向となっています。 欠陥管理はソフトウェア開発ライフサイクル全体を通じて行われ、不可欠かつ重要なリンクですが、一部の国内開発者はこれに十分な注意を払っていません。
• CMM とその他のプロセス能力向上手法をどのように組み合わせて、企業が欠陥管理メカニズムを確立および改善し、欠陥管理レベルを向上できるかは、実用上非常に重要な問題です。
• 欠陥管理と欠陥追跡システムの研究は有望な分野であり、海外の研究状況と比較すると、中国ではまだ比較的新しい研究分野であり、詳細な研究と議論に値するものがたくさんあります。

第 13 章 結合テスト

13.1 概要:

13.1.1 統合テストの定義:

統合テストとは、さまざまなモジュールを組み立ててテストし、モジュール間の相互作用や連携が正常であるかどうかを検証し、システム全体の機能が要件を満たしているかどうかを確認するプロセスを指します。統合テストは通常​​、単体テストの後、システム テストの前に実行されます。

13.1.2 統合テスト、単体テスト、システム テストの違い:

統合テスト、単体テスト、システム テストはソフトウェア テストの 3 つの重要なフェーズであり、それぞれの違いは次のとおりです。

• 単体テストは、ソフトウェア内の独立した最小のテスト可能なユニットをテストすることです。その目的は、各ユニットの機能とビジネス ロジックが正しいことを確認することです。
• 統合テストとは、複数のユニットを統合し、それらの相互作用や連携が正常であるかどうかをテストし、システム全体の機能が要件を満たしているかを検証することです。
• システムテストとは、ソフトウェアシステム全体をテストして、ユーザーの要求や仕様を満たしているかどうかを確認することです。

13.1.3 統合テストの主なタスク:

統合テストの主なタスクには次のようなものがあります。

• さまざまなモジュール間のインターフェイスとデータ転送が正しいことを確認します。
• システムの機能とパフォーマンスが仕様、ユーザーのニーズ、設計要件を満たしていることを確認します。
• システムの抜け穴や欠陥の存在を検出し、修復や最適化を行います。
• システムの安定性と信頼性を確保し、品質要件を満たします。

13.1.4 統合テストのレベルと原則:

結合テストは通常​​、単体結合テスト、モジュール結合テスト、サブシステム結合テスト、システム結合テストの 4 つのレベルに分かれています。統合テストの原則には次のものが含まれます。

• レイヤーごとの統合: 単体テストから始めて、すべてのレベルのモジュールを段階的に統合して、各レベルの機能が正しいことを確認します。
• モジュール式テスト: システム全体をテスト用にいくつかの独立したモジュールに分解し、各モジュールの機能が正しいことを確認します。
• インターフェイス テスト: インターフェイスとモジュール間のデータ転送が正しいかどうかのテストに重点を置きます。
• 自動テスト: 自動テスト ツールを使用してシステムをテストし、テストの効率と品質を向上させます。
• 完全性テスト: システムのすべての機能と境界条件がテストされていることを確認し、考えられるすべての問題を可能な限り検出して解決します。

13.2 統合テスト戦略:

13.2.1 非増分統合:

非増分統合とは、すべてのモジュールが実装された後、テストのために一度に組み立てられることを意味します。この方法の利点は、テストが一度に完了し、問題を迅速に特定して解決できることですが、欠点は、問題の特定の場所を特定することが難しく、多くのデバッグと修復作業が必要になることです。 、効率は低いです。

13.2.2 増分統合:

増分統合とは、単体テストから始めて、テスト用のさまざまなモジュールを徐々に統合することを指します。この方法のメリットは、問題を早期に発見して解決でき、テストサイクルを短縮できることですが、デメリットは、各段階でテストを繰り返す必要があり、テストの負荷が増加することです。

13.2.3 その他の統合テスト戦略:

非増分統合と増分統合に加えて、ハイブリッド統合、トップダウン統合、ボトムアップ統合などの他の統合テスト戦略もあります。このうちハイブリッド統合は、増分統合と非増分統合を組み合わせた手法であり、プロジェクト要件に応じて柔軟に選択できます。

13.2.4 いくつかの統合テスト実装の比較:

表に示すように、統合テスト戦略が異なれば、実装計画も異なります。

統合テスト戦略	実行計画
非増分的	全体的なテストのためにすべてのモジュールを一度に組み立てる
増分	単体テスト -> モジュール結合テスト -> サブシステム結合テスト -> システム結合テスト
ハイブリッド統合	最初にモジュール間の非増分統合テストを実行し、次に全体的な増分統合テストを実行します。
トップダウンの統合	最初に高レベルのモジュールを統合し、次に下位レベルのモジュールを徐々に統合します
ボトムアップの統合	最初に低レベルのモジュールを統合し、次に高レベルのモジュールを徐々に統合します

さまざまな実装計画はさまざまなプロジェクト要件や技術的条件に適しており、特定の状況に応じて選択する必要があります。

13.3 統合テストケースの設計:

13.3.1 システム運用の設計ユースケース:

システムの仕様やユーザーの要求に応じてシステムの機能・性能要件を決定し、システムがその要件を満たしているかどうかを検証するテストケースを設計する手法です。

13.3.2 フォワードテストのユースケースを設計する:

この方法は、システムの通常の使用シナリオに基づいており、テスト ケースは、システムの機能と性能が通常の使用条件下で要件を満たしているかどうかを検証するために設計されています。

13.3.3 リバーステストのユースケースを設計する:

この手法は、入力エラーやネットワーク障害などのシステムの異常状態を考慮してテストケースを設計し、異常状態におけるシステムの耐障害性や堅牢性を検証するものです。

13.3.4 特別な要件を満たすユースケースを設計する:

セキュリティ、信頼性、拡張性などの一部の特殊な要件については、対応するテスト ケースを設計して、システムがこれらの要件を満たしているかどうかを検証します。

13.3.5 高カバレッジのユースケースを設計する:

この手法は、コード分析やテストカバレッジツールの分析結果に基づいて、コードの各分岐条件や境界条件をカバーするテストケースを設計し、テストカバレッジを向上させます。

13.3.6 モジュールインターフェースの依存関係に基づいたユースケースの設計:

この手法は、モジュール間のインターフェースの依存関係に応じてテストケースを設計し、モジュール間のインターフェースやデータ伝送が正しいかどうかを検証し、インターフェースの問題によるシステムエラーを回避する方法です。

13.4 統合テストのプロセス:

13.4.1 計画段階:

統合テスト計画の作成、テスト戦略と実装計画の決定、テスト リソースとツールの決定、テスト ケースとテスト スクリプトの作成、テストの進捗状況とレポートの作成など。

13.4.2 設計実装段階:

テスト計画に従ってテストケースやテストスクリプトを設計・実装し、テスト環境やツールを設定し、単体テストやモジュール結合テストを実行して機能が正しいことを確認します。

13.4.3 評価フェーズを実行します。

サブシステムとシステムの統合テストを実行し、テスト結果を分析および評価し、テストの欠陥と問題を記録および報告し、問題の追跡、修復および検証を実施し、最終的にシステムの品質と安定性が要件を満たしていることを確認します。

13.5 オブジェクト指向の統合テスト:

13.5.1 オブジェクトの相互作用:

オブジェクト指向の統合テストでは、オブジェクト間の対話とコラボレーションが重視され、クラス間のメッセージ受け渡しとデータ共有が正しいかどうか、クラス間の依存関係が設計要件を満たしているかどうかをテストする必要があります。

13.5.2 オブジェクト指向統合テストの手順:

オブジェクト指向の統合テストには主に次の手順が含まれます。

• テストするクラスとオブジェクトを特定する
• クラス間の依存関係とインターフェイスを特定する
• テストケースの設計と実装
• テストを実行して結果を記録する
• テスト結果を分析し、問題を解決する

13.5.3 オブジェクト指向の統合テストに一般的に使用されるテスト手法:

オブジェクト指向統合テストでは、階層化テスト、機能分割テスト、モックオブジェクトテストなど、さまざまなテスト手法を採用できます。その中でも、モックオブジェクトテストは、テストオブジェクトの動作をシミュレートして、テスターがより便利にテストを実行できる一般的な方法です。

13.6 要約:

結合テストはソフトウェアテストの重要なリンクであり、その目的はシステムの機能とパフォーマンスが要件を満たしているかどうかを検証することです。実際の状況に応じて、さまざまな結合テスト戦略と実装スキームを選択し、テストケース設計とテストプロセス管理を実行できます。オブジェクト指向の統合テストでは、オブジェクト間の相互作用と連携が重視され、テストの信頼性と有効性を確保するために適切なテスト手法を使用する必要があります。

• 結合テストは、単体テストの後、システムテストの前に行われる重要なステップであり、ある意味、3 つの段階の中で最も重要なステップです。
• 統合テストは開発者が行うのが最善ですが、タスクの完了をテスト部門に報告すると、テストが繰り返し行われることになり、進捗が遅れやすくなります。
• 統合テストの戦略は、主に、単一の統合テスト ケースの範囲と統合ツリー全体のトラバース パスを中心に設計されています。
• さまざまな戦略には、テストケースの規模、ドライバーやスタブモジュールの負荷、欠陥箇所などの観点から一長一短があり、実際の状況に応じて柔軟に使用する必要があります。

第 14 章 システムのテスト

14.1 概要:

14.1.1 システムテストの定義:

システム テストは、ソフトウェア統合が完了した後にソフトウェア システム全体をテストするプロセスです。その目的は、ソフトウェア システムの機能、信頼性、セキュリティ、パフォーマンス、使いやすさがユーザーのニーズや設計要件を満たしているかどうかを検証することです。

14.1.2 システムテストプロセス:

システム テストのプロセスには、テスト計画、テスト設計、テスト実行、テスト分析、テスト レポートのいくつかの段階が含まれます。このうち、テスト計画はテストリソースとツール、テスト戦略と実装計画、テスト時間と進捗状況などを決定し、テスト設計はテストケースとテストスクリプトを作成し、テスト環境とツールを構成し、テストシナリオとデータを決定します。テスト計画とテストに従います テストを設計および実施し、テスト結果と問題を記録します テスト分析 テスト結果と問題を分析し、問題の原因と解決策を見つけます テストレポート テスト結果に基づいてテストレポートを作成し、関係者に提出しますそして分析。

14.1.3 システムテストの目的:

システムテストの主な目的は、ソフトウェアシステムが機能、信頼性、セキュリティ、パフォーマンス、使いやすさなどのユーザーのニーズや設計要件を満たしているかどうかを検証することです。

14.1.4 システムテストのガイドライン:

システム テストのポリシーはユーザー中心、品質指向であり、効果的で信頼性の高いテスト結果を保証するための効率と信頼性に重​​点を置いています。

14.1.5 システムテストの原則:

システムテストの原則には、テストの品質と有効性を確保するための、包括性、独立性、有効性、重要性、継続性などの側面が含まれます。

14.2 システムテストの主な方法:

14.2.1 パフォーマンステスト:

パフォーマンス テストでは、応答時間、スループット、同時ユーザー数など、さまざまな負荷の下でソフトウェア システムのパフォーマンス指標を評価し、システムの容量と安定性を判断します。

14.2.2 強度試験:

強度試験は、システムの信頼性と安定性を検証するために、システムを長時間動作または高負荷で動作させる試験です。

14.2.3 セキュリティテスト:

セキュリティテストは、システムのセキュリティパフォーマンスを評価し、システムが攻撃や損傷に対して脆弱かどうかを検出し、システムのセキュリティと安定性を向上させるために使用されます。

14.2.4 互換性テスト:

互換性テストは、システムとさまざまなハードウェアおよびソフトウェア環境の互換性を検証し、システムがさまざまな環境で正常に動作できることを確認することです。

14.2.5 回復テスト:

リカバリテストとは、システムが故障した後に正常に正常に復旧できるかどうかをテストし、システムのリカバリ能力と信頼性を評価することです。

14.2.6 グラフィカル ユーザー インターフェイスのテスト:

グラフィカル ユーザー インターフェイス テストは、システムの使いやすさとユーザー エクスペリエンスを向上させるために、システムのユーザー インターフェイスがユーザーのニーズと設計要件を満たしているかどうかを検証することです。

14.2.7 インストールテスト:

インストールテストは、ユーザーがシステムを正しくインストールして使用できることを確認するために、システムのインストールプロセスがスムーズで正確かつ完全であるかどうかを検証することです。

14.2.8 信頼性テスト:

信頼性テストはシステムの安定性と信頼性を検証するもので、システムのエラー処理および回復能力を評価するために使用されます。

14.2.9 構成テスト:

構成テストは、さまざまな構成でシステムの動作とパフォーマンスを検証し、システムがさまざまな構成で正常に動作できることを確認することです。

14.2.10 ユーザビリティテスト:

ユーザビリティテストは、システムの使いやすさとユーザーの満足度を向上させるために、システムの使いやすさと人間とコンピュータの相互作用を評価することです。

14.2.11 文書化テスト:

ドキュメントテストは、システムのわかりやすさと使いやすさを向上させるために、システムのドキュメントや資料が明確、正確、完全であるかどうかを検証することです。

14.2.12 Web サイトのテスト:

Webサイトテストとは、Webサイトの品質やユーザーエクスペリエンスを向上させるために、Webサイトの機能、パフォーマンス、信頼性、セキュリティなどを検証することです。

14.3 システムテストツールとそのア​​プリケーション:

14.3.1 システムテストツールの分類:

システムテストツールは、テストの効率と信頼性を向上させるために、テスト管理ツール、自動テストツール、パフォーマンステストツール、セキュリティテストツール、互換性テストツール、インターフェイステストツールなどに分類できます。

14.3.2 テスト管理システム TestDirector の使用:

TestDirector は、テスト担当者がテスト計画、テスト設計、テスト実行、テスト レポートなどを管理および共同作業するのに役立ち、テスト管理の効率と品質を向上させる、一般的に使用されるテスト管理ツールです。

14.4 要約:

システム テストはソフトウェア テストにおける重要なリンクであり、その目的は、ソフトウェア システムがユーザーのニーズと設計要件を満たしているかどうかを検証することです。システムのテスト手法には、パフォーマンステスト、セキュリティテスト、互換性テスト、インターフェーステストなど、さまざまな種類があります。テスト管理ツール TestDirector などのテスト ツールを適用すると、テストの効率と信頼性を向上できます。

• システム テストでは、コンピュータ システム全体の一部として、適切に統合されたソフトウェア システムを使用します。
• コンピュータ ハードウェア、外部機器、サポート ソフトウェア、データ、人員などの他のシステム要素と組み合わせて、実際の使用 (実行) 環境でコンピュータ システムに対して一連の厳密なテストが実行され、ソフトウェアの潜在的な欠陥を発見し、アフターサービスが保証されます。システムはユーザーに納品され、正常に使用できます。
• 一般に、システム テストは製品出荷前の最後のテスト リンクであり、重要な役割を果たします。
• システムテストの最終的な目的は、開発者がユーザーに提供したソフトウェア製品がユーザーのニーズを満たしているかどうかを確認することであるため、システムテストのテストケースは実際のユーザー環境で実行される必要があります。

第 15 章 テスト管理

15.1 概要:

15.1.1 テストのプロセスと組織

テストはソフトウェア開発プロセスの不可欠な部分であり、テスト プロセスには、テストの計画、テストの設計、テストの実行、およびテスト結果の分析が含まれます。テストは特定の組織構造の下で実行する必要があり、テスターは開発者と緊密に連携する必要があります。

15.1.2 試験方法の適用

テスト方法とは、特定のソフトウェア システムに採用されるテスト手法と戦略を指します。一般的なテスト方法には、ブラック ボックス テスト、ホワイト ボックス テスト、グレー ボックス テストなどがあります。

15.1.3 試験の人員構成

テスターの組織には、テスト マネージャー、テスト エンジニア、テスト アナリストなどの役割が含まれます。

15.1.4 ソフトウェアテストのドキュメント

ソフトウェア テスト文書には、テスト計画、テスト ケース、テスト レポート、欠陥レポートなどが含まれます。

15.2 ソフトウェアテスト管理システムを確立します。

15.2.1 ソフトウェアテスト管理システムの構築方法

ソフトウェアテスト管理システムを構築するには、テスト戦略の決定、テスト計画の策定、テストチームとテスト管理組織の確立が鍵となると同時に、テストの品質と効率を評価する必要があります。

15.2.2 組織構造の設計とソフトウェアテストプロジェクトの選択

ソフトウェア テスト プロジェクトの組織構造の設計では、プロジェクトの規模とテストの要件を考慮する必要があります。オプションのテスト組織構造には、集中型、分散型、ハイブリッド型などがあります。

15.2.3 テストマネージャーの動作原則

テスト管理者が従う必要がある作業原則には、テスト目標の決定、テスト計画の策定、テスト プロセスの最適化、テストの効率と品質の向上が含まれます。

15.3 テスト文書の作成:

15.3.1 テスト計画

テスト計画書とは、テストの戦略や計画を策定するための文書を指し、テストの目的、テストリソース、テストの進捗状況、テスト方法、テストケースなどが含まれます。

15.3.2 テスト仕様書

テスト仕様書とは、テスト環境の構築、テストデータの準備、テストケースの作成、テストの実行、テストレポートなど、テストのプロセスや操作の仕様を指します。

15.3.3 テストケースとテストレポート

テスト ケースは、ソフトウェア要件に合わせて作成されたテスト ケースを指し、テスト レポートは、テスト結果、欠陥レポート、その他の情報を含む、テスト実行後に生成されるレポートを指します。

15.3.4 ソフトウェア欠陥レポート

ソフトウェア欠陥レポートとは、テストプロセスで見つかったソフトウェア欠陥のレポートを指し、欠陥の重大度、欠陥の説明、欠陥環境、再現手順、その他の情報が含まれます。

15.4 デバッグのヒント:

15.4.1 試運転プロセス

デバッグとは、ソフトウェア開発プロセスにおけるプログラムのエラーや欠陥を解決するプロセスを指します。これには、問題の特定、問題の分析、および問題の修復のプロセスが含まれます。

15.4.2 デバッグ方法

一般的に使用されるデバッグ方法には、印刷デバッグ、シングルステップ実行、ブレークポイント デバッグ、メモリ リーク チェックなどが含まれます。

15.4.3 心理的要因

デバッグの成功は、認知バイアスや気分の変動などの心理的要因にも影響されます。

15.5 ソフトウェアテストの自動化:

15.5.1 概要

ソフトウェア テストの自動化とは、スクリプトを作成し、ツールを使用してテストの効率と品質を向上させる自動テストを指します。

15.5.2 ソフトウェアテスト自動化を実装する理由

ソフトウェア テスト自動化を実装する理由には、テスト効率の向上、テスト コストの削減、テスト カバレッジの向上などが含まれます。

15.5.3 ソフトウェアテスト自動化の導入条件

ソフトウェアテスト自動化の導入には、特定のテスト仕様とプロセスが必要であり、テスト対象は安定しており、要件は明確です。

15.5.4 さまざまな段階での自動テストの利点

さまざまな段階での自動テストにより、テストの効率が向上し、問題を早期に検出し、テストのコストを削減できます。

15.5.5 一般的な自動テスト開発ツール

一般的に使用される自動テスト開発ツールには、Selenium、Appium、Robot Framework などが含まれます。

15.6 概要

この章では、ソフトウェア テスト管理の関連する概念、原則、手法、およびデバッグ スキルとソフトウェア テスト自動化の適用について紹介します。ソフトウェアテストのプロセスでは、実際の状況やニーズに応じて適切なテスト方法やツールを選択し、テストの仕様と手順を厳密に実装してテストの効率と品質を向上させる必要があります。

• ソフトウェアテストの管理は、ソフトウェアエンジニアリングと管理のプロジェクト管理の概念、方法、技術、ツールを共通性から継承しており、これにはプロセス管理、進捗管理、リソース管理、リスク管理、文書管理の継承も含まれます。

• ソフトウェアは世界で最も重要な製品であり、最も重要な産業となっており、その影響力と重要性は大きく進歩しています。

第十六章

1. 第 16 章 テストの「オフトピック」とは、テスト計画、テストレポート、欠陥追跡など、ソフトウェアテストにおける些細だが重要な内容を指します。
2. ユーザビリティテストとは、特定の使用環境において、特定のユーザーが製品をどの程度効果的、効率的、満足して完成させることができるかを評価することを指します。一定数の代表的なユーザーに製品に対する通常の操作を実行してもらい、ユーザーと開発者のパフォーマンスとフィードバックを観察して記録します。
3. ユーザビリティ テストの基本要素には、ユーザーの理解、学歴、環境圧力が考慮されているかどうか、プログラムの出力が有意義か、物議を醸すか、曖昧かどうか、エラー メッセージが明確かどうか、効果的な入力検証が行われているかどうか、などが含まれます。システムオプションが多すぎる、ユーザーの操作が使いやすいか、再現しやすいかなど。
4. ユーザビリティテストの基本要素には、ユーザーが正確に入力できるように設計されているか、多くの機能の間でユーザーがスムーズに操作できるか、ユーザーの主観的な認知的観点に適合しているかなどが引き続き含まれます。
5. ユーザビリティテストのプロセスには、テストユーザーの選定、テスターの規模の決定、データ収集方法、ユーザビリティアンケート、アンケートの終了方法などが含まれます。
6. 循環的複雑さはソフトウェアの複雑さの尺度であり、コード内の線形に独立したパスの数を指します。計算式は、V(G)=E-N+2、V(G)=P+1、V(G)=Rの3つがあります。
7. ソフトウェアの複雑さのその他の要素には、高精度を必要とするソフトウェア システムが効果的な入力検証を提供するかどうか、システムに多すぎるオプションや使用されないオプションが含まれているかどうか、学習が簡単かどうかなどが含まれます。
8. ソフトウェアの複雑さのその他の要素には、引き続きソフトウェア設計仕様が満たされているかどうか、およびユーザーの主観的な認知的観点が含まれます。
9. CK 測定方法は、WMC、DIT、NOC、CBO、RFC、および LCOM6 測定方法を含むオブジェクト指向ソフトウェアの複雑さの測定方法です。
10. ソフトウェア分析モデリングには、フローチャート、制御フロー グラフ、デシジョン テーブル、因果関係グラフ、ペトリ ネットなどが含まれます。
11. ソフトウェアの複雑さのユニットレベルの尺度には、循環的複雑さと意思決定の複雑さが含まれます。
12. 統合レベルでのソフトウェアの複雑さの測定には、統合レベルの循環的複雑さとメッセージ フローの複雑さが含まれます。
13. ペトリ ネットは、現象を記述および発見するためのツールです。ペトリ ネットでは、場所は円を使用してシステムの可能なローカル状態をマークし、遷移は長方形を使用してシステム状態を変更するイベントをマークし、有向円弧は場所ノードから遷移ノードまたは遷移ノードを指すことができます。トランジションノードからプレイスノードまで。
14. ペトリ ネットの進化には、トークンの色付け、属性、タイムスタンプ、階層、時相ロジックの追加が含まれます。
15. SQA はソフトウェア品質保証、ST はソフトウェア テストです。SQA には、最終製品の品質を保証するために、ソフトウェア ライフ サイクルにおける品質基準、プロセス、方法、およびツールを開発および実装するプロセスが含まれます。ST は、ソフトウェア製品をテストして検証し、欠陥を発見して修復するプロセスです。