アドベントカレンダー14日目
こんにちは。リリカルです。
前回からWACATEの必須予習項目である、テスト技術者のFoundation Levelシラバス 第2章についてまとめています。今日もその続きです。
WACATE2016 夏 満員御礼!と 予習内容について - WACATEブログ
2章を読みながら作成したマインドマップもどきがこちらです。(再掲)
今日はこの左側の部分です。
では早速参りましょう!
2.3 テストタイプ
テストタイプは大きく以下のような分類で説明されています。
2.3.1 機能テスト
2.3.2 非機能テスト
2.3.3 変更部分のテスト
2.3.4 保守テスト
一つずつまとめていきます。
2.3.1 機能テスト
機能とは、システムが「何をするのか」を表します。
機能テストは機能やフィーチャと、システムとの相互運用性に基づいたもので、すべてのテストレベルで実施する必要があります。
ソフトウェアやシステムの機能からテスト条件とテストケースを抽出するのには、仕様ベースの技法を使うことができます。また、機能テストはブラックボックステストになるのが一般的です。ここで注意すべきなのは、ISTQBではセキュリティテストは非機能テストではなく機能テストとされているところです。「脅威を検知する機能をテストしている」という捉え方のようです。
2.3.2 非機能テスト
非機能テストには、例えば以下のようなものがあります。
- 性能テスト
- ロードテスト
- ストレステスト
- 使用性テスト
- 相互運用性テスト
- 保守性テスト
...他にもまだありますが割愛します。
非機能テストは、機能テストとは異なりシステムが「どのように動作するのか」をテストします。非機能テストも、すべてのテストレベルで実施できます。
非機能テストを実施する場合、例えばISO9126やISO25010のような規格で定義されている品質モデルを参照することがよくあります。この非機能テストにおいても、多くの場合ブラックボックステストが使用されます。
2.3.3 構造テスト
構造テストは別名ホワイトボックステストでもあるのですが、これもすべてのテストレベルで実施できます。構造を網羅するテスト手法であるため、一般的に仕様ベースの技法の適用後に実施されます。
有名なのが、カバレッジでテスト結果を評価する点です。ソフトウェアの構造のうち何%を網羅していて、100%網羅するにはどうしたらいいか、あるいは何%を目標としてカバレッジを高めていくかなどを考えていきます。コードのカバレッジの計測には、ツールが用いられることも多いです。
2.3.4 変更部分のテスト
欠陥を摘出してそれを修正した場合、元の欠陥が正しく修正されたか確認するために再テストを行います。これを確認テストということもあります。
回帰テストとは、変更をした場合に、変更によって作り込んだ欠陥や新しい欠陥を見つけるために、すでにテスト済みのプログラムを対象に何度も実施されるテストのことです。ソフトウェアあるいはソフトウェアの動作環境が変わった時に実施します。派生開発とも関連する技術です。回帰テストの範囲は、さすがに全範囲を網羅するのは非現実的なので、テストして欠陥が見つけられなかった場合にどれだけのリスクがあるかを考え、その大きさを基に決定します。欠陥を見逃すことによるリスクが極大であれば、テストする範囲としてもほぼ全体かそれに準ずる程度の規模となるでしょうし、逆にそうでもないのならある程度範囲を絞って実施することもできるでしょう。
また、回帰テストのテストスイートは少しずつ内容に変更を加えられて何度も実行されるのが普通ですから、テスト自動化によって期待される効果も非常に大きくなります。
2.4 保守テスト
ソフトウェアがひとたびリリースされると、長いものでサービスは数十年続きます。そしてその稼働期間中に、システムや構成データ、または動作環境に修正、変更、拡張が行われることも多々あります。
保守テストは、現在稼働しているシステムに対して行われるテストです。保守テストでは、変更部分のテストに加えて未修正の部分に対する回帰テストも実施します。保守テストの実施範囲は、変更のリスクやテストの規模、変更の大きさによって変わってきます。
次回予告
以上、Foundation Levelシラバスの2章を簡単にまとめました。
3章は…飛ばしまして、次回は4章のまとめをお送りします。