https://sites.google.com/site/testautomationresearch/test_automation_principle
| 分類 | 成果物 |
|---|---|
| 計画書 | 試験計画書 |
| 計画書 | 試験計画書 |
| 試験 | 試験手順書 |
| 試験 | 障害処理票 |
| 成績書 | 試験成績書 |
| 成績書 | エビデンス |
| 成績書 | 試験完了報告書 |
| 成績書 | 品質報告書 |
| テスト名 | 概要 |
|---|---|
| タスク指向機能テスト（TOFT：Task-Oriented Functional Test） | アプリケーションの各機能が実行するタスクが、仕様書・ユーザーガイド・要求仕様書・設計文書に違反する動作をしていないかを確認する正常系テスト |
| タスク指向機能テスト（TOFT：Task-Oriented Functional Test） | アプリケーションの各機能が実行するタスクが、仕様書・ユーザーガイド・要求仕様書・設計文書に違反する動作をしていないかを確認する正常系テスト |
| 強制エラーテスト（FET：Force-Error Test） | プログラムを強制的にエラーにするよう設計された異常系テスト |
| 境界値テスト | 極端な入力データに対するプログラムの応答を確認する |
| システムレベルテスト | システム全体を通して動作させ、正常に機能するかを確認する |
| 現実のユーザーレベルテスト | ユーザーがプログラムに対して行うであろうことを予測してテストする |
| 探索型テスト | 問題の「起こりそうな」場所に焦点をしぼってテストする |
| 負荷／ボリュームテスト | プログラムが大量のデータ／計算／処理をどのように扱うかをテストする |
| ストレステスト | 限られたリソースのもとでプログラムを動作させる |
| パフォーマンステスト | ユーザーが許容できるシステム性能を維持するための効果的な方法を作成するために行う |
| フェイルオーバーテスト | システムレベルのエラー処理やリカバリプロセスをテストする |
| アベイラビリティテスト | システムやコンポーネントが動作可能でアクセス可能な状態となるまでをテストする |
| 信頼性テスト | システムが一定時間の間連続で操作可能かをテストする |
| スケーラビリティテスト | システムの拡張性をテストする |
| APIテスト | ハーネスアプリケーション等を利用し、APIをテストする |
| 回帰テスト | バグ修正後に、それが確実に修正されているかと、新たなバグが発生していないかをテストする |
| 互換性テスト、構成テスト | アプリケーションがさまざまなハードウェアやソフトウェア上で正常に機能するかをテストする |
| ドキュメントテスト | リファレンスガイドやユーザガイドが正しく記述されているかをテストする |
| オンラインヘルプテスト | オンラインヘルプの内容やヘルプシステムが正常に機能するかをテストするユーティリティ、ツール、その他付属品のテスト |
| システムに付属するもののテストインストール／アンインストールテスト | インストーラのテスト、READMEやアイコンの確認、インストールした機能が正常に動作するかをテストする |
| ユーザーインタフェーステスト | 使いやすさや見た目の評価、UIが仕様通りに動作するかをテストする |
| ユーザビリティテスト | 使いやすさやユーザーの満足度をはかる情報を収集するなど |
| 外部ベータテスト | プログラムを試しフィードバックをくれる外部の協力者にテストしてもらう |
| 日付テスト | 2000年問題や2038年問題のテスト |
| セキュリティテスト | 脆弱性／情報洩れなどがないかをテストする |
| 単体テスト | ソフトウェアをほかのソフトウェアと結合する前に単体でその完全性を評価する |
| テスト名 | 説明 |
|---|---|
| アドホックテスト | 直感や経験に基づくテスト設計・実行する手法 |
| 探索的テスト | テストの設計と実行を同時に平行して進める手法 |
| 同値分割 | 同じ結果をもたらす集合（同値クラス）に分割し、各集合の代表値を用いてテストを行う手法 |
| 境界値分析 | 同値クラスの境界値付近（境界値、境界値の前後）を重点的にテストする手法 |
| ドメイン分析テスト | 同値分割と境界値分析を多次元に拡張した手法 |
| デシジョンテーブル | 入力条件の全ケースと出力との関係を表形式で整理する手法 |
| 原因ー結果グラフ | 入力条件や環境条件などの原因と、出力などの結果の論理的な関係をグラフで表し、最終的にデシジョンテーブルに展開することでテスト項目を設計する手法 |
| FD(Cause Flow Diagram) | 原因結果グラフの発展形ともいうべき技法で、同値分割、デシジョンテーブルの手法を組み合わせた手法 |
| 状態遷移テスト | 状態遷移を状態遷移図や状態遷移表を使ってテストする手法 |
| ランダムテスト | テストの入力値にツール等でランダムに生成した値を使ってテストする手法 |
| ペア構成テスト | パラメータや環境の組合せテストにおいて、組合せの爆発を避け、バグ摘出効果の高い組合せ（2因子のペア）を重点的にテストする技法 |
| ユースケーステスト | ユースケース(*)記述を元にテストする手法 |
| トランザクションフローテスト | トランザクションフローグラフを用いてトランザクションをテストする技法。 |
| 制御フローテスト | ソースコード内のパスを網羅する観点で行われるテスト。複数の網羅基準がある |
| データフローテスト | プログラム内の変数に注目してテストする手法 |
| 静的解析 | プログラムを実行することなしに、与えられたプログラムのコードを解析して、プログラムの実行時の属性を発見する解析手法 |
| エラー推測 | 対象プログラムにおいてありがちなエラーを想定し、テストケースを設計する手法 |
| 運用プロフィール | 運用時に利用される状況をできるだけ忠実に再現するテストをする際に用いられる手法 |
| アプリケーションの性質に基づいた技法 | テストされるアプリケーションの性質に特化したテスト技法 |
| リスクベーステスト | リスクの高い箇所からテストを優先的に行う手法 |
| テスト項目番号 | 確認内容 | 操作手順 | 確認結果 | 確認日 | 確認者 | 障害報告票番号 |
|---|---|---|---|---|---|---|
※結果は、OK,NGでなく問題なし、問題ありで記述すること
日経BP社 体系的ソフトウェアテスト P349から抜粋
http://www.atmarkit.co.jp/ait/articles/1008/25/news106.html
大枠レベル
各項目レベル
一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない
テストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。
有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろうとしている(単一責任の原則に反している)
テストがテスト対象のコードの内部メソッド(privateやprotectedのメソッド)にまでアクセスしている。これはリファクタリングしにくくなる。
テストが開発環境のみで動作し他で動かない。こういう問題を出来る限り早期に発見するため、継続的インテグレーションを利用すること。
テストが熱心という以上にチェックしている。こういうテストは本来チェックする必要のない箇所をちょっと変えただけで失敗することになってしまう。特にモックを利用していたり、ソートされていないコレクションの並び順をチェックするようなことをしていると発生しやすい。
テストが何もアサーションを使っていない
コンソールをテキストで埋めてしまうようなテスト。たぶん何かのチェックを手動で行うために使われているんだろう。。。
テストが例外をキャッチして握り潰しテストを通している
既にシステムで必要とされていない項目をチェックしている。そういうコードが参照されていると綺麗なプロダクションコードにすることが妨げられる
テスト内容がセットアップメソッドや基底クラスやヘルパークラスに書かれている。テストはテストメソッドを見るだけで何をテストしているか把握可能であるべきである。テストは他の場所で初期化したりアサーションしたりしてはいけない。
コードの実行結果をアサーションでチェックしている。最初にテスト対象のコードを実行してローカル変数に代入し、その値をアサーションでチェックしている。
テストを分割するかアサーションメッセージを使う必要がある。
テストの中では条件分岐によるテストロジックは組み込むべきではない。そうしてしまうとテストが読みにくくなる。
テストが製品コード内の特殊ロジックに依存している。
時々はテストに通るが、時々は環境等の理由で失敗する
出来る限り素早い頻繁なフィードバックを得るためには、小さいステップで進める必要がある。
テストに失敗して初めて製品コードが必要となる。さらに驚くことにテストが失敗しなかったら、テストが本当に正しいのか確認すること。
リファクタリングは将来への投資である。可読性、変更容易性、拡張性となって返ってくる
想定ではなくてチェックすべきだ。もし機能が簡単ならテストもより簡単なんだから。
よりシンプルにすること。さもないとバグが混入し、保守性が下がる。
メソッドのテストは壊れやすくリファクタリングキラーだ。テストは実際に使われる機能の小さなユースケースをテストすること。
コードカバレージを不足しているテストの発見に使うこと。さもないとコードカバレージは増えたけれども不確かな役に立たないテストが増えたということになりかねない。
エビデンス取得を実施させる場合、エビデンスを取得する人とエビデンスを整理する人にわける。エビデンスを整理する人はエビデンスを確認したあと、「○○を確認した」という記載をいれるようにする。
| ディレクトリ | 説明 |
|---|---|
| unit | モデル単体のテスト、ライブラリ単体のテスト |
| functional | コントローラーのテスト |
| integration | 実際にユーザーが操作した時のような、複数のコントローラーにまたがる総合テスト |
| performance | パフォーマンステスト用らしいが、今回は割愛。 |
| fixtures | テストを実行する上で、予め DB に投入しておく検証用データのこと。 |
| prepare | DBからスキーマをコピーするなど、テスト用のDBを準備する |