レポート

Qtが拓くUIの未来を先取り ―「Qt World Summit 2018 Boston」レポート

この記事を読むのに必要な時間:およそ 6 分

セッション

セッションは2日目の午後に,4つの部屋に分かれて行われました。合計26のセッションがあり,1つのセッションは30分~1時間程度でした。例年同様,各セッションにはAutomotiveやMedical等のタグがついており,各セッションで扱うトピックが一目で分かるようになっていました。

ここでは,私が参加したセッションのうち,以下について詳細を記載します。

  • 「Qt and You: Navigating the Medical Device Regulatory Pathways」
  • 「Let Automated GUI Testing Drive your Qt Development」
  • 「Mastering Qt for Python in 20 min」

Qt and You: Navigating the Medical Device Regulatory Pathways

Roger Mazzella氏によるセッション

Roger Mazzella氏によるセッション

The Qt Company社のシニアプロダクトマネージャーであるRoger Mazzella氏によるセッションです。医療機器を製造する際に従うべき規定に対し,Qtがどのようにアプローチしているかを,Qtと医療機器との関係にも触れながらわかりやすく説明していました。

Roger Mazzella氏はまず,医療機器の製造における規定に対し,

  1. Qtの認証
  2. Qtの法規・コンプライアンス支援
  3. Qtパートナーを通じたグローバル市場へのアクセス

の3つのアプローチをとっていると述べました。

まず,1. Qtの認証についてですが,QtはISO 9001:2015の認証を受けています。また,セーフティクリティカルなUI描画の仕組みを,商用ライセンス向けのアドオンであるQt Safe Rendererで提供しており,こちらではIEC 62304,IEC 61508,ISO 26262の認証を受けています。上記に加えて,Roger Mazzella氏はQt Safe Rendererの機能についても触れていました。Qt Safe RendererはQt ToolsとQt Quickに統合されていて,多くの認証済みリアルタイムOSに対応しています。

Qt Safe Rendererの主な機能は以下です。

  • セーフティクリティカルなUIの描画
  • 表示対象のグラフィックスレイヤを制御
  • セーフティクリティカルでないUIの正常な操作を監視
  • 操作上のエラーが検知された場合,セーフティクリティカルでないUIの無効化
  • 失敗が検知された場合,セーフティクリティカルでないUIの再起動

すでにリリースされているQt Safe Renderer 1.0では,アラームアイコン等の静的なアイコン,メッセージテキスト,ダイアログの描画が可能となっています。次バージョンの2.0では心拍や呼吸数などの数値をリアルタイムで描画できるように,2.0以降ではリアルタイム波形の描画ができるように対応する予定とのことです。

次に,2. Qtの法規・コンプライアンス支援については,Qt Safe RendererはIEC 62304の認証を受けていますが,Qtは全体的にSOUP(開発過程が不明なソフトウェア)の扱いになります。そのためQtでは,開発プロセス,プロダクトの性能,内部処理の妥当性やテストについてドキュメントを提供し,透明性を確保しているとのことでした。

最後に,3. Qtパートナーを通じたグローバル市場へのアクセスについては,Qtは医療分野のリーダーであるEmergoグループとパートナーであり,AdvaMedやQmed,MassMEDIC等の医療組織のメンバであることが挙げられていました。

Let Automated GUI Testing Drive your Qt Development

Alan Ezust氏によるセッション

Alan Ezust氏によるセッション

このセッションでは,froglogic社のトレーナー兼コンサルタントのAlan Ezust氏が,Qtの自動GUIテストツールであるSquish for Qt(以下 Squish)の使い方を説明していました。

Squishには,BDD(Behavior Driven Developent)向けの機能,自動テストのレコーディングとプレイバック機能,直感的なテスト作成環境等,自動GUIテストを行うためのさまざまな機能があります(Squish を使用するにはライセンスの購入が必要です)⁠

Squish でテストを行うには以下の2つが必要になります。

  • テスト対象のアプリケーションであるApplication Under Test(AUT)
  • AUT を動かすためのテストスクリプト

Squishでテストを作成・実行するにあたっては,専用のIDEであるSquish IDEが使用可能です。本セッションでは,Squish IDEを使用してBDD向けのテストケースを作成するデモがありました。BDDはテスト駆動開発から派生したプログラム開発手法で,開発のはじめに受け入れ基準を満たす振る舞いをテストケースとして定義します。

BDDのテストは,アプリの振る舞い(シナリオ)を1つもしくは複数記述したFeatureファイルのセットとして構成されます。Featureファイルは多くの場合Gherkin等の人が読める言語で記述しますが,Squishを使う場合も同様にGherkinを使用します。

たとえば,Qtの電卓アプリのテストを行う場合は,Featureファイルを以下のように記述します(9×8の計算で72が表示されるかどうかのテストを行う例です)⁠

Feature: Multiplication of a calculator

    Scenario: 9 times 8 is 72

        Given Calculator is running
        When User enters 9*8=
        Then Calculator displays 72

SquishでBDDのテストケースを作成するには,まず上記Featureファイルを記述し,その後でFeatureファイルに対応する操作を追加します。操作の追加はSquishのレコード機能を使用し,AUTで操作を行うことにより可能です。プログラミングを行う必要がないため,テスタ等のプログラマ以外の人でもテストケースの作成が可能になります。操作の追加後はSquish IDEからテストの実行を行うことで,任意のタイミングでテストを実行できます。

本セッションで扱っていた内容はSquishの機能の一部になりますが,初心者が使い方のイメージをつかむのには適した内容になっていました。

なお,Squishについては,弊社SRAでも2018年12月7日にセミナーを開催する予定です(本セッションの内容とは異なります。詳細は本文の最後をご参照ください)⁠

著者プロフィール

千田順子(ちだじゅんこ)

株式会社SRAのエンジニア。2016年からQtチームに配属され,Qtのアプリケーション開発を担当している。

コメント

コメントの記入