Summit

Developers

Developers Summit 2013 Action !

自動改札機の 運賃計算プログラムのデバッグ手法 ～1040のパターンをいかにテストするか～

幡山 五郎 オムロンソーシアルソリューションズ

ソリューション事業本部

14-B-3 #devsumiB

2

１．自動改札機について

1. 自動改札機について

2. 間違えない自動改札機

3

自動改札機導入前の改札風景

１．自動改札機について

4

１．自動改札機について

＜磁気システム＞

メカ機構の 高機能化

＜ICシステム＞

情報システム化

磁気からＩＣへ求められる技術が変わってきた（高機能化→高信頼化）

ＰＡＳＭＯ導入、Suica+PASMO 2007年

1967年 初の自動改札機

2003年

1989年

1972年 ～80年

関西地区に大量普及

日本初のＳＦ（ｽﾄｱｰﾄﾞﾌｪｱ方式）導入 イオカード

1996年 複数枚処理スタート（定期＋回数券など）

ＰｉＴａＰａ導入、 Suica+ICOCA

ＩＣ化スタート（Ｓｕｉｃａ導入）

ＩＣＯＣＡ導入

2001年

2004年

2000年 共通ＳＦ：パスネット導入

日本初のＳＲ（ｽﾄｱｰﾄﾞﾗｲﾄﾞ方式）導入

1991年

1999年 Ｊスルー導入

2006年 ＴＯＩＣＡ導入、ICOCA・PiTaPa相互利用

ＩＣ乗車券全国共通化（北海道～九州の10種類） 2013年

5

切符から見た自動改札機の進化

光学パンチ方式 定期券のみ

現在の切符 （サイバネ規格改定） 磁気塗膜方式 数種類の切符

ストアードフェア・カード 改札機への直接投入 複数枚処理可能 共通利用

ICカード タッチ＆ゴー

1967年頃 1977年～ 199１年～ 200１～

１．自動改札機について

6

２．間違えない自動改札機

1. 自動改札機について

2. 間違えない自動改札機

7

２．間違えない自動改札機 ①機器シミュレータ-1

■ 従来のテストの課題 ・実機確認のためのデバッグ工数が多くかかっている

（立ち上げ、テスト券発券、確認、戻り工数）

・改札機全体のシステムデバッグが実機中心のため、時間的な制約から

網羅性が低くなっていた

発券

改札機に通して、下記を確認 「画面」「ランプ」「印字」「パンチ」 「エンコード」「回収、放出」

集計機器にて、確認

「集計」

券データ

発券している 枚数が膨大

従来の改札機ソフトウェアのテスト

8

２．間違えない自動改札機 ①機器シミュレータ-２

■ 機器シミュレータ導入の効果 ・券データを何度も利用可能

・機器内ソフトウェア間インタフェース誤りによる戻り工数低減

・自動化によりテストパターン数増加→網羅性の向上による品質向上

・デバッグ工数50％削減

PC＋ボード

券データ

PC上で表示・確認 ・「画面」「ランプ」⇒実機画面状態を表示 ・「エンコード」「回収、放出」⇒券状態を表示 ・「集計」⇒帳票を表示を表示

リアルタイムでの確認が可能。

機器シミュレータによる改札機ソフトウェアのテスト

9

例えば、関東エリアでは、ICカードなどの共通利用化により、次のような規模となっている。

① 乗降り駅と経路の組合せのみ ＞ 10３３ 通り

② ①に定期券有効区間の組合せを考慮した場合

＞ 104０ 通り

運賃計算パターン数

２．間違えない自動改札機 ②運賃計算-１

10

ＩＣ化で運賃計算が複雑化する例１： 連絡鉄道会社増加による、２駅間を結ぶルート数の増大。

Ａ社

Ｂ社

駅６

駅１

Ｃ社の参入で、駅１から駅６へ行くルートが、１本から４本に増加。 その中での最安ルートを計算することが必要になる。

駅２

駅３

Ｃ社

駅４

駅５

飛躍的に複雑化する運賃計算

２．間違えない自動改札機 ②運賃計算-２

11

ＩＣ化で運賃計算が複雑化する例２： 精算方法の多様化 チャージ払い＋定期＋チャージ払いの精算が可能に

飛躍的に複雑化する運賃計算

２．間違えない自動改札機 ②運賃計算-３

駅４ 駅１

駅２ 駅３

定期を用いない精算 = 600円 600円

定期区間 300円 200円

定期を用いた精算 = 200円+300円 = 500円

比較して 安い方が

精算経路となる

12

ＩＣ化で運賃計算が複雑化する例３： トリップ継続

飛躍的に複雑化する運賃計算

駅２と駅３とが乗換可能であれば、割引の適用可否の判断のため 駅３乗車後もこれまでの乗降情報の記録をICカード内に残す。

２．間違えない自動改札機 ②運賃計算-４

駅４ 駅３ 駅１ 駅２

４５０円

２００円 ３００円

乗換

13

運賃検証システムの目指す姿

目標２：大規模なテスト

実現方法：

２つの運賃計算ソフトウェアを突合検証 実機とは独立にソフトウェアを

作成し予想結果を自動生成

目標１：見落としのないテスト

実現方法：

網羅性のあるテストパターン作成 網羅性のあるテストパターンを

自動生成するための「ガイド」を作成

目指しているテスト

従来のテスト

２．間違えない自動改札機 ③運賃検証システム-１

14

例） ICカード（定期なし）の試験要項作成ガイド 乗り降りの駅の並びをパターン化

運賃検証テストパターン設計の課題：

① 不具合検出にはエリアごとの路線図の形状・特殊仕様の熟知が必要（属人性）

② 乗車券・乗降駅の組合わせは数が多く思いつかないパターンもありうる ↓

どのエリアでも使えて、起こりうるパターンを網羅的に含むテストパターンの

試験要項作成ガイドを利用してテストパターンを設計している

一般駅 乗換え駅 （同じ会社）

乗換え駅 （違う会社）

P1-1

P1-2

P2-1

P2-2

P2-4

P2-3

属人性なし

記号に該当する駅を当てはめればテストパターンができる

網羅的

起こりうる乗降パターンは必ずどれかのパターンにあてはまる

２．間違えない自動改札機 ③運賃検証システム-２

2社までの乗換えパターンを全て表現

15

検証実施パターン

1.E+00

1.E+02

1.E+04

1.E+06

1.E+08

1.E+10

1.E+12

1.E+14

1.E+16

1.E+18

1.E+20

1.E+22

1.E+24

1.E+26

1.E+28

1.E+30

1.E+32

1.E+34

1.E+36

1.E+38

1.E+40

1.E+42

条件

パター

ン数

禁則：

クローズド路線、P4乗車まで、IC非参入駅 絞り込みレベル１：

・4社局目は入場まで

・自2ラッチ回数1回まで

・ラッチ外連絡1とラッチ外連絡2が同じ併割範囲内

・最短最少社局数が5以上のものは削除

・重複削除

・連絡駅

・同値分割

テストパターン全数

絞り込みレベル２：

・足し算理論

・ラッチ外連絡は併割関係がある社局のみ

・メトロ自2ラッチを36→18

・p2ラッチ外連絡を併割範囲内のみ

条件1

時間とコストを考慮した検証実行可能件数ライン

全数 条件2 条件3 条件4 条件5 条件6 条件7 条件8 条件9 条件10 条件11 条件12 条件13 条件14

許容可能な絞込み ・駅の同値分割 ・自線内乗換は１回まで ・自線内乗換駅の半分が乗換対象

妥当な絞込み ・重複パターン削除 ・ラッチ外連絡は割引関係のある駅のみ ・５社にまたがるトリップは削除 ・４社目は入場まで

安全な絞込み ・クローズド路線をまたがない ・IC改札機非導入駅を削除

２．間違えない自動改札機 ③運賃検証システム-３

時間とコストを考慮した検証実行可能件数

テストパターン全数

16

特殊駅

入場駅

自線乗換

精算経路(正)

精算経路(誤)

Ａ社

Ｂ社

特殊なルールが２つ重なった例での誤り検出

共同駅２

思いつきにくい乗車経路での誤り検出

自線乗換

共同駅１ 機能（仕様）の掛け合わせパターンでの不具合傾向がある。

→機能デバッグでのテストでは限界があるため、網羅的確認

が有効である。

・特殊駅仕様

・自線２ラッチ乗車

・往復乗車判定

・共用区間

２．間違えない自動改札機 ③運賃検証システム-４

精算経路(正)

精算経路(誤)

Ｄ社

Ｃ社

17

補足.

誤った運賃計算 共同駅1(C社)で乗った→X駅(C社)で降りた →X駅(C社)で乗った→共同駅2(C社)で降りた ※ C社初乗り料金×２

正しい運賃計算 共同駅1(D社)で乗った→改札機を通る乗換(D社→C社) →共同駅2(C社)で降りた ※ C社初乗り料金＋D社初乗り料金 -乗継割引

共同駅２

思いつきにくい乗車経路での誤り検出

自線乗換

共同駅１

精算経路(正)

精算経路(誤)

Ｄ社

Ｃ社

駅X

18

２つの運賃計算ソフトウェアは、同じ間違いをすると問題点を検出できない

→ 独立にソフトウェアを開発し、課題検出率を向上させる。

1. 実機とは別のチームが開発

2. 実機とは別のプログラム言語

3. 実機とは別のアルゴリズム

4. 実機とは別の運賃データ

パターン 検証ｿﾌﾄ 実機ｿﾌﾄ 突合結果

１ 300 300 一致

２ 300 320 不一致

３ 330 300 不一致

４ 310 310 一致

正解＝３００円

独立性が低いと同じ誤りを行う確率が高くなる。

２．間違えない自動改札機 ③運賃検証システム-５

テストケース設計

テストデータ作成

突合ツール

差異解析

自動改札機

自動精算機

検証用 運賃ソフトウェア

実機用 運賃ソフトウェア

19

テスト設計 & 解析用 PC

クライアント PC （運賃計算 & 突合実行用）100台以上使用

サーバ

UPS 1000Base - HUB

２．間違えない自動改札機 ③運賃検証システム-５ 補足

• テスト件数は大幅に増加

数万件→数百万～数千万件

• ２週間～３か月で差異原因解析

• 検証用運賃ソフトウェアの品質維持が課題

20

実機用ソフトウェア 検証用ソフトウェア

計算時間 50ミリ秒以下 制限なし

メモリ使用量 約2ＭＢ 10ＭＢ～1ＧＢ

ソフトウェア開発における制約の違い

実機用ソフトウェア 検証用ソフトウェア

運賃計算方法 データをなるべく利用 運賃計算ルールどおり

運賃データ 共通運賃データ

31テーブル

基礎運賃データ

19テーブル

設計方針の違い

制約の無い検証用ソフトウェアと突合することによって、

制約から誘発されることの多い実機ソフトウェアの問題点を洗い出すことができる

２．間違えない自動改札機 ③運賃検証システム-６

21

実機用運賃ソフトウェア ・経路テーブル

・三角表

：

共通運賃データ

検証用運賃ソフトウェア

精算金額 １００円

①乗車経路を共通運賃上の経路テーブルより検索します。

②決定した経路に対して運賃算出を行います。

160円 120円

割引20円

表参道 池尻大橋

表参道→１６０円

磁気券

メトロ普通券

渋谷

精算金額算出、各種判定を行い結果を出力します。

東急

都交 ＪＲ

メトロ

埼玉

・路線ネットワーク

・サイバネデータ（路線情報） ①基礎運賃データを利用して路線ネットワークを構築します。

②路線ネットワークを探索して、想定乗車経路を全て計算します。

・基礎運賃データ

： 経路候補１ 併割20円

・割引表

・三角表

経路候補１

表参道 渋谷 池尻大橋

表参道 中目黒 池尻大橋

表参道 池尻大橋 目黒

割引20円

共用区間

120円 160円

③１つ１つの経路に対して全ての割引、ルール適用を計算します。

最安経路の計算結果、仕様に適合する計算結果 を出力します。

精算金額 ９０円

精算金額 １００円

最安経路結果 仕様に従った結果

運賃計算結果

表参道乗車

ICカード

or

精算金額 ２６０円

磁気券

ICカード

精算金額 ２５０円

精算金額 ２６０円

磁気券

ICカード （※実際の運賃とは異なります）

表参道-池尻大橋の運賃計算例

２．間違えない自動改札機 ③運賃検証システム-７

22

・実機プログラム・・・定期区間の計算起点を発駅、着駅、経由駅、交差駅

・検証プログラム・・・定期区間の計算起点を全駅

例）定期券（①駅～④駅経由～⑤駅） ①駅乗車 小児割引

①

着駅

Ａ駅

Ｂ駅

④

②

③ ⑤

【実機用ソフトウェア計算経路一覧】

①～Ａ駅経由～着駅 大人730円 小児割引400円

④～Ａ駅経由～着駅 大人710円 小児割引390円

⑤～Ａ駅経由～着駅 大人710円 小児割引390円

【検証用ソフトウェア計算経路一覧】

①～Ａ駅経由～着駅 大人730円 小児割引400円

②～Ｂ駅経由～着駅 大人730円 小児割引370円

③～Ｂ駅経由～着駅 大人730円 小児割引370円

④～Ａ駅経由～着駅 大人710円 小児割引390円

⑤～Ａ駅経由～着駅 大人710円 小児割引390円

計算していない経路が最安となる → 計算起点を制限している仕様の問題

実機最安

検証最安

２．間違えない自動改札機 ③運賃検証システム-８

③駅で定期券で降りて、切符を買う場合がもっとも安い

23

補足. 前のページの例を説明用に簡単なものに修正

①

着駅

Ａ駅

Ｂ駅

④

②

③ 50円

50円

50円

④から着駅までの大人運賃

60円

100円

大人運賃 A駅経由 50+50+50=150円 B駅経由 60+100=160円

問題. ①～④の定期を持っている小学生。①から乗って着駅で降りました。精算金額は？

大人 最安

①

着駅

Ａ駅

Ｂ駅

④

②

③ 60円

50円

50円

60円

100円

大人運賃 A駅経由 60+50+50=160円 B駅経由 60+100=160円

③から着駅までの大人運賃 （③～④の定期券の権利を放棄）

大人 最安

小児運賃 A駅経由 30+30+30=90円

小児運賃 A駅経由 30+30+30=90円 B駅経由 30+50=80円 正解

24

属人性のない網羅的なテスト

設計者の気づきにくい不具合の検出

複合的な要因による不具合の検出

実機とは違う運賃計算ソフトと突合

仕様の課題の検出

２．間違えない自動改札機 ③運賃検証システム-９

①

着駅

Ａ駅

Ｂ駅

④

②

③ ⑤

共同駅２

思いつきにくい乗車経路での誤り検出

自線乗換

共同駅１

精算経路(正)

精算経路(誤)

Ｄ社

Ｃ社

25

形式手法

数学・論理学に基づいた厳密な記述でシステムの振る舞いを表現し、ツールを利用してシステムの分析や検証を行う開発手法。

使いやすいツールの普及と共に、2000年頃から産業界での適用事例の報告が増加。

•地下鉄の無人運転用信号システム（仏）

•モバイルFeliCa ICチップ（日本）

経済産業省「情報システムの信頼性向上に関するガイドライン」 高水準の信頼性・安全性が求められるソフトウェアには形式手法の適用を推奨

設計文書 日本語

形式化 設計文書 形式言語

ツールで 検証

２．間違えない自動改札機 ④仕様書テスト-１

26

特徴 長所

厳密な言語体系 記述の誤解釈が起こりにくい 文法の誤りをツー

ルでチェック可能

使用する用語は必ず定義を記述

読み手に暗黙の知識を要求しない

ルールの適用範囲を必ず記述

記述漏れや矛盾が起こりにくい

形式仕様記述

形式的手法の一手法。形式仕様記述言語で厳密に記述した仕様を利用する開発手法。

原券発駅からの社局単独運賃による差額精算

(a原券,a精算駅,a社局) ==

let a発駅から精算駅までの単独運賃 =

社局単独の最安運賃(a原券.発駅(), a精算駅, a社局) in

if a発駅から精算駅までの単独運賃 <= a原券.全価値()

then return <不要>

else return a発駅から精算駅までの単独運賃 - a原券.全価値();

原券発駅から精算駅までの社局単独運賃が原券価値以下の場合は精算不要とし、そうでない場合

はその差額を精算金額とする。

形式記述言語VDM++で形式記述

２．間違えない自動改札機 ④仕様書テスト-２

27

形式記述結果

効果① 仕様書の誤解釈を生みやすい記述の列挙

形式記述工数：6人月 （仕様理解の時間は除く） 記述量：36クラス 9400行 仕様書の不備指摘件数： 29件 =曖昧19件＋矛盾3件＋漏れ7件

課題：可読性の向上 形式記述の精度

暗黙知

精算 仕様書

１６０ページ

仕様書翻訳 部分

８０００行

暗黙知 １４００行

日本語 形式仕様 記述言語

形式記述

効果② 再利用性の高い仕様書の構造の提案 仕様書の構造に起因する課題の洗い出し

２．間違えない自動改札機 ④仕様書テスト-３

28

補足. 誤解釈を生みやすい記述-1

分類 定義される項目

乗車券 原券価値 連絡駅 ６の字定期

路線図

線区 駅 連絡駅関係 ラッチタイプ

運賃 社局単独運賃 経路に対する運賃 乗継割引

記述１

仕様書外の暗黙知が多い

表．精算仕様書の暗黙知の例

暗黙知

精算 仕様書

１６０ページ

仕様書翻訳 部分

８０００行

暗黙知 １４００行

日本語 形式仕様 記述言語

形式記述

仕様書に書かれていないさまざまな用語が使われており、ドメイン知識の少ない設計者の仕様理解を困難にしている。

記述改善策

関連知識の体系化

使われる用語は必ず定義が必要となる。 すべての用語の型が明確化。

すべての述語の入力と出力の型が明確化。

29

補足. 誤解釈を生みやすい記述-2

複数の意味で使われる用語は各々で別の名前で定義されており、どの意味で使われている

かが明確となる

public 社局単独の最安運賃 :

「駅」* 「駅」 ==> 「金額」 ～中略～

public ノーラッチ最安運賃 :

「駅」* 「駅」 ==> 「金額」 ～中略～

public 合算運賃 :

「駅」* 「駅」 ==> 「金額」 ～中略～

発駅から着駅までの運賃が…。

日本語 形式仕様 記述言語

形式記述

○○運賃 ？？？

？

？

？

記述２

複数の意味で使われる用語

多義語の意味の区別を文脈から判断する必要がある場合、設計者の誤解釈が起こりうる。

記述改善策

多義語は明確に区別できるように記述する

30

補足. 誤解釈を生みやすい記述-3

ルールの適用範囲は明確。

形式記述

記述３

適用範囲が不明確なルール

特殊ルール間の優先順位や適用範囲が不明確なケースがあり、設計者の誤解釈が起こりうる。

記述改善策

ルールの適用範囲の明確化 ルールの優先順位の明確化

日本語

○○の場合は△△の方法で精算する。

××の場合は▽▽の方法で精算する。

ただし、精算駅がA駅の場合は…。

？

形式仕様記述言語

iｆ 精算駅＝A駅 then

精算結果＝（略） else （略）

文章で一般的なルール、表でより詳細なルールを記述することもあるが、それらの間の優先順位が明確でない場合もある。

31

補足. 仕様書の構造-1

形式記述仕様書の構造

80万行(VDM++)

8000行(VDM++)

1400行(VDM++)

鉄道会社共通1400行

鉄道会社独自6600行

路線図

乗り換え

連絡 共通利用可能な モジュール

仕様書 (日本語)

駅

運賃 乗車券

暗黙知

外部 データ 「共通利用可能なモジュール」は

他の鉄道会社の精算仕様書で再利用できる 仕様書およびプログラムのメンテナンスの向上。

32

精算仕様書に運賃計算の記述あり 精算仕様書に乗車券のエンコードの記述あり

扱える乗車券の全容が不明確 扱えない乗車券の全容が不明確

各鉄道会社で共通な仕様と独自仕様が混在 仕様変更時のメンテナンスが煩雑 共通な仕様部分に用語の不統一

路線や運賃変更時の影響範囲調査が困難 路線形態や運賃の前提が不明確 適用条件が一般化されていないルール

補足. 仕様書の構造-2

日本語仕様書のアーキテクチャの課題

路線・運賃 データ

運賃計算 経路計算

乗車券

精算 仕様書

旅客に過剰な支払いを求めない

各鉄道会社のルールのすり合わせが必要

仕様の前提条件の不統一により、他社の仕様を形式記述する際に「鉄道会社共通部分」にかなりの修正が必要となった。

33

仕様書テストの方針

精算仕様書の妥当性の確認が目的

運賃計算アルゴリズムやデータの妥当性は別の手段で確認

精算機に搭載されている精

算金額計算ソフトウェアのプログラムの一部と連携

品質を担保すべき仕様のみの形式記述でテスト可能

テストの実行速度向上

精算仕様書 (VDM++)

○駅 500円

精算金額 ○○円

入力

出力 データ

運賃計算 経路計算

アルゴリズム 運賃

運賃を 求める区間

実機プログラム(C++)

２．間違えない自動改札機 ④仕様書テスト-４

34

実機

ソフトウェア

③比較

下流工程のコスト低減

②モジュールと形式記述仕様書の連携可能 品質に影響する部分のみ形式記述する

データ プログラム

精算金額

計算部分 プログラム

（運賃・経路）

形式記述した 精算仕様書

仕様書実行

システム

○駅 500円

入力データ

①形式記述ツールで仕様書自動実行

レビューのみの仕様書テストからの脱却

仕様書による

処理結果

実機ソフトウェアの

処理結果

検出不具合 VDM仕様書のコーディングミス 26件

ミスリーディングな日本語仕様書 2件

課題 ①読みやすい形式仕様記述では処理速

度が著しく下がる例がある （例 For all …） 約10%のテストケースが実行不可能

②実機プログラムのデバッグに使うには

形式記述の精度を向上させる必要あり 実機との相違 およそ20%

実行環境

64コアのCPUを利用し、80万ケースを5日間で実行

実行速度は実機の1/10～1/20

実行結果

２．間違えない自動改札機 ④仕様書テスト-５

35

要求

要求分析

設計

実装

結合テスト

システム テスト

ユーザー テスト

詳細設計 単体テスト

仕様書

（日本語） 現状

実行 実行結果 仕様書

（VDM++）

「曖昧さ」、「漏れ」等の不備を除去

コスト 増

コスト 減

仕様書を元にテストケースが作成可能

開発全体として コストの増減なし

ピークコストが減少

目指している姿

２．間違えない自動改札機 ④仕様書テスト-６

36

２．間違えない自動改札機 ⑤まとめ

本発表では、自動改札機ソフトウェアに対する３つのテストを紹介。

機器シミュレータ

実機レスでテスト

機器内ソフトウェア間のインターフェースの確認

運賃検証システム

全テスト空間の定義、理由付でのテストケースの絞込み

２つの独立プログラムによる大規模テストの実行

仕様書テスト

開発の上流工程でテストの実行

品質を確保したい仕様のみのテスト

Summit

Developers

Developers Summit 2013 Action !

I suggest your Next Action!

Summit

Developers

Developers Summit 2013 Action !

Next Action

•テストケースの全体を定義

•そして、絞り込み

M Y R E C O M M E N D N E X T A C T I O N !

Summit

Developers

Developers Summit 2013 Action !

It’s your turn.