Loading article…
ソフトウェア テストは、ソフトウェアが期待を満たしているかどうかを確認する行為です。
ソフトウェアテストは、ソフトウェアの品質と障害のリスクに関する客観的で独立した情報をユーザーやスポンサーに提供することができます。[1]
ソフトウェアテストは特定のシナリオにおけるソフトウェアの正しさを判断できますが、すべてのシナリオにおける正しさを判断することはできません。[2] [3]すべてのバグを見つけることはできません。
ソフトウェアテストでは、オラクルから正確さを測定する基準に基づいて、問題を認識できる原則とメカニズムを採用します。オラクルの例には、仕様、契約、[4]比較可能な製品、同じ製品の過去のバージョン、意図または期待される目的に関する推論、ユーザーまたは顧客の期待、関連する標準、適用可能な法律などがあります。
ソフトウェア テストは、多くの場合、動的な性質を持ち、ソフトウェアを実行して実際の出力が期待どおりであることを確認します。また、コードとそれに関連するドキュメントを確認するなど、静的な性質を持つこともあります。
ソフトウェア テストは、多くの場合、「ソフトウェアは想定された動作と必要な動作を実行しているか?」という質問に答えるために使用されます。
ソフトウェアテストから得られた情報は、ソフトウェア開発プロセスの改善に活用できる可能性がある。[5] : 41–43
ソフトウェアテストは「ピラミッド」アプローチに従う必要があります。つまり、テストの大部分は単体テスト、次に統合テスト、そして最後にエンドツーエンド（e2e）テストの割合が最も少なくなるはずです。[6] [7] [8]
経済
2002年にNISTが実施した調査によると、ソフトウェアのバグは米国経済に年間595億ドルの損害を与えている。ソフトウェアテストをより適切に実施すれば、このコストの3分の1以上を回避できる可能性がある。[9] [疑わしい–議論する]
コスト面からソフトウェア テストをアウトソーシングすることは非常に一般的であり、中国、フィリピン、インドが好まれるアウトソーシング先です。[引用が必要]
歴史
グレンフォード・J・マイヤーズは1979年にデバッグとテストの分離を最初に導入しました。[10]彼の注目は破損テスト（「成功したテストケースとは、まだ発見されていないエラーを検出するテストケースである。」[10] ：16 ）でしたが、それはソフトウェアエンジニアリングコミュニティがデバッグなどの基本的な開発活動を検証から分離したいという願望を示しました。
目標
ソフトウェア テストは通常、目標主導で行われます。
バグを見つける
ソフトウェアテストには通常、ソフトウェアのバグ（望ましくない結果を引き起こすコードの欠陥）の処理が含まれます。 [11] : 31 バグは一般的にテストの進行を遅らせ、デバッグと修正にプログラマーの支援を必要とします。
すべての欠陥が障害の原因となるわけではありません。たとえば、デッド コードの欠陥は障害とはみなされません。
ある時点では故障を引き起こさない欠陥でも、環境の変化によって後から発生する可能性があります。環境の変化の例としては、新しいコンピュータハードウェアでの実行、データの変更、異なるソフトウェアとのやり取りなどが挙げられます。[12]
1 つの欠陥によって複数の障害症状が発生する可能性があります。
要件が満たされていることを確認する
ソフトウェアテストには、要件のギャップ（設計から要件が漏れている）が含まれる場合があります。[5] ：426 要件のギャップは、多くの場合、テスト可能性、スケーラビリティ、保守性、パフォーマンス、セキュリティなどの非機能要件です。
コードカバレッジ
ソフトウェアテストの根本的な限界は、単純な製品であっても、あらゆる入力と前提条件（初期状態）の組み合わせでのテストが不可能なことである。 [3] : 17–18 [13] 異常な状況で現れる欠陥は、テストで見つけるのが難しい。また、品質の非機能的側面（想定される状態と想定される動作）である使いやすさ、スケーラビリティ、パフォーマンス、互換性、信頼性は主観的である可能性があり、ある人にとって十分な価値を構成するものが、別の人にとってはそうではない可能性がある。
あらゆる入力をテストすることは現実的ではありませんが、テストでは組み合わせ論を使用してカバレッジを最大化し、テストを最小限に抑えることができます。[14]
分類
テストはさまざまな方法で分類することができます。[15]
自動テスト
レベル
ソフトウェアテストは、ソフトウェアシステムのどの程度がテストの焦点であるかに基づいてレベルに分類できます。[18] [19] [20] [21]
ユニットテスト
ユニットテスト（別名コンポーネントテストまたはモジュールテスト）は、分離されたソースコードをテストして期待される動作を検証するソフトウェアテストの一種です。 [22]
統合テスト
統合テストは、統合とテストとも呼ばれ、略して I&T とも呼ばれ、ソフトウェア システムの複数の部分をグループとしてテストするソフトウェア テストの形式です。
システムテスト
システム テスト、別名エンドツーエンド (E2E) テストは、完全なソフトウェア システムに対して実行されるテストです。
静的、動的、受動的なテスト
ソフトウェアテストには多くのアプローチがあります。レビュー、ウォークスルー、検査は静的テストと呼ばれ、特定のテストケースセットを使用してプログラムされたコードを実行することは動的テストと呼ばれます。[23] [24]
静的テストは、校正のように暗黙的に行われることが多く、プログラミングツールやテキストエディタがソースコードの構造をチェックしたり、コンパイラ（プリコンパイラ）が静的プログラム分析として構文やデータフローをチェックしたりするときにも行われます。動的テストは、プログラム自体の実行時に行われます。動的テストは、特定のコードセクションをテストするために、プログラムが100％完成する前に開始される場合があり、個別の関数やモジュールに適用されます。[23] [24]これらの一般的な手法は、スタブ/ドライバーを使用するか、デバッガー環境から実行することです。[24]
静的テストには検証が含まれますが、動的テストにも検証が含まれます。[24]
パッシブテストとは、ソフトウェア製品とのやり取りなしにシステムの動作を検証することを意味します。アクティブテストとは対照的に、テスターはテストデータを提供せず、システムログとトレースを調べます。彼らは何らかの決定を下すためにパターンと特定の動作を探します。[25]これはオフラインランタイム検証とログ分析に関連しています。
探索的
プリセットテストと適応型テスト
実行されるテスト戦略のタイプは、IUTに適用されるテストをテスト計画の実行開始前に決定する必要があるかどうか（プリセットテスト[28]）、またはIUTに適用される各入力が以前のテストの適用中に得られた出力に動的に依存できるかどうか（適応型テスト[29] [30]）によって異なります。
黒/白のボックス
ソフトウェアテストは、ホワイトボックスとブラックボックスに分けられることが多い。これら2つのアプローチは、テストケースを設計する際にテスターが取る視点を説明するために使用される。グレーボックスと呼ばれるハイブリッドアプローチは、両方のボックスの側面を含み、ソフトウェアテスト方法論にも適用される可能性がある。[31] [32]
ホワイトボックステスト
ホワイトボックステスト（クリアボックステスト、グラスボックステスト、透明ボックステスト、構造テストとも呼ばれる）は、エンドユーザーに公開されている機能ではなく、プログラムの内部構造や動作を検証します。ホワイトボックステストでは、システム（ソースコード）の内部観点とプログラミングスキルを使用してテストケースを設計します。テスターはコード内のパスを実行するための入力を選択し、適切な出力を決定します。[31] [32]これは、回路内テスト（ICT） などの回路内のノードをテストすることに似ています。
ホワイトボックステストは、ソフトウェアテストプロセスのユニットレベル、統合レベル、システムレベルで適用できますが、通常はユニットレベルで行われます。 [33]ユニット内のパス、統合中のユニット間のパス、システムレベルテスト中のサブシステム間のパスをテストできます。このテスト設計方法では多くのエラーや問題を発見できますが、仕様の未実装部分や要件の欠落を検出できない場合があります。
ホワイトボックステストで使用される技術には以下のものがある: [32] [34]
- API テスト– パブリックおよびプライベートAPI (アプリケーション プログラミング インターフェイス)を使用したアプリケーションのテスト
- コード カバレッジ- コード カバレッジのいくつかの基準を満たすテストを作成します (たとえば、テスト設計者は、プログラム内のすべてのステートメントが少なくとも 1 回実行されるようにテストを作成できます)
- フォールトインジェクション法 – テスト戦略の有効性を測定するために意図的にフォールトを導入する
- 突然変異検査法
- 静的テスト方法
コードカバレッジツールは、ブラックボックステストを含むあらゆる方法で作成されたテストスイートの完全性を評価できます。これにより、ソフトウェアチームは、めったにテストされないシステムの部分を検査し、最も重要な機能ポイントがテストされていることを確認できます。[35]ソフトウェアメトリックとしてのコードカバレッジは、次のパーセンテージとして報告できます。[31] [35] [36]
- 関数カバレッジは実行された関数をレポートします
- ステートメントカバレッジは、テストを完了するために実行された行数を報告します。
- 決定カバレッジは、特定のテストのTrueブランチとFalseブランチの両方が実行されたかどうかを報告します。
100%のステートメントカバレッジは、すべてのコードパスまたは分岐（制御フローの観点から）が少なくとも1回実行されることを保証します。これは正しい機能を保証するのに役立ちますが、同じコードが異なる入力を正しくまたは誤って処理する可能性があるため、十分ではありません。[37]
ブラックボックステスト
ブラックボックステスト（機能テストとも呼ばれる）は、実装の知識がなく、ソースコードを読むことなくテストケースを設計することを指します。テスターはソフトウェアが何をすべきかを知っているだけで、どのように行うかは知りません。[38]ブラックボックステストの方法には、同値分割、境界値分析、全ペアテスト、状態遷移表、決定表テスト、ファズテスト、モデルベーステスト、ユースケーステスト、探索的テスト、仕様ベーステストなどがあります。 [31] [32] [36]
仕様ベースのテストは、適用可能な要件に従ってソフトウェアの機能をテストすることを目的としています。[39]このレベルのテストでは通常、テスト担当者に徹底的なテストケースを提供する必要があります。テスト担当者は、特定の入力に対して、出力値 (または動作) がテストケースで指定された期待値と同じか同じでないかを確認するだけで済みます。テストケースは、仕様と要件、つまりアプリケーションが行うことになっていることを中心に構築されます。テストケースを導き出すために、仕様、要件、設計など、ソフトウェアの外部記述を使用します。これらのテストは機能的でも非機能的でもかまいませんが、通常は機能的です。仕様ベースのテストは、正しい機能を保証するために必要な場合もありますが、複雑または高リスクの状況から保護するには不十分です。[40]
ブラックボックステストは、通常ユニットレベルではないものの、あらゆるレベルのテストに使用できます。[33]
コンポーネントインターフェーステスト
コンポーネントインターフェーステストはブラックボックステストの一種で、サブシステムコンポーネントの関連アクションだけでなく、データ値にも焦点を当てています。 [41]コンポーネントインターフェーステストの実践は、ユニット間の完全な統合テストを超えて、さまざまなユニットまたはサブシステムコンポーネント間で渡されるデータの処理を確認するために使用できます。[42] [43]渡されるデータは「メッセージパケット」と見なすことができ、1つのユニットから生成されたデータの範囲またはデータ型を確認し、別のユニットに渡す前に有効性をテストできます。 インターフェーステストの1つのオプションは、渡されるデータ項目の別のログファイルを保持することです。これには、数日または数週間にわたってユニット間で渡された何千ものデータのケースを分析できるように、多くの場合、タイムスタンプが記録されます。 テストには、他のインターフェース変数が通常の値として渡されている間に、いくつかの極端なデータ値の処理を確認することを含めることができます。[42]インターフェースの異常なデータ値は、次のユニットでの予期しないパフォーマンスを説明するのに役立ちます。
視覚テスト
ビジュアルテストの目的は、開発者が必要な情報を簡単に見つけることができ、その情報が明確に表現されるようにデータを提示することで、ソフトウェア障害が発生した時点で何が起こっていたのかを調査する能力を開発者に提供することである。[44] [45]
ビジュアル テストの核となるのは、問題 (またはテストの失敗) を単に説明するのではなく、誰かに見せることで、明確さと理解が大幅に向上するという考えです。したがって、ビジュアル テストでは、テスト プロセス全体を記録する必要があります。つまり、テスト システムで発生するすべてのことをビデオ形式でキャプチャします。出力ビデオには、ピクチャー イン ア ピクチャー Web カメラによるリアルタイムのテスター入力と、マイクからの音声解説が補足されます。
ビジュアル テストには、多くの利点があります。テスターは開発者に問題 (およびそれに至るイベント) を単に説明するだけでなく、実際に見せることができるため、コミュニケーションの質が大幅に向上し、多くの場合、テストの失敗を再現する必要がなくなります。開発者は、テストの失敗について必要なすべての証拠を入手し、代わりに障害の原因と修正方法に集中できます。
アドホックテストと探索的テストは、ソフトウェアの整合性をチェックするための重要な方法論です。なぜなら、実装に必要な準備時間が少なく、重要なバグを迅速に発見できるからです。[46]アドホックテストでは、テストが即興で即興的に行われますが、テスト担当者が文書化された方法に基づいてテストを行い、それらのテストのバリエーションを即興で作成する能力により、欠陥修正のより厳密な検査が可能になります。[46]ただし、手順の厳密な文書化が維持されない限り、アドホックテストの限界の1つは再現性の欠如です。[46]
グレーボックステスト
グレーボックステスト（アメリカ式綴り：グレーボックステスト）では、テストを設計する目的で内部データ構造とアルゴリズムの知識を使用し、それらのテストをユーザーレベルまたはブラックボックスレベルで実行します。テスターは多くの場合、「ソースコードと実行バイナリ」の両方にアクセスできます。[47]グレーボックステストには、境界値やエラーメッセージなどを決定するためのリバースエンジニアリング（動的コード分析を使用）も含まれる場合があります。 [47]入力データの操作と出力のフォーマットは、入力と出力がテスト対象システムと呼ばれる「ブラックボックス」の外部にあることは明らかなので、グレーボックスとはみなされません。この区別は、 2人の異なる開発者によって書かれた2つのコードモジュール間の統合テストを実行するときに特に重要です。この場合、テストではインターフェイスのみが公開されます。
ソフトウェアがどのように動作するかという基本的な概念を知ることで、テスターは外部からソフトウェアをテストする際に、より情報に基づいたテストの選択を行うことができます。通常、グレーボックステスターは、データベースのシードなどのアクティビティを含む分離されたテスト環境をセットアップすることが許可されます。テスターは、データベースに対してSQL文を実行し、クエリを実行して、予想される変更が反映されていることを確認するなどの特定のアクションを実行した後、テスト対象の製品の状態を観察できます。グレーボックステストは、限られた情報に基づいてインテリジェントなテストシナリオを実装します。これは、データ型の処理、例外処理などに特に当てはまります。[48]
グレーボックステストの概念により、ブラックボックステストとホワイトボックステストの間のこの「恣意的な区別」はやや薄れてきました。[33]
インストールテスト
ほとんどのソフトウェアシステムには、主な目的で使用する前に必要なインストール手順があります。これらの手順をテストして、使用可能なインストール済みソフトウェアシステムを実現することをインストールテストと呼びます。[49] : 139 これらの手順には、完全または部分的なアップグレード、およびインストール/アンインストールのプロセスが含まれる場合があります。
- ユーザーはさまざまなオプションを選択する必要があります。
- 依存ファイルとライブラリを割り当て、ロード、または配置する必要があります。
- 有効なハードウェア構成が存在している必要があります。
- ソフトウェアシステムは他のソフトウェアシステムに接続するために接続性を必要とする場合がある。[49] : 145
互換性テスト
ソフトウェア障害(実際の障害または認識上の障害) の一般的な原因は、他のアプリケーション ソフトウェア、オペレーティング システム(またはオペレーティング システムのバージョン、新旧を問わず)、または元の環境とは大きく異なるターゲット環境 (デスクトップでの実行を意図していた端末またはGUIアプリケーションが、 Web ブラウザーでレンダリングする必要があるWeb アプリケーションになる必要があるなど) との互換性の欠如です。たとえば、下位互換性がない場合は、プログラマーが最新バージョンのターゲット環境でのみソフトウェアを開発およびテストしているため、すべてのユーザーがそのバージョンを実行しているとは限らないために発生する可能性があります。その結果、最新の作業が以前のバージョンのターゲット環境、または以前のバージョンのターゲット環境で使用できた古いハードウェアでは機能しないという意図しない結果が発生します。このような問題は、オペレーティング システムの機能を別のプログラムモジュールまたはライブラリに積極的に抽象化することで修正できる場合があります。
スモークテストと健全性テスト
健全性テストでは、さらにテストを進めることが妥当かどうかを判断します。
スモーク テストは、ソフトウェアを最小限の操作で実行し、ソフトウェアの動作を妨げる基本的な問題があるかどうかを判断することを目的としています。このようなテストは、ビルド検証テストとして使用できます。
回帰テスト
回帰テストは、大規模なコード変更が発生した後の欠陥を見つけることに重点を置いています。具体的には、古いバグが再発するなど、機能の低下や消失などのソフトウェアの回帰を明らかにしようとします。このような回帰は、以前は正しく動作していたソフトウェア機能が意図したとおりに動作しなくなったときに発生します。通常、回帰はプログラム変更の予期しない結果として、ソフトウェアの新しく開発された部分が既存のコードと衝突したときに発生します。回帰テストは、以前のソフトウェア機能の多数の詳細をチェックするため、通常、商用ソフトウェア開発における最大のテスト作業です。 [50]また、新しいソフトウェアを開発しながら、古いテストケースを使用して新しい設計の一部をテストし、以前の機能が引き続きサポートされていることを確認することもできます。
回帰テストの一般的な方法には、以前のテスト ケース セットを再実行し、以前に修正した障害が再発したかどうかを確認することが含まれます。テストの深さは、リリース プロセスのフェーズと追加された機能のリスクによって異なります。リリースの後半で追加された変更やリスクが高いと見なされる変更の場合は、テストは完全に行われますが、リリースの初期段階で変更が行われたり、リスクが低いと見なされる場合は、各機能に対する肯定的なテストで構成される非常に浅いテストになります。
受け入れテスト
受け入れテストは、ソフトウェアが顧客の期待に応えているかどうかを確認するためのシステムレベルのテストです。[51] [52] [53] [54]
受け入れテストは、開発の任意の 2 つのフェーズ間の引き継ぎプロセスの一部として実行される場合があります。[引用が必要]
テストは、ソフトウェア開発プロセスの中で実行される場所やテストの特殊性のレベルによって、これらのレベルにグループ化されることが多い。[54]
- ユーザー受け入れテスト (UAT)
- 運用受け入れテスト (OAT)
- 契約および規制上の受入テスト
- アルファテストとベータテスト
場合によっては、UAT は顧客自身の環境とハードウェア上で実行されることもあります。
OAT は、品質管理システムの一環として、製品、サービス、またはシステムの運用準備 (リリース前) を実施するために使用されます。OAT は、ソフトウェア開発およびソフトウェア保守プロジェクトで主に使用されている、一般的なタイプの非機能ソフトウェア テストです。このタイプのテストは、サポートされるシステム、または実稼働環境の一部となるシステムの運用準備に重点を置いています。そのため、運用準備テスト (ORT) または運用準備および保証(OR&A) テストとも呼ばれます。OAT内の機能テストは、システムの 非機能面を検証するために必要なテストに限定されます。
さらに、ソフトウェアテストでは、システムの移植性が期待通りに機能するだけでなく、動作環境に損傷を与えたり部分的に破損したり、その環境内の他のプロセスが動作しなくなったりしないことを確認する必要があります。[55]
契約上の受け入れテストは契約締結時に定められた契約上の受け入れ基準に基づいて実施され、規制上の受け入れテストはソフトウェア製品に関連する規制に基づいて実施されます。これら2つのテストはどちらもユーザーまたは独立したテスターによって実施できます。規制上の受け入れテストでは、規制機関がテスト結果を監査することもあります。[54]
アルファテスト
アルファテストは、潜在的なユーザー/顧客または開発者のサイトでの独立したテストチームによるシミュレーションまたは実際の運用テストです。アルファテストは、ソフトウェアがベータテストに進む前に、内部受け入れテストの一形態として市販のソフトウェアによく使用されます。[56]
ベータテスト
ベータテストはアルファテストの後に行われ、外部ユーザー受け入れテストの一種と考えることができます。ベータ版と呼ばれるソフトウェアのバージョンは、ベータテスターと呼ばれるプログラミングチーム外の限られたユーザー向けにリリースされます。ソフトウェアはグループにリリースされ、さらなるテストによって製品に欠陥やバグがほとんどないことを確認できます。ベータ版は、フィードバックフィールドを将来のユーザー最大数に増やし、より早く価値を提供するために、長期間または無期限（永久ベータ）で一般に公開することができます。[57]
機能テストと非機能テスト
機能テストとは、コードの特定のアクションまたは機能を検証するアクティビティを指します。これらは通常、コード要件ドキュメントに記載されていますが、一部の開発手法はユースケースまたはユーザー ストーリーに基づいて機能します。機能テストは、「ユーザーはこれを実行できるか」または「この特定の機能は動作するか」という質問に答える傾向があります。
非機能テストとは、スケーラビリティやその他のパフォーマンス、特定の制約下での動作、セキュリティなど、特定の機能やユーザー アクションに関連しない可能性のあるソフトウェアの側面を指します。テストでは、スケーラビリティやパフォーマンスが極端になると実行が不安定になる限界点を特定します。非機能要件は、特にユーザーの適合性の観点から、製品の品質を反映する要件になる傾向があります。
継続的テスト
継続的テストとは、ソフトウェア配信パイプラインの一部として自動テストを実行し、ソフトウェアリリース候補に関連するビジネスリスクに関する即時のフィードバックを得るプロセスです。 [58] [59]継続的テストには、機能要件と非機能要件の両方の検証が含まれます。テストの範囲は、ボトムアップ要件またはユーザーストーリーの検証から、包括的なビジネス目標に関連するシステム要件の評価にまで及びます。[60] [61]
破壊試験
破壊的テストは、ソフトウェアまたはサブシステムに障害を発生させることを試みます。無効または予期しない入力を受け取った場合でもソフトウェアが適切に機能することを検証し、入力検証およびエラー管理ルーチンの堅牢性を確立します。 [要出典] ファジング形式のソフトウェア障害注入は、障害テストの一例です。ソフトウェア障害注入ページには、さまざまな商用の非機能テストツールへのリンクがあります。また、破壊的テストを実行するオープンソースおよび無料のソフトウェアツールも多数あります。
ソフトウェアパフォーマンステスト
パフォーマンス テストは、通常、特定のワークロードにおけるシステムまたはサブシステムの応答性と安定性のパフォーマンスを判断するために実行されます。また、スケーラビリティ、信頼性、リソース使用率など、システムのその他の品質属性を調査、測定、検証、または確認するためにも使用できます。
負荷テストは主に、大量のデータや多数のユーザーなど、特定の負荷の下でシステムが動作し続けることができるかどうかをテストすることに関係しています。これは通常、ソフトウェアのスケーラビリティと呼ばれます。非機能アクティビティとして実行される関連する負荷テスト アクティビティは、多くの場合、耐久テストと呼ばれます。ボリューム テストは、特定のコンポーネント (ファイルやデータベースなど) のサイズが大幅に増加した場合でもソフトウェア機能をテストする方法です。ストレス テストは、予期しないまたはまれなワークロード下での信頼性をテストする方法です。安定性テスト(多くの場合、負荷テストまたは耐久テストと呼ばれます) は、ソフトウェアが許容期間内またはそれ以上に継続的に正常に機能できるかどうかを確認します。
パフォーマンス テストの具体的な目標についてはほとんど合意が得られていません。負荷テスト、パフォーマンス テスト、スケーラビリティ テスト、ボリューム テストという用語は、多くの場合、同じ意味で使用されます。
リアルタイム ソフトウェアシステムには厳しいタイミング制約があります。タイミング制約が満たされているかどうかをテストするには、リアルタイム テストを使用します。
ユーザビリティテスト
ユーザビリティ テストは、ユーザー インターフェイスが使いやすく、理解しやすいかどうかを確認することです。主にアプリケーションの使用に関するものです。これは自動化できる種類のテストではありません。熟練したUI デザイナーによって監視される実際の人間のユーザーが必要です。
アクセシビリティテスト
アクセシビリティテストは、ソフトウェアが障害者にとってアクセス可能であることを確認するために行われます。一般的なウェブアクセシビリティテストには次のようなものがあります。
- フォントと背景色の色のコントラストが適切であることを確認する
- フォントサイズ
- マルチメディアコンテンツの代替テキスト
- マウスに加えてコンピューターのキーボードを使用してシステムを使用できる機能。
コンプライアンスのための共通基準
セキュリティテスト
機密データを処理するソフトウェアでは、ハッカーによるシステム侵入を防ぐためにセキュリティ テストが不可欠です。
国際標準化機構（ISO）はこれを「テスト項目および関連するデータと情報が、権限のない人物やシステムが使用、読み取り、変更できないように保護され、権限のある人物やシステムがアクセスを拒否されない程度を評価するために実施されるテストの種類」と定義しています。[62]
国際化とローカリゼーション
国際化とローカリゼーションのテストでは、ソフトウェアがさまざまな言語や地域で使用できることが検証されます。疑似ローカリゼーションのプロセスは、アプリケーションを別の言語に翻訳できるかどうかをテストし、ローカリゼーション プロセスによって製品に新しいバグが導入される可能性があるかどうかを容易に特定するために使用します。
グローバリゼーションテストでは、ソフトウェアが異なる通貨やタイムゾーンなどの新しい文化に適応しているかどうかを検証します。[63]
実際の人間の言語への翻訳もテストする必要があります。ローカリゼーションとグローバリゼーションの失敗には次のようなものがあります。
- 一部のメッセージは翻訳されていない可能性があります。
- ソフトウェアは、文脈を無視して文字列のリストを翻訳することによってローカライズされることが多く、翻訳者はあいまいなソース文字列に対して間違った翻訳を選択する可能性があります。
- プロジェクトが適切な調整なしに複数の人によって翻訳された場合、または翻訳者が不注意であった場合、技術用語に一貫性がなくなる可能性があります。
- 逐語的な翻訳は、対象言語では不適切、不自然、または技術的すぎるように聞こえる可能性があります。
- 元の言語の未翻訳メッセージはソース コードにハードコードされている可能性があり、そのため翻訳できません。
- 一部のメッセージは実行時に自動的に作成され、結果の文字列が文法的に正しくなかったり、機能的に間違っていたり、誤解を招いたり、混乱を招いたりする可能性があります。
- ソフトウェアは、ソース言語のキーボード レイアウトでは機能しないが、ターゲット言語のレイアウトで文字を入力するために使用されるキーボード ショートカットを使用することがあります。
- ソフトウェアはターゲット言語の文字エンコードをサポートしていない可能性があります。
- ソース言語で適切なフォントとフォント サイズが、ターゲット言語では不適切である場合があります。たとえば、フォントが小さすぎると、CJK 文字が判読できなくなる場合があります。
- ターゲット言語の文字列がソフトウェアで処理できる長さを超えている可能性があります。これにより、文字列の一部がユーザーに見えなくなったり、ソフトウェアがクラッシュしたり誤動作したりする可能性があります。
- ソフトウェアには双方向テキストの読み取りまたは書き込みに対する適切なサポートがない可能性があります。
- ソフトウェアはローカライズされていないテキストを含む画像を表示する場合があります。
- ローカライズされたオペレーティング システムでは、システム構成ファイルや環境変数の名前が異なっていたり、日付や通貨の形式が異なっていたりする場合があります。
開発テスト
開発テストは、ソフトウェア開発のリスク、時間、コストを削減するために、幅広い欠陥防止および検出戦略を同期して適用するソフトウェア開発プロセスです。ソフトウェア開発ライフサイクルの構築フェーズでソフトウェア開発者またはエンジニアによって実行されます。開発テストの目的は、コードが他のテストに進められる前に構築エラーを排除することです。この戦略は、結果として得られるソフトウェアの品質と開発プロセス全体の効率を向上させることを目的としています。
組織のソフトウェア開発に対する期待に応じて、開発テストには、静的コード分析、データフロー分析、メトリック分析、ピアコードレビュー、ユニットテスト、コードカバレッジ分析、トレーサビリティ、およびその他のソフトウェアテストプラクティスが含まれる場合があります。
A/Bテスト
A/B テストは、提案された変更が現在のアプローチよりも効果的かどうかを判断するために、制御された実験を実行する方法です。顧客は、機能の現在のバージョン (コントロール) または変更されたバージョン (処理) のいずれかにルーティングされ、データが収集されて、どちらのバージョンが目的の結果を達成するのに優れているかが判断されます。
同時テスト
同時実行テストまたは同時実行性テストは、通常、通常の使用条件下で、同時実行コンピューティングを使用するソフトウェアおよびシステムの動作とパフォーマンスを評価します。このタイプのテストで明らかになる典型的な問題は、デッドロック、競合状態、共有メモリ/リソース処理に関する問題です。
適合性テストまたは型式テスト
ソフトウェア テストでは、適合性テストによって、製品が指定された標準に従って動作するかどうかが検証されます。たとえば、コンパイラは、その言語の公認標準を満たしているかどうかを判断するために、広範囲にテストされます。
出力比較テスト
テキストのデータ比較やUIのスクリーンショットなど、予想される出力を表示することを作成する[3] ：195は 、スナップショットテストまたはゴールデンマスターテストと呼ばれることもありますが、他の多くの形式のテストとは異なり、自動的に障害を検出することはできず、代わりに人間が出力の不一致を評価する必要があります。
特性テスト
プロパティ テストは、特定の入力が特定の期待される出力を生成することをアサートする代わりに、実行者がランダムに多数の入力を生成し、それらすべてに対してプログラムを実行し、すべての入力と出力のペアに対して真であるはずの「プロパティ」の真偽をアサートするテスト手法です。たとえば、シリアル化関数からのすべての出力は、対応するデシリアル化関数によって受け入れられる必要があり、ソート関数からのすべての出力は、その入力とまったく同じ要素を含む単調に増加するリストである必要があります。
プロパティ テスト ライブラリを使用すると、ユーザーはランダム入力を構築する戦略を制御して、テスト対象の実装の側面を完全に実行するために必要な、退化したケースや特定のパターンを特徴とする入力をカバーできるようになります。
プロパティテストは、HaskellライブラリQuickCheckによって導入され普及したため、「生成テスト」または「QuickCheckテスト」と呼ばれることもあります。[64]
変成テスト
メタモーフィック テスト (MT) は、プロパティ ベースのソフトウェア テスト手法であり、テスト オラクル問題とテスト ケース生成問題に対処するための効果的なアプローチとなります。テスト オラクル問題とは、選択したテスト ケースの期待される結果を判断したり、実際の出力が期待される結果と一致するかどうかを判断したりすることが難しいことです。
VCRテスト
VCR テストは、「再生テスト」または「記録/再生」テストとも呼ばれ、通信が遅いか信頼性が低いコンポーネント (多くの場合、テスト担当者の制御外にあるサードパーティ API) を含む回帰テストの信頼性と速度を向上させるためのテスト手法です。このテストでは、システムと外部コンポーネントのやり取りを記録し (「カセット」)、その後のテスト実行時に外部システムとの通信の代わりに記録されたやり取りを再生します。
この手法は、Ruby ライブラリ vcr によって Web 開発で普及しました。
チームワーク
役割
組織では、テスターはソフトウェア開発チームの他のメンバーとは別のチームに所属している場合もあれば、1 つのチームに統合されている場合もあります。ソフトウェア テストは、専任ではないソフトウェア テスターによって実行される場合もあります。
1980 年代には、ソフトウェア テスターという用語は、独立した職業を指すために使われるようになりました。
注目すべきソフトウェアテストの役割と肩書には、次のものがあります。[65] テストマネージャー、テストリーダー、テストアナリスト、テスト設計者、テスター、自動化開発者、テスト管理者。[66]
プロセス
ソフトウェアを開発する組織はそれぞれ異なる方法でテストを実行しますが、共通のパターンがあります。[2]
ウォーターフォール開発
ウォーターフォール開発では、テストは通常、コードが完成した後、製品が顧客に出荷される前に実行されます。[67]この方法では、テストフェーズがプロジェクトの遅延を補うためのプロジェクトバッファとして使用されることが多く、テストに費やされる時間が犠牲になります。[10] : 145–146
ウォーターフォールプロセスでは、開発プロジェクトの開始時にテストを開始し、プロジェクトが終了するまで継続的なプロセスにすることができると主張する人もいます。[68]
アジャイル開発
アジャイル ソフトウェア開発では、通常、コードの作成中にテストを実施し、プログラマーとテスターの両方でチームを編成し、チーム メンバーがプログラミングとテストの両方を実行します。
アジャイルプラクティスの1つであるテスト駆動型ソフトウェア開発（TDD）は、製品コードの作成中にユニットレベルのテストを実行するユニットテストの方法です。 [69]テストコードは、新機能が追加され、障害条件が発見される（バグが修正される）と更新されます。通常、ユニットテストコードはプロジェクトコードとともに維持され、ビルドプロセスに統合され、各ビルドで実行され、回帰テストの一部として実行されます。この継続的統合の目標は、開発をサポートし、欠陥を減らすことです。[70] [69]
プログラミングとテストの機能ごとにチームを分けている組織でも、多くの場合、プログラマーがユニットテストを実行します。[71]
サンプルプロセス
以下のサンプルはウォーターフォール開発に共通です。同じアクティビティは他の開発モデルでもよく見られますが、説明が異なる場合があります。
- 要件分析: テストは、ソフトウェア開発ライフサイクルの要件フェーズで開始する必要があります。設計フェーズでは、テスターは設計のどの側面がテスト可能か、またそれらのテストがどのようなパラメータで機能するかを判断します。
- テスト計画:テスト戦略、テスト計画、テストベッドの作成。テスト中には多くのアクティビティが実行されるため、計画が必要です。
- テスト開発:ソフトウェアのテストで使用するテスト手順、テスト シナリオ、テスト ケース、テスト データセット、テスト スクリプト。
- テスト実行: テスターは計画とテスト ドキュメントに基づいてソフトウェアを実行し、見つかったエラーを開発チームに報告します。プログラミングの知識が不足している状態でテストを実行する場合、この部分は複雑になる可能性があります。
- テスト レポート: テストが完了すると、テスターはメトリックを生成し、テスト作業とテストされたソフトウェアがリリースの準備ができているかどうかに関する最終レポートを作成します。
- テスト結果分析: または欠陥分析は、通常、開発チームがクライアントと一緒に実行し、どの欠陥を割り当てるか、修正するか、拒否するか (つまり、ソフトウェアが正常に動作しているかどうか)、または後で対処するために延期するかを決定します。
- 欠陥の再テスト: 開発チームによって欠陥が処理されると、テストチームによって再テストされます。
- 回帰テスト: 最新の配信によって何も損なわれず、ソフトウェア製品全体が引き続き正常に動作していることを確認するために、新規、変更、または修正されたソフトウェアの統合ごとに、テストのサブセットで構築された小さなテスト プログラムを用意するのが一般的です。
- テストの終了: テストが終了基準を満たすと、主要な出力、学んだ教訓、結果、ログ、プロジェクトに関連するドキュメントのキャプチャなどのアクティビティがアーカイブされ、将来のプロジェクトの参照として使用されます。
品質
ソフトウェアの検証と検証
ソフトウェアテストは検証と妥当性確認に関連して使用される：[72]
- 検証: ソフトウェアは正しく構築されていますか? (つまり、要件を実装していますか)。
- 検証: 適切なソフトウェアを構築しましたか? (つまり、成果物は顧客を満足させますか)。
検証と妥当性確認という用語は、業界では一般的に同じ意味で使用されていますが、この2つの用語が矛盾した定義で定義されているのもよく見られます。IEEE標準ソフトウェアエンジニアリング用語集によると：[11] ：80–81
- 検証とは、特定の開発フェーズの製品がそのフェーズの開始時に課された条件を満たしているかどうかを判断するために、システムまたはコンポーネントを評価するプロセスです。
- 検証とは、開発プロセス中または開発プロセスの最後にシステムまたはコンポーネントを評価し、指定された要件を満たしているかどうかを判断するプロセスです。
ISO 9000規格によれば、次のようになります。
- 検証とは、検査と客観的な証拠の提供を通じて、指定された要件が満たされていることを確認することです。
- 検証とは、特定の使用目的または用途の要件が満たされていることを検査および客観的な証拠の提供によって確認することです。
この矛盾は、要件と指定された要件という概念が異なる意味で使用されることによって発生します。
IEEE 標準の場合、検証の定義で言及されている指定要件は、ソフトウェアが解決し、満たさなければならない利害関係者の問題、ニーズ、要望のセットです。このような要件は、ソフトウェア要件仕様 (SRS) に文書化されています。また、検証の定義で言及されている成果物は、ソフトウェア開発プロセスの各フェーズの出力成果物です。これらの成果物は、実際には、アーキテクチャ設計仕様、詳細設計仕様などの仕様です。SRS も仕様ですが、検証できません (少なくともここで使用されている意味では検証できません。この件については後述します)。
しかし、ISO 9000 の場合、指定された要件は、上で述べたように、検証する必要がある仕様のセットです。仕様は、前述のように、別の仕様を入力として受け取るソフトウェア開発プロセス フェーズの成果物です。仕様は、入力仕様を正しく実装すると正常に検証されます。SRS は最初の仕様であるため、SRS を除くすべての仕様を検証できます (ただし、検証は可能です)。例: 設計仕様は SRS を実装する必要があります。また、構築フェーズの成果物は設計仕様を実装する必要があります。
したがって、これらの単語を共通の用語で定義すると、明らかな矛盾は消えます。
SRS とソフトウェアの両方を検証する必要があります。SRS は、関係者と相談して静的に検証できます。ただし、ソフトウェアの部分的な実装またはあらゆる種類のプロトタイプ (動的テスト) を実行し、関係者から肯定的なフィードバックを得ることで、SRS が正しく策定されているという確実性をさらに高めることができます。一方、最終的な実行中の製品としてのソフトウェア (ソース コードを含む成果物やドキュメントではありません) は、ソフトウェアを実行して関係者に試用してもらうことで、関係者とともに動的に検証する必要があります。
SRS の場合、入力は利害関係者の言葉であり、したがって SRS 検証は SRS 検証と同じであると主張する人もいるかもしれません。このように考えることは、混乱を招くだけなのでお勧めできません。検証は、正式かつ技術的な入力ドキュメントを含むプロセスであると考える方が適切です。
ソフトウェア品質保証
一部の組織では、ソフトウェアテストはソフトウェア品質保証(SQA) プロセスの一部です。 [3] : 347 SQA では、ソフトウェアプロセスの専門家と監査人は、ドキュメント、コード、システムなどの成果物だけでなく、ソフトウェア開発プロセスに関心を持っています。彼らはソフトウェアエンジニアリングプロセス自体を検査して変更し、納品されたソフトウェアに最終的に発生する欠陥の数、いわゆる欠陥率を減らします。許容できる欠陥率はソフトウェアの性質によって異なります。フライトシミュレータのビデオゲームは、実際の飛行機のソフトウェアよりもはるかに高い欠陥許容度を持っています。SQA と密接な関係がありますが、テスト部門は独立して存在することが多く、一部の企業では SQA 機能が存在しない場合があります。[要出典]
ソフトウェア テストは、品質に関する情報を利害関係者に提供するために、テスト対象のソフトウェアを調査する活動です。対照的に、QA (品質保証) は、欠陥が顧客に届かないようにするためのポリシーと手順の実装です。
対策
品質の測定には、正確性、完全性、セキュリティなどのトピックや、機能、信頼性、効率性、移植性、保守性、互換性、使いやすさなどのISO/IEC 9126要件が含まれます。
ソフトウェアの状態やテストの適切性を判断するのに役立つ、 頻繁に使用されるソフトウェア メトリック (測定基準)がいくつかあります。
遺物
ソフトウェア テスト プロセスでは、複数の成果物が生成されることがあります。実際に生成される成果物は、使用されるソフトウェア開発モデル、利害関係者、組織のニーズによって決まります。
テスト計画
テスト計画とは、意図したテスト活動に対して取られるアプローチを詳述した文書です。計画には、目的、範囲、プロセスと手順、人員要件、緊急時対応計画などの側面が含まれます。[51]テスト計画は、すべてのテスト タイプ (受け入れテスト計画やシステム テスト計画など) と計画上の考慮事項を含む単一の計画の形で提供される場合もあれば、複数の詳細なテスト計画の概要を示すマスター テスト計画 (計画の計画) として発行される場合もあります。[51]テスト計画は、全体的なテスト アプローチを文書化した広範な「テスト戦略」の一部となる場合もあり、それ自体がマスター テスト計画である場合もあれば、別の成果物である場合もあります。
トレーサビリティマトリックス
ソフトウェア開発
において、トレーサビリティマトリクス（TM）[73] : 244 は、通常表形式の文書であり、多対多の関係比較を使用して任意の2つのベースライン文書を相関させることにより、関係の完全性を判断するのに役立ちます。 [73] : 3–22 これは、製品の高レベル要件（マーケティング要件で構成されることが多い）と詳細要件を、高レベル設計、詳細設計、テスト計画、テストケースの対応する部分に使用することがよくあります。
テストケース
テストケースは通常、一意の識別子、設計仕様からの要件参照、前提条件、イベント、従うべき一連の手順 (アクションとも呼ばれる)、入力、出力、期待される結果、および実際の結果で構成されます。臨床的に定義すると、テスト ケースは入力と期待される結果です。[74]これは「条件 x の場合、導出された結果は y です」のように簡潔になることもありますが、通常、テスト ケースでは入力シナリオと期待される結果についてより詳細に説明します。テスト ケースは一連の手順になることもありますが (多くの場合、手順は、複数のテスト ケースに対して実行できる別のテスト手順に含まれており、これは経済性の問題です)、期待される結果または期待される成果は 1 つです。オプションのフィールドは、テスト ケース ID、テスト ステップ、または実行順序番号、関連する要件、深度、テスト カテゴリ、作成者、およびテストが自動化可能かどうか、および自動化されているかどうかを示すチェック ボックスです。大規模なテスト ケースには、前提条件の状態または手順、および説明も含まれる場合があります。テスト ケースには、実際の結果のための場所も含める必要があります。これらの手順は、ワードプロセッサ ドキュメント、スプレッドシート、データベース、またはその他の一般的なリポジトリに保存できます。データベース システムでは、過去のテスト結果、結果を生成したユーザー、およびそれらの結果を生成するために使用されたシステム構成を確認することもできます。これらの過去の結果は通常、別のテーブルに保存されます。
テストスクリプト
テストスクリプトは、ユーザー アクションを複製する手順またはプログラミング コードです。当初、この用語は、自動化された回帰テスト ツールによって作成された作業の成果物から派生しました。テスト ケースは、ツールまたはプログラムを使用してテスト スクリプトを作成するためのベースラインになります。
テストスイート
ソフトウェア開発
において、テストスイート（あまり一般的には検証スイートとも呼ばれる）は、ソフトウェアプログラムをテストして、特定の一連の動作を備えていることを示すためのテストケースの集まりです。 [75]テストスイートには、各テストケースのコレクションの詳細な指示や目標、テスト中に使用されるシステム構成に関する情報が含まれることがよくあります。テストケースのグループには、前提条件となる状態や手順、および後続のテストの説明も含まれる場合があります。
テストフィクスチャまたはテストデータ
ほとんどの場合、特定の機能の同じ機能をテストするために、複数の値またはデータ セットが使用されます。すべてのテスト値と変更可能な環境コンポーネントは、個別のファイルに収集され、テスト データとして保存されます。このデータをクライアントに提供したり、製品やプロジェクトに提供したりすることも有用です。テスト データを生成するための手法があります。
テストハーネス
ソフトウェア、ツール、データ入力と出力のサンプル、および構成はすべて、総称してテスト ハーネスと呼ばれます。
試運転
テスト実行とは、ユーザーが実行し、期待される結果と実際の結果を比較するテスト ケースまたはテスト スイートのコレクションです。完了すると、レポートまたは実行されたすべてのテストが生成される場合があります。
認定資格
ソフトウェア テスターや品質保証スペシャリストの専門職としての志をサポートする認定プログラムがいくつかあります。論争のセクションで述べたように、テスト分野はまだ認定の準備ができていないと主張する専門家もいます。
論争
ソフトウェア テストに関する主な論争には次のようなものがあります。
- アジャイル vs. 従来型
- テスターは不確実性と絶え間ない変化の条件下での作業を学ぶべきでしょうか、それともプロセスの「成熟」を目指すべきでしょうか？アジャイルテスト運動は2000年代初頭から主に商業界で人気が高まってきましたが[76] [77] 、政府や軍事[78]のソフトウェアプロバイダーはこの方法論だけでなく、従来のテストラストモデル（ウォーターフォールモデルなど）も使用しています。[要出典]
- 手動テストと自動テスト
- 一部の著者は、テスト自動化はその価値に比べて非常に高価であるため、控えめに使用すべきだと考えています。[79]テスト自動化は、要件を捕捉して実装する方法と見なすことができます。一般的なルールとして、システムが大きく複雑であるほど、テスト自動化のROIは高くなります。また、ツールと専門知識への投資は、組織内で適切なレベルの知識共有を行うことで、複数のプロジェクトに分散できます。
- ISO 29119ソフトウェア テスト標準の存在は正当化されますか?
- ISO 29119規格については、コンテキスト駆動型ソフトウェアテスト派から大きな反対意見が出た。国際ソフトウェアテスト協会などの専門テスト協会は、この規格の撤回を試みている。[80] [81]
- 一部の専門家は、テスト分野は認証の準備ができていないと主張している。
- [82]現在提供されている認定資格は、申請者にソフトウェアテスト能力を証明することを要求していません。広く受け入れられている知識体系に基づいた認定資格はありません。認定資格自体は、個人の生産性、スキル、実践的な知識を測定することはできず、テスターとしての能力やプロ意識を保証することもできません。[83]
- 欠陥の修正にかかる相対的な費用を示すために使用される研究
- 欠陥の導入と検出に応じて、欠陥を修正するための相対的な費用を示すために使用される研究の適用性については、相反する見解があります。たとえば、
欠陥が早期に発見されるほど、修正コストが安くなると一般に考えられています。次の表は、欠陥が発見された段階に応じて、欠陥を修正するコストを示しています。[84]たとえば、要件の問題がリリース後にのみ発見された場合、要件レビューですでに発見されていた場合よりも、修正に10～100倍のコストがかかります。現代の継続的デプロイメントプラクティスとクラウドベースのサービスの出現により、再デプロイメントとメンテナンスのコストは時間の経過とともに軽減される可能性があります。
この表の元になったデータは乏しい。ローラン・ボサヴィットは分析の中でこう述べている。
「小規模プロジェクト」の曲線は、1 年生の 2 チームのみから得られたものであることが判明しました。サンプル サイズが小さすぎるため、「小規模プロジェクト全般」に外挿することはまったく弁解の余地がありません。GTE の調査では、2 つのプロジェクト (1 つは大規模、もう 1 つは小規模) から得られたデータについて説明していません。ベル研究所の「セーフガード」プロジェクトについて引用されている論文では、ボームのデータ ポイントが示唆するきめ細かいデータを収集していないことを明確に否定しています。IBM の調査 (フェイガンの論文) には、ボームのグラフと矛盾しているように見える主張が含まれており、ボームのデータ ポイントに明確に一致する数値結果はありません。
ボームはTRWのデータについて論文を引用していないが、2010年に「Making Software」に寄稿した際は1976年のオリジナル論文を引用している。ボームが引用するのにちょうど良い時期にTRWで行われた大規模な調査は存在するが、その論文にはボームの主張を裏付けるようなデータは含まれていない。[85]
参照
- データ検証 – コンピュータのデータが正確かつ有用であることを確認するプロセス
- クロスブラウザテスト – さまざまなブラウザでWebアプリケーションをチェックする
- データベーステスト、データベースのテスト
- ドメインテスト
- 動的プログラム解析 – プログラム実行時に実行されるソフトウェアの解析
- 形式検証 – 特定のアルゴリズムの正しさを証明または反証すること
- グラフィカル ユーザー インターフェイス テスト – ソフトウェア エンジニアリング用語
- 独立したテスト組織 – 合意された要件に従ってテストを行う組織
- 手動テスト – 自動化なしでソフトウェアをテストする
- 直交表テスト - ソフトウェアテスト手法
- ペアテスト – ソフトウェアテスト手法
- 逆セマンティックトレーサビリティ – 品質管理技術
- ソフトウェアテスト戦略
- テスト管理ツール – テスト手順、テスト計画、レポートを保存します
- トレーステーブル – ソフトウェアテスト技術
- Webテスト – Webアプリケーションに重点を置いたソフトウェアテスト
参考文献
- ^ Kaner, Cem (2006 年 11 月 17 日)。探索的テスト(PDF)。Quality Assurance Institute Worldwide Annual Software Testing Conference。フロリダ州オーランド。2014年11 月 22 日閲覧。
- ^ ab Pan, Jiantao (1999年春)。「ソフトウェアテスト」(コースワーク)。カーネギーメロン大学。 2017年11月21日閲覧。
- ^ abcd Kaner, Cem ; Falk, Jack; Nguyen, Hung Quoc (1999). Testing Computer Software (第 2 版). ニューヨーク: John Wiley and Sons. ISBN 978-0-471-35846-6。
- ^ Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand ; Fiva, Arno (2007 年 9 月)。契約駆動開発 = テスト駆動開発 - テストケースの作成(PDF)。ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007。クロアチア、ドゥブロヴニク。2017年12 月 8 日閲覧。
- ^ ab Kolawa, Adam; Huizinga, Dorota (2007). 自動欠陥予防: ソフトウェア管理のベストプラクティス 。Wiley -IEEE Computer Society Press。ISBN 978-0-470-04212-0。
- ^ コーン、マイク (2009)。アジャイルで成功する: スクラムを使用したソフトウェア開発。Addison -Wesley Professional。ISBN 978-0321579362。
- ^ Molina, Alessandro (2021). Python によるテスト駆動型ソフトウェアの作成: Python と PyTest を使用して、アプリケーションのニーズと複雑さに合わせて拡張できるテスト スイートを作成します。Packt Publishing。ISBN 978-1838642655。
- ^ Fernandes da Costa 、 Lucas (2021)。JavaScriptアプリケーションのテスト。Manning。ISBN 978-1617297915。
- ^ 「ソフトウェアテストのための不十分なインフラストラクチャの経済的影響」(PDF)。米国国立標準技術研究所。2002 年 5 月。2017 年12 月 19 日閲覧。
- ^ abc Myers, Glenford J. (1979). ソフトウェアテストの芸術。John Wiley and Sons. ISBN 978-0-471-04328-7。
- ^ ab IEEE 標準ソフトウェアエンジニアリング用語集、IEEE、1990、doi :10.1109/IEEESTD.1990.101064、ISBN 978-1-55937-067-7
- ^ 「Certified Tester Foundation Level Syllabus」。International Software Testing Qualifications Board 。2011年3月31日。セクション1.1.2。 2017年10月28日時点のオリジナル(pdf)からアーカイブ。 2017年12月15日閲覧。
- ^ 「Certified Tester Foundation Level Syllabus」（PDF）。International Software Testing Qualifications Board 。2005年7月1日。原則2、セクション1.3。 2008年12月17日時点のオリジナル（PDF）からアーカイブ。2017年12月15日閲覧。
- ^ Ramler, Rudolf; Kopetzky, Theodorich; Platz, Wolfgang (2012 年 4 月 17 日)。TOSCAテストスイートでの組み合わせテスト設計: 学んだ教訓と実践的な影響。IEEE 第 5 回ソフトウェアテストおよび検証に関する国際会議 (ICST)。モントリオール、ケベック州、カナダ。doi :10.1109/ICST.2012.142 。
- ^ Kaner, Cem; Bach, James; Pettichord, Bret (2001).ソフトウェアテストで学んだ教訓: コンテキスト駆動型アプローチ. Wiley. pp. 31–43. ISBN 978-0-471-08112-8。
- ^ Kolawa, Adam; Huizinga, Dorota (2007).自動欠陥予防: ソフトウェア管理のベストプラクティス. Wiley-IEEE Computer Society Press. p. 74. ISBN 978-0-470-04212-0。
- ^ ロリー・V・オコナー;アッカヤ、マリエ・ウメイ。ケマネシ、ケレム。ユルマズ、ムラット。ポール、アレクサンダー。リチャード・メスナーツ（2015年10月15日）。システム、ソフトウェア、およびサービスのプロセス改善: 第 22 回欧州会議、EuroSPI 2015、アンカラ、トルコ、2015 年 9 月 30 日～10 月 2 日。議事録。スプリンガー。ISBN 978-3-319-24647-5。
- ^ Bourque, Pierre; Fairley, Richard E. 編 (2014)。「第 5 章」。ソフトウェア エンジニアリング知識体系ガイド。3.0。IEEE コンピュータ ソサエティ。ISBN 978-0-7695-5166-1. 2018年1月2日閲覧。
- ^ Bourque, P.; Fairley, RD, 編 (2014). 「第 4 章: ソフトウェア テスト」(PDF) . SWEBOK v3.0: ソフトウェア エンジニアリング知識体系ガイド. IEEE. pp. 4–1–4–17. ISBN 978-0-7695-5166-1. 2018年6月19日時点のオリジナル（PDF）よりアーカイブ。2018年7月13日閲覧。
- ^ Dooley, J. (2011). ソフトウェア開発と専門的実践. APress. pp. 193–4. ISBN 978-1-4302-3801-0。
- ^ Wiegers, K. (2013). ソフトウェアエンジニアリング文化の創造. Addison-Wesley. pp. 211–2. ISBN 978-0-13-348929-3。
- ^ Kolawa, Adam; Huizinga, Dorota (2007).自動欠陥予防: ソフトウェア管理のベストプラクティス. Wiley-IEEE Computer Society Press. p. 75. ISBN 978-0-470-04212-0。
- ^ ab グラハム、D.;ヴァン・ヴィーネンダール、E.エヴァンス、I. (2008)。ソフトウェアテストの基礎。センゲージ学習。 57～58ページ。ISBN 978-1-84480-989-9。
- ^ abcd Oberkampf, WL; Roy, CJ (2010). 科学計算における検証と妥当性確認。ケンブリッジ大学出版局。pp. 154–5。ISBN 978-1-139-49176-1。
- ^ Lee, D.; Netravali, AN; Sabnani, KK; Sugla, B.; John, A. (1997). 「パッシブテストとネットワーク管理への応用」。1997年国際ネットワークプロトコル会議議事録。IEEE Comput. Soc. pp. 113–122. doi :10.1109/icnp.1997.643699. ISBN 978-0-8186-8061-8. S2CID 42596126。
- ^ Cem Kaner、「探索的テストのチュートリアル」Wayback Machineに 2013-06-12 にアーカイブされました、p.2
- ^ Cem Kaner、「探索的テストのチュートリアル」、Wayback Machineに 2013-06-12 にアーカイブ、p. 36。
- ^ Lee, D.; Yannakakis, M. (1996). 「有限状態マシンのテストの原理と方法 - 概要」. Proceedings of the IEEE . 84 (8): 1090–1123. doi :10.1109/5.533956.
- ^ Petrenko, A.; Yevtushenko, N. (2011). 「非決定性 FSM によって指定された決定性実装の適応型テスト」。ソフトウェアとシステムのテスト: 第 23 回 IFIP WG 6.1 国際会議、ICTSS 2011、パリ、フランス、11 月 7 ～ 10 日。コンピュータ サイエンスの講義ノート。第 7019 巻。Springer Berlin Heidelberg。pp. 162 ～ 178。doi : 10.1007 /978-3-642-24580-0_12。ISBN 978-3-642-24579-4。
- ^ Petrenko, A.; Yevtushenko, N. (2014). 「FSM による非決定性システムの適応型テスト」。2014 IEEE 第15 回国際高保証システム エンジニアリング シンポジウム。IEEE。pp. 224–228。doi :10.1109 / HASE.2014.39。ISBN 978-1-4799-3466-9。
- ^ abcd Limaye, MG (2009). ソフトウェアテスト. Tata McGraw-Hill Education. pp. 108–11. ISBN 978-0-07-013990-9。
- ^ abcd Saleh, KA (2009). ソフトウェアエンジニアリング. J. Ross Publishing. pp. 224–41. ISBN 978-1-932159-94-3。
- ^ abc Ammann, P.; Offutt, J. (2016). ソフトウェアテスト入門. ケンブリッジ大学出版局. p. 26. ISBN 978-1-316-77312-3。
- ^ Everatt, GD; McLeod Jr., R. (2007). 「第 7 章: 機能テスト」。ソフトウェア テスト: ソフトウェア開発ライフサイクル全体にわたるテスト。John Wiley & Sons。pp. 99–121。ISBN 978-0-470-14634-7。
- ^ ab スティーブ・コーネット（1996年頃）。「コードカバレッジ分析」。ブルズアイテストテクノロジー。はじめに。 2017年11月21日閲覧。
- ^ ab Black, R. (2011). 実用的なソフトウェアテスト: 効果的で効率的なテストプロフェッショナルになる. John Wiley & Sons. pp. 44–6. ISBN 978-1-118-07938-6。
- ^ 簡単な例として、C関数は1 つのステートメントのみで構成されます。が選択されている場合を除き、仕様に対するすべてのテストは成功します。
int f(int x){return x*x-6*x+8;}f(x)>=0x=3 - ^ Patton, Ron (2005). ソフトウェアテスト (第2版). インディアナポリス: Sams Publishing. ISBN 978-0-672-32798-8。
- ^ Laycock, Gilbert T. (1993). 仕様ベースのソフトウェアテストの理論と実践(PDF) (博士論文).シェフィールド大学コンピュータサイエンス学部. 2018年1月2日閲覧。
- ^ Bach, James (1999 年 6 月). 「リスクと要件に基づくテスト」(PDF) . Computer . 32 (6): 113–114 . 2008 年8 月 19 日閲覧。
- ^ Mathur, AP (2011). ソフトウェアテストの基礎. ピアソン教育インド. p. 63. ISBN 978-81-317-5908-0。
- ^ ab Clapp, Judith A. (1995). ソフトウェア品質管理、エラー分析、テスト。ウィリアム・アンドリュー。p. 313。ISBN 978-0-8155-1363-6. 2018年1月5日閲覧。
- ^ Mathur, Aditya P. (2007). ソフトウェアテストの基礎. ピアソン教育インド. p. 18. ISBN 978-81-317-1660-1。
- ^ Lönnberg, Jan (2003年10月7日). ソフトウェアのビジュアルテスト(PDF) (修士論文). ヘルシンキ工科大学. 2012年1月13日閲覧。
- ^ Chima, Raspal. 「ビジュアルテスト」. TEST Magazine . 2012年7月24日時点のオリジナルよりアーカイブ。 2012年1月13日閲覧。
- ^ abc Lewis, WE (2016). ソフトウェアテストと継続的品質改善（第3版）. CRC Press. pp. 68–73. ISBN 978-1-4398-3436-7。
- ^ ab Ransome, J.; Misra, A. (2013). コアソフトウェアセキュリティ: ソースのセキュリティ。CRC Press。pp. 140–3。ISBN 978-1-4665-6095-6。
- ^ 「ブラック、ホワイト、グレーボックス向け SOA テスト ツール」(ホワイト ペーパー)。Crosscheck Networks。2018 年 10 月 1 日時点のオリジナルよりアーカイブ。2012 年12 月 10 日閲覧。
- ^ ab Myers, G. (2004). Sandler, C; Badgett, T; Thomas, M. (編).ソフトウェアテストの芸術(第 2 版). Wiley. ISBN 9780471469124。
- ^ Ammann, Paul; Offutt, Jeff (2008 年 1 月 28 日)。ソフトウェアテスト入門。ケンブリッジ大学出版局。p. 215。ISBN 978-0-521-88038-1. 2017年11月29日閲覧。
- ^ abc Lewis, WE (2016). ソフトウェアテストと継続的品質改善（第3版）. CRC Press. pp. 92–6. ISBN 978-1-4398-3436-7。
- ^ Machado, P.; Vincenzi, A.; Maldonado, JC (2010)。「第 1 章: ソフトウェア テスト: 概要」。Borba, P.; Cavalcanti, A.; Sampaio, A.; Woodcook, J. (編)。ソフトウェアエンジニアリングにおけるテスト手法。Springer Science & Business Media。pp. 13–14。ISBN 978-3-642-14334-2。
- ^ Clapp, JA; Stanten, SF; Peng, WW; et al. (1995). ソフトウェア品質管理、エラー分析、およびテスト。Nova Data Corporation。p. 254。ISBN 978-0-8155-1363-6。
- ^ abc 「ISTQB CTFL シラバス 2018」(PDF)。ISTQB - 国際ソフトウェアテスト資格委員会。 2022年3月24日時点のオリジナルよりアーカイブ(PDF) 。 2022年4月11日閲覧。
- ^ Woods, Anthony J. (2015 年 6 月 5 日)。「運用上の受け入れ - ISO 29119 ソフトウェア テスト標準の適用」(ホワイトペーパー)。Capgemini Australia。2018年1 月 9 日閲覧。
- ^ 「ソフトウェアテストで使用される用語の標準用語集」(PDF)。バージョン 3.1。国際ソフトウェアテスト資格委員会。2018年1 月 9 日閲覧。
- ^ O'Reilly, Tim (2005 年 9 月 30 日)。「Web 2.0 とは何か」。O'Reilly Media。セクション 4. ソフトウェア リリース サイクルの終了。2018年1 月 11 日閲覧。
- ^ Auerbach, Adam (2015 年 8 月 3 日)。「パイプラインの一部: 継続的テストが不可欠な理由」。TechWell Insights。TechWell Corp。2018年1 月 12 日閲覧。
- ^ Philipp-Edmonds, Cameron (2014 年 12 月 5 日)。「リスクと継続的テストの関係: Wayne Ariola 氏へのインタビュー」。Stickyminds。2018年1月 16 日閲覧。
- ^ Ariola, Wayne; Dunlop, Cynthia (2015 年 10 月)。DevOps: バグをより早くクライアントにプッシュしていますか? (PDF) 。Pacific Northwest Software Quality Conference。2018年1 月 16 日閲覧。
- ^ Auerbach, Adam (2014 年 10 月 2 日)。「Shift Left and Put Quality First」TechWell Insights。TechWell Corp. 2018 年1 月 16 日閲覧。
- ^ 「セクション 4.38」。ISO/IEC/IEEE 29119-1:2013 – ソフトウェアおよびシステムエンジニアリング – ソフトウェアテスト – パート 1 – 概念と定義。国際標準化機構。2018年1 月 17 日閲覧。
- ^ 「Globalization Step-by-Step: The World-Ready Approach to Testing. Microsoft Developer Network」。Microsoft Developer Network。2012 年 6 月 23 日時点のオリジナルよりアーカイブ。2012年1 月 13 日閲覧。
- ^ Claessen, Koen; Hughes, John (2000)。「QuickCheck」。第5 回 ACM SIGPLAN 国際関数型プログラミング会議の議事録。Icfp '00。pp. 268–279。doi :10.1145 / 351240.351266。ISBN 978-1-58113-202-1. S2CID 5668071。
- ^ Gelperin , David ; Hetzel, Bill (1988 年 6月1日)。「ソフトウェアテストの成長」。Communications of the ACM。31 ( 6): 687–695。doi : 10.1145/62959.62965。S2CID 14731341。
- ^ グレゴリー、ジャネット、クリスピン、リサ (2014)。『More Agile Testing』。Addison-Wesley Professional。pp. 23–39。ISBN 978-0-13-374956-4。
- ^ 「ソフトウェアテストライフサイクル」。etestinghub。ソフトウェアテストにおけるテストフェーズ。 2012年1月13日閲覧。
- ^ Dustin, Elfriede (2002). Effective Software Testing. Addison-Wesley Professional. p. 3. ISBN 978-0-201-79429-8.
- ^ a b "What is Test Driven Development (TDD)?". Agile Alliance. December 5, 2015. Retrieved March 17, 2018.
- ^ "Test-Driven Development and Continuous Integration for Mobile Applications". Microsoft Developer Network. January 14, 2009. Retrieved March 17, 2018.
- ^ Brown, Chris; Cobb, Gary; Culbertson, Robert (April 12, 2002). Introduction to Rapid Software Testing.
- ^ Tran, Eushiuan (1999). "Verification/Validation/Certification" (coursework). Carnegie Mellon University. Retrieved August 13, 2008.
- ^ a b Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (January 1, 2012). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (eds.). Software and Systems Traceability. Springer London. doi:10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
- ^ IEEE (1998). IEEE standard for software test documentation. New York: IEEE. ISBN 978-0-7381-1443-9.
- ^ Pinto, Leandro Sales; Sinha, Saurabh; Orso, Alessandro (November 11, 2012). "Understanding myths and realities of test-suite evolution". Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering. Association for Computing Machinery. pp. 1–11. doi:10.1145/2393596.2393634. ISBN 9781450316149. S2CID 9072512.
- ^ Strom, David (July 1, 2009). "We're All Part of the Story". Software Test & Performance Collaborative. Archived from the original on August 31, 2009.
- ^ Griffiths, M. (2005). "Teaching agile project management to the PMI". Agile Development Conference (ADC'05). ieee.org. pp. 318–322. doi:10.1109/ADC.2005.45. ISBN 978-0-7695-2487-0. S2CID 30322339.
- ^ Willison, John S. (April 2004). "Agile Software Development for an Agile Force". CrossTalk (April 2004). STSC. Archived from the original on October 29, 2005.
- ^ An example is Mark Fewster, Dorothy Graham: Software Test Automation. Addison Wesley, 1999, ISBN 978-0-201-33140-0.
- ^ "stop29119". commonsensetesting.org. Archived from the original on October 2, 2014.
- ^ Paul Krill (August 22, 2014). "Software testers balk at ISO 29119 standards proposal". InfoWorld.
- ^ Kaner, Cem (2001). "NSF grant proposal to 'lay a foundation for significant improvements in the quality of academic and commercial courses in software testing'" (PDF). Archived from the original (PDF) on November 27, 2009. Retrieved October 13, 2006.
- ^ Kaner, Cem (2003). Measuring the Effectiveness of Software Testers (PDF). STAR East. Archived from the original (PDF) on March 26, 2010. Retrieved January 18, 2018.
- ^ McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press. p. 29. ISBN 978-0-7356-1967-8.
- ^ Bossavit, Laurent (November 20, 2013). "The cost of defects: an illustrated history". The Leprechauns of Software Engineering: How folklore turns into fact and what to do about it. leanpub.
Further reading
- Meyer, Bertrand (August 2008). "Seven Principles of Software Testing" (PDF). Computer. Vol. 41, no. 8. pp. 99–101. doi:10.1109/MC.2008.306. Retrieved November 21, 2017.
External links
Wikimedia Commons has media related to Software testing.
At Wikiversity, you can learn more and teach others about Software testing at the Department of Software testing
- Software testing tools and products at Curlie
- "Software that makes Software better" Economist.com