Upload
developers-summit
View
11.531
Download
6
Embed Size (px)
DESCRIPTION
鉄道の自動改札機に搭載されている運賃計算プログラムが扱う乗車券と経路の組み合わせのパターン数は10の40乗を超えており、全パターンのテストを行うことは不可能です。 本講演では、10の40乗のパターンを間違えずに計算するために実施している「運賃計算プログラムの大規模自動検証」の方法を紹介します。
Citation preview
Summit
Developers
Developers Summit 2013 Action !
自動改札機の 運賃計算プログラムのデバッグ手法 ~1040のパターンをいかにテストするか~
幡山 五郎 オムロンソーシアルソリューションズ
ソリューション事業本部
14-B-3 #devsumiB
2
1.自動改札機について
1. 自動改札機について
2. 間違えない自動改札機
3
自動改札機導入前の改札風景
1.自動改札機について
4
1.自動改札機について
<磁気システム>
メカ機構の 高機能化
<ICシステム>
情報システム化
磁気からICへ求められる技術が変わってきた(高機能化→高信頼化)
PASMO導入、Suica+PASMO 2007年
1967年 初の自動改札機
2003年
1989年
1972年 ~80年
関西地区に大量普及
日本初のSF(ストアードフェア方式)導入 イオカード
1996年 複数枚処理スタート(定期+回数券など)
PiTaPa導入、 Suica+ICOCA
IC化スタート(Suica導入)
ICOCA導入
2001年
2004年
2000年 共通SF:パスネット導入
日本初のSR(ストアードライド方式)導入
1991年
1999年 Jスルー導入
2006年 TOICA導入、ICOCA・PiTaPa相互利用
IC乗車券全国共通化(北海道~九州の10種類) 2013年
5
切符から見た自動改札機の進化
光学パンチ方式 定期券のみ
現在の切符 (サイバネ規格改定) 磁気塗膜方式 数種類の切符
ストアードフェア・カード 改札機への直接投入 複数枚処理可能 共通利用
ICカード タッチ&ゴー
1967年頃 1977年~ 1991年~ 2001~
1.自動改札機について
6
2.間違えない自動改札機
1. 自動改札機について
2. 間違えない自動改札機
7
2.間違えない自動改札機 ①機器シミュレータ-1
■ 従来のテストの課題 ・実機確認のためのデバッグ工数が多くかかっている
(立ち上げ、テスト券発券、確認、戻り工数)
・改札機全体のシステムデバッグが実機中心のため、時間的な制約から
網羅性が低くなっていた
発券
改札機に通して、下記を確認 「画面」「ランプ」「印字」「パンチ」 「エンコード」「回収、放出」
集計機器にて、確認
「集計」
券データ
発券している 枚数が膨大
従来の改札機ソフトウェアのテスト
8
2.間違えない自動改札機 ①機器シミュレータ-2
■ 機器シミュレータ導入の効果 ・券データを何度も利用可能
・機器内ソフトウェア間インタフェース誤りによる戻り工数低減
・自動化によりテストパターン数増加→網羅性の向上による品質向上
・デバッグ工数50%削減
PC+ボード
券データ
PC上で表示・確認 ・「画面」「ランプ」⇒実機画面状態を表示 ・「エンコード」「回収、放出」⇒券状態を表示 ・「集計」⇒帳票を表示を表示
リアルタイムでの確認が可能。
機器シミュレータによる改札機ソフトウェアのテスト
9
例えば、関東エリアでは、ICカードなどの共通利用化により、次のような規模となっている。
① 乗降り駅と経路の組合せのみ > 1033 通り
② ①に定期券有効区間の組合せを考慮した場合
> 1040 通り
運賃計算パターン数
2.間違えない自動改札機 ②運賃計算-1
10
IC化で運賃計算が複雑化する例1: 連絡鉄道会社増加による、2駅間を結ぶルート数の増大。
A社
B社
駅6
駅1
C社の参入で、駅1から駅6へ行くルートが、1本から4本に増加。 その中での最安ルートを計算することが必要になる。
駅2
駅3
C社
駅4
駅5
飛躍的に複雑化する運賃計算
2.間違えない自動改札機 ②運賃計算-2
11
IC化で運賃計算が複雑化する例2: 精算方法の多様化 チャージ払い+定期+チャージ払いの精算が可能に
飛躍的に複雑化する運賃計算
2.間違えない自動改札機 ②運賃計算-3
駅4 駅1
駅2 駅3
定期を用いない精算 = 600円 600円
定期区間 300円 200円
定期を用いた精算 = 200円+300円 = 500円
比較して 安い方が
精算経路となる
12
IC化で運賃計算が複雑化する例3: トリップ継続
飛躍的に複雑化する運賃計算
駅2と駅3とが乗換可能であれば、割引の適用可否の判断のため 駅3乗車後もこれまでの乗降情報の記録をICカード内に残す。
2.間違えない自動改札機 ②運賃計算-4
駅4 駅3 駅1 駅2
450円
200円 300円
乗換
13
運賃検証システムの目指す姿
目標2:大規模なテスト
実現方法:
2つの運賃計算ソフトウェアを突合検証 実機とは独立にソフトウェアを
作成し予想結果を自動生成
目標1:見落としのないテスト
実現方法:
網羅性のあるテストパターン作成 網羅性のあるテストパターンを
自動生成するための「ガイド」を作成
目指しているテスト
従来のテスト
2.間違えない自動改札機 ③運賃検証システム-1
14
例) ICカード(定期なし)の試験要項作成ガイド 乗り降りの駅の並びをパターン化
運賃検証テストパターン設計の課題:
① 不具合検出にはエリアごとの路線図の形状・特殊仕様の熟知が必要(属人性)
② 乗車券・乗降駅の組合わせは数が多く思いつかないパターンもありうる ↓
どのエリアでも使えて、起こりうるパターンを網羅的に含むテストパターンの
試験要項作成ガイドを利用してテストパターンを設計している
一般駅 乗換え駅 (同じ会社)
乗換え駅 (違う会社)
P1-1
P1-2
P2-1
P2-2
P2-4
P2-3
属人性なし
記号に該当する駅を当てはめればテストパターンができる
網羅的
起こりうる乗降パターンは必ずどれかのパターンにあてはまる
2.間違えない自動改札機 ③運賃検証システム-2
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非参入駅 絞り込みレベル1:
・4社局目は入場まで
・自2ラッチ回数1回まで
・ラッチ外連絡1とラッチ外連絡2が同じ併割範囲内
・最短最少社局数が5以上のものは削除
・重複削除
・連絡駅
・同値分割
テストパターン全数
絞り込みレベル2:
・足し算理論
・ラッチ外連絡は併割関係がある社局のみ
・メトロ自2ラッチを36→18
・p2ラッチ外連絡を併割範囲内のみ
条件1
時間とコストを考慮した検証実行可能件数ライン
全数 条件2 条件3 条件4 条件5 条件6 条件7 条件8 条件9 条件10 条件11 条件12 条件13 条件14
許容可能な絞込み ・駅の同値分割 ・自線内乗換は1回まで ・自線内乗換駅の半分が乗換対象
妥当な絞込み ・重複パターン削除 ・ラッチ外連絡は割引関係のある駅のみ ・5社にまたがるトリップは削除 ・4社目は入場まで
安全な絞込み ・クローズド路線をまたがない ・IC改札機非導入駅を削除
2.間違えない自動改札機 ③運賃検証システム-3
時間とコストを考慮した検証実行可能件数
テストパターン全数
16
特殊駅
入場駅
自線乗換
精算経路(正)
精算経路(誤)
A社
B社
特殊なルールが2つ重なった例での誤り検出
共同駅2
思いつきにくい乗車経路での誤り検出
自線乗換
共同駅1 機能(仕様)の掛け合わせパターンでの不具合傾向がある。
→機能デバッグでのテストでは限界があるため、網羅的確認
が有効である。
・特殊駅仕様
・自線2ラッチ乗車
・往復乗車判定
・共用区間
2.間違えない自動改札機 ③運賃検証システム-4
精算経路(正)
精算経路(誤)
D社
C社
17
補足.
誤った運賃計算 共同駅1(C社)で乗った→X駅(C社)で降りた →X駅(C社)で乗った→共同駅2(C社)で降りた ※ C社初乗り料金×2
正しい運賃計算 共同駅1(D社)で乗った→改札機を通る乗換(D社→C社) →共同駅2(C社)で降りた ※ C社初乗り料金+D社初乗り料金 -乗継割引
共同駅2
思いつきにくい乗車経路での誤り検出
自線乗換
共同駅1
精算経路(正)
精算経路(誤)
D社
C社
駅X
18
2つの運賃計算ソフトウェアは、同じ間違いをすると問題点を検出できない
→ 独立にソフトウェアを開発し、課題検出率を向上させる。
1. 実機とは別のチームが開発
2. 実機とは別のプログラム言語
3. 実機とは別のアルゴリズム
4. 実機とは別の運賃データ
パターン 検証ソフト 実機ソフト 突合結果
1 300 300 一致
2 300 320 不一致
3 330 300 不一致
4 310 310 一致
正解=300円
独立性が低いと同じ誤りを行う確率が高くなる。
2.間違えない自動改札機 ③運賃検証システム-5
テストケース設計
テストデータ作成
突合ツール
差異解析
自動改札機
自動精算機
検証用 運賃ソフトウェア
実機用 運賃ソフトウェア
19
テスト設計 & 解析用 PC
クライアント PC (運賃計算 & 突合実行用)100台以上使用
サーバ
UPS 1000Base - HUB
2.間違えない自動改札機 ③運賃検証システム-5 補足
• テスト件数は大幅に増加
数万件→数百万~数千万件
• 2週間~3か月で差異原因解析
• 検証用運賃ソフトウェアの品質維持が課題
20
実機用ソフトウェア 検証用ソフトウェア
計算時間 50ミリ秒以下 制限なし
メモリ使用量 約2MB 10MB~1GB
ソフトウェア開発における制約の違い
実機用ソフトウェア 検証用ソフトウェア
運賃計算方法 データをなるべく利用 運賃計算ルールどおり
運賃データ 共通運賃データ
31テーブル
基礎運賃データ
19テーブル
設計方針の違い
制約の無い検証用ソフトウェアと突合することによって、
制約から誘発されることの多い実機ソフトウェアの問題点を洗い出すことができる
2.間違えない自動改札機 ③運賃検証システム-6
21
実機用運賃ソフトウェア ・経路テーブル
・三角表
:
共通運賃データ
検証用運賃ソフトウェア
精算金額 100円
①乗車経路を共通運賃上の経路テーブルより検索します。
②決定した経路に対して運賃算出を行います。
160円 120円
割引20円
表参道 池尻大橋
表参道→160円
磁気券
メトロ普通券
渋谷
精算金額算出、各種判定を行い結果を出力します。
東急
都交 JR
メトロ
埼玉
・路線ネットワーク
・サイバネデータ(路線情報) ①基礎運賃データを利用して路線ネットワークを構築します。
②路線ネットワークを探索して、想定乗車経路を全て計算します。
・基礎運賃データ
: 経路候補1 併割20円
・割引表
・三角表
経路候補1
表参道 渋谷 池尻大橋
表参道 中目黒 池尻大橋
表参道 池尻大橋 目黒
割引20円
共用区間
120円 160円
③1つ1つの経路に対して全ての割引、ルール適用を計算します。
最安経路の計算結果、仕様に適合する計算結果 を出力します。
精算金額 90円
精算金額 100円
最安経路結果 仕様に従った結果
運賃計算結果
表参道乗車
ICカード
or
精算金額 260円
磁気券
ICカード
精算金額 250円
精算金額 260円
磁気券
ICカード (※実際の運賃とは異なります)
表参道-池尻大橋の運賃計算例
2.間違えない自動改札機 ③運賃検証システム-7
22
・実機プログラム・・・定期区間の計算起点を発駅、着駅、経由駅、交差駅
・検証プログラム・・・定期区間の計算起点を全駅
例)定期券(①駅~④駅経由~⑤駅) ①駅乗車 小児割引
①
着駅
A駅
B駅
④
②
③ ⑤
【実機用ソフトウェア計算経路一覧】
①~A駅経由~着駅 大人730円 小児割引400円
④~A駅経由~着駅 大人710円 小児割引390円
⑤~A駅経由~着駅 大人710円 小児割引390円
【検証用ソフトウェア計算経路一覧】
①~A駅経由~着駅 大人730円 小児割引400円
②~B駅経由~着駅 大人730円 小児割引370円
③~B駅経由~着駅 大人730円 小児割引370円
④~A駅経由~着駅 大人710円 小児割引390円
⑤~A駅経由~着駅 大人710円 小児割引390円
計算していない経路が最安となる → 計算起点を制限している仕様の問題
実機最安
検証最安
2.間違えない自動改札機 ③運賃検証システム-8
③駅で定期券で降りて、切符を買う場合がもっとも安い
23
補足. 前のページの例を説明用に簡単なものに修正
①
着駅
A駅
B駅
④
②
③ 50円
50円
50円
④から着駅までの大人運賃
60円
100円
大人運賃 A駅経由 50+50+50=150円 B駅経由 60+100=160円
問題. ①~④の定期を持っている小学生。①から乗って着駅で降りました。精算金額は?
大人 最安
①
着駅
A駅
B駅
④
②
③ 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
属人性のない網羅的なテスト
設計者の気づきにくい不具合の検出
複合的な要因による不具合の検出
実機とは違う運賃計算ソフトと突合
仕様の課題の検出
2.間違えない自動改札機 ③運賃検証システム-9
①
着駅
A駅
B駅
④
②
③ ⑤
共同駅2
思いつきにくい乗車経路での誤り検出
自線乗換
共同駅1
精算経路(正)
精算経路(誤)
D社
C社
25
形式手法
数学・論理学に基づいた厳密な記述でシステムの振る舞いを表現し、ツールを利用してシステムの分析や検証を行う開発手法。
使いやすいツールの普及と共に、2000年頃から産業界での適用事例の報告が増加。
•地下鉄の無人運転用信号システム(仏)
•モバイルFeliCa ICチップ(日本)
経済産業省「情報システムの信頼性向上に関するガイドライン」 高水準の信頼性・安全性が求められるソフトウェアには形式手法の適用を推奨
設計文書 日本語
形式化 設計文書 形式言語
ツールで 検証
2.間違えない自動改札機 ④仕様書テスト-1
26
特徴 長所
厳密な言語体系 記述の誤解釈が起こりにくい 文法の誤りをツー
ルでチェック可能
使用する用語は必ず定義を記述
読み手に暗黙の知識を要求しない
ルールの適用範囲を必ず記述
記述漏れや矛盾が起こりにくい
形式仕様記述
形式的手法の一手法。形式仕様記述言語で厳密に記述した仕様を利用する開発手法。
原券発駅からの社局単独運賃による差額精算
(a原券,a精算駅,a社局) ==
let a発駅から精算駅までの単独運賃 =
社局単独の最安運賃(a原券.発駅(), a精算駅, a社局) in
if a発駅から精算駅までの単独運賃 <= a原券.全価値()
then return <不要>
else return a発駅から精算駅までの単独運賃 - a原券.全価値();
原券発駅から精算駅までの社局単独運賃が原券価値以下の場合は精算不要とし、そうでない場合
はその差額を精算金額とする。
形式記述言語VDM++で形式記述
2.間違えない自動改札機 ④仕様書テスト-2
27
形式記述結果
効果① 仕様書の誤解釈を生みやすい記述の列挙
形式記述工数:6人月 (仕様理解の時間は除く) 記述量:36クラス 9400行 仕様書の不備指摘件数: 29件 =曖昧19件+矛盾3件+漏れ7件
課題:可読性の向上 形式記述の精度
暗黙知
精算 仕様書
160ページ
仕様書翻訳 部分
8000行
暗黙知 1400行
日本語 形式仕様 記述言語
形式記述
効果② 再利用性の高い仕様書の構造の提案 仕様書の構造に起因する課題の洗い出し
2.間違えない自動改札機 ④仕様書テスト-3
28
補足. 誤解釈を生みやすい記述-1
分類 定義される項目
乗車券 原券価値 連絡駅 6の字定期
路線図
線区 駅 連絡駅関係 ラッチタイプ
運賃 社局単独運賃 経路に対する運賃 乗継割引
記述1
仕様書外の暗黙知が多い
表.精算仕様書の暗黙知の例
暗黙知
精算 仕様書
160ページ
仕様書翻訳 部分
8000行
暗黙知 1400行
日本語 形式仕様 記述言語
形式記述
仕様書に書かれていないさまざまな用語が使われており、ドメイン知識の少ない設計者の仕様理解を困難にしている。
記述改善策
関連知識の体系化
使われる用語は必ず定義が必要となる。 すべての用語の型が明確化。
すべての述語の入力と出力の型が明確化。
29
補足. 誤解釈を生みやすい記述-2
複数の意味で使われる用語は各々で別の名前で定義されており、どの意味で使われている
かが明確となる
public 社局単独の最安運賃 :
「駅」* 「駅」 ==> 「金額」 ~中略~
public ノーラッチ最安運賃 :
「駅」* 「駅」 ==> 「金額」 ~中略~
public 合算運賃 :
「駅」* 「駅」 ==> 「金額」 ~中略~
発駅から着駅までの運賃が…。
日本語 形式仕様 記述言語
形式記述
○○運賃 ???
?
?
?
記述2
複数の意味で使われる用語
多義語の意味の区別を文脈から判断する必要がある場合、設計者の誤解釈が起こりうる。
記述改善策
多義語は明確に区別できるように記述する
30
補足. 誤解釈を生みやすい記述-3
ルールの適用範囲は明確。
形式記述
記述3
適用範囲が不明確なルール
特殊ルール間の優先順位や適用範囲が不明確なケースがあり、設計者の誤解釈が起こりうる。
記述改善策
ルールの適用範囲の明確化 ルールの優先順位の明確化
日本語
○○の場合は△△の方法で精算する。
××の場合は▽▽の方法で精算する。
ただし、精算駅がA駅の場合は…。
?
形式仕様記述言語
if 精算駅=A駅 then
精算結果=(略) else (略)
文章で一般的なルール、表でより詳細なルールを記述することもあるが、それらの間の優先順位が明確でない場合もある。
31
補足. 仕様書の構造-1
形式記述仕様書の構造
80万行(VDM++)
8000行(VDM++)
1400行(VDM++)
鉄道会社共通1400行
鉄道会社独自6600行
路線図
乗り換え
連絡 共通利用可能な モジュール
仕様書 (日本語)
駅
運賃 乗車券
暗黙知
外部 データ 「共通利用可能なモジュール」は
他の鉄道会社の精算仕様書で再利用できる 仕様書およびプログラムのメンテナンスの向上。
32
精算仕様書に運賃計算の記述あり 精算仕様書に乗車券のエンコードの記述あり
扱える乗車券の全容が不明確 扱えない乗車券の全容が不明確
各鉄道会社で共通な仕様と独自仕様が混在 仕様変更時のメンテナンスが煩雑 共通な仕様部分に用語の不統一
路線や運賃変更時の影響範囲調査が困難 路線形態や運賃の前提が不明確 適用条件が一般化されていないルール
補足. 仕様書の構造-2
日本語仕様書のアーキテクチャの課題
路線・運賃 データ
運賃計算 経路計算
乗車券
精算 仕様書
旅客に過剰な支払いを求めない
各鉄道会社のルールのすり合わせが必要
仕様の前提条件の不統一により、他社の仕様を形式記述する際に「鉄道会社共通部分」にかなりの修正が必要となった。
33
仕様書テストの方針
精算仕様書の妥当性の確認が目的
運賃計算アルゴリズムやデータの妥当性は別の手段で確認
精算機に搭載されている精
算金額計算ソフトウェアのプログラムの一部と連携
品質を担保すべき仕様のみの形式記述でテスト可能
テストの実行速度向上
精算仕様書 (VDM++)
○駅 500円
精算金額 ○○円
入力
出力 データ
運賃計算 経路計算
アルゴリズム 運賃
運賃を 求める区間
実機プログラム(C++)
2.間違えない自動改札機 ④仕様書テスト-4
34
実機
ソフトウェア
③比較
下流工程のコスト低減
②モジュールと形式記述仕様書の連携可能 品質に影響する部分のみ形式記述する
データ プログラム
精算金額
計算部分 プログラム
(運賃・経路)
形式記述した 精算仕様書
仕様書実行
システム
○駅 500円
入力データ
①形式記述ツールで仕様書自動実行
レビューのみの仕様書テストからの脱却
仕様書による
処理結果
実機ソフトウェアの
処理結果
検出不具合 VDM仕様書のコーディングミス 26件
ミスリーディングな日本語仕様書 2件
課題 ①読みやすい形式仕様記述では処理速
度が著しく下がる例がある (例 For all …) 約10%のテストケースが実行不可能
②実機プログラムのデバッグに使うには
形式記述の精度を向上させる必要あり 実機との相違 およそ20%
実行環境
64コアのCPUを利用し、80万ケースを5日間で実行
実行速度は実機の1/10~1/20
実行結果
2.間違えない自動改札機 ④仕様書テスト-5
35
要求
要求分析
設計
実装
結合テスト
システム テスト
ユーザー テスト
詳細設計 単体テスト
仕様書
(日本語) 現状
実行 実行結果 仕様書
(VDM++)
「曖昧さ」、「漏れ」等の不備を除去
コスト 増
コスト 減
仕様書を元にテストケースが作成可能
開発全体として コストの増減なし
ピークコストが減少
目指している姿
2.間違えない自動改札機 ④仕様書テスト-6
36
2.間違えない自動改札機 ⑤まとめ
本発表では、自動改札機ソフトウェアに対する3つのテストを紹介。
機器シミュレータ
実機レスでテスト
機器内ソフトウェア間のインターフェースの確認
運賃検証システム
全テスト空間の定義、理由付でのテストケースの絞込み
2つの独立プログラムによる大規模テストの実行
仕様書テスト
開発の上流工程でテストの実行
品質を確保したい仕様のみのテスト
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.