内容別リスト/基本/テスト - 競技プログラミング用 知識集積所

---

---

雑な説明

プログラムをきちんと書いたつもりでも、本当に意図通りに書けているとは限らない。
そのため、プログラムが意図通り動作するかを実際に動かして確認する必要がある。
とはいえ、入力を闇雲に与えるだけではまともな確認にはならない。
効率よくテストを行うために必要な知識をここに記載する。

テストの注意点

どんな入力例を与える場合でも、実際に与える前に以下の2つは必ず意識する。

• この入力例は何を確認するために与えているのか
• この入力例に対する正しい出力は何なのか

これらのどちらかが欠けると、プログラムがよく見れば変な動作をしているのに、見落として「正常動作、ヨシ！」としてしまう危険性が大幅に上昇する。

テストの種類

サンプルテスト

問題文にある入力例を実際に試し、サンプル出力と一致するか確認する。
最初に必ず行う基本的なテストであり、どんな問題でも最低限行うべきテストである。
ブラウザをChromeにして、AtCoder Easy Testスクリプトを導入すると、このテストを全入力例に対して行ってから提出するのをワンボタンでできる。

注意点として、"Yes"と"yes"のような細かい表記ミスは見落としがちなので丁寧に確認すること。
また、正解となる出力が複数ある場合は、出力例と一致しない結果になっても問題ない場合があるので、その場合は自分の解答が正答かどうか丁寧に確認すること。

誤答しやすい入力を意図的に省いてある問題もあるので、このテストが通ったからと言って過信は禁物。
特に、非常に長い数列の入力などが入力例に掲載されていることはまずないので、注意が必要。

自作テスト

自分で入力を作り、手計算した答えとプログラムの出力を比較する。
問題で与えられている入力例は、誤答しやすい入力を意図的に載せていない場合がある。
「入力例には存在しないけど、こういうケースは何か起こりそう」と感じるものがあったら、自作テストを行うとよい。
何か起こりそうな入力例は、次以降の項目も参照。
冒頭の注意にあるように、実行前に手計算で正しい出力を求めておくこと。

コーナーケースのテスト

特殊な入力のときに特殊な対応をしなければならない場合に、それができているかのテスト。
詳しくはコーナーケース参照。
提出前にやるのはもちろんだが、提出結果が1つ2つだけWAだったときはこれを再度やってみるとよい。

境界値テスト

条件が切り替わる直前直後の値を試す。
例えば「Nは1以上500以下の整数で、その各桁の数の合計を求める」という場合、

• 制約の下限と上限である、1と500
  • 本来はここで0と501で入力不正を検出できるかのテストも必要だが、競プロでは制約外入力への対応は略してよい
• 1桁と2桁が切り替わる直前直後である、9と10
• 2桁と3桁が切り替わる直前直後である、99と100

を試すことになる。

主に、if分岐の条件の不等号間違い、ループ処理の1回不足や1回過剰、といった論理エラーを検出できる。
また、全く気づいていなかったコーナーケースが偶然検出できることもある。

ある程度処理を行った先の条件分岐の境界値テストだと、そこで狙った値ぴったりになっているような入力例を作るのが大変なこともある。
特に、答えが最大になるケースは理論的に探すのが不可能な場合も。

場合分けのテスト

if分岐や考察上の場合分けがあるなら、それぞれの場合に対応する入力を試す。
サンプルテストが実は片方の分岐だけしか通らず、提出後にもう片方のエラーでWAすることがある。
複数の入力例で、コード上の全ての分岐を通るように入力例を取りそろえること（分岐網羅）。

&&を使っている場合は、それぞれの条件が1つだけfalseになる例を用意したり、||の場合は逆に1つだけtrueになる例も用意するといいかもしれない。（条件網羅を少し簡略化したもの）

ストレステスト

大量のデータを処理させて、何か異常が起きないか試してみるテスト。
この場では、巨大な数列などの入力に対してTLEしないかどうかのテストを意味する。（下の項目の、ランダムテストをストレステストと呼ぶ人もいる）
入力例に絶対に存在しないテストなのでやる価値は高いが、入力データを用意するのが大変。

ランダムテスト

小さい入力をランダムに大量に作り、愚直解と本解の出力を比較する。
手で見つけにくいミスを発見できることがある。
自動で入力例を生成するコードと、愚直解を出力するコード、結果が一致するか確認するコードを書かなければいけないので時間はかなりかかる。