自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（中編）

9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み　厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。

本記事は、前編、中編、後編の3部構成です。いまお読みのページは中編です。

自動改札機の制御は1000件くらいのテスト

さて、次は間違えない自動改札機の話です。ここからソフトウェアの話になります。

1つは運賃計算。この切符はこの駅で降りられるのか、というもの。そしてもう1つは自動改札の制御。ランプを光らせるとか、切符を回収するとかです。

まずはその自動改札の扉の開閉や画面などの制御のテスト。昔は実機で確認していました。みんなでいろんな切符を入れて、合ってるかどうかという項目をチェックしていました。昔は忙しくなるとみんなでガーッとやっていましたが、さすがに最近は頑張ってソフトウェア的にテストできるようになりました。これで券を作る必要もなくなり、テストパターン数も増加して品質も改善しましたし、デバッグ工数も削減できたので開発コストも下がりました。

制御部はこれでだいたい1000件くらいのテストで済みます。

運賃計算の何が大変か？

しかし運賃計算は1000件のテストでは全然足りません。

そもそも関東の全部の運賃パターンを計算してみると10の40乗通りくらい。これを計算する運賃計算ソフトウェアの正しさを確認するためには、なんとかしてテストしなければいけないので運賃検証システムを作りました。

そもそも運賃計算の何が大変なのでしょう。

まず駅1で乗って駅6で降りたとします。簡単な例ですが、これでも連絡鉄道会社が入ると2駅間のルートが複雑になります。運賃計算とは、この中から最も安い運賃で計算する、という原則があります。

さらにICカードには定期券の機能も入っています。そうすると、途中で定期を使っているかもしれません。定期を使った場合と使わなかった場合を両方計算しなければなりません。定期が入ることがふたつめの難しさになってくると。

いまこうした話をするのは、これがテストの話をするときにいかにそれが大変かにつながってくるので。

さらに、乗り継ぎ割引というのがあります。駅2で降りて駅3で乗り継ぐと運賃を割り引くもの。これは計算するのに過去のデータ（どの駅で降りたか）をもっていなければいけません。このパターンもいくつもあります。

違う鉄道会社、例えば新宿で京王線から丸ノ内線に乗り換えた場合もありますが、新宿で乗り継げばなんでも割引になるわけではなく、京王線で笹塚から新宿のあいだに乗った人について、割引料金が京王線が10円、東京メトロには20円とか、こういう割引の表がばーっとあります。

乗り継ぎ割引の乗り換えは運賃計算の鬼門のひとつで、最大4社くらいの乗り継いできたデータを持っていなければなりませんし、割引範囲もありますし、乗り継ぎ時間もありますし、方向性もあります。これもマニアックな話ですが、同じ乗り継ぎでもこっちの方向は10円割引だけれど逆方向だと20円割引とか、どういう経緯でできたのか分かりませんがそういうのもあります。

運賃計算の網羅的パターンをどうやって作る？

こうした運賃計算が間違っていないかどうか、検証システムを作るわけです。

目指しているのは見落としのないテスト。従来のテストよりも網羅性を高めた見落としのないものを作りましょうと。そして大規模なテストをしましょうと。

まずは網羅性の話からします。

網羅性のあるテストを作るには、運賃に関わるいろんなことを知っていなければなりません。しかし、思いつくパターンだけやっていても網羅性のあるものを作るのは無理です。

属人性をなくして、網羅性のあるテストパターンを作るために2つのステップを踏んでいます。

まずステップ1。これはICカードの定期券なしで、2社までの乗り換えパターンを図形化しています。こうすると、すべての乗り換えパターンを網羅していますよと。

△は、改札機を通る乗り換えをして次の電鉄会社へと乗り換えることを示しています。これは2社の乗り換えパターンでいちばんよくあって、京王線の笹塚から乗って新宿で降りて、丸ノ内線に乗って大手町で降りましたと。

また、電車を降りずに乗り換えるパターン、改札機を通るパターンと両方あります。2社の乗り換えで考えれば、この絵の中に2社のパターンが必ず少なくとも全部含まれています。

こうやって図を作って、駅を当てはめて掛け合わせていけば、完全に網羅的なテストパターンができます。

完全に網羅的なパターンができたのはいいのですが、いらないパターンも含まれていますし、全部で10の40乗パターンもあるので現実には全部のテストはできません。

そこでステップ2でパターンを絞っていきます。これは3段階あります。

まず「安全な絞り込み」。現実に路線をまたがないようなパターン、例えばディズニーリゾートラインの駅からいきなり新宿にはこれないので。それからIC改札機が導入されていない駅を削除します。

次に「妥当な絞り込み」。よく考えればテストしなくてもほぼリスクはないだろうというのを絞っていきます。例えば、笹塚から新宿、というパターンは、笹塚から新宿で乗り換えて大手町というパターンでテストするからいらないだろう、とか。

それでもまだ10の26乗くらい残ります。そこで最後に泣く泣く「許容可能な絞り込み」として、同値分割などをしています。例えば、路線内の隣同士の駅は1つの代表駅にしてしまおうとか、自線内の乗り換えは1回までにしようとか。これでパターンを1000万件くらいに絞り込んでいます。この絞り込みは本当に割り切りで、実行可能な量のパターンにしていくと。

こうやって網羅的なものから絞り込んでいくことのいいところは、テストできていないのがどこなのか、分かっているということです。なぜこのテストをやっていなかったか、という理由が分かるし、バグがすり抜けてしまうこともありますが、それはどうしてなのか、納得できるんですね。

≫次の記事では、大規模なテストを効率化する手法として形式手法の可能性について解説しています。