テスト設計のとっかかりテストをどう考えてますか？

株式会社日立製作所
加藤大受
daiju.kato.fc@hitachi.com

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.2

テストの目的1.
2.

バグを未然防止するための情報をプログラマに提供する。
ソフトウェアの稼働中に発生するリスクを予測するための管理用情報を提供する。

3.
4.

特定の環境下ではバグがないことを保証する。
容易にテスト可能な設計法を提供する。すなわち、検証が簡単で、不良の摘出、保守が容易な設計方式を提供する。
要求仕様書に記述された仕様、あるいは、要求仕様書に記述していない仕様をもとに、対象ソフトウェアが正しく動作しないことを証明する。これは「ソフトウェアの破壊(breaking thesoftware)」ともよぶ。

5.

6.

対象ソフトウェアを検証する。すなわち、ソフトウェアが正しく動作することを確認する。

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テストの最終目標品質保証を支援することにある。すなわち、品質に関連した情報を収集し、プログラマにその情報をフィードバックすることで、過去に発生した不良を防止し、ソフトウェアの品質をよい方向へと導くことである。

『実践的プログラムテスト入門』〜ソフトウェアのブラックボックステスト〜
ボーリス・バイザー著／小野間彰、山浦恒央、石原成夫訳「1.3.2 ソフトウェアテストの理由づけ」より 抜粋『実践的プログラムテスト入門』〜ソフトウェアのブラックボックステスト〜
ボーリス・バイザー著／小野間彰、山浦恒央、石原成夫訳「1.3.2 ソフトウェアテストの理由づけ」より 抜粋
Page.3

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.4JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

一概にテストといってもテスト設計を考える前に

機能テスト単体テスト結合テストシステムテスト
性能テスト負荷テストストレステスト
ユーザビリティテスト
回帰テスト環境テスト
テストアイテムは山ほどあり、どのようなテストを、どの程度の期間やるのかを考える作業が必要
テストは単純作業ではなく、想像力と知識が必要な作業です

Page.5JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.6JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato1

テスト設計とはテスト設計とは、「どうやってテストをするか」を考える作業のこと。
その前にテスト戦略とはテスト戦略とは、「一つ以上のプロジェクトのために、組織またはプログラムが実行されるべきテストレベルとそのレベルでテストを定義するハイレベルのドキュメント。」
JSTQB 『ソフトウェアテスト標準用語集 日本語版Ver 1.1 』

テスト設計をするには、「テスト戦略とテストアプローチ」が必要
Page.7

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テストアプローチとは
テストアプローチとは、「あるプロジェクトのためのテスト戦略を実現化したもの。
この中には、（テスト実施）プロジェクトの目的と評価済みリスクを基に決めた決定事項、テストプロセスの開始場所、適用するテスト設計技法、テスト終了基準、実施するテストの種別を含む。」『ソフトウェアテスト標準用語集 日本語版Ver 1.1 』よりPage.9JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.8JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

効率的なテストを取り組む
効率的なテストを取り組むには、テスト戦略とテストアプローチの基、「テスト計画」が必要。
そのためには、まずは正しい「テストプロセス」を理解することが必要。
テストプロセス全体のアクティビティ•計画とコントロール•分析と設計•作成と実行•終了基準の検証とレポート•終了作業
Page.10JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テスト設計までの全体像
テスト設計を考えよう

テストの計画
テスト戦略
テスト分析
要件
アーキテクチャ設計
テスト対象の情報収集、取捨選択

スケジュールPage.11

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.12JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato2

テスト計画テスト分析
テスト分析をなぜ行うのかIEEE std 829-1998のテスト計画書のテンプレート

完璧なテストはできない
スケジュール、リソース、環境などの制約を踏まえ、もっとも適したテストを遂行するため

11.テスト項目の合否基準
1.テスト計画書識別番号
12.一時定期基準と再開要件
2.目次
13.テスト資料
3.参考資料
14.テストタスク
4.用語集
15.環境条件
5.概要
16.責任
6.テスト項目
7.ソフトウェアのリスクに関する問題 17.スタッフの配置とトレーニング
18.スケジュール8.テスト対象機能
19.プランニングリスクと対応策
9.テスト非対象機能
20.承認
10.アプローチ

何を対象とするのかRFP、要求仕様書、アーキテクチャ定義書、設計仕様書
標準文書（RFC、ISO/IEC標準）、業界標準、社内標準
会議の議事録、設計メモ、メール．．．．．．

Page.13

Page.14

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テスト要件を洗い出す

テスト分析

テスト計画時にどんなテストが必要なのかをすべて洗い出す。洗い出し方は何でもOK。必要な情報をすべて書き出すことが重要。

計画したテストをISO9126の品質特性にマッピングして、品質が保証できるかを分析した例
実施
設計実装
β版
テスト
回帰テスト
設計実装
β版
テスト
システムテスト 設計
実装
β版
テスト
機能テスト

•テストマトリクス•KJ法•マインドマップ
機能要求と非機能要求と分けて考えてみよう

Page.15

○
○
○
○
○
○

Page.16

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テスト関係のドキュメント

○
○

担当

ISO/IEC 9126 品質特性
機能性 信頼性 使用性 効率性 保守性 移植性

QAエンジニア、テス
ター
QAエンジニア、
テス
ター
要求管理者、
品質管理者

○
○

△△

△
△

○
○

△
△

△
△

○
○
○

○
○
○

○
○
○

○
○
○

○

○

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

開発側成果物とテスト側成果物
フェーズ
要件定義

開発側成果物
システム要件 性能要件

マスター
テスト計画書

テスト側成果物

ユースケース
概念モデル

システム
設計書
内部設計

概略設計

マスター
テスト計画書

外部設計

非機能要求

機能テスト

負荷テスト

性能検証

システム

計画書

計画書

計画書

テスト仕様書ユースケース 機能一覧

画面遷移図

性能検証
シナリオ

システム
テスト仕様書
機能要求

詳細設計
機能設計書

回帰テスト

機能テスト

負荷テスト

性能検証

項目

仕様書

仕様書

仕様書

・・・

画面遷移図
単体テスト
仕様書

実装β版

セキュリティテスト仕様書

機能テスト
仕様書

不具合情報

システム
セキュリティ
重要度
Highの項目
テスト仕様書テスト仕様書
回帰テスト
機能テスト
項目
報告書
システムテスト セキュリティテスト

テスト

仕様書兼報告書

Page.17

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.18

仕様書兼報告書

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato3

テスト設計の視点
User-oriented
ユーザー指向Spec-oriented
要件指向

テスト設計のポイント
ホワイトボックス

少ないテストで漏れなく網羅
そのためにはDesign-oriented
設計指向

テスト対象を網羅するための３つの視点

ブラックボックス

Fault-oriented
不具合指向

要件ベース 設計ベース コード・ベース『JSTQB教科書 JSTQB認定テスト技術者 Foundation Level試験』
P14. 図1.1 テスト設計の視点
Page.19

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.20

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テスト対象を網羅するための３つの視点
視点

業務要件及びそれを機能仕様に落としたレベルでソフトウェアやシステムを網羅する。内部状態を知らない状態のテストを行う。プログラムの内部やシステム設計を知ったうえで、機能仕様から見た動作をテストすることもある。
機能要求として現れない、設計として設計ベース考慮していることを網羅する。要件
ベースを補う形で技術要素特有のリスクに関して考慮する。基本的にグレーボックス・テストを行う。
コード・ベース 一般的にホワイトボックス・テストと呼ばれる、関数やメソッド単位ごとにプログラム構造を網羅しているかを確認するテスト。主に単体テストで実施する。
要件ベース

Page.21

要件ベースのテスト設計

概要

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

要件からテストを設計する方法のこと。
要件からテストケースを考える手法としてデシジョンテーブルテストなどがある。
デシジョンテーブル（判断表）

見出し部
条件指定部

条件記述部

（行動の全ての条件を記述する部分）(条件の成否、条件の範囲などを指定する部分）

動作記述部

動作指定部

（行動内容の全てを列 (上の条件が満たされた場記する部分）合の行動を指定する部分）
JaSST 2007 Kyushu
Tutorial Session copyright(c) Daiju KatoPage.22

デシジョンテーブルの記入法
指定形式

デシジョンテーブルの例

意味または内容

Y
条件
Nの指定 語句、値またはコード規則を満足するには、この「Y」に対応する条件が満たされなければならない。（条件成立）
規則を満足するには、この「Nに対応する条件が満たされなければならない。（条件不成立）
条件記述部を補足する形で、この語句、値またはコードによって完成させる。この完成した条件が満たされなければならない。コードを用いる場合、その意味を注記する。
（条件成立）−または 規則を満足するには、「−」か「＃」に対応する条件は無＃関係または論理的に成立しない。（条件無関係）
X
規則が満足されると、記述された動作を実行する。（動動作）作
語句、値
動作記述部を細くする形で、語句、値またはコードによっの指 または て完成させる。この完成した動作が実行され、コードを用コード いる場合、その意味を注記する。（動作）定−または 規則が満足されると、記述された動作は実行されない。
＃（無実行）
Page.23

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

会員登録処理で、名前と住所の記載があれば「会員」、名前と電話番号ならば「準会員」の場合とすると、

条件

名前の記載あり

Y

Y

Y

Y

N

N

N

N

住所の記載あり

Y

Y

N

N

Y

Y

N

N

電話番号の記載あり

Y

N

Y

N

Y

N

Y

N

会員登録

X

X

X

X

X

X

X

行動

準会員登録
登録しない

Page.24X

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato4

コード・ベース視点のテスト設計
コード・ベース視点のテスト設計はホワイトボックステストで、代表的なテスト設計技法として、「制御パステスト」がある。
制御パステストとは、モジュール内のロジックをすべて通すようにテストデータを与えるテスト
pubic void foo(int x, int y){if ( x != 0) {y=y/x;
if ( y > 0 ) {y = y -1 ;}}}(x=1, y=1), (x=0,y=0), (x=1, y=0) という3種類の入力値を利用すると、すべてのパスが通る
Page.25

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

コード・ベースのテスト設計
コード・ベースのテストの場合、つまり、ホワイトボックステストでは、ツールを利用すると効率よくテストが可能カバレッジ計測ツール
メトリクス計測ツール
単体テストツール
コード解析ツールプロファイルツール
・・・・・・・
Page.26

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テスト設計の第一歩
効率よくテスト設計するために

機能要求
z機能テストzテストケースを使ったテスト
非機能要求z性能テスト、負荷テスト
zシナリオを使ったテスト
それぞれテスト設計のやり方が異なる

Page.27

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.28

テストケース設計
テストケースとは、テストを行う際に、プログラムにどのような入力を与え、その結果としてどのような出力が得られるべきかを記述したもの。
テストケースの書き方
目的
zテストによって得たい情報
入力条件
z入力するデータの値、入力方法や入力するときのソフトウェアの状態
実施手順
zテストを実施する手順全般。正式にはテスト手順書に記載
期待結果
z期待される結果。期待される結果は、仕様書を基にした値、他のテスト済みの製品との比較、過去のテスト結果、既存システムとの比較から導かれる。
Page.29

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テストケース設計
効率よいテストとは最低限のテストケースで、漏れなくテストすること効率を上げるには、テスト設計技法を知ることが重要
同値分割
z入力値を有効値の集合と無効値の集合に分け，各集合から代表値を選び，その代表値を与えてプログラムの動作を確認するテストのこと。有効値も仕様や内部構造などによってそれ以上に分割することもできる。

境界値分析
z入力データとして処理結果が変わる境界の値を与えて，プログラムの動作を確認するテストのこと。

グレーボックステスト
zソフトウェアやシステムの内部構造を知った上で、ブラックボックステストのように、機能仕様から見た動作をテストする方法。
Page.30

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato5

テストケース設計
３歳未満、３歳以上６歳未満、６歳以上でプログラム上の処理が違う場合、の同値クラスと境界値は？
同値クラス：３歳未満、３歳以上６歳未満、６歳以上という３つに分類される。
もし、年齢として適当でない数値や数値以外のものも入力される可能性を考える
ならば、「同値クラス」は４つに分かれる。
境界値：２歳、３歳、５歳、６歳Page.31

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テストケース設計
作成時のポイント１

各テストケースに優先順位をつける
テスト実施ができないケースを考慮
zテストケースを作成する時間があってもテストが実施できるかどうかは別。
zテスト設計カバレッジ≠テスト実施カバレッジ

回帰テストでの利用を考慮
z 優先順位が高いテストケースは回帰テストでの再利用が効果的である

Page.32

テストケース設計

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テストケース設計

作成時のポイント２

作成時のポイント３

異常系テストケースを作成する
正常系テスト

トレーサビリティを確保トレーサビリティの確保によって意味のあるテストであることを証明

z正しい結果が返るテストケース
z正しいエラー結果が返るテストケース

異常系テストz 本来起こらない動作やユーザーが起こしやすいミスによって引き起こされる動作を基にしたテストケース
正常系テストケースと異常系テストケースの比率を考慮して設計

Page.33

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

シナリオテストの設計
シナリオテストの設計は、業務フローやユースケースを基に行う。
1. 業務フローから基本フローを導きだし、シナリオを洗い出す。
2. 例外フローを業務フローの中で不自然な流れから洗い出す。
洗い出したフローを仕様書として加工

各シナリオパターンで表示されるが画面、処理とシナリオが流れるための必須条件、事後条件を記載してテスト仕様書とする。
Page.35

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

z機能要求と詳細機能設計のトレーサビリティの確保
z詳細機能設計とテストケースのトレーサビリ
ティの確保
機能IDをつけて管理することが望ましい

Page.34

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

シナリオテストの実施
本番を意識して実施•データ•システム環境
テスト結果の分析が必須

シナリオテストを利用し、性能テスト、負荷テストを設計する
 シナリオテストはフローが正しいことを確認する
テスト
 性能テストは性能要件を満たすかどうかを確認するテスト
 負荷テストは予想される負荷がかかっても正常に動作するかを確認するテスト
Page.36

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

6

性能テストの設計
性能要件を満たすかを確認するテスト
簡易テスト：システム構成の決定後に実施
本テスト：システムテスト時に実行早め早めにテストを実施

レイヤーを分けて実施できる場合は、レイヤーごとに測定を実施
Webアプリケーションの場合では、zDB層での測定
zミドルウェア層での測定
zアプリケーション層での測定

Page.37

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

性能テストの設計
テストケースの作成
性能要求を基に、測定すべき内容を記載
zメニューを選択後のレスポンス時間
z問い合わせの処理時間
z画面の表示時間zetc.
性能測定を行う環境
測定手順
期待される結果（時間）
できる限り具体的に記述する

Page.38

負荷テストの設計
テストケースの作成
要求される負荷を基に、測定すべき内容を記載
zCPU負荷zI/O負荷zストレージ負荷
zネットワーク負荷
z同時アクセス負荷zetc.
負荷測定を行う環境
測定手順
期待される結果(動作、対応負荷）

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

回帰テストの設計
回帰テストとは「変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現しないことを確認するため、変更実施後、既にテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わるたびに実施する。」
JSTQB 『ソフトウェアテスト標準用語集 日本語版Ver 1.1 』

できる限り具体的に記述する
Page.39JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju KatoPage.40

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

回帰テストの設計
回帰テストの設計
発見された不具合の修正確認
不具合の修正による影響確認
機能テストの優先順位の高いテストケース

閑話休題〜よくある話ですが〜

回帰テストのポイント

回帰テストの実施条件をテスト計画で明確にタイミング
実施回数
合格条件
Page.41

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.42JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

7

仕様書がないけどテストする

テスト対象を分析しようテスト対象物の仕様書がない、あるいは仕様書がまったく更新されていない。あるものは、z稼働システム
zソースコードzビルド環境顧客の要望により修正しなければならなくなった。どうやってテストするか。

ソフトウェアの動作環境
zシステム構成（ハードウェア、ネットワーク）
zソフトウェア構成（OS,ミドルウェア）
zソフトウェア設定
ソースコードの分析

こういう状況でもきちんとテストするのがテストエンジニア

zアーキテクチャの分析
9構造図の作成
9言語によっては仕様書作成ツールに通してみる
zDB利用時：スキーマ構造

ユースーケースの分析
z業務フローの作成

まずは分析
Page.43

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

機能テスト設計機能一覧作成
z機能を項目（メニュー階層）ごとに洗い出す
z機能の優先順位を作成

権限マトリックスの作成
z権限で表示・非表示される機能を洗い出す
ここまでできれば後はテストケース作成

Page.44JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

非機能要求のテスト
性能テストz既存システムの顧客からのヒアリングで性能要求を決定
z性能劣化がおきていないことを確認
負荷テストz 既存アクセスログやソフトウェア構成から必要な要件を洗い出す
z 顧客からのヒアリングで対応負荷要件を決定
z 業務フローからシナリオを作成し、テストケースを作成

システムセキュリティテスト
機能一覧をベースにテストケースを作成
z優先順位によって作成するテストケース数を決定

Page.45

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Katoz 既存システムのセキュリティ状況を洗い出す
z 現状からセキュリティ要件を洗い出し、顧客にヒアリング
z セキュリティ要件を基にセキュリティテストのテストケースを作成

Page.46

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

作成した資料を仕様書にする作成した資料z システム設計書z ソフトウェア設計書
z ソフトウェア構造書
z ユースケース定義書
z 性能要件z セキュリティ要件
z 各テスト計画書
z 各テスト設計書
z 各テスト仕様書（テストケース）

テスト設計に磨きをかけるために

報告書の作成
z テスト結果のテスト報告書を作成

こういう開発・テストは正道ではありません
Page.47

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.48

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

8

知識の習得

バグの分析発見されたバグを分析することによってエラーの推測
品質の分析
回帰テストの効果測定
今後の工数・テストケース分析のデータ

アプリケーションの知識

バグ管理システムを利用しよう

テスト手法のテスト手法の知識

バグをデータとして生かしていくためにはバグ管理システムの構築が必要不可欠
バグの内容、手順を分かりやすく記載
バグの深刻度、レベルを分類し、優先順位付けを行う。回帰テスト設計時のデータとして利用

テストエンジニアに必要なスキル
OSやハードウェアの知識
OSやハードウェアの知識

ネットワークの知識

分析力
分析力

プログラミングの知識

文章力
プログラミング環境の知識

いろんな角度からテスト対象を分析できる知識を習得しよう
テスト技法の習得も忘れずに

Page.49

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.50

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

テストに悩んだら機能テストのテストケースに悩んだら開発者に相談しよう入力値の組み合わせが多すぎてテストケースが爆発するときは組み合わせを減らす技法（All-Pair法、直行表）を利用しよう
シナリオテストに悩んだらユーザーに相談しようテスト技法を知りたいときはテスト関連書籍を参照しようテストを行う時間があまりにないときは、テスト不足による品質リスクを洗い出して、PMと交渉しよう
どんなにテストしても品質が上がらないときは、リスクを洗い出して、PMに相談しよう他の人の意見を聞きたいときはTEFのMLを利用しようもっといろいろと勉強したいときは、TEFの勉強会やJaSSTに参加しよう

ご静聴ありがとうございました

いろんな形で悩みを解決していくことができるでしょう
Page.51

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

Page.52

JaSST 2007 Kyushu Tutorial Session copyright(c) Daiju Kato

9