1.はじめに
2022年はモデルベースドテスト(MBT)に取り組んできました。MBTはMBTモデルからテストケースを自動生成する技術です。ソフトウェアテストや品質保証に対して、ソフトウェアの品質を保ちつつもリリースのスピードを向上するための貢献（自動化など）が求められており、その要求に対応する技術としてMBTが重要になってきます。そして今年、MBTに関する発表をいくつか行いました。主だったのはInSTA 2022とソフトウェア品質シンポジウム 2022です。そこでこの記事ではそれぞれの発表の概説をして振り返ってみようと思います。本記事ではその1としてInSTAの発表を取り扱います。
2.発表概説
タイトルはPatterns to Improve Fidelity for Model-Based Testingです。(論文はこちら)
2.1.概要
内容をざっくり説明していきます。まず背景として、１つのMBTモデルから生成されたテストケースでは不具合を検出できないことがあり、それらの不具合は探索的テストなどで見つかることがあるということでした。そのような不具合を分析してみると探索的テストを行うテスターは暗黙的に複数のモデルを統合させてテストを考えていることがわかりました。そこで不具合を分析することで複数のモデルを統合させるパターンを蓄積し、そのパターンを使うことができればMBTで生成するテストケースを改善できるのではと考え、これに対して取り組みました。結果的に発表や論文の中では2つの不具合を分析し、2つのパターンを紹介しました。発表としてはそんな感じの内容です。せっかくなので、この記事でも論文や発表で使用したパターンの１つを載せておきます。
2.1.1.複数のモデルを統合するパターン1（Unstable Read-Write Pattern）
このパターンのもとにした不具合はSleep状態からWakeup状態への遷移に失敗するという不具合でした。Sleep状態に遷移時に不揮発性メモリにデータを書き込み、Wakeup状態に遷移時に不揮発性メモリのデータを読み込みますが、このデータが消失していたことで読み込みにできず遷移に失敗するという原因でした。
この不具合からは、何らかのハードウェアにデータの読み書き処理を行う状態遷移があり、そしてそのハードウェアの信頼性が低い場合（データが損失する可能性がある場合）に、状態遷移モデルと信頼性モデルを統合するというパターンと作りました。このパターンを使用して２つのモデルを統合することで先ほどの不具合を検出できるテストケースが生成可能になります。
3.発表補足
当時を少し振り返りつつ、発表について補足したいと思います。
3.1.どのような経緯でこのテーマで発表することになったのか？
もともとはMBTモデルからテストケースを生成するロジックについて発表しようと検討していました。ただ単なるロジックだけだと面白く無さそうなので、通常のMBTでは生成できないようなものの方が良いのではということになりました。そこでテストケースから漏れ、探索的テストで見つけるような不具合から考えてみることにしました。議論を重ねる中で、おそらく探索的テストで不具合を見つけるテスターは１つのモデルだけでテストを考えているのではなく、複数のモデルを組み合わせてテストを考えているではとなりました。そこで、その観点で不具合を分析することでMBTに活用できるパターンを見つけてみようということでこのテーマになりました。
3.2."Fidelity"って何？
モデル、シミュレーションの世界で使われる言葉のようで、日本語だと"忠実"、"忠実度"のような意味になります。モデルであれば、現物をどれほど表現できているかということになるかと思います。本来はそういう意味なのですが、なかなか掴みづらいので発表の中では「必要なテストケースを生成できる度合い」といった定義をして使用することにしました。MBTにおいては、そしてこの発表においては、その定義で説明した方が伝わりやすいと考えたからです。
3.3.他にもパターンはありそうなのか？
もちろんあると思います。実際のテスト設計、テストケースの成果物だったり、不具合を分析していくと本発表で扱った複数のモデルを統合するパターンは見つかってくるはずです。しかし単にパターンを増やせばいいというわけではなく、パターンを活用、再利用可能な形でパターン化していくことが大事だと思います。そこで重要なのがパターン適用の手がかりになるモデル上の特徴、特性の情報です。上記のパターンの例で言えば「ハードウェアへの読み書き処理をする」などの情報になります。この情報があることでパターンを適用可能かを識別できます。どんな場合でもパターンが適用されてしまうと無駄なテストケースが生成されてしまうので気をつける必要があります。
3.4.今後の課題はどんな点か？
パターンを増やしていくというのもありますが、そのパターンをMBTツールに実装し、実用化を考えいくことかなと思います。MBTに実装するのはよりパターン適用の情報を形式的に表現する必要が出てきますし、テストケースの生成ロジックもしっかりと考えていかないといけません。パターンが増えてくるとそのあたりも複雑になってきますし、パターン間の関係性なども考えないといけません。そのような点が課題になってくると考えています。
3.5.発表するうえで何が大変だったか？
論文や発表の内容自体を検討することはもちろん大変でした。それはテーマ決めのところで記述した通りです。また、論文もあまり書いたことがなかったので、わかりやすいストーリーを作る事や、伝わるように表現することには苦労しました。そして何より発表、プレゼンテーションですね。私にとって初めて英語でプレゼンテーションするという体験だったので凄く大変でした。普段のプレゼンテーションの5倍以上練習した気がしましたし、音声読み上げソフト（音読さん）を使いながら英語の発音、発話を確認したりしました。そして当日、物凄く緊張しました。今年一番緊張していた日だったかもしれません。結果淡々としたプレゼンテーションになってしまった気はしますが、何とかやり遂げました。これは本当にいい経験になりました。
4.まとめ
2022年にMBTに関して発表したことを紹介する記事でした。本記事ではその1としてInSTA 2022を扱いました。MBTを改善するための複数のモデルを統合するパターンという内容です。いろいろと大変ではあったのですが凄くいい経験になりました。その2ではソフトウェア品質シンポジウム 2022について扱いたいと思います。