ほんとは18以上の無限のチェックポイントがあります。
異常系入力チェックしてる？
Webシステムを開発している皆さんは常日頃どのようなテスト（デバッグ）を行っていますか？
私は主にPHPでの開発を行っていますが、スクラッチでWebフォーム（お問い合わせフォーム、アンケートフォーム、予約フォームなど）を開発することがあります。
だいたいしっかりとテスト済のライブラリ、ルーチンモジュールやテンプレを使って、毎回異常系のテストを網羅しなくて良いようにしています。
異常系入力エラーを出さないためには、処理をルーチン化することが大事です。
ですが、完全に一からスクラッチで開発する場合などもあります。
また、お客様よりテスト仕様書の作成とエビデンスを求められる場合もあります。
その際にどのような入力パターンでテストすればよいかをまとめてみました。
テストを行う前に
ブラウザのアドオン、デバッグツールを利用しましょう。
- ブラウザのデバッグで「コンソール」を出してJavaScriptのエラーが発生しないか確認しながら入力する
- ブラウザのデバッグで「ネットワーク」を出して送信する際のPOST値を確認する
いろいろな入力パターンで何を確認すればいいのか
入力中のエラー
- 入力内容によって変動する項目の制御がちゃんと効くか
送信前の確認画面でのエラー
- 入力内容にタグなどのいけない文字列を含めると、レイアウトが崩れたりしないか
- 入力したJavaScriptが実行される、フォームが改ざんされる（クロスサイトスクリプティングが発生）などが発生しないか
登録処理でのエラー
- サーバーエラー、JavaScriptエラー、PHPエラー、データベースエラーなどが発生しないか
登録後のエラー
- データが改ざんされたりしないか（SQLインジェクションが発生）
- 入力した文字が正しく登録されていなかったりしないか
- 途中で切れている
- 文字化けしている
- 空で登録されてる
- 自動応答メール
- メールが送信されなかったりしないか（宛先、ヘッダの異常など）
- 記述した内容が文字化けしていたりしないか
それでは、実際に何をどんな風にテストしていけばいいかを下記にパターンとして列挙していきます。
エラーチェック 入力パターン集
01. システム的に意味がありそうな記号
半角カンマ、クオート、ダブルクオート、スペース、ピリオド、スラッシュ、バックスラッシュ、ドル、イコール、クエスチョン、エクスクラメーション、コロン、セミコロン
入力例
,'" ./\n$=?!:;","a","b"- 送信後にシステムエラーが起きる。
- 登録したはずの値がクオーテーションによって途中で切られる。
- 登録したはずの値に変な改行が生まれる。
- 登録データのCSV出力でカンマによってカラムがおかしくなる。
- 自動応答メールで文字化けする。
02. カタカナ、半角カタカナ
カタカナの範囲を正規表現で「ァ-ンー」と定義しているTipsサイトなどがありますが、これだとちょっと漏れるカタカナ「ヴ」もあります。
また、カタカナで制限したい項目にも会社名などで「・」（なかぐろ）を入れたいケースもあるかもしれませんよね。
入力例
ヲンヰヱヴーヾ・ｧｰｭｿﾏﾞﾟ↑半角カタカナを入れたらDBで文字化け、なんてこともあるかも……。
- カタカナ入力チェックではじかれて入力できない。
- 確認画面やデータベース内、自動応答メールで文字化けする。
03. 環境依存文字
WEBシステムの多くがUTF-8になっているのでフロントページでは問題ないケースが多いですが、DBや連携するシステムが他の文字コードであったりします。
入力例
㌶Ⅲ⑳㏾㈱髙﨑- 確認画面やデータベース内、自動応答メールで文字化けする。
04. マッピングに差がある文字
UTF-8とEUCでマッピングに差がある文字。
入力例
¢£¬‖−〜―- 確認画面やデータベース内、自動応答メールで文字化けする。
05. サロゲートペア
1文字で4バイト使用する文字＝1つの文字を表すのに2つの文字コードを使用する文字（サロゲートペア）があります。
入力例
𠀋𧚄𪗱𪘚𪘂𩊠𩒐𨩱- 確認画面やデータベース内、自動応答メールで文字化けする。
- 登録先データベースのカラムサイズをオーバーフローする。（1文字3バイトで100文字までの計算をしていたのに4バイトが入ったためはみ出る）
06. 絵文字
スマートフォンから絵文字を入力してみます。
入力例
😄👀👃
- 確認画面やデータベース、自動応答メールで文字化けする。
07. EUCのサーバで文字化けする文字（いわゆる”ソ能表”）
EUCで動作するUNIX系のサーバで、Windows系の文字コード＝SJISを使用すると、特定文字での文字化けが発生することがあります。
入力例
ポソ能芸表十貼申- 確認画面やデータベース、自動応答メールで文字化けする。
08. javascript
入力例
<script>alert('Bug!!!');</script>- この場合、確認画面などでアラート「Bug!!!」が表示される。
09. HTML
CMSのような管理者が使うシステムとかブログのようなツールの場合はHTML許可の入力項目なんてのもありますが、お問い合わせフォームなどでは絶対に入らないようにしたいのがHTMLタグです。
入力例
<input type="text" value="<font color="red">- この場合、確認画面などでテキスト入力欄が出てしまったり、それ以降の文字が赤くなる。
10. HTML特殊文字
入力例
<©&- これが<©&と出てしまう場合、エスケープがされてないということで誤動作を招く恐れがある。
11. データベースに対するインジェクション
入力例
';delete from user_table;' or 1 = 1;- SQLが正しくエスケープ、バインドされていないと、「user_table（例）」が全削除されたり、重複制限するような値がオールOKで通過したりする。
12. MAX桁数
必ずマックス桁数の入力をする。inputでmaxlengthなどを指定していたり、JavaScriptで制限していたりしても、本当に制限されているかどうかも含めて一応試しましょう。
マックス桁数を入力する際に、サロゲートペア（4バイト文字）なども含んでみます。
- MAX以上が入れられてしまったり、MAXを守っているのにデータベース登録でエラーが発生したり、文字が切れたりする。
項目タイプ別
13. メールアドレス入力欄
メールアドレスの禁止文字
入力例
!=()<>,;:\@"@example.com- これらの文字が入っていてもメールが送信される処理まで行ってしまう。
14. 日付項目
入力例
2016/5/22016/05/022016/5/02↑数字を直接入れることもできる入力欄の場合、ゼロ埋めがあったりなかったり
2017/2/292017/6/31↑存在しない日付(うるう年ではないのにうるう日、存在しない末日)
- システムエラーが発生する。
15. 数値項目
入力例
(1)ゼロ (2)半角空白 (3)少数ありの数字 (4)少数以下の数字 (5)マイナス (6)全角数字
(7)上限が決まっている場合の上限を越える値、上限の値、上限１つ前の値
(8)下限が決まっている場合、下限を下回る値、下限の値、下限１つ前の値
- 想定した数値の範囲外で登録されてしまう。
16. 明細項目
意外と実施しないのですが、明細を追加していけるようなフォームの場合、必ずMAX明細数まで入力、登録テストする。
データベースの明細NOが格納されている項目があれば、その定義サイズの桁数まで入れてみる。（Integerの3桁なら、999件+1件）
- 意外とMAX登録できなかったり、登録時データベースエラーが出たりする。
動作パターン別
17. お問い合わせ、会員登録、アンケートフォームなど
- わざとエラーを出す。
エラーメッセージが間違っている。 - 全部のエラーを出す。
エラー処理自体がないなんてことも……。 - 入力途中で送信してみる。
意外と変なことになる。 - 入力途中や確認途中、完了画面でそれぞれブラウザの「戻る」「進む」を押してみる。
二重送信や重複登録が発生する場合あり。 - 入力中にエンターキーを押してみる。
いきなり送信される（それが仕様の場合もある）。 - 入力→確認→入力（編集）→確認→入力 など画面を何度も行ったり来たりしてから登録する。
入力した値がどんどん増える。
確認画面から戻った際、入力済みの値に反映もれがある。
18. カート機能などのテスト
- 商品の追加と削除を繰り返してみる。
消したのに増えたり、増やしたのに減ったり。 - 購入完了したあと、カートに戻る。
カートに中身が残る。 - カートで手続き中にそのウィンドウで別のサイトを見る。
戻ったらカートの中身が消える。 - カートで手続き中にブラウザの「戻る」「進む」など押す。
カートの中身が消えたり、中身が二倍になったりする。 - 別タブでカートを同時に開いてみたりする。
一方の処理がもう一方に反映される。 - カートで手続き中にブラウザのタブを閉じ、そのあと再びカートにいって正常に購入できるかどうか。
カートの中身が消える。
まとめ
これらのポイントを網羅した標準の単体テスト仕様書があると良いですね。
