竜巻を追いかけるのはどのような感じですか? カナダ国境でソフトウェアをテストすることになったのはなぜですか? 車のトランクをいっぱいに詰め込み、AC/DC をフルパワーで作動させた状態で、中東のオンタリオ州に向かいます。 ルートをたどるにつれて、反抗的な空の色が変わります。雷が鳴り響き、震源地にゆっくりと近づいていることを示しています。 嵐が起こりつつあり、それが近づいているのを感じます。
せいぜいXNUMX分の距離だ。
急に曲がった後、トランクから反転する音が聞こえます。まるで三脚がビデオ機器の他の部分の上を飛んでいるように見えます。 被害がなければいいのですが、それを理解する時間はありません。アドレナリンが高まり、何十もの息をのむような画像が危険にさらされています。
いくつかのカメラ、電源ユニット、および持ち運ぶすべてのアクセサリとは別に、バックグラウンドで実行される特別なチェイサーのモバイル アプリがあります。 ルートのログを収集し、地図上の位置を定期的に変更し、最近撮影した写真を含むすべてのメディア ファイルをアップロードすることで、他のチェイサーと最新情報を共有します。
このアプリを使用すると、マップ上を移動しながら他の追跡者とチャットしたり、接続を維持したりすることもできます。 あなたの位置情報を共有することで、あなたは安全に保たれ、他の嵐を追う人たちも気象状況や道路状況を最新の情報で知ることができます。
渦巻く強風に向かってさらに 200 マイル進んでいるときに、アプリが突然クラッシュし、追跡を続ける機会がなくなりました。 あなたのすべての努力と乗車ログはライブマップから消去され、あなたと他のチェイサーの両方にとって永遠に失われます。
後者はアプリの「本格的なテスト」と言えますが、私も実際にそれを目撃しました。 同時に、大きなリリースの前にアプリを最大限の状態でテストすることは、ソフトウェア テスターにとって依然として最優先事項です。 これは、最も現実的な状況を再現し、いくつかのシナリオを実行することで実現できます。
位置情報ベースのアプリのテスト
私は夢中になっています モバイルアプリの開発 とテスト GPSナビゲーション かなり久しぶりのソフトウェア。 位置情報ベースのアプリのテストで私が最も気に入っているのは、実際の状況でアプリがどのように動作するかです。 簡単に言えば、主な課題は、チェイサーが予想される距離を走行するときに到達する実際の速度を再現することです。
しかし、最初から始めましょう。
チェイサー アプリの最初のバージョンが運用環境にデプロイされ、稼働する前に、次のようないくつかの方法でテストに時間を費やしました。
- 機能テスト: これには、位置情報ベースのアプリの応答性、UI、画面サイズ、向きなどの基本パラメーターのテストが含まれます。
- ユーザビリティテスト： アプリの UX をテストすることを目的としており、それがユーザーフレンドリーで包括的であるかどうかという質問に答えます。
- ローカリゼーションテスト: 場所固有の機能とパラメータを確認します。 これには、地図上の日付と時刻、速度、距離が適切に表示されていることを確認することが含まれます。
- ネットワークと機内モードのテスト: 位置情報ベースのアプリでは、さまざまなネットワーク接続 (Wi-Fi、4G または 5G、LTE など) でアプリがどのように動作するかをテストすることが不可欠です。 さらに、チェイサーの一部が飛行機で距離を達成したため、機内モードでのアプリの動作を確認しました。
- 割り込みテスト: 着信やメッセージ、信号損失、または音楽プレーヤーのトラックの切り替えにアプリがどのように反応するかをテストすることを目的としています。 また、アプリが中断前の状態に戻っているかどうかも検出します。
- 地理位置情報ブロックのテスト: 政治的またはその他の理由により、一部のアプリの使用が特定の地域で制限される場合があります。 そのため、アプリの使用が予想される地域でユーザーのアクセスが制限されていないことを確認することが重要です。
すべてのテストが完了して成功したように見え、数時間の連続使用でもアプリが安定した状態を維持できるようになると、ベータ版を正式にリリースしました。 実際の条件でテストすると、次のリリースで修正するさらに多くのバグが検出されることが期待されていました。 そして実際にそうなりました。
実際の追跡者がアプリを使用して数回乗車したところ、追跡から約 5 ～ 6 時間後に iOS デバイスでクラッシュが発生し、アプリを再起動してもすべてのデータを復元できなくなっていることに気づきました。 他の追跡者にとって、クラッシュを経験したユーザーはマップ上でスタックし、「オフライン」として表示されました。
臨床検査の実施
さて、目標はバグを調査し、再現し、修正することでした。 私たちは別のテストラウンドに座りました。 13.6つの問題。 このクラッシュについて私たちが知っていたのは、それが iOS バージョン XNUMX で発生したということだけでした。
私たちは同様のデバイスでアプリを起動し、アプリをバックグラウンドで実行しながら 10 時間から 20 時間続く「追跡」を XNUMX 回実施しました。
そして、何だと思いますか？ クラッシュは発生しませんでした。
私たちは、次のライドはもっと長く、実験室の環境から離れて行うべきであることを理解しており、本物のストームチェイサーであるかのように道路に出なければなりませんでした。
実際の状況をシミュレートする
場合によっては、ソフトウェア テストが行われる地域では、実際の状況でのソフトウェア テストが不可能なことがあります。 私たちの場合、実際のストームチェイサーがトルネードアレイのどこかを移動している速度は、私たちの場所内では到達することが不可能であることがすぐにわかりました。 その国の交通法規は単にそれを禁止しているだけです。
市内での私たちの平均速度は時速約30マイルでしたが、他の追跡者は高速道路を時速55マイルで走行中に衝突を経験しました。 航空機を操縦するスカイチェイサーも、オフィスのコンピューターの前に座っている平均的な QA テスターが再現するのは非常に困難です。
私たちは、走行速度、距離、ルートを徐々に増加させることで、衝突だけでなく、追跡者に衝突が発生した正確な状況を再現する方法を見つける必要がありました。
つまり、クラッシュに有益な方法で対応できる必要がありました。 私たちは、これがアプリのクラッシュを引き起こした手順と状況を再現する唯一の方法であると考えました。
位置情報ベースのアプリをテストするための模擬位置情報の使用
したがって、私たちの目標は、速度を徐々に上げながら、実際のチェイサーのルートをたどる連続走行をシミュレートすることでした。 期待された結果は、クラッシュを捕捉し、ログを取得し、アプリが不安定になる原因となった正確な速度値、距離、ルート座標を受信することでした。
GPS ナビゲーション アプリは一夜にして登場したわけではありません。 iMyFone、AnyTo、EaseUS、MobiAnyGo、iSpoofer、Wondershare の Dr. Fone、Xcode など、位置シミュレーション用のさまざまなアプリで利用できるテスト ソフトウェア ビルド。
私たちはそれらをすべて試してみましたが、主な制限はまさに私たちがシミュレートできない (またはそれ以上の) 速度であることがわかりました。 iMyFone と EaseUS では制限速度が時速 22 マイルにすぎず、Wondershare の Dr. Fone では時速約 31 マイルでした。これにより、基本的に実験室の状態に戻り、クラッシュを再現することが不可能になりました。
これが明らかになった後、私たちは Xcode に切り替え、ルールに従って、自分で設定したさまざまな速度値でクラッシュを追跡してみました。
追跡をシミュレートする Xcodeの つまり、希望する速度と地理座標をテキスト ファイルに設定する必要がありました。 このデータ形式は .gpx として知られており、GPX ジェネレーターで生成できます。
このタイプのファイル形式を Xcode にアップロードすると、物理的に PC の前に居ながら、米国の地図上に示されたスポットを連続して走行するシミュレーションを行うことができます。 Xcode を使用すると、インターネット接続の切断や、接続タイプの 2G、3G、EDGE などへの変更をシミュレートすることもできました。 結局のところ、必要な情報をすべて含む GPX ファイルは、アプリのデバッグ ビルドから直接アップロードできます。
残っているのは、iOS デバイスを PC に接続し、Xcode を起動し、GPX ファイルをアップロードするだけです。
これにより、模擬ロケーションを使用し、米国旅行をシミュレートし、アプリがクラッシュする前に竜巻追跡者が到達できた速度と同様のさまざまな速度で可能なルートをテストすることができました。 私たちの場合、時速 6 マイルで 30 時間連続走行した後に iOS ビルドがダウンしました。合計の走行距離はわずか約 180 マイルです。
速度が時速 50 マイルに増加すると、アプリの連続動作時間は 4 時間に減少しました。 速度が高いほど、クラッシュをより速く再現できます。 アプリがフォアグラウンドで実行されているかバックグラウンドで実行されているか、チェイサーによってメディア ファイルがアプリにアップロードされているかどうかに関係なく、常に 180 マイルの距離で出現しました。
今度はクラッシュを修正する時が来ました。 macOS にインストールされた Xcode を使用して、デバッグ ビルドから中断された最新のチェイスに関する情報を含むファイルを含むコンテナーをダウンロードしました。
これにより、衝突を再現するための手順と条件に関する最も正確な情報を得ることができました。 さらに、これらのファイルを使用すると、開発者側で Xcode を使用して別のデバイスで追跡を続行し、クラッシュが発生した追跡中のアプリのパフォーマンスを調査することができました。
Xcode を使用して位置ベースのアプリをテストすることは、必要な修正を適用するために十分なデータを収集する効果的かつ比較的簡単な方法であると思われます。 開発者がクラッシュと小さなバグを修正し、アプリの最終バージョンが公開されたときに、私の Tornado Alley への旅は完了しました。
位置情報ベースのアプリをテストするときに知っておくべき重要なこと
さて、嵐を追う人々が竜巻シーズンに向けて準備を進めているとき、このシーズンは墜落事故なく通過すると予測されています。位置情報ベースのアプリをテストしたときに学んだポイントを共有するときが来ました。
- データを受信または送信するときのアプリの状態 (バックグラウンド/フォアグラウンド): 私たちの場合、アプリはフォアグラウンドとバックグラウンドの両方でクラッシュしたため、状態は問題ではありませんでした。
- インターネット接続の種類、その品質、および発生する可能性のある中断の品質: モバイル データまたは WiFi - どちらも開発者向けオプションでシミュレーションに使用できます。 地図を使って移動する人はガソリン スタンドに立ち寄って WiFi 信号に接続する可能性があるため、EDGE、2G、または 3G を含む利用可能なすべての接続タイプをシミュレートすることが重要です。 同時に、アプリはバックグラウンドでスムーズに動作し続けることが期待されます。
- 地理位置座標の形式: これらは正確である必要があり、緯度と経度、高度、速度、時間、方向、およびルートをできるだけ正確に再現するのに役立つすべてのデータが含まれている必要があります。
- 地理位置情報データを送信する時間と頻度: ここでも、ルート全体を再現する必要があります。 アプリをオフロードするために、マップの各ポイント間の距離 (チェイサーの地理位置情報を送信する間隔) を増やしてその数を減らしてみました。 ただし、この方法ではルートの精度が低くなり、バグの特定と再現ができなくなる可能性があります。 つまり、地図上に引く「線」はルートや走行条件に対応している必要があります。
- バックグラウンド モードでのアプリの継続的な作業: アプリを折りたたんだり、デバイスをロックしたりしても、アプリはスムーズに動作し続けることが期待されます。
- 再起動後のアプリの回復: アプリはいかなる中断にも耐え、アプリが閉じられた後、強制的に閉じられた後、またはクラッシュが発生した場合にルート全体を回復する必要があります。
- 位置シミュレーションに合わせて実際の条件を使用する: 幸いなことに、ソフトウェア テスターは Android と iOS の両方で位置シミュレーション用のツールをいくつか利用できます。
これらすべてのテストを経て、私たちはついに位置情報ベースのアプリを適切にテストし、最も勇敢な竜巻追跡者でも機能することを確認する方法に到達しました。
トルネード、QA エンジニア、そして永遠の物語がここにあります。
コインスマート。 BesteBitcoin-ヨーロッパのBörse
出典: https://www.iotforall.com/riders-on-the-storm-a-true-story-about-testing-a-gps-location-based-apps-told-by-qa-engineer
