Technical Information
車載ドメインにおけるモデルベースドテストの実践例のご紹介
モデルベースドテスト（MBT）はテスト設計手法の一つで、テスト設計の品質や効率を改善するほか、テストの自動化にも重要な役割を果たします。国際的なテスト技術者の資格認定を行っているISTQBでは、Model-Based Testerの認定を行っており、そのシラバスにはテスト設計からテスト実行までのテスト自動化のイメージが示されています。しかし、実際にMBTを前提としてテスト設計からテスト実行までを自動化する日本の事例はあまり提供されていません。そこで、ベリサーブでMBTによる「テスト設計」から「テスト実行」までの自動化環境を実際に構築し、実用を前提とした検証を試みました。本講演では、車載ドメインを対象とした実践例をご紹介します。
※この記事は、『ベリサーブ オートモーティブ カンファレンス 2021』の講演内容を基にした内容です。
株式会社ベリサーブ
研究開発部 技術戦略課 課長
須原 秀敏
モデルベースドテストとは
MBTの定義と意義
オートモーティブ分野におけるテストボリュームは拡大の一途をたどっています（図1）。中でも、情報セキュリティの重要性の高まりやユーザーサービスの拡大志向により、IoTに代表される情報系ECUの機能拡大は顕著です。こうした状況を背景としてテスト自動化プロジェクトが多数発足していますが、そこにはプロジェクトオーナーの「今よりも楽にテスト計画を完遂させたい」という漠然とした期待があるように思います。まず、MBTの定義と意義を確認しましょう。Model-Based Tester認定試験のシラバス※ によると、MBTとは、テスト設計仕様の表現にモデル（一定のルールに基づいた記述方法）を使い、モデルに含まれる形式的な（数学的に意味づけされた）パターンに従ってテストケースを生成することと定義されています。電気通信大学の西康晴氏によると、MBTで使用する代表的なモデルとしては、フローモデル、状態遷移モデル（図1）、トレースベースドモデル、組み合わせモデル、統計モデルなどがあります。
モデルの多くが絵や図、表などで表現されるためステークホルダーがテスト設計仕様を理解しやすくなること、テスト仕様が一定の規則に基づくため、テスト設計（場合によってはテスト実行まで）の自動化がしやすくなることがその意義として挙げられています。
※：“ISTQB Ⓡ Foundation Level Certified Model-Based Tester Syllabus Version 2015”, ISTQB,
車載ドメインにおけるMBTの実践例
ここからは、本講演の主題であるMBTの実践例をご紹介します。対象はMBTそのものではなく、MBTをテストプロセスに組み入れた上で、テストの設計、実装、実行を自動化したシステムです。
MBTのツールチェーンの例
実践に当たっては、冒頭で紹介したシラバスに掲載されている典型的なツールチェーン※1 の例を参考にしました（図2）。最も重要なのは「MBT Tool」で、ここでテストケースを生成します。「Requirements Management Tool」はテスト対象への要求管理、「Test Management
Tool」はテストケース管理、「Test Automation Framework」はテスト実行、そして全体の管理が「Configuration Management」という構成です。ここにはテスト実装に該当するものは明記されていませんが、MBT Toolに含まれていると解釈しました。
出典："ISTQB Ⓡ Foundation Level Certifi ed Model-Based Tester Syllabus Version 2015" ISTQB, 2015より作成
※1：特定の目的のために組み合わせて使用するツール（プログラム）の集合体を指す。ツールには実行順序が設定されており、一つ前のツールの出力結果を次のツールの入力として利用し、連鎖的に実行することから鎖（チェーン）に例えられている。
実践したツールチェーン
これを基に私たちが構築したシステムが図3です。図の左上にある仕様の記述が行われると、自動的に処理が始まります。テスト仕様となるモデルはSparx Systems社の①「Enterprise Architect」を使いSysML※2 で記述、構成管理には②「GitHub」を、CI（継続的インテグレーション）サーバー※3 には③「Jenkins」を利用します。MBTのメインとなるMBT Toolについては、テストケースを生成する④「テスト設計ツール」とテストスクリプトを生成する⑤「テスト実装ツール」を独自に実装しました。また、「テスト設計ツール」では、ベリサーブがリリースした、Webブラウザー上でテスト設計モデルを作成するためのツール⑥「GIHOZ」をTest Case generator（テストケース自動生成装置）として部分的に活用します。作成したテストケースを、これも当社の⑦「QualityForward」というテスト管理ツールに登録すると、「テスト実装ツール」がテストケースを受け取り、テスト実行用のスクリプトを生成します。テスト実行ツールには、Vector社の⑧「CANoe」を使用し、Vector社の「vTESTstudio」の形式で生成されたテストスクリプトを実行します。
※2：米OMG（Object Management Group、IT関連の世界標準を推進する非営利団体）によって公開されている、システム全体をモデリングするための表記言語。主にソフトウェア設計に用いられるUML（統一モデリング言語）をベースに、ハードウェアなども含めて設計しやすいように拡張・整理されている。
※3：ソフトウェアの更新のたびにテストを行うことで、ソフトウェアが常に正常に動作する状態を維持し、開発スピードを落とさないことを目的とした「継続的インテグレーション」を実現するためのサーバー。「ビルド」や「テスト」など継続的インテグレーションに必要なさまざまなプロセスの実行を制御する。
Requirements（テスト仕様）
次に、ツールチェーンの実行に関わる要素のうち、実行の順に要点となる箇所をピックアップし、具体的な動作を説明します。
Enterprise Architectで作成したSysMLモデル（テスト仕様）をMBTの入力としています。GitHubが要求管理の役割を担い、モデルの保管、
MBT Toolへ入力値（モデルのデータ）の連係などを行います。今回ターゲットにしたのはアクティビティ図、状態遷移図、ブロック定義図です。ブロック定義図については、入力や出力のデータ取得に活用しています。図4は、アクティビティ図の一部を表現しており、これを入力にしてテストケースを生成しています。手順は、Enterprise ArchitectにAPI経由でアクセスし、オブジェクト（処理の対象）・アクション（処理）・デシジョン（条件分岐）などのデータを取得、そこからテストケースを生成するという流れです。
テストパイプライン
テストパイプラインはテスト設計の実装、実行といった処理の流れ全体を制御する考え方で、今回はJenkinsがそれに該当します。Jenkinsで仕様書やモデルを監視して、更新があった場合にテスト設計ツール、テスト実装ツール、テスト実行ツールを順に起動し、最終的な実行結果を受け取ります。
MBT Tool
モデルの特定の構造を抽出してテストケースを生成しています。例えば図5のような分岐条件で、オブジェクト（CAN：イベント検知用データ）が［有効値］もしくは［無効値または不定値］である場合にどちらのパスを通るかというテストケースを、アクティビティ図からオブジェクトとデシジョンの組み合わせを抜き出して生成しています。実際にはこうしたパターンを複数抽出して、手作業での設計と同じことが再現できるようにしています。
Test Case generator
Test Case generatorについて、GIHOZを用いたテストケースの自動生成にも触れておきます。GIHOZにはGUIで作成したモデルからテストケースを生成する機能があります。モデルにこの機能と相性のいい特定の構造が含まれているとテスト設計ツールが判断した場合、APIを経由してこの機能を利用し、JSONで値の入出力を行っています。図6の左側がモデルを表現するパラメーター、右側が出力されたテストケースです。
GIHOZにモデル相当の情報を投入し、テストケースを戻します。APIによる入出力機能はまだ製品リリースされていませんが、実装が検討されています。
（左：モデル相当の入力パラメーター、右：生成されたテストケース）
Test Management Tool
テスト設計ツールが生成したテストケースをQualityForwardに投入し、テストケースとテスト実行状況が管理できるようにします。可読性は低下しますが、テスト実装ツールに渡しやすいようにテストケースはJSON形式で格納しています。
QualityForwardにはWebのAPIが用意されているため、API経由で自動的にテストケースに関する情報を投入する仕組みを実現しています
（図7）。
Test script generator（テスト実行可能な形式への変換）
テスト実装ツールに該当するもので、作成したテストケースを実行可能な形式へと変換します。今回はvTESTstudioの形式でテストスクリプトを生成しています。
テスト実装ツールに該当するもので、作成したテストケースを実行可能な形式へと変換します。今回はvTESTstudioの形式でテストスクリプトを生成しています。また、今回はテストスクリプトの「流れ」をあらかじめ固定し、そこに入るパラメーターをテストケースに従って変化させる「データ駆動スクリプト」を使っています。一般的にテストスクリプトの自動生成ではキーワード駆動を使うことが多いのですが、今回は入力となるモデルがセミフォーマルな形式であるため、全てをキーワードにしてスクリプトの中の手順を自動的に変更することまではできていません。ここは今後の課題となります。
Test automation Framework
最後がテストの自動実行です。CANoeを使用してテストを実行し、その結果をAPI経由でQualityForwardに自動的に入力します。
以上がMBTを前提とした自動テストシステムに関する概要です。このシステムの動作ではモデルが更新されると、ツールチェーンが動作し、テストケース作成からテスト実行、テスト管理ツールへの実行結果登録までの一連の処理の自動化を実現することができました。
実践を通じて
今回は、MBTモデルやテスト技法を一部に限定適用しての実践となりましたが、仕様作成／修正をトリガーに、テスト設計からテスト実行まで人の手を介することなく実施できました。社内で紹介したところ、現場の技術者から高い評価が得られました。
テスト設計の際、頭の中で考えていることをMBT用にルール化するのは意外と難しく、あらためてテスト技術者が多くのことを考慮しながらテスト設計していることが分かりました。また、モデリング言語はモデルを記述するための記述法ですが、例外的な記述も許容されているため単純にルール化できないことがあります。MBTではSysMLで仕様書を書くだけでは制約が足りず、MBTのためのモデルとしての制約を守る必要があります。
なお、今回は車載ドメインとしてHILSを対象としましたが、SILSへの応用も可能だと考えられます。また、テストは一つの環境でのみ実行しましたが、この仕組みを使えば複数の環境での並列実行も簡単に実現できるはずです。
おわりに
MBTによるテスト設計が実現すると、テスト設計は「ルールを作り、ツールに入力する」という活動になり、人間の創造性をより必要とする作業にテストエンジニアのリソースを集中することが可能になります。また、仕様書完成からテスト完了までのリードタイムを大幅に短縮することができるため、アジャイル開発における短い期間でのリリースに対応したり、時間的な制限により今まで実施できなかったテストを行うことでリスクを回避したりという効果が期待できるでしょう。
一方で、プロダクト設計のために作成したモデルはそのまま利用できないことが多いため、MBTで利用できる形に整形する、情報を付加するなどの追加作業が発生します。また、仕様変更に応じてモデルのメンテナンスが継続的に発生する点も考慮する必要があります。
以上のように考慮の必要な点はありますが、総合的に評価するとメリットがデメリットをはるかに上回るため、MBTには大きな価値があると考えています。当社でも積極的に取り入れて、手作業での設計を減らしていきたいと考えています。
今回ご紹介した当社の実践例が、これからMBTを実践しようとする皆さまの参考になれば幸いです。
この記事をシェアする
