テスト方針

2

次開発のテスト方針を表 5-11 に示す．

表 5-11

2

次開発テスト方針 単

体 テ ス ト

テスト実行者 各メソッドの実装者

使用ツール

simpleTest（cakePHP

のテストツール）

テストする部位

model

クラスの，新しく追加されたメソッド全て 主な確認点 引数のミス

実行結果の一致 コードカバレッジ

バグ管理方法

Google drive

に用意したバグ管理票に記録 結

合 テ ス ト

テスト実行者 児玉

使用ツール なし．実行環境である

FireFox

上で確認する テストする部位

1

次開発で新しく追加された画面全て

主な確認点 画面表示は定義通りであるか 画面が定義通りの画面に遷移するか 入力箇所が正常に動作しているか

エラーチェック，エラーメッセージは正常か バグ管理方法

Google drive

に用意したバグ管理票に記録 シ

ス テ ム テ ス ト

テスト実行者 児玉

使用ツール なし．実行環境である

FireFox

上で確認する テストする部位

1

次開発で新しく追加された画面全て

主な確認点 ユースケースのフローに従い操作できるか 操作手順にわかりにくさはないか

バグ管理方法

Google drive

に用意したバグ管理票に記録

2

次開発では，1 次開発テストでの振り返りなどを踏まえ次の

3

点に取り組むこととした．



単体テスト担当者の変更

1

次開発では，メソッド定義書とプログラムコードの不一致が発生した．対策として，メ ソッドに変更がある場合すぐにメソッド定義書を変更することをチーム内に周知した．しか し，2 次開発の実装工程においてもメソッドの変更が頻繁に発生する可能性があったため，

単体テストは実装者を中心として行う方針とした．実装者はメソッドの内容を常に把握して いるため，テストケースとメソッド内容の不一致の発生を防ぐことができると考えた．



テストケースの作成と並行した画面定義書の修正

1

次開発では，定義書に曖昧な部分を残したまま実装を進めてしまったため，バグ発生の

原因となってしまった．その対策として，テストケースの作成と並行して仕様書を正確にし

ていく作業を行うこととした．画面定義書やユースケース記述からテスト仕様書を作成する

際，定義が曖昧な部分を発見したらすぐに修正し，修正点をプログラム担当者に伝えるもの とした．

 CFD

技法を用いたテストケース作成

1

次開発テストでは，テストケースを作成する際にテスト技法を用いなかった．

2

次開発で は，条件の網羅性の確認を行いやすくするため，CFD 技法というテスト技法を採用した．

CFD

技法は，

CFD(Case Flow Diagram)と呼ばれる図を作成し，その図からデシジョンテー

ブルを導き出す技法である[10]．

CFD

技法を用いた例を図 5-5 と表 5-12 に示す．CFD には原因と結果を列挙する．原因 となる要素は，取りうる値を同値分割する．そして，仕様を満たすように原因同士を線で結 び，結果へと繋ぐ．仕様を網羅するように線を引き終えたら，表 5-12 のデシジョンテーブ ルを作成する．デシジョンテーブルでは，

CFD

で列挙した原因を条件記述部，結果を動作記 述部に並べる．そして原因と結果を繋いだ線をテストケースとする．

図 5-5

CFD

の作成例

表 5-12 図 5-5 から導出したデシジョンテーブル

実際に

CFD

技法が有用かを確認するため，2 次開発で開発する患者薬歴登録画面（注射）

を用いて，

CFD

を作成した（図 5-7）．患者薬歴登録画面では，以下に示す動作が行われる．

この動作を対象に，CFD 技法による分析を行った．

I.

ユーザは薬歴情報を入力し，「確認画面へ」ボタンを押す．

II.

システムは入力内容を確認し，次の動作をする．

(ア)

入力内容に不備がなければ，内容確認画面へ遷移する．

(イ)

入力内容に不備があれば，エラーメッセージを表示する．エラーメッセージは，「値 が未入力である」 「入力した数値が有効範囲外である」 「型の違う値が入力されている」

の

3

種である．

図 5-6 患者薬歴登録画面（注射）

以下の手順で

CFD

を作成した．

① 結果を列挙し，有効系と無効系に分類する

ここで言う結果は，II でシステムが行う動作である．有効系とは，仕様で定められた正常 な動作であり，II の（ア）を指す．無効系は，それ以外の，エラー処理などで定められた動 作である．ここでは

II

の（イ）に示すエラー出力

3

種を指す．

② 原因を列挙する

ここで言う原因は，I で入力する薬歴情報のうち

II

の動作の選択に影響するものである．

例えば薬の投与日は，正しい入力なら

II

の（ア）の動作となるが，不備があれば

II

の（イ）

の動作となる．

③ 原因ごとに，入力値の同値分割を行う

同じ結果につながる入力同士をグループ化する．例えば投与日ならば，date 型の入力と，

型違いの入力（文字列，数値）にグループ化できる．

④ 原因から結果に向けて線を結ぶ

各原因の，同値分割された要素を線で結び，それらが全て入力された場合の結果へ繋ぐ．

ここで，無効系の結果へ線を結ぶ場合，依存関係のない原因同士を繋がない．例えば，投与 日が

date

型以外の入力であれば，必ず型違いエラーとなる．そのため，この場合は他の原 因を通さず，投与日の項目から直接型違いエラーに線を繋ぐ．

以上のことから，実際に作成した

CFD

を図 5-7 に示す．

図 5-7

CFD

技法による分析

図 5-7 から，有効系の結果に辿り着くルートは#1,#2 の

2

通り，無効系の結果に辿り着く ルートは#3～#13 の合計

11

通りであることがわかる．

そこから導出したデシジョンテーブルを表

6

に示す．

13

通りのテストを表から導出するこ

とができた．

表 5-13 図 5-7 の

CFD

から導出したデシジョンテーブル

実際に

CFD

を作成して，無効系のテストケースを削減出来る点が有用であった．④で示し

た「無効系の線は依存関係のない原因同士を繋がない」というルールにより，同じエラーを

発生させるテストケースの重複を，図に起こした段階で回避できる．また，表記が理解しや

すく，レビューを行いやすい点も有用であると感じた．

ドキュメント内 大学病院における抗がん剤 (ページ 31-36)