_ [つくる][etc] 大大大規模テスト(10⁴⁰通り)

デブサミ行ってきた。聞いた講座は1つ。自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか。
テスト件数が爆発しているぞさあどうするのお話。

• 裏向けたら表向けて出てくる
• 紙の切符は0.6秒で出てくる
• ICカード(Suicaとか)は0.2秒で全処理を終える必要がある
• 料金は各種割引を考慮して最安を選ぶ
• 5路線目は考えなくていい
• 大阪圏では相互乗り入れが少なかったので自動改札が作り易かった
• 首都圏の駅は3000個もある。マジ？
• ICカードのせいで相互乗り入れ増える→件数爆発
• 大勢で切符持って歩きまくるは都市伝説じゃなかった
• でもそれだとテスト件数がO(10²)。疲れるから。
• ICカードのふりをするテスト用の装置を作っても件数はO(10³)
• そもそもテストケース作成に属人性があった
• 廃するべく、機械的に全パターン作った→10⁴⁰　むり。しぬ
• 不要なケース削る。その過程で「削った理由」をはっきりさせることで残りのケース(を通した結果)に自信がつく？(これ肝でした)
• 10⁷くらいになった
• それでも全部実行すると2w - 2months かかる。(テストを機械でぶん回してこんなにかかるのか聞きたかった)
• ケース数が多すぎて各ケースの正例を作れない。→別のアルゴリズム&別部隊&別言語で、対照用のプログラムをもう1つ作った(C++とJavaだった)→出力が一致すれば(たぶん)正解扱い、食い違ったら調べる。まあ両方間違っていることもあるだろう。
• やってみるととんでもない「そのテストケース無理！思いつかん！！！！」みたいなのは出てくる
• 仕様を仕様記述専用言語で書き直すとページ数が3割くらい増えた
  →仕様にもかなりの暗黙知が含まれていたことが発覚
• 全ての言葉を定義し直して書き直すことで仕様書がロジカルになってよかった(副作用)

おまけ:<sup>のタグを初めて使った。
テスト実行方法&結果データ照合方法とかも聞けばよかったなー。