この1冊でよくわかる【ソフトウェアテストの教科書】
(1)ソフトウェアとは？
コンピュータが理解できる命令形式(プログラミング言語)で記述された 「コンピューターを動作させるためのプログラム」であり、「命令文をコンピューターに実行させたい順番に並べて記述した文章」
テストを行う際は設計書や仕様書といったドキュメントに目を通すが、この時は、各ドキュメントに書かれている文面を自分の理解内で直結するのではなく、設計書や開発者の真の意図を理解する必要がある。
求められる品質意識
当たり前品質：
当たり前品質とはユーザーの基本要求を満たす品質です。基本要求とはユーザーが「これだけは絶対に満たしてほしい」と考えるもの。不充足の場合は不満に感じる機能。
洗濯機で例えると、「洗濯物がきれいになることなので」洗浄力を向上させる努力を続けること
一元的品質：
一元的品質とは、充足されていると満足し、不足しているとユーザーの評価が落ちる。
洗濯機で例えると、静音機能、節水、節電機能、洗濯の取り出しが容易なデザインなど
魅力的品質：
魅力的機能とは充足されていると満足し不充足の場合は「仕方ない」と感じる機能。
つまり、ユーザーの期待を上回るもの、実現すればユーザーに大きな満足を与えれるもの。
洗濯機で例えると、「確実にシミを抜いてくれる機能」
↓図
品質要素 充足 不充足
当たり前品質 当たり前 不満
一元的品質 満足 不満
魅力的品質 満足 仕方がない
ソフトウェアの欠落を減らすために、テストをすることは重要です。
しかしそれだけでは十分ではありません。
開発仕様上では欠陥に分類されないものでも、ユーザーが不満に感じると考えられるものは欠陥として拾い上げて、品質を高めるべくはたらきかけることが重要
(2)Never、Must、Want
テストを実行する際の以下の視点を持つことが重要
Neverあってはならないこと
Mustできなければならないこと
Wantできたら良いこと
(Never)
そのテスト対象を使用する上で絶対に起こってはいけないこと。
人の生命や財産に影響を及ぼすような事態。
例えば。
- 携帯電話のバッテリーが異常に発熱する
- 会員情報が漏洩する
- 商品購入サイトで金額の合計が間違ってる
(Must)
テストを対象する上でできなければならないこと。
ユーザーが思った通りに要求を達成できるかどうかを確認。
リリースの目玉機能などもここに含まれる
(Want)
できたらいいなと思うもの。
テストを実施する際にテストケースを実行することに意識がいきがちですが
「仕様通りではあるが改善した方が良い点」や「ユーザービリティへの気づき」などがあれば積極的にメモなど記録して残しておくべき。
(3)【ウォーターフォール型の一連の流れ】
ウォータフォール型：1つの工程が完了してから次の工程を開始する。
↓
要求定義：顧客のニーズや、ソフトウェア搭載製品の企画担当者が頭に描く要望を企画書やヒアリングによって引き出した上で分かりやすく整理し最終的に要求として定義すること
↓
基本設計：「画面をどのような構成にするか(画面設計)」や「何種類の機能を用意するのか」を決定する
・この段階で「基本設計書」と「機能仕様書」が作られる。
↓
詳細設計：基本設計で定義した仕様をもとにコーディングに必要な各処理の使用を決定する。
モジュールとはソフトウェアの最小単位です。
連結方法(モジュール間のデータの受け渡し方法)についても詳細設計で決定します。
決定された事項を仕様として記述すると詳細設計書が作成される。
↓
コーディング：詳細設計が完了したら実際にコンピューターが人間の意図した通りに動作するようにソフトウェアを作成。この工程を「コーディング」と言います。
テスト工程
ウォーターフォール型開発モデルではテストは１つの工程にまとめられているが、実際にはいくつかの工程に分かれている。
単体テスト：ソフトウェアの最小単位である「モジュール」ごとに行うテスト
主に詳細設計どおりにモジュールが動くかどうかをテストする。
単体テストはコーディングを行ったプログラマ自身が担当します。
↓
結合テスト：複数のモジュールを含めて動作を確認するテスト
機能テスト：組み合わせたモジュールを１つの機能としてテスト
この場合内部構造を確かめるのではなく、「機能として正しく役割を果たしているか」を確認
↓
システムテスト：要求定義の内容が実現されているかを確認するテスト。
テストは要求定義書に基づいて、製品として出荷する状態。もしくはサービスとして提供する状態に近づける。
(4)ホワイトボックステストとブラックボックステストについて
【2種類のテスト】
ブラックボックスとは：実態のある機械装置において、原理や機械を知らなくてもその機械装置の働きを理解でき、利用できること。
ホワイトボックスとは：機械装置があたかも透明の箱に収めらていてて内部構造が外側から見えているような状態のこと(原理や機械を認識できる状態)
【ホワイトボックステストとは】
ホワイトボックステスト：ソフトウェアの最小単位であるモジュールの一つひとつを対象とした単体テストで用いられています。
- 命令文の処理順序を確認する「制御フローテスト」とデーターの流れを理解する「データフローテスト」の2種類があります。
- ホワイトボックステストを行うメリットは、モジュール内部の処理(命令文)単位で動作確認を行える点です。また、単体テストのホワイトボックステストによって検出された欠陥は、その原因箇所はモジュール内部に限定されるため、そのモジュールを調査・変更するだけで修正を完了することができます。
【モジュールと論理構造】
- ホワイトボックステストは、ソフトウェアの論理構造を確認するために実施するため、テスト担当者は事前に「論理構造とは何か」について正しく理解しておく必要があります。各モジュールには、必要とされる計算結果を得るために複数の処理が含まれていますが、この処理の流れや実行順序のことを「論理構造」と呼びます。論理構造に誤りがあると、モジュールが正常に動作しないばかりか、そのモジュールを他のモジュールと組み合わせた際に数多くの問題を引き起こすことになります。
例：このモジュールは合計金額と人数を元に1人当たりの割勘額を算出する
モジュールの中ではA~Fの順番に実行する。(数字以外の文字が入力された場合については考えなくてよいものとします)
A：合計金額を入力する
B：入力された金額が0ならば処理Aに戻る
C：人数を入力する
D：入力された人数が0ならば処理Cに戻る
E：割勘額(合計金額➗人数)を計算する
F：計算結果を表示する
このモジュールでは、各処理の実行順序が変わると適切な結果が得られなくなる場合があります。下記のように処理の実行順序を変更してみます。
A：合計金額を入力する
C：人数を入力する
E：割勘額(合計金額➗人数)を計算する
B：入力された金額が0ならば処理Aに戻る
D：入力された人数が0ならば処理Cに戻る
F：計算結果を表示する
ここでは処理Eの計算結果を合計金額と人数入力の直後に移動しました。そして0(ゼロ)が入力された場合の処理Bと処理Dを、処理Eの後に移動しました。
このモジュールは、正しい合計金額と人数が入力された場合は問題なく処理を進めることができますが、処理Cで0が入力された場合、ゼロ除算が起きてしまうため処理を進めることができなくなります。
各行の処理自体に誤りがなくても、その順番を誤るとモジュール全体での正しい処理は実行できなくなります。このような場合に「モジュールの論理構造に誤りがある」と言います。
なお、正しい結果を導き出すモジュールの論理構造が常に1つだけになるとは限りません。
何通りもの異なる論理構造を用いて同じ結果を出すこともできます。
【論理構造の視覚化】
ホワイトボックステストを効率的に行うには、テストする際に「モジュールの論理構造」を明示する必要があります。
ソースコードのままでは把握しにくい「条件分岐命令などで処理が複数行後に進む場合」や「繰り返し命令などで処理が複数行前に戻る場合」にフローチャートによる処理の視覚化は効果的です。
ホワイトボックステストを確実に行いたいのであれば、フローチャートを描くようにしましょう。しかし数百行のソースコードをフローチャート化するにもそれなりの労力をつかいます・
【制御フローテストの実施方法】
制御フローテストでは、モジュールを構成する要素である「命令文」「分岐した経路」「条件」のいずれかに着目してすべて実行されるか確認します。
以下の手順で行う。(細かな詳細は書籍)
(1) ソースコードをもとにして、フローチャートを書く
(2) カバレッジ基準(網羅したい要素)を決める
(3) カバレッジ基準を網羅する経路を抽出する
(4) 抽出した経路を通るようにテストを行う
(5) 結果を確かめる
[ステートメントカバレッジ]
制御フローテストで着目する要素に「命令文」を選択した場合、それを「ステートメントカバレッジ」と呼びます。この場合は、すべての命令文を最低1度は通すようにします。
[ステートメントカバレッジ]
- 制御フローテストで着目する要素に「命令文」を選択した場合はそれを「ステートメントカバレッジ」と呼ぶ。全ての命令文を最低1度は通るようにテストする。
[デシジョンカバレッジ]
- 制御フローテストで着目する際に「分岐した経路」を選択した場合、それを「デジションカバレッジ」と呼びます。デジションとは判定です。
[複合条件カバレッジ]
- 制御フローテストで着目する要素に「条件」を選択した場合、それを「複合条件カバレッジ」と呼びます。このカバレッジ基準は論理(And)や論理和(Or)で結ばれた複合条件が設定されている際に利用。ここでは「火曜日は女性に限り3割引」というレディースデーの条件が複合条件になります。
[カバレッジレベルの違い]
-
カバレッジを3種類実施しましたが実際にテストをする際にどの基準を採用すれば良いのか？カバレッジ基準事に「カバレッジ100%」を達成するために必要なテスト回数が異なります。
-
カバレッジ基準はそれぞれ異なる点に着目していることから無関係に見えるが3種類のカバレッジ基準は上位のカバレッジ基準が下位のカバレッジ基準を包含する関係にあります。
【ブラックボックステストとは】
- ブラックボックステストとは：ホワイトボックスを用いた単体テストが終わると続いて、ソフトウェアの内部構造を意識しない「ブラックボックステスト」を行います。
- ブラックボックステストは主に機能テストとシステムテストを実施
(5)さまざまなテスト技法
【同値分割テスト・境界値テストについて】
- 同値分割テストと境界値テストはどちらも「ソフトウェアの動作が変わる条件の境目」に注目するテスト技法です。一般的に欠陥は条件の境目付近に潜んでいる可能性が高い。
【同値分割テスト】
- 同値分割テストとは：同値パーティション(同じ動作をする条件の集まり)ごとにテストを行う技法。
- 4~15文字の同値パーティションは設定可能な文字数であることから「有効同値パーティション」
3文字以下または16文字以上の同値パーティションは設定不可なので「無効同値パーティション」と呼ぶ
【同値分割テストの実施方法】
- 同値分割テストは各同値のパーティションから最低1つの代表値を選んでテストを行う
- 有効同値→設定可能な9文字を使用
無効同値→設定不可な2文字を使用
代表値には範囲の中間値を選択することが多く、この場合は9。
パスワードの場合は文字数が多いよりも少なすぎる方が多いので2にしている。 - 同値分割テストは、テストの工数を減らす方法であり、1つの基準を示す考え方です
【境界値テストとは】
- 境界値テストとは：仕様条件の境界となる値とその隣の値に対してテストを行うテスト技法
境界値に着目する理由は、欠陥は境界に潜んでる可能性が高いため。
(6)【状態遷移図と状態遷移表の特徴】
-
状態遷移図とは：ソフトウェアのできることを図に表し確認する方法。テストの目的が「開発仕様書どおりにソフトウェアが動作すること」や「ユーザーが使うシナリオを確認すること」
-
状態遷移表とは：「できること」に加え「できないはずのこと」も確認する方法です。開発仕様書に定義されていない、つまり使い方として想定されていない状態とイベントの組み合わせを含む、全ての遷移を網羅的に確認したい場合に適している。
(7)【テスト自動化】
テスト自動化とは：
人間が手作業で行なっているソフトウェアをコンピューターに実行させること
テストの自動化を行うツールのことを「テスト自動化ツール」と呼びます
テスト自動化の8原則とは？
- 手動テストはなくてはならない
- 手動でおこなって効果のないテストを自動化しても無駄である
- 自動テストは書いたことしかテストしない
- テスト自動化の効用はコスト削減だけではない
- 自動テストシステムの開発は継続的におこなうものである
- 自動検討はプロジェクト初期から
- 自動テストで新種のバグが見つかることは稀である
- テスト結果分析という新たなタスクが生まれる
テスト自動化のメリット・デメリット
メリット１：コストを抑えたリスクヘッジができる
- テスト自動化を導入すれば、ソフトウェア全体の品質保証が低コストで実現できる
メリット2：問題点をすぐ発見できる
- 自動テストを活用することで、正確な作業によって問題点の早期発見が実現します。
デメリット1：かえってコストが増える可能性がある
- 自動テストは開発したら終わりではなく、導入後にもメンテナンスやアップデートが必要です。
全てを自動化しようとしない
- すべてを自動化の対象とすればよいわけでなく、目的に合わせた最適な範囲を検討する必要があります。
参考書籍