既存開発プロセスへのモデルベーステスト手法の適用
張暁 晶†1丹 野 治

門†1星 野隆†1

テスト項目やテストデータの自動生成を行うモデルベーステスト手法を，従来の開発プロセスとの親和性を高める方法を提案し，開発現場への適用を容易にする方法について議論する．

How to Integrate Model-based Testing Technology
into Traditional Development Process
Xiaojing ZHANG ,†1 Haruto TANNO †1
and Takashi HOSHINO†1
The authors would like to discuss on how to integrate the model-based testing techniquessuch as test case extraction and test data generation into traditional development process.

1. は じ め に記述を前提としている．一方，既存開発プロセスにおいて，設計工程の成果物として，外部設計書，内部設抽象モデルに基づいてテスト工程成果物を自動生成

計書，プログラム設計書など各種の設計書を作成し，するモデルベーステスト（以降，MBT）手法は，ソまたテスト工程の成果物として，テスト項目表などをフトウェア開発のテスト工程のコスト削減に寄与でき作成することが定められている．多くの開発現場におると期待されている．しかし，既に開発標準が規定さいて，これらの設計文書やテスト文書は，MS Oﬃceれている現場に新しい手法を導入するには困難を伴文書の形式で，一定のテンプレートに準拠した形で記う．本ワークショップにおいては，既存 MBT 手法を述される．抽象モデルの記述は，こうした従来の執筆拡張することで従来の開発プロセスとの親和性を高め作業を代替するものではないため，開発案件ごとの技る方法を提案し，適用を容易にする方法について議論

術者が記法を学び，新たな成果物を作成することとなしたい．

る．特に開発案件が改造開発である場合，過去の開発

2. モデルベーステストを適用する際の障壁
MBT を用いたテスト項目抽出手法は，組み込みシステムのドメインで報告されている少数の利用事例を除き，開発現場への導入はまだあまりなされていない．

で作成された設計文書を再利用して加工できないため，母体を含めたシステム全体のモデルを新規に作成するとしたらさらに大きなコストとなる．

2.2 従来の手作業によるテスト項目抽出を代替できるかが不明

多くの開発現場では，既に「開発標準」が規定されて第二の障壁は，従来の人手による抽出をカバーできいる．そうした現場で MBT の既存手法の導入を試みるのかという不安である．既存の MBT 手法に対すても，2 つの問題が壁となり，スムーズな導入ができる評価は，バグ検出能力やモデル網羅率，ソースコーない．

ド網羅率など，「テストした結果」に着目した評価指2.1 抽象モデルの記述によるオーバーヘッドコストがかかる標がよく用いられる．一方，開発プロセスでは仕様を網羅的にテストすることが求められており，ピンポイ

第一の障壁は，開発現場で抽象モデルを記述するこントでバグを検出できればいいという訳ではない．そとの困難さである．既存の MBT 手法の入力に着目すのため，従来手作業で抽出するテスト項目のバリエー

ると，有限状態機械（FSM）やラベル付き遷移システ

ションに対して，うちどの部分が自動抽出されたテスム（LTS），UML 振る舞いモデル等の抽象モデルのト項目で代替可能なのか，その部分が開発案件では多†1 NTT ソフトウェアイノベーションセンタNTT Software Inovation Center

いのか少ないのか，が知りたい．不足部分があれば，手動もしくは他の自動化手法でテスト項目を補うようにできる．そうすると結果的に，テスト項目抽出にか設計書 (以後，Ad と呼ぶ) を作成する．これを使ってかるコストが自動化によりどの程度削減できるかとい自動生成したテスト項目（以後，At ）を用意する．

う予測につながる．既存評価では，開発プロセス観点

評価観点 1：従来の手作業を代替できるかで「もともと人間がやっていた作業を代替可能か」と手動作成したテスト項目 Mt と自動生成したテストいう評価が欠けているため，特定の開発案件に対して項目 At の比較を行い，定量的尺度である手動代替率特定の手法を導入できるかの判断が困難である．

を定義する．Mt の要素 m と At の要素 a の間に，テ3. 障壁を低減する方法
前節で述べた 2 つの障壁それぞれを低減する方法のコンセプトを述べる．具体的な拡張事例や評価事例については，筆者らの過去文献1) で紹介している．

スト項目が一致することを示す二項関係 =R を定義す
る．目視でつき合わせを行い，一定のルールに従って一致するか否かを判定する．
「対応あり」を示す Mt の部分集合 MtR ，At の部分集合 ARt を次のように定義する．

3.1 MBT 手法の入出力の拡張

MtR = {m ∈ Mt |∃a ∈ At s.t. m =R a}

第一の障壁を低減するために，利用者である一般的ARt = {a ∈ At |∃m ∈ Mt s.t. m =R a}

な開発者に対して「抽象モデル」を隠蔽できるよう，ここで，手動代替率 MtR / |Mt | を定義する．これ

既存のテスト項目抽出手法を拡張する．
「抽象モデル」

は手動作成するテスト項目の中で，自動生成によってを隠蔽し，手法の入力として，より簡便でなじみがあ代替されうるテスト項目の割合を表す．同様に自動有る記法（シンタックスシュガー）を提供する．ここで効率 AR
t / |At | も定義する．これは自動生成のテス

シンタックスシュガーとしては，独自に定義するのでト項目の中で，従来手作業でも作成していたため経験はなく，既存開発プロセスで規定された工程成果物で的に有効と思われるテスト項目の割合を表す．

ある設計文書のテンプレートに準拠する．テスト項目

評価観点 2：手法の導入にかかるコストはどの程度か

抽出は，設計文書から抽象モデルへ変換したのちに，テスト項目抽出手法を利用するための作業工数を測

既存の MBT 手法を用いる．こうすることにより，利定する．自動化によりテスト項目抽出自体の工数は用者は余分な作業をすることなく，「○○工程では×ほぼゼロとなるが，抽出の元情報である設計書 Ad を×書を作成」という既存開発プロセスで規定された通適切に作成する工数を指す．評価に用いたアプリケーりの作業だけをすればよい．入力となる設計書の制定

ションの規模に依存しないよう，単位当たり（例えばでは，既存開発プロセスの設計書として，テンプレー1Web 画面分あたり）の設計書一式を作成するためのト化された帳票や図面を用いることにより，開発者か工数を測定する．さらに，Ad の作成工数 < MtR の作

ら，なじみのない「モデル」あるいは「モデリング」成工数となれば，手法導入により工数削減の効果が期を隠蔽し，通常の設計作業と同じような使用感で設計待できる．

を行うことができる．設計文書によって，利用者から抽象モデルを隠蔽できる条件を述べる．Web アプリ

4. お わ り にケーションのドメインを対象に考えると，画面遷移や開発現場への MBT 手法の導入の障壁となっている

ビジネスロジックの呼び出し等 MVC アーキテクチャ

問題を提起し，問題を解決するための拡張方法およびに則った設計事項は定型的になっている．こうしたド評価観点を提案した．新しい評価観点により，MBTメイン限定の暗黙知を利用することで，利用者に意識手法を適用できるか否かの判断がしやすくなったと考させずに内部で抽象モデルへの変換が可能となる．

える．しかし，従来手作業のうち，MBT の自動生成

3.2 MBT 手法に対する評価方法の拡充に「完全に」任せておける領域，すなわち，自動抽出第二の障壁を低減するために，MBT で自動生成し手法の能力の境界線を，利用者に対してどのようにしたテスト項目と，従来手作業で作成したテスト項目のて明確に示すかについて，今後さらに検討を深めたい．

比較を通して，MBT 手法に対する新しい評価観点を定義する．
評価に必要な資材を示す．まず評価用アプリケー
ションの開発過程で手作業で作成された，既存の設計書（以後，Md と呼ぶ）と，結合テストを対象とした既存のテスト項目（以後，Mt と呼ぶ）を入手する．そして，Md を元に，拡張後の MBT 手法が入力とする

参考文献1) 張暁晶, 丹野治門, 星野隆. 設計書に基づくテス
ト項目抽出手法の提案および既存開発プロセスへの適用. 電子情報通信学会技術研究報告. SS, ソ
フトウェアサイエンス, Vol. 113, No. 269, pp.
167–172, oct 2013.