皆さん、こんにちは。
先週に引き続き、JSTQBシラバス「モバイルアプリケーションテスト担当者」の5項「テスト実行の自動化」についてご紹介していきたいと思います。
JSTQBシラバス「モバイルアプリケーションテスト担当者」は、1項～5項までの構成となっており、今回の5項の紹介をもって、最後となります。
5項の構成は以下となっています。
■「5.テスト実行の自動化」目次リンク
□5.1自動化手法
モバイルアプリケーションの自動化の手法とフレームワークは、さまざまなものがあります。
一般的に使用されるテスト自動化アプローチは、以下の２つが挙げられます。
・ユーザーエージェントベースドテスト
・デバイスベースドテスト
「ユーザーエージェントベースドテスト」
ブラウザから送信されるユーザーエージェント識別子の文字列を使用して、特定のデバイス上の特定のブラウザを偽装します。
これは、モバイルWebアプリケーションの実行に使用できます。
Webアプリケーションが対象となるため、ネイティブアプリ等では利用が行えません。
モバイルWebでは、一般的なWebアプリケーション自動化ツールを使用してデスクトップ上でテストできます。
例として、Chromeブラウザのコンソールまたはブラウザの表示幅サイズを調整し、疑似的にモバイル表示として、Selenium等でテスト自動化を行なうものと考えます。
(具体例)
Selenium、Cypressなど
「デバイスベースドテスト」
テスト対象のアプリケーションを直接デバイス上で実行します。
Webに限らず、全てのタイプのモバイルアプリケーションに使用可能です。
(具体例)
Appium、Test Projectなど
モバイルアプリケーションテストフレームワークが一般的に備える主要機能は以下となります。
・オブジェクトの識別
・オブジェクトの操作
・テストレポート
・アプリケーションプログラミングインターフェース及び拡張可能な能力
・適切な文書
・他のツールとの統合
・テスト開発のプラクティスからの独立
□5.2自動化方法
こちらでは、自動化の方法について、述べられています。
JSTQBシラバスでは「自動化テストを開発する場合、テスト担当者は自動スクリプトの記録や作成のメカニズムを理解し、そしてアプリケーションのボタン、リストボックス、入力フィールドなどグラフィカルオブジェクトにアクセスして操作する方法を理解する必要がある」と記載されています。
グラフィカルオブジェクトを識別する方法としては、以下があります。
・画像認識
・OCR（※1） /テキスト認識
・オブジェクト認識
※1：光学文字認識と呼ばれる活字、手書きテキストの画像を文字コードの列に変換するソフトウェア。
スクリプト/コーデイングの知識の他、UIを操作してどのようにアプリケーションが挙動するかといった仕様周りについても理解しておく必要があるとのことです。
私個人としては、デスクトップWebアプリケーション、デスクトップアプリケーションのテスト自動化と比べると、モバイルWebアプリケーション、モバイルネイティブアプリケーションのテスト自動化は敷居が高いと考えます。
それは、Android OSであれば、Android StudioやJavaに関する知識が必要であったり、iOSの場合はXcodeの知識や有料アカウントが必要であるためと考えています。
特に、「Appium」では、Webやyoutubeなどで検索すると、ほとんど海外の有志が開設しているものがほとんどです。
環境設定手間がかかるためだと思います。
当ブログでは、なるべく本年の内に、Web記事またはYoutube動画を投稿予定ですので、ブックマーク頂ければ幸いです。
話を戻しますが、モバイル自動化テストにおいて、自動化を行なう目的によっても、スクリプトの作成方法が異なります。
| 比較項目 | オブジェクト識別 | 画像/OCR比較 |
| 信頼性 | 識別子が固定されている限り、画面レイアウトを変更できる。 リスクとして、ユーザーから隠されているオブジェクトが、コード上で識別され操作される可能性がある。 これは、偽陰性のテスト結果をもたらす可能性がある。 | 画像は画面サイズに応じて拡大/縮小される可能性があり、レイアウトが変更されるとすぐにテストは失敗する。 |
| ユーザーエクスペリエンス | 通常、手動でスクリプトを作成する必要があり、最低限、記録されたスクリプトの読みやすさやメンテナンス性を改善する必要がある。 | スクリプト作成を必要としない完全な GUI ベースドテスト。 |
| 実行速度 | 特にシステム製造元により提供され るネイティブツールを使用する場合 は、画像/OCR 比較より高速になる 傾向にある。 | 画面をピクセル単位でベースラインの画像と比較する必要があるため、オブジェクト識別より遅くなる傾向にある。 |
| メンテナンス | テストスクリプトの品質に依存する。 | 変更されたベースラインの画像の用意が主な作業 |
| 作成における課題 | 接続可能な自動化ソリューションを実現するには、スクリプト言語とソフトウェア設計方法の知識が必要となる。 | 特にアプリケーションが頻繁に変更される場合では、ベースラインの画像の作成が課題になる。 |
□5.3自動化ツールの評価
この項目では、自動化ツールの評価についてとなります。
JSTQBシラバスでは、「テスト自動化のチームは、ツールセットの選択、およびツール間の主な違いを理解し、プロジェクトの要件に対する合目的性を考慮する必要がある」
と表記されています。
自動化ツールの選定、またはツールを導入する際、プロジェクトの要件に合っているか、さらに実際にツールを使用しての評価を行なう必要があると思います。
プロジェクト振り返り時など、自動化ツールに関する振り返りも行い、評価を行なうことです。
テスト自動化ツールの評価パラメータとしては、以下の2つのカテゴリが挙げられています。
・組織的な統合
・技術的な統合
FLのモバイルアプリケーションテスト担当者シラバスでは、「組織的な統合」については特に明記されておらず、「ISTQB_CTFL_2018 6.2」を参照と明記されています。
「技術的な統合パラメータ」
技術的な統合では、以下のパラメータが挙げられています。
テスト自動化ツールを評価する場合、例として、以下のパラメーター／項目に対して５段階評価を行なうといったことができると思います。
例）
評価点数１〜５
数値が高いほど高得点
| No. | 概要 | 評価パラメータ | 評価点数 |
| No.01 | 新し要件への対応 | FaceID、指紋、チャットボットなど新しい機能をアプリケーションが使用するといったテスト自動化の要件と複雑度 | 3 |
| No.02 | テスト環境要件への対応 | ネットワーク条件、テストデータのインポートや作成、サーバー再度の仮想化といったテスト環境の要件 | 4 |
| No.03 | リザルト／FBへの対応 | テストレポートおよびフィードバックグループの機能 | 4 |
| No.04 | フレームワークへの対応 | ローカルまたはクラウドのいずれかのテストラボにおいて、大規模な実行を管理および推進するフレームワークの能力 | 3 |
| No.05 | 他ツールとの連携／対応 | テストフレームワークと、組織で使用されている他のツールとの統合 | 2 |
| No.06 | 将来性／アウトプット対応 | 現在および将来のアップグレードに対するサポートと文書の可用性 | 3 |
□5.4自動化テストラボをセットアップする手法
こちらの項目では、テスト自動化の対象として使用するデバイステストラボについてとなります。
第4項の「モバイルアプリケーションのプラットフォーム、ツール、環境」でもご紹介したように、テストラボはオンプレミス、リモートデバイスが挙げられます。
以下では、オンプレミスデバイス、リモートデバイスのテストラボのそれぞれの特徴を表記しています。
「オンプレミスデバイステストラボ」について
・一般的にメンテナンスが困難かつ、時間がかかる。
・開発とテストの初期フェーズでは、エミュレータやシミュレーターと並行してデバイスをローカルで利用できるようにすることが最善。
「リモートデバイステストラボ」について
・アプリ開発が進んだ段階でのリグレッションテスト、機能性テスト、非機能のテスト実施に最適。
・クラウド管理、継続してメンテナンスされており、最新の環境に維持されている。
尚、テスト自動化フレームワーク、継続的インテグレーションジョブ（CI）を介して大規模に実行する場合、テストラボ全体の安定性が、テストの効率性と信頼性にとって重要となります。
オンプレミス、リモートデバイスのテストラボは、状況等によって選択すると良いかもしれませんね。
■最後に
以上、JSSTQBシラバスモバイルアプリケーションテスト担当者の5項について紹介致しました。
他のJSTQBシラバスについても、適時紹介したいと思います。
最後まで読んで頂き、ありがとうございました。
iOSアプリ開発自動テストの教科書 〜XCTestによる単体テスト・UIテストから，CI/CD，デバッグ技術まで
作ればわかる！Androidプログラミング Kotlin対応 10の実践サンプルで学ぶAndroidアプリ開発入門
