ソフトウェアテスト技法からテストを再勉強する。その1
社会人になってからテスト周り任されることが多く、ただ経験ベースでしかテストを語れなかったので、以下の本を読んで勉強中。
- 作者: リー・コープランド,宗雅彦
- 出版社/メーカー: 日経BP社
- 発売日: 2005/11/03
- メディア: 単行本
- 購入: 24人 クリック: 539回
- この商品を含むブログ (51件) を見る
一度通して読んだ上で再度最初から見直しているので、内容をメモ程度に残しておく。
そもそもテストとは
実際どうなっているか、本来はどうあるべきかを比較するプロセスである。IEEE 610.12-1990 では
ある特定の条件下でシステムまたはコンポーネントを操作するプロセスであり、その結果を観察または記録して、システムまたはコンポーネントのある側面を評価すること
「ある特定の条件下」をテストしたい対象の条件としたものをテストケース。
テストケース
テストケースは3点で構成されている。- INPUT
- OUTPUT
- 実行順番
INPUTがあって、それに対して実行順に沿って処理をおこなってOUTPUTが出力される。
それを正しく評価することで、要件または実装が正しいのか間違っているのか判断できる。
また、テストケースがまとまったものがテストスイートになる。
テストスイート
テストケースでは単一のチェックしか基本しないので、他にも観点があるのであればテストケースを追加していって、このテストケースの塊実行したら正しいと担保できるぜってなった際のテストケースの塊。テスト対象のコンポーネント又はシステムのためのいくつかのテストケースのセット。一つのテストの実行事後条件は、次のテストの実行事前条件としてよく利用される。
ソフトウェアテスト標準用語集(日本語版)
ソフトウェアテスト(動的テスト)の最小単位はテストケースといえるが、実際にテスト作業ではいくつものテストケースを組み合わせることによって不具合をあぶり出したり、確率的に十分なテストを行ったという結論を出したりする。このようなテスト目的やテスト対象に応じて、多数のテストケースを束ねたものをテストスイートという。
テストスイート(てすとすいーと) - ITmedia エンタープライズ
INPUT
INPUTは、キーボードからの入力データや、ファイルやデータベースのデータなど、テストするにあたって事前に用意しておかなきゃいけないもの。あるテストを行おうとしたとき、結果を得るために事前にやっておく仕込みの作業。
OUTPUT
OUTPUTはそのままある程度の結果のこと。OUTPUTが画面上に表示された結果や、データベースへ書き込まれたデータ、外部機能へのデータ連携、ログなど、「何かをした結果出てくるもの」のことを指す。その沢山ある結果の中で「何がどうあれば正解」なのかは5パターンで定義できる(らしい)
子供のオラクル
単純にプログラムを実行して結果を眺める。なんとなく正しそうなら正しいっていう、結果が明示できてないやつ。
回帰テストのテストスイート
プログラムを実行して、以前のバージョンのプログラムに適用したテストケースの結果を今回の結果と比較する。主に保守運用フェイズで用いられるもの、経験上保守している機能に対し、会社の横展開をしたいぜってパターンもそれにあたる。
これをやらないと、今まで出ていた結果がでず本番環境で障害が起こってえらい目に遭う。
正当性が実装されたデータ
プログラムを実行して、テーブル、公式、その他の正当な出力の定義として認められた基準とプログラムを実行した結果の出力を比較する。これはちょっとよく分からない。
市販のテストスイート
既存の検証済み標準テストスイートに対してプログラムを実行する。標準でテスト機能を備えているものがあって、それを実行したらいいようなものかな。
市販ではないが、プロジェクトでアーキを作ったときにテスト標準みたいなのを作った。
新規機能を作ってもそのテストを通過すると概ね問題なしみたいなやつ。
既存のプログラム
プログラムを実行して、その結果を異なるバージョンのプログラムでの結果と比較する。SalesforceとかのSaaSを使用した際のテストに当たるのかなあ。
Salesforceでは年4回のバージョンアップで影響が大きい場合、一時的に有効してテストして、バージョンアップ前と同じ結果になるかどうかを確認する場合があるので。
実行の順番
テストケースを実施するにあたって、前後に依存がある場合、独立できる場合が存在する。前後に依存がある場合、データの用意→テーブルからRead→テーブルへwrite→テーブルからRead→テーブルからDeleteみたいな一連の流れがある。
上の場合、Readするのにwrite用とdelete用を別に作らなくていいとう利点があるが、Deleteがうまくできないみたいな状況になった際にwriteからやり直しみたいな状況もあり手戻りがでかい。
独立できる場合、パラレルでテストできるので、複数人でできる場合もあるのでテストが早く済む。欠点はテストケースが大きくなりがちで、設計・作成・メンテナンスが大変
テストの種類
ブラックボックステストとホワイトボックステストが存在する。ブラックボックステスト
テスト対象ソフトウェアの内部パス、構造、実装に関わる知識が不要であるのが利点。要件からINPUT情報を用意する形になるので、実装されているコードの知識は必要なし。
ただ、INPUTしたOUTPUTしかわからないので、一旦中で何をしているかが分からない。
ホワイトボックステスト
テスト対象ソフトウェアの内部パス、構造、実装に基づいてテストを実施する。実装に基づいてテストするということは、実装されているコードの詳細を理解できる力が必要。要件についての知識は不要。
テストのレベル
テストのレベルは通常4つのレベルで実施される。テストは経験上、Vモデルあることが多い。
基本設計と詳細設計が一緒になっていることがあるので、そのときはシステムテストと結合テスト同じスケジュールに入ったりする。
Vモデル(V-Model)とは、IT製品開発の手法の一種。ドイツ政府と軍関係のプロジェクトで標準として採用されている。また、一般に利用可能であるため、様々な企業でも使われている。プロジェクトマネジメント手法としては、PRINCE2に匹敵する。また、システム開発やソフトウェア開発の手法としても使われている
設計とテストが紐づいているので、粒度も各設計に合わせる必要がある。
ここで下の粒度のテストがテストコンディションにあると、かなり違和感があるし指摘されるので気を付けたほうがいい。
単体テスト
作成した機能(サブシステム)の最小単位でのテスト。自分が作った機能のみに閉じたテストを行う。1部品のテスト。
普通、要件を満たす機能を作るとなると自分が作った1機能だけではなく、他機能とのつながり、外部機能とのつながり等あるがそこは一旦考慮しない。
以前新人の子に質問されたことがあるんだが、他の機能から来たデータをINPUTにする場合、そのINPUTデータは自分が要件or設計書で想定されているデータが正として自前で作るなりして実施してよい。
本当に要件or設計書通りのデータ来るよね?なテストは内部結合テストに当たるので、テスト粒度が違う。
統合テスト
いわゆる結合テスト。単体テストでも書いたが、ある要件を満たすために作成した複数のサブシステム(部品)を結合して、ひとつの要件に沿って行うテスト。
内部のサブシステム同士であれば内部結合テスト、外部システムとのデータ連携等が必要であれば、外部結合テストを行う。
ここで発覚するのは大体、連携元のデータがデータ型が違っていたとか、想定外のデータがきたとかそういうパターンのものが多い。
システムテスト
いわゆる総合テスト。最も高いレベルの統合時に起こる結果に焦点を絞っています。普通、システムテストには様々なタイプのテストが含まれています。それは機能性、ユーザビリティ(使いやすさ)、セキュリティ、国際化、ローカライゼーション、信頼性、可用性、大容量、パフォーマンス、バックアップと復元、その他もろもろのテストです。
ざっくり書きすぎて全然わからないが、経験上ほぼ本番同等の状態で業務に即したテストケースでやられているかと。
パフォーマンステストもここに割り当たるのかな?データ連携されるのであれば、連携されるファイルやデータサイズが想定される最大数か、それよりも少し大きいくらいで連携テストすることが多いかなと。
受け入れテスト
UATとも。ここのテストのメインはユーザ側。ここも本番想定の環境か本番環境をそのまま使うことが多いのかなー。
ここまでにテストの改修が間に合わない場合、経験上順番に開放するという逃げの戦法もある。というかそういうこともあった。
もっと勉強するならJSTQBの資格を取ったほうがいいなあ。
正直概要は意味がちょっと分からない箇所もあるし。
資格とらなくてもいいからこの本買うかなー。
ソフトウェアテスト教科書 JSTQB Foundation 第3版
- 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美
- 出版社/メーカー: 翔泳社
- 発売日: 2011/11/12
- メディア: 単行本(ソフトカバー)
- 購入: 5人 クリック: 85回
- この商品を含むブログ (12件) を見る