「ソフトウェアテスト」の版間の差分
削除された内容 追加された内容
AdaYamamoto (会話 | 投稿記録) m編集の要約なし |
AdaYamamoto (会話 | 投稿記録) m 見出しを大文字化。英語が併記された用語に「英: 」を追加。 |
||
1行目:
{{ソフトウェア開発工程}}'''ソフトウェアテスト''' (
== 目的 ==
48行目:
仕様通りに動いているか、試験仕様に基づいて確認する試験を検証試験 (verification test)、[[エンドユーザー]]の意図通りに動いているかどうかを確認する試験を妥当性確認試験 (validation test) という。
=== 検証試験 (
決めた仕様に合致しているかどうかを試す試験。プログラミング言語、OS、通信規約、データベースなどの仕様に合致しているかどうかを試す試験を適合試験ということがある。
==== 適合試験 (
OS、プログラミング言語、ネットワーク通信プロトコル、データベースなどソフトウェアを動かすための基本的なプラットフォームが、仕様に適合しているかどうかを確認する検証試験 (verification test)。OSの国際規格の一つであるPOSIXでは、 [[アメリカ国立標準技術研究所|NIST]] が適合試験のソースコードを公開している<ref name="faq">{{cite web |date = 2006-07-07 |title = POSIX Test Suite (POSIX 1990 version)
|url = http://www.itl.nist.gov/div897/ctg/posix_form.htm |accessdate = 2014-08-08 }}</ref>。
自動車用OSの国際規格OSEKでは、MODISTARC (Methods and tools for the validation of OSEK/VDX based distributed architectures) がある。
TOPPERS OSでは、TTSP (TOPPERS Test Suite Package) というテスト環境を提供し、適合テスト等を実施しやすくしている<ref name="ttsp">{{cite web |date = 2014-08-08 |title = TTSP
|url = https://www.toppers.jp/ttsp.html |accessdate = 2014-08-08 }}</ref>。
プラットフォームの適合試験を実施せずに、[[アプリケーションソフトウェア]]の試験を実施すると、プラットフォーム仕様の変化に対応できていないことがある。
=== 妥当性確認試験 (
エンドユーザーが意図している動作をするかどうかを試験することを妥当性確認試験という。
性能試験、システム試験、受入試験の一部として実施することがある。
==上から (
全体が完成してからテストをすることを[[ビッグバン]]テストという。規模の小さな[[プログラム (コンピュータ)|プログラム]]であれば、この手法でうまくいく場合もある。この手法は大規模なプログラムに対して適当でない。なぜなら、大規模なプログラムを一気にテストをして問題が発生したときに、問題の原因を巨大なプログラム中から探すのが困難だからである。また、ソフトウェア中に複数のバグが存在する場合、それらのバグが相互に影響しあい、バグの原因の特定がさらに困難になる場合もある。そのため、ソフトウェアテストでは、最初に単体テストによってモジュール単位のテストを行う。単体テストの問題で、十分にモジュール単位のテストが終わったら、結合テストまたはシステムテストに進む。また、小規模なプログラムであっても、単体テストを行わずに結合テスト又はシステムテストへ入るのはテスト全体の効率を下げる。しかし、再利用性が高く、時間についての制約だけが中心の試験の場合は現場でビッグバンテストを行う場合がある。
=== 下降試験 (
単体テストおよび結合テストにおける手法の一つ。単体テストが完了した[[モジュール]]のうち、上位モジュールから順に結合させてテストを行なう。この手法の利点は、仕様的な振る舞いを決定する上位モジュールを早期に検証することによって、機能漏れ、仕様の認識違いなどの致命的な不具合を、開発の早い段階で発見できることにある。一方で、数の多い下位モジュールの検証が先送りされるため、開発と平行してテストを進めにくいという欠点もある。
* トップダウンテストを行う際には「[[ソフトウェアテスト#テスト代替 (Test Doubles)|テストスタブ]]」を用意しなければならない。
=== 上昇試験 (
単体テストおよび結合テストにおける手法の一つ。トップダウンテストとは逆に、単体テストが完了した下位モジュールから順に結合させてテストを行なう。この手法の利点は、数が多く独立性の高い下位モジュールから順に検証することで、開発とテストを平行して実施できることにある。一方で、システムの根幹となる上位モジュールで不具合が発見された場合、テストが完了したはずの下位モジュールも影響を受けるという欠点も持っている。単体試験を行う場合に、他の関数等を呼び出している関数を試験する場合に、呼出のない関数を試験してから、呼出をしている試験を行う場合にボトムアップテストになっている。
* ボトムアップテストを行う際には「[[ソフトウェアテスト#テスト代替 (Test Doubles)|テストドライバ]]」を用意しなければならない。
== ホワイトボックステストとブラックボックステスト ==
[[プログラム (コンピュータ)|プログラム]]の内部構造に注目したテストを[[ホワイトボックステスト]] (英: {{Lang|en|white box test}})、プログラムの入力と出力に注目したテストを[[ブラックボックステスト]] (英: {{Lang|en|black box test}}) という。
=== ホワイトボックステスト (white box test) ===
{{main|ホワイトボックステスト}}
ホワイトボックステスト (英: white box test) は、[[プログラム (コンピュータ)|プログラム]]の構造に着目したソフトウェアテストのことである。着目する構造には命令や分岐などがあり、注目した構造に対してどれだけの割合の部分を実行できたかを[[コード網羅率|網羅率]]で表す。
<syntaxhighlight lang="c" line>
90行目:
</syntaxhighlight><!-- この実装はINT_MINを渡すと破たんする。本質ではないので省略。 -->
==== 命令網羅 (
命令網羅基準を用いてテストを行う場合は、すべての命令を実行すればよい<ref name="myers1979">G. J. Myers『ソフトウェアテストの技法』近代科学社 1980年</ref><ref name="ITmedia">{{cite web|url=http://www.itmedia.co.jp/im/articles/1111/07/news142.html
|title=情報システム用語事典：カバレッジ基準 |publisher=ITmedia|accessdate=2016-04-17}}</ref>。上記のabs関数では、<code>x = -1</code> を用いてテストすれば命令網羅基準に従ってテストできたことになる。
==== 分岐網羅 (
判定条件網羅 (英: decision coverage) とも。分岐網羅基準を用いてテストを行う場合は、すべての分岐において、すべての分岐の方向を実行すればよい<ref name="myers1979" /><ref name="ITmedia" />。上記のabs関数では、<code>x = -1</code>と<code>x = 0</code>を用いてそれぞれテストすれば、分岐網羅基準にしたがってテストできたことになる。分岐網羅は命令網羅の基準を満たす<ref name="myers1979" />。
==== 条件網羅 (
条件網羅基準を用いてテストを行う場合は、各々の個別条件について、全ての可能な結果を少なくとも1回はとるように実行すればよい<ref name="myers1979" /><ref name="ITmedia" />。条件網羅基準は分岐の方向を意識しないため、分岐網羅・命令網羅の基準を満たさないことがある<ref name="myers1979" />。
109行目:
# <code>x <= 0</code> かつ <code>y <= 0</code>
==== 判定条件／条件網羅 (
判定条件／条件網羅基準を用いてテストを行う場合は、各々の個別条件について全ての結果を少なくとも1回はとるようにし、かつ各々の分岐について全ての分岐の方向を実行すればよい<ref name="myers1979" /><ref name="ITmedia" />。
==== 複合条件網羅 (
複合条件網羅基準を用いてテストを行う場合は、それぞれの判定における全ての結果の全ての可能な組み合わせを少なくとも1回はとるように実行すればよい<ref name="myers1979" /><ref name="ITmedia" />。ただし、ある組み合わせは作ることが不可能である場合がある。たとえば、条件 (A > 2) と (A < 10) とでは、可能な組み合わせは3つしかない<ref name="myers1979" />。
==== 経路網羅 (
経路網羅基準を用いてテストを行う場合は、すべての経路が少なくとも1回はとるように実行すればよい<ref name="myers1979" /><ref name="ITmedia" />。反復構造を持つプログラムの全ての経路を特定することは普通は不可能であるから、この場合、完全な経路網羅は実行可能な目標とは考えられない<ref name="myers1979" />。
=== ブラックボックステスト (
{{main|ブラックボックステスト}}
[[File:Blackbox.svg|thumb|200px|[[ブラックボックス]][[ダイアグラム]]]]
ブラックボックステスト (英: black box test) は、[[プログラム (コンピュータ)|プログラム]]の[[入出力]]だけに注目し仕様通りにプログラムが動作するか（もしくは仕様通りに動作しないか）をテストする。プログラムの入力が単一の値である場合は同値分割や限界値分析を、プログラムの入力が複数あり相互に影響を与えるような場合は[[決定表]]や原因結果グラフなどを用いて入力を決定する。大域変数の読み書き、通信、割り込みなどが処理中にある場合には、それらも入出力の一つとして扱う。
==== 同値分割 ====
179行目:
=== 単体試験 (Unit Test) ===
{{Main|単体テスト}}
単体試験 (英: unit test) は、関数、メソッドなどの小さな単位で行うテストのことである。単体テストは、関数の場合には基本はブラックボックステストである。ブラックボックステストが済んだものの品質を確保するためにホワイトボックステストを行う。「{{Lang|en|Unit Testing}}」の略である「UT」と呼ぶことがある。また、開発現場によっては「CT（和製: {{Lang|en|Coding Test}}）」や「PT（和製: {{Lang|en|Program Test}}）」と略すこともある。
単体試験の道具としてJavaではテスティング[[アプリケーションフレームワーク|フレームワーク]][[JUnit]]が有名である。これは[[Java]]専用である。他の言語にも同様のものがあり、それらを総称して[[xUnit]]と呼んでいる。
185行目:
=== 統合試験 ({{Lang|en|Integration Testing}}) ===
{{Main|統合テスト}}
統合試験 (英: integration testing) は、単体試験が完了したプログラムを組み合わせて行うテストである。プログラムのどの部分から組み合わせていくかで、トップダウンテスト
統合試験とシステム試験を分ける場合もある。統合試験とシステム試験を分ける場合に、模擬試験 (英: simulation) を統合試験に分類する場合と、システム試験に分類する場合がある。
=== システムテスト (System Testing) ===
194行目:
=== 受入試験 (Acceptance Test) ===
{{Main|受け入れテスト}}
受入試験 (英: acceptance test) は、検収テスト、承認テストとも呼ぶこともある。受入試験は、システムを受け入れるかどうかを判定する試験である。システムの実際の利用者が行う場合と受け入れ試験をシステム運用・保守会社が実施する場合がある。システムが仕様通りの機能や性能を備えているかどうか確認する検証試験だけの場合と、システムが利用者の意図通りに動くかどうかを確認する妥当性試験を含む場合がある。
== アルファテスト、ベータテスト ==
200行目:
== テスト代替 (Test Doubles) ==
単体テストや結合テストを行う際に、テスト対象の[[プログラム (コンピュータ)|プログラム]]を呼び出すためのプログラムや、テスト対象のプログラムが利用しているプログラムがまだ使えない（もしくは、テストが完了していないため使うべきでない）場合がある。このような場合に、テスト対象のプログラムを呼び出すためのプログラムを'''テストドライバ''' (英: {{Lang|en|test driver}})、テスト対象のプログラムが利用しているプログラムの代替となるプログラムを'''テスト[[スタブ]]''' (英: {{Lang|en|test stub}}) という。
<syntaxhighlight lang="c">
235行目:
== 回帰試験 (Regression Test) ==
{{Main|回帰テスト}}
[[プログラム (コンピュータ)|プログラム]]を修正・変更した場合に、過去に実施したテストを再度実施することを回帰試験 (英: [[:en:Regression_testing|regression test]]) 又は退行テストという。修正前の試験に再度合格するかどうか、他の機能に影響与えていないかどうか、他の機能が動作するかどうかを確認する。過去のテスト資産を使い、実施する回数も多いことから、実施を省略することがないように[[テスト自動化]]することにより効率化を図る。
回帰試験にて、テストする範囲を全[[テストケース]]とするか、(全テストケースを実施した場合に要する時間や工数と修正が及ぼす範囲を考慮して)部分テストケースとするか判断し、また、欠陥を検出する頻度を考慮して高い優先度で実施するテストケースを選択する方法がある。{{要出典範囲|一方で、アジャイル開発手法を選択した場合、ソフトウェアの更新頻度も仕様変更頻度も共に高くなることが見込まれるため、特に開発期間が短いアジャイル開発手法においては、回帰試験が多くの不必要なオーバーヘッドになる可能性がある。回帰試験をサードパーティーに委託する場合、あるいは、ソフトウェアの一部がサードパーティーによって開発される場合、必ずしも修正が及ぼす範囲が判断できるわけではないので、テストする範囲は全テストケースと成らざるを得ない。|date=2022-07-06}}
| |||