機能テスト × GUI表示テスト × 多言語テスト × 実機E2Eテスト
組込み機器のGUIは、近年ますます高度化しています。
産業機器、医療機器、車載機器、POS、キオスク端末、デジタルサイネージ、計測機器などでは、単に機能が正常に動作するだけではなく、
- 正しい文字列が表示されている
- 選択した言語に正しく切り替わっている
- 翻訳漏れがない
- 文字がボタンや枠からはみ出していない
- 文字が途中で切れていない
- 操作対象となるボタンが正しく表示されている
- アラビア語などRTL（Right-to-Left）言語でレイアウトが崩れていない
- 実際の機器上で一連のユーザー操作が正常に完了する
といった、「最終的にユーザーが目にするGUIそのもの」の品質保証が重要になっています。
特に製品をグローバル展開する場合、
機能テスト × GUI表示テスト × 多言語テスト × 実機E2Eテスト
を組み合わせる必要があります。
しかし、組込み機器では、この領域の自動化が容易ではありません。
なぜ組込み機器のGUIテストは難しいのか
Webアプリケーションでは、HTML、DOM、CSS、JavaScriptなど、テストツールから参照できる構造情報が存在します。
一方、組込み機器では、
テスト対象GUIの内部構造を外部のテストツールから取得できない
ケースが少なくありません。
例えば、
- 独自GUI Framework
- Qt
- OpenGL
- DirectFB
- framebuffer
- Androidベース独自UI
- Linux組込みGUI
- Windows Embedded
- 専用HMI
- リモート表示されたGUI
- HDMIキャプチャされた実機画面
などです。
テストツールから見ると、ボタンも、文字も、アイコンも、単なる「画面上の画像」としてしか見えない場合があります。
Web E2Eテストとの決定的な違い
WebのE2Eテストでは、SeleniumやPlaywrightが広く利用されています。
SeleniumはWebDriverを中心としたWebブラウザ自動化のための技術であり、公式ドキュメントでもWebブラウザを自動化するプロジェクトとして位置付けられています。
Playwrightも、Chromium、Firefox、WebKitなどのブラウザを対象とした、Webアプリケーション向けE2Eテストフレームワークです。
Webであれば、例えば、
という形で、テスト対象を構造として認識できます。
しかし組込みGUIでは、
となります。
ここに、Webテストと組込みGUIテストの大きな違いがあります。
Selenium / Playwrightでは解決しにくい領域
SeleniumやPlaywrightが優れていないということではありません。
Webアプリケーションを対象とするのであれば、非常に有力な選択肢です。
しかし、組込みGUIでは「ブラウザ内部の要素を操作する」という前提そのものが成立しない場合があります。
| テスト対象 | Selenium / Playwright |
| Webページ | ◎ |
| DOM Element | ◎ |
| HTML Button | ◎ |
| Web Input | ◎ |
| ChromiumベースWeb UI | ◎ |
| Native GUI | △～× |
| framebuffer GUI | × |
| 独自HMI | × |
| HDMI経由の実機画面 | × |
| VNC/RFB越しのGUI | 原則としてWeb DOM操作とは別領域 |
| GUI上に描画された文字 | DOMがなければ直接取得困難 |
| 実機画面の見切れ | DOMだけではユーザー視点の判定にならない場合がある |
つまり、
Webを自動化するためのE2Eテスト技術を、そのまま組込み機器へ持ってくることには限界がある
ということです。
では、組込み機器では何を基準にテストするのか？
答えはシンプルです。
「ユーザーが見ているもの」をテストする
組込みGUIでは、内部オブジェクトを探すのではなく、実際に画面に表示されているものを認識する
という考え方が有効です。
そこでテスト対象を、
DOM / Object / Control
ではなく、
Screen
Image
Text
Coordinate
Visual State
として扱います。
発想の転換
従来型： GUIの内部構造を取得してテストする
組込みGUI向け： GUIを人間と同じように「見て」「判断して」「操作する」
このアプローチによって、
- Web
- Windows
- Linux
- Android
- 組込みGUI
- Remote Desktop
- VNC
- 実機
など、GUIの実装技術への依存を減らすことができます。
そこで再考したい T-Plan Robot
T-Plan Robotを「Visual E2E Automation Platform」として捉え直す
T-Plan Robotは、一般的なWeb DOMベースのテストツールとは異なり、Black Box / Image-Based Testing を基本思想としています。
T-Plan自身もRobotを、画像ベースの考え方に基づき、ユーザーインターフェースを人間に近い方法でテストするBlack Box型テスト自動化ツールとして説明しています。
つまり、
というアプローチです。
T-Plan Robotを多言語GUIテストへ発展させる
ここでT-Plan Robotを単なる「画像認識型GUI自動化ツール」から、Multilingual GUI E2E Automationへ発展させます。
基本構成は、
と考えます。
Golden Data Driven Multilingual Testing
多言語テストでは、
「何が正しい表示なのか」
という基準が必要です。
そこで、翻訳済みの承認文字列をGolden Dataとして管理します。
例えばExcelで、
| ID | Japanese | English | German | Spanish | Chinese | Korean | Arabic |
| MENU01 | メニュー | Menu | Menü | Menú | 菜单 | 메뉴 | القائمة |
| MENU02 | 計測結果 | Measurement Results | Messergebnisse | Resultados de medición | 测量结果 | 측정 결과 | نتائج القياس |
| MENU03 | 機能設定 | Function Settings | Funktionseinstellungen | Configuración | 功能设置 | 기능 설정 | إعدادات الوظيفة |
と管理します。
テスト実行時には、
という自動検証を実施します。
文字列一致だけでは十分ではない
多言語GUIテストで重要なのは、
「翻訳された文字列が存在すること」だけではありません。
例えばドイツ語では英語より文字列が長くなることがあります。
英語：Settings
ドイツ語：Einstellungen
翻訳そのものが正しくても、
┌─────┐
│ Einstellun │
└─────┘
となればGUIとしては不具合です。
したがって、検証すべき対象は、
① Text correctness
正しい翻訳文字列か。
② Text completeness
文字が途中で欠けていないか。
③ Layout correctness
文字や部品が重なっていないか。
④ Visual correctness
ボタン、アイコン、ダイアログが正しく表示されているか。
⑤ Functional correctness
操作結果が正しいか。
です。
OCR × Image Recognition のハイブリッド
ここがT-Plan Robotを多言語GUIテストへ適用する上で重要なポイントです。
OCRが得意なもの
「設定」
「Measurement Results」
「Sicherheit」
「로그인」
などの文字列。
Image Recognitionが得意なもの
アイコン
ボタン
ロゴ
ダイアログ
チェックマーク
レイアウト
したがって、
OCR + Image Recognition
を組み合わせます。
OCR Engineを交換可能な構成にする
T-Plan RobotのOCR機能は、画面イメージから文字列を取得するための仕組みを備えています。公式FAQでも、OCRまたは画像ベースの文字認識によって画面上のテキストを取得できると説明されています。
またComparetoのmethod=”tocr”では、外部OCR Engineを利用してRemote Desktop Imageから文字を取得する仕組みが用意されています。
この仕組みを利用して、
T-Plan Robot
│
├── Tesseract
│
├── Google Cloud Vision
│
└── Other OCR Engine
というOCR Engine非依存型の多言語検証基盤へ発展させることが考えられます。
特にCJKへの対応
多言語GUIでは、
- Japanese
- Chinese
- Korean
いわゆるCJK文字の認識精度が重要になります。
さらに、
- Arabic
- Thai
- Hindi
- Vietnamese
- European languages
などへ対象を広げれば、単純な一つのOCR Engineですべてを解決することが最適とは限りません。
そのため、
という構成にします。
多言語特有の「表記差」も吸収する
OCR結果とGolden Dataを単純完全一致させるだけでは、実用的でない場合があります。
例えば、
全角 / 半角
空白
改行
Unicode正規化
句読点
OCRによる不要Space
などです。
そこで、
とします。
必要に応じて、
Exact Match
完全一致
Normalized Match
正規化後一致
Partial Match
部分一致
Similarity Match
類似度判定
などを使い分けます。
RTL言語への対応
ArabicやHebrewでは、単純な文字列確認だけでは不十分です。
重要なのは、Right-to-Left Layout です。
確認項目例：
- テキストの開始位置
- アイコン位置
- Back Button
- Navigation
- Label alignment
- 数字表示
- punctuation
- Left / Right配置
したがって、
を組み合わせます。
これによって、
「文字は合っているが、レイアウトが間違っている」
という問題も検出対象にできます。
「画面単体テスト」から「E2Eテスト」へ
多言語GUIテストは画面キャプチャだけで終わらせません。
例えば、
という一連のユーザー操作を自動実行します。
各画面で、
を確認します。
これが、Multilingual GUI E2E Test です。
テスト対象を「内部」ではなく「外側」から見る
T-Plan Robotの大きなメリットはここにあります。
つまり、
人間が製品を使うインターフェースそのものを検証する というBlack Box E2Eテストです。
なぜこれが組込み機器に向いているのか
製品内部のGUI Frameworkが、
Qt
Android
Linux
Java
C++
OpenGL
WebView
Proprietary GUI
のどれであったとしても、最終的にユーザーが見るものは、
Screen
です。
その画面を基準にテストすることで、実装技術への依存度を低くできるというメリットがあります。
テストアーキテクチャ例
Selenium / Playwrightとは競合ではなく「適材適所」
このBlogでは、
SeleniumやPlaywrightを否定するものではありません。
むしろ、
Web Application
↓
Selenium / Playwright
と、
Embedded / Native / Remote GUI
↓
T-Plan Robot
という適材適所を明確にします。
| 領域 | 推奨アプローチ |
| Web DOM | Selenium / Playwright |
| Web API | API Test |
| Mobile Native | Appium等 |
| 組込みGUI | T-Plan Robot |
| Remote GUI | T-Plan Robot |
| Image Based UI | T-Plan Robot |
| OCR Validation | T-Plan Robot + OCR |
| Multilingual Visual E2E | T-Plan Robot + OCR + Golden Data |
さらに重要な差別化
DOMの「正しさ」と、画面の「正しさ」は同じではない
例えばHTML上では、 <button>Measurement Results</button> と正しく存在していたとしても、
実画面上で、Measurement Res… となっている可能性があります。
つまり、内部的には正しいが、ユーザーには正しく見えていないという不具合です。
組込み機器の品質保証では、
What the user actually sees
を確認することが重要です。
T-Plan Robotの位置付けを再定義する
従来： Image Based Test Automation Tool
から、
Visual E2E Test Automation Platform
へ。
さらに多言語GUIでは、
Multilingual Visual E2E Test Automation Platform
として位置付けます。
本ソリューションで自動化するもの
Functional
- Menu Navigation
- Button Operation
- Screen Transition
- Login / Logout
- Settings
- Workflow
Visual
- Button
- Icon
- Dialog
- Layout
- Image
- Screen
Localization
- Translation
- Missing Translation
- Language Mixing
- Incorrect Characters
OCR
- Text Recognition
- Golden Text Comparison
Layout
- Text Clipping
- Overflow
- Misalignment
- RTL
Evidence
- Screenshot
- OCR Result
- Expected Text
- Actual Text
- PASS / FAIL
テスト結果イメージ
| Language | Screen | Test Item | Golden | OCR Result | Result |
| Japanese | Menu | MENU01 | メニュー | メニュー | PASS |
| English | Menu | MENU01 | Menu | Menu | PASS |
| German | Menu | MENU01 | Menü | Menü | PASS |
| Spanish | Menu | MENU01 | Menú | Menú | PASS |
| Chinese | Menu | MENU01 | 菜单 | 菜单 | PASS |
| Korean | Menu | MENU01 | 메뉴 | 메뉴 | PASS |
| Arabic | Menu | MENU01 | القائمة | القائمه | FAIL |
FAIL時には、
Expected
Actual OCR
Screenshot
Coordinates
Language
Timestamp
をEvidenceとして保存します。
CI/CDへの展開
将来的には、
という形へ発展できます。
これにより、
Localization Testを開発後半の人手による確認作業から、継続的なRegression Testへ移行
できます。
多言語GUIテストマトリクス
例えば、
の場合、
18,000 checks
になります。
これを人手だけで繰り返すのは現実的ではありません。
一方、Golden Dataとテストシナリオを共通化できれば、言語数や機種数が増えるほど自動化効果が大きくなる可能性があります。
特に有効と考えられる製品分野
本ソリューションは、
- 産業用HMI
- 計測機器
- 医療機器
- POS
- Kiosk
- デジタルサイネージ
- Printer / MFP
- Network Appliance
- 車載IVI
- カーナビ
- Factory Automation
- Consumer Electronics
- Android Dedicated Device
など、
画面を持つ組込み製品 との親和性が高いと考えられます。
提案する新しいテストコンセプト
従来のLocalization Test： 翻訳確認
から、
へ発展させます。
本blogでのご提案の本質
本提案の目的は、
「OCRを使って文字を確認すること」ではありません。
OCRは構成技術の一つにすぎません。
本当に実現したいのは、
実際のユーザーが行う操作を再現しながら、
実際のユーザーが見る多言語GUIを自動検証すること
です。
T-Plan Robotを選択する理由
Webアプリケーションの世界では、
というテスト手法が確立されています。
しかし組込み機器では、必ずしもその世界が存在しません。
そこで、
という別のアプローチが必要になります。
そのための基盤として、
T-Plan Robot
を活用します。
/
Webをテストするのではなく、製品をテストする
SeleniumやPlaywrightはWebブラウザ自動化に非常に優れています。
しかし組込み機器では、
ブラウザの中ではなく、製品そのものをユーザー視点から検証する
必要があります。
そのため、
DOMを必要としないBlack Box型Visual Automation
という選択肢を再考する価値があります。
まとめ
組込み機器の多言語GUIテストには、Webアプリケーションとは異なる難しさがあります。
SeleniumやPlaywrightはブラウザ自動化を主対象とする優れた技術ですが、DOMやWeb要素を取得できない組込みGUIでは、同じアプローチをそのまま適用できません。
そこで、
Image Recognition + OCR + GUI Operation + Golden Data
を組み合わせ、
実装内部ではなく、
「ユーザーが実際に見るGUI」
を基準に自動テストします。
その中核としてT-Plan Robotが
Multilingual GUI E2E Automation Platform
として機能します。
これは単なるOCRテストではありません。
機能・表示・翻訳・レイアウトを、実際のユーザー操作の流れの中で統合的に検証する、組込み機器向けVisual E2Eテスト基盤です。