iOS版BLEアプリの作り方【第6回：アプリの評価（動作テスト）】

2021年7月29日2022年5月9日

こんにちは。連載企画「iOS版BLEアプリをゼロから作ってみました（企画〜開発〜審査まで）」を担当させていただきました株式会社ERiの澤村です。

企画の趣旨や概要説明はこちらの記事をご覧ください。

第6回目はアプリの評価、動作テストについてお話します。

評価項目の作り方について

アプリの開発が終わったら、App Storeの審査に出す前に、仕様通り動作していること・バグがないことを確認します。

弊社は自動車の組込開発にも取り組んでいるので、V字プロセスに沿って、仕様書と対になるような評価項目を作成して評価を行いました。

一般的なV字プロセスは以下のようになっています。

仕様書と対になるような評価項目というのは、仕様書に書いている内容をそのまま評価項目とすることです。

例えば、収容アプリの仕様は

リストUIの表⽰・更新にはBluetoothを使⽤します。
本体のBluetooth機能がOFFになっていた場合は、Bluetooth機能をONにすることを促す内容のダイアログを表⽰します。

となっています。これに対し、評価項目を

「本体のBluetooth機能がOFFになっていた場合は、Bluetooth機能をONにすることを促す内容のダイアログが表⽰されること。」

とすることで、仕様書の内容を網羅した評価項目を作ることができ、抜け漏れを防ぐことができます。

BLE通信に関係する評価項目を作るときのポイント

BLE通信に関係する評価項目の作り方については、社内でたくさんのアドバイスを頂きました。

今回のケースでは、

受信したデータのアウトプットが期待通りの内容になっているか？
10KiBのような大量のデータを受信したときに、データの欠落が起きていないか？
アプリからの接続⇔切断が100回成功するか？
デバイスからの接続⇔切断が100回成功するか？

といった評価を行いました。

前の記事で書いたように、無線通信は安定した通信状態を維持できるとは限らないため、無線デバイスでは

接続できない（または再接続できない）
意図せず切断してしまう
データ抜けやデータ化けが起きる

といったトラブルが必ず挙がってきます。

例えば、「受信したデータがたまたま1バイト欠落した場合に、アプリがクラッシュした」ということも起きるかもしれませんので、そういったケースも考慮して評価します。

LINBLE Keyboardでは、特定のASCIIコードのみを扱う仕様のため、ASCIIコードすべてを送信して、期待通りの出力結果になっているかを確認しました。

なお、この評価では、Xcode上の単体テストで問題ないことを確認していますが、実際にBLE通信したときの動作も問題ないという保証はありません。だからこそ無線デバイスの動作テストにおいては、実機での通信評価も不可欠となります。

このように、無線デバイスを数多く手掛けてきた弊社は、「異常系」の評価も手厚く行った上で出荷をしています。

無線デバイスならではの評価方法

弊社ではデバイスとiPhoneが接続or切断できた、データが送信できた、というようなシンプルなチェックだけでは終わらせず、プロトコルアナライザを使用して実際にデバイスが出しているパケットを確認し、通信品質やパラメータを確認しています。

例えば今回のアプリだと、「接続ボタン」を押しただけでは本当に選択したLINBLEと通信できているかわかりません。アプリでは接続できたように見えても、実際はうまく通信できていない可能性もあります。

そこでLINBLE Keyboardの評価でもプロトコルアナライザを使って、選択したLINBLEがアドバタイズを出していること、iPhoneからそのLINBLEに対してちゃんと接続要求を出していることを確認しました。

また、これはアプリの評価とは直接関係ないのですが、私自身の知見を深めるために、ペリフェラルとセントラル間のパケットのやり取りからConnection IntervalやSupervision Timeoutなどのパラメータを決定するシーケンスを確認したり、LINBLEのadvIntervalパラメータを変更したときにBLE通信にどのように影響を与えるのかなど、さまざまなBluetooth通信の挙動についても確認しました。