スポンサーリンク

単体テスト仕様書を誰が作るかわからない場合に参考にするポイント

アサインされた現場にある単体テスト仕様書を見た時に、条件を持つ機能を作ろうとすることがおいでしょう。

単体テストで最も大切なことはテスト対象を漏らさないことです。実装者がどんなに注意深く実装をしても、バグがないことはまずありません。なので、そう言ったバグは単体テストや結合テストをはじめとしたテスト工程で検知する必要があります。上記のような漏れのある単体テスト仕様書でテスト項目をすべて消化しても、その漏れたテストケースの部分にバグが含まれていた場合はそれを検知することはできません。

単体テストの観点

テスト観点が漏れている

システムやソフトウェアの要件定義書の読み込みが充分でない場合に起こりえることです。
テストすべき機能は洗い出されているのに、テスト観点が漏れてしまうと、テストケースも作られないため、機能が正常に動作するのかどうか、エンジニアはテストすることができません。

テスト観点がずれている

要件定義書を読み込んでいたとしても、テスト観点がずれていると、テストの目的や方法もずれてしまいます。
いくらテストケースを詰めたとしても、正常な動作かどうか、判断するための結果は得られません。

テスト観点の表現が曖昧

表現が曖昧なテスト観点からは、正しいテストケースを作ることはできません。
例えば、「条件」といった表現を使った場合、どのような条件なのか詳しく表現しなければ、テストを行うたびに結果が異なる、という事態に陥ります。

項目名 実施可否
同値分割
境界値
maxlengthが指定(※10文字である場合、9文字、10文字は入力可能。11文字は、入力できないこと)
maxlengthが指定されていない場合
空白文字
半角文字(アイウエオ、カキクケコ)
全角文字(あいうえお、かきくけこ)
機種依存文字(①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳:㍉㍍㌔㌘㌧㌦㍑㌫㌢:㍻㍼㍽㍾:ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ)
小数点(第一位まで、第二位まで)
記号文字(〃 仝 ゝ ゞ 々 〆 ヾ ― ‐ / 〇 ヽ _  ̄ ¨ ` ´ ゜ ゛ \ § ^ ≫ ¬ ⇒ ⇔ ∀ ∃ ∠ ⊥ ⌒ ∂ ∇ ≡ ∨ ≪ † √ ∽ ∝ ∵ ∫ ∬ Å ‰ ♯ ♭ ♪ ‡ ~ ′ ≒ × ∥ ∧ | … ± ÷ ≠ ≦ ≧ ∞ ∴ ♂ ♀ ∪ ‥ ° ⊃ ⊂ ⊇ ∩ ⊆ ∋ ∈ 〓 〒 ※ ″)
マイナス値
HTMLエスケープ(<>&”‘)
JavaScriptへの埋め込み文字(<>&”‘)
SQLエスケープ(‘”%_%_)
リンク表示、リンククリック遷移
ボタン表示、ボタンクリック遷移
プルダウン値、ラジオボタン、チェックボックス、テキストエリア
必須項目で未入力の場合の振る舞い
クリックを数回した場合の振る舞い
数回リロードした場合
存在しないパラメータを渡す
画面間のデータの受け渡し
ステータスによる画面表示処理の振る舞い

その他の観点

1. テストでの前提条件、使用するテストデータ(DB)、ファイルなどはすべて説明に残す
2. 動作条件でテストケースを分類する
3. 入力(データや条件)によって出力がどうなるかがわかるようにテストケースを書く
4. 境界値をテストに含める
5. 異常値をテストに含める
6. 入力/出力のパターン(条件)を網羅する

(Visited 20 times, 1 visits today)
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク