はじめに
会社のこれからの方向性の関係でソフトウェアのテストについて調べた備忘録になります。
ソフトウェアのテストとは？
今の社会はソフトウェアなしでは何も出来ません。
例えば個人のスマートフォンにはOSやアプリケーションが入っています。
また仕事で使うパソコンにもOSやアプリケーションが入っています。
そして最近ではインターネットにアクセスするブラウザで操作するWebアプリケーションがあります。
今はアプリからでもアクセスできますが、あなたはパソコンからはブラウザでSNSなどにアクセスしていないでしょうか？
SNSもWebアプリケーションの一種です。
また、ソフトウェアは上記以外にも以下のような物にも搭載されています。
- ATMなどの端末
- 車の制御
- 医療機器の制御
上記のようなソフトウェアが正しく動作しなかったらどうなるでしょうか？
「SNSなどに投稿できない」などであればまだ修正を待てば良いですが、「車を減速するプログラムが動作しない」や「医療機器が動作しない」などの問題が発生した場合は人命に関わります。
そのためソフトウェアはただ作るだけでなく、作った後正しく動作することを確認しなければなりません。
その動作確認のことをIT業界ではテストと呼んでいます。
テストの基本
ITの開発工程は一般的なウォーターフォール型の開発の場合以下の手順で進んでいきます。
- 要件定義
- 基本設計
- 構造設計
- 詳細設計
- 実装
- 単体テスト
- 結合テスト
- システムテスト
- 受け入れテスト
基本的には上記のような工程で進む場合は以下のように設計とテストが紐付いています。
- 詳細設計 - 単体テスト
- 構造設計 - 結合テスト
- 基本設計 - システムテスト
- 要件定義 - 受け入れテスト
一般的に受け入れテストはシステムを発注した会社が行うため、開発者が手を出すことはありません。
一方でそれ以外のテストについては開発するチームがテストを行う場合が多いです。
それぞれのテストについては以下のようになります。
単体テスト
単体テストでは主に作成した1つの機能や、細かいところでは作ったプログラムの1つのメソッド単位でテストを行います。
Javaを例に取った場合、JUnitというテストツールがあります。
これはメソッド単体でプログラムを動作させ、結果が期待値と合っているかを確認するツールになります。
このようなツールを使ってプログラムが正しく動作するかを検証していきます。
単体テストではJUnitを使用する際に、Javaでコーディングを行う必要があります。
結合テスト
結合テストは複数のモジュールや機能などを組み合わせて動作させ、問題がないことを確認します。
結合テストについては私は手動でプログラムを動作させ、結果を確認する事が多かったです。
システムテスト
システムテストはシステム全体を通して問題がないかや、外部システムとの連携、またアクセス数が非常に多い場合にしっかり動作するかなどの観点で行われるテストになります。
受け入れテスト
これはシステムの発注を行なった会社が問題ないかを実際の業務と同じようなパターンを用意して行うテストになります。
テストの流れ
テストを行う際は以下の流れを各テスト工程で行います。
- 仕様分析
- テスト計画
- テスト設計
- テスト実装
- テスト実行
- テスト報告
仕様分析
仕様分析では要件定義などの設計書やプロジェクトの関連文書などを解析します。
この分析を元にテスト計画を立てます。
ただし場合によっては要件定義や設計書が存在しない場合があります。
その場合は以下のURLのようなテストタイプを使用します。
2.3.2 機能以外の特性のテスト（非機能テスト） - Summarize-JSTQB-FL
テスト計画
テスト計画では仕様分析に従ってテスト計画を立てます。
テスト計画を立てる際に使用するテスト計画書についてはIEEE829というテスト計画書のフォーマットがあります。
そのためこの計画書に沿ってテスト計画を立てます。
内容については以下の通りです。
- テスト識別番号 - 文書番号にあたる
- はじめに(序文) - プロジェクトの背景やドキュメントとの関連を記載する
- テストアイテム - 対象のソフトウェアとそのバージョンを記す
- テストすべき機能 - テスト対象の機能
- テストしない機能 - テスト対象の範囲外の機能とその理由
- アプローチ - テストの種類
- 合否判定基準 - テストしたシステムの合否基準、またテストの終了条件にも関わる
- テスト中止・再開基準 - テストの中止の基準と再開の基準
- テスト成果物 - テストで作成するドキュメントなど
- テストのタスク - テストで必要な作業
- 環境要員 - テストを行うために必要なハードウェアやソフトウェア
- 責任範囲 - テストに関わる人々の責任範囲
- 要員計画とトレーニング計画 - テストに必要なスキルとそのトレーニング方法、また人数
- スケジュール - テストのスケジュール
- リスク対策 - テストに関わるリスクと対策
- 承認 - これらの計画を誰が承認したか
テスト設計
テスト設計ではテスト計画を元に、どのようなテスト項目を作成するかを決めます。
例えば性能に対する設計を行い場合は、どれだけの負荷に耐えられるかをテストします。
そのためにどのようなどのようなアクセスが多いかを分析し、どういうテストを行うかを決めます。
テスト実装
テストの実装ではテスト設計を元に、具体的にどのような項目にどういうテストを行うかを決めます。
一般的にテストケースと言われるものがここで作成されます。
テスト実施
テストの実施ではテストを実際に行います。
そしてテスト結果の記録と、不具合が発生した場合はその不具合を記録します。
大切な事としてテストの記録はいつ、誰が行い、どういう結果だったかを記します。
不具合の記録については同じ原因の不具合を、いくつも不具合の記録として残してしまうと開発者が混乱します。
そのため同じ原因のものはまとめることが肝心です。
テスト報告
テストが終わったらテストの結果について報告書を作成します。
こちらもIEEE829にテンプレートがあり、以下のような項目で構成されています。
- テスト報告書番号
- 本報告の要約と見解
- テスト実施内容と要約
- テストの総合評価
- 不具合の傾向と積み残し
- テストにおける特記事項
- テスト実施時のステークホルダー
テストの種類について
上記まででテストの流れを説明してきました。
次はテストの種類について説明します。
テストの種類には以下のような物があります。
- ホワイトボックステスト
- ブラックボックステスト
- 探索的テスト
- 非機能要求テスト
ホワイトボックステスト
ホワイトボックステストはソースコードをベースに行うテストです。
このテストではソースコードのルートを網羅することを目的としています。
ソースコードのルートとは条件分岐やループなどで処理の流れが分かれると、それぞれにルートができます。
その両方をテストし、どちらを通過しても問題ないことを確認します。
網羅する比率のことをカバレッジと呼び、理想は100%通ると良いですが、一般的には起こり得ない例外の処理だったり発生が非常に困難な条件がある場合もあり、必ずしも100%を目指さない場合もあります。
ブラックボックステスト
ブラックボックステストはソースコードをベースに行わず、設計書などを参考にテストを行います。
例えば年齢の入力欄に数値以外が入った場合はエラーとする。
また、4桁以上の数値は入力できないようにする、などが設計書に記載されているとします。
テストとしてはそれらの制限ないであればエラーにならず、制限に引っかかる場合はエラーとなることを確認します。
探索的テスト
探索的テストはテスト対象を、テスト実施者が自由に触りエラーを見つけるテストになります。
ホワイトボックステストやブラックボックステストでは一般的にはテストケースに沿ってテストを行います。
一方探索的テストではテスト実施者が対象のソフトウェアを使用しながら学習し、バグを見つけ出していきます。
私の考えとしてはゲームのデバッグなどが1番近いものとなります。
非機能要求テスト
非機能要求テストは以下のようなざっくりした観点からテストを実施します。
- 機能性
- 信頼性
- 効率性
- 移植生
- 使用性
このテストの難しいところは観点がざっくりしている事もありますが、テストの合格基準が難しい所にあります。
例えば一般的にシステムを使いやすくする(使用性を上げる)とセキュリティの観点からはリスクが伴います(信頼性が下がる)。
そのためどこをゴールに設定するかが難しいです。
また、このテストの一種にセキュリティテストが含まれます。
セキュリティテストは日本では行える技術者が少なく、あまりテストされていない分野になります。
終わりに
上記のようにテストの流れと手法について解説していきました。
ソフトウェアは一般的にはバグを0にすることが不可能と言われています。
そのためどこでテストを終えるかも重要な判断になってきます。
そのような細かい話や、上記の内容について詳しく知りたい方は以下の書籍を参考にしてみてください。