simple guide interoperability testing
のテクニックを理解する前に 「相互運用性テスト」 、最初に「相互運用性」という用語を理解しましょう。
YouTubeをオンラインで無料でmp4に変換
相互運用性は、あるシステムが別のシステムと相互作用する能力です。この相互作用は、2つの異なるシステム間または2つの異なるアプリケーション間で行われます。
多くの場合、相互運用性はと混同されます 統合 、互換性と移植性。まあ、これらのテクニックの間には違いがあります。
まず、違いを説明することから始めましょう。
統合 –同じシステムのコンポーネントが相互作用する場合の手法です。したがって、テストの世界では、統合テストを行うときに、同じシステムの2つ以上の最低レベルのコンポーネントの動作を実際にテストしています。
互換性 –2つ以上のアプリケーションが同じ環境で相互作用する手法です。したがって、テストの世界では、互換性テストを行うとき。 2つ以上のアプリケーションまたはシステムが同じ環境で期待どおりに動作するかどうかを検証します。
ここでの目的は、2つのシステムが、同じ環境で互いに動作を妨げることなく、期待されるタスクを実行することを確認することです。同様に– MS WordとCalculatorは2つの異なるアプリケーションであり、同じオペレーティングシステムで独立して期待される動作を実行します。したがって、これら2つのアプリケーションは相互に互換性があると言えます。
移植性 –アプリケーションまたはシステムが別の環境に移動されたときに期待どおりに動作する場合の手法です。だからで 移植性 テストでは、アプリケーションを他の環境にエクスポートし、その動作をテストします。同様に、Windows XPでうまく機能するアプリケーションがある場合、Windows10でもうまく機能するはずです。
相互運用性 –アプリケーションが別のアプリケーションと相互作用する方法です。したがって、相互運用性テストを行うときは、あるアプリケーションからのデータが、事前の通知なしに、意味のある方法で別のアプリケーションに転送され、さらに処理されて受け入れられた出力が得られる方法を確認します。
この特定のペーパーは相互運用性テスト（IOT）に焦点を合わせているので、相互運用性に焦点を合わせ続けましょう。 :)
学習内容：
相互運用性テスト–簡単な紹介
相互運用性= Inter +操作可能
インテル –「私たちの間」、「お互いの中で」、「相互」を意味します
操作可能 –「特定のタスクを実行できる」という意味
したがって、2つの用語を組み合わせる–相互運用性とは、割り当てられたタスクを独立して実行でき、割り当てられた個々の機能に影響を与えることなく、期待どおりに相互に通信できる2つ（またはそれ以上）のシステムを意味します。
例1：フライトの予約の例を見てみましょう。ニューデリーからニューヨークに旅行する必要があると考えてください。今、あなたは直行便を持っていません。ニューデリーからロンドンに移動してから、ロンドンからニューヨークへの乗り継ぎ便を利用する必要があります。時間の制約があるため、ニューデリーからロンドンへのフライトは「ジェットエアウェイズ」で、ロンドンからニューヨークへは「ヴァージンアトランティック」で予約します。つまり、すべての乗客の詳細がジェットエアウェイズからヴァージンアトランティック航空に渡されたことを意味します。したがって、ここでは、ジェットエアウェイズとヴァージンアトランティック航空の両方が独立したアプリケーションであり、フライトを予約している間に、予約の詳細がジェットエアウェイズからヴァージンアトランティック航空に完全な方法で交換されました。
例2：同様に、患者の記録が1つの部門から他の部門に交換される病院管理システムについて考えてみます。したがって、ここで部門をアプリケーションにリンクできます。患者の詳細は、事前の通知なしに、あるアプリケーションから別のアプリケーションに交換されます。
では、なぜIOTを実行する必要があるのでしょうか。
相互運用性テストを実行して、次のことを確認する必要があります。
- ネットワーク内のアプリケーションは、期待される動作を独立して実行します。
- 事前の通知なしに情報を交換できます
- 情報/データは、個々の予想される動作を中断することなく交換されます
- 交換されるデータ/情報は変更または変更されません
相互運用性テストを行う方法は？
みなしホイール（PDCAサイクル）に従って、相互運用性テストを実行できます。
＃1）計画
計画は、ソフトウェア開発でほとんどすべてを行う戦略を決定する上で最も重要なフェーズです。 IOTを実行する手順を実際に決定する前に、ネットワークにデプロイされているすべてのアプリケーションまたはシステムを理解することが重要です。
すべてのアプリケーションについて知っておく必要があります-その機能、動作、それが取る入力とそれが明らかにする出力。
また、相互運用性テストの準備をする前に、すべてのアプリケーションを欠陥なく完全に機能的にテストすることをお勧めします。したがって、計画するときは、1つまたは2つのアプリケーションだけでなく、すべてのアプリケーションを1つのユニットとして考えてください。このテスト手法を計画するときは、鳥瞰図が必要です。言うまでもなく、計画を文書化します。
使用できます 標準のテスト計画文書 そして、IOTの計画を文書化するための要件に従って少し調整します。テスト計画を立てたら、先に進んでテスト条件を導き出します。
テスト条件の導出の焦点は、個々のアプリケーションに限定されるべきではありません。代わりに、すべてのアプリケーションを通過するデータの流れに基づく必要があります。条件は、すべてではないにしても、ネットワーク内のほとんどのアプリケーションがトラバースされるように設計する必要があります。
テスト条件が特定されたら、テストケースの設計またはスクリプト作成（自動化を計画している場合）に進みます。あなたはできる RTMを作成する （要件トレーサビリティマトリックス）テストケースをテスト条件にマッピングし、テスト条件を受け入れテスト条件/要件にマッピングします。
ネットワークで作業しているときは、非機能テストアクティビティも計画することが重要です。これはどこにも書かれたり文書化されたりすることはありませんが、システム全体の機能しない側面をチェックする必要があります。これらの非機能領域には、パフォーマンスとセキュリティが含まれます。必要に応じて、機能テスト、パフォーマンステスト、およびセキュリティテストの個別の計画を作成できます。または、これらのテストタイプごとに、単一の計画とテスト条件の異なるドキュメントを作成します。
＃2）する
実行–実際に実行を行う期間です。それに応じて、機能テストと非機能テストを実行する時間を計画してください。ケースを実行し、欠陥をログに記録し、開発チームにフォローアップして問題を解決し、システム全体の再テストと回帰テストを実行し、テスト結果を報告してに移動するというこのフェーズのテストサイクルに従います。閉鎖。
ソフトウェア開発ライフサイクルウォーターフォール方式
＃3）チェック
チェック–テスト結果を再検討し、それらをRTMにマッピングして、予想されるすべての要件が満たされているかどうか、およびすべてのアプリケーションがトラバースされているかどうかを検証するフェーズです。データがアプリケーション/システム間で正しくスムーズにトラバースおよび交換されることを確認します。また、トラバースされるデータが変更されないことを検証する必要があります。
また、相互運用性テストのプロセス全体を振り返ることも検討してください。うまくいった領域、うまくいかなかった領域、および注意が必要なアクションアイテムを特定します。
＃4）行動
行動–遡及的項目に基づいて行動することです。 「グッドプラクティス」として特定されたポイントは、それらを実行し続け、より適切に機能する可能性のあるポイントを特定し、それらを修正するための手順を特定し、それに応じて行動します。うまく機能しなかった領域や手順を繰り返さないように注意してください。結局のところ、私たちは自分の過ちから学び、それを繰り返すべきではありません。
5½ステップ：
- ネットワークの一部であるすべてのアプリケーションを識別します。
- それぞれの機能を特定します。
- アプリケーションごとに、取得する入力と返される出力を特定します。
- すべて/ほとんどのアプリケーションを通過するデータを特定します。
- 検証が必要なアプリケーションと日付の組み合わせごとに予想される動作を特定します
½それを文書化します。
次の図を検討してください。
図に基づいて、5½ステップを複製してみましょう。
- アプリケーション1、アプリケーション2、アプリケーション3、およびアプリケーション4は4つの異なるシステムです。
- これらの各システムには、識別する必要のある明確な機能セットがあります。
- 各システムの入力と出力を識別する必要があります。
- Application1の場合、2つの出力をレンダリングします。 1つの出力はアプリケーション3の入力を形成し、1つの出力はアプリケーション2の入力を形成します。アプリケーション2からの出力は、アプリケーション3およびアプリケーション4への入力を形成します。
- 入力と出力のそれぞれの有効性がチェックされます。ここで考慮すべき重要な点は、入力と出力の形式でトラバースしているデータは変更されず、すべてのアプリケーションがカバーされているということです。
½実生活でのこの数字は、これほど単純ではないように思われるかもしれません。これにより、実際には、n個の入力条件と出力条件を持つより複雑な構造になります。
この種の図を描くと、さまざまなシステムを通過するデータと情報を特定するためのより良い図が得られます。これは、テスト条件とケースを導き出すのに役立ちます。
例：
「病院管理システム」の相互運用性テストを実施する例を考えてみましょう。
病院は、以下の部門とサブ部門で構成されています。
ここで、各部門はそれ自体がアプリケーションです。各部門（アプリケーション）には独自のサブ部門（モジュール）があり、各モジュールには独自のユニットがあります。
そこで、IOTの範囲を検討するために、いくつかのテスト条件を示します。
- 交通事故（OPD部門–事故）に遭遇した患者は、脚の手術（ENT –一般外科）を受け、次に理学療法（サポート部門–理学療法）を受けてから退院（サポート部門–閉鎖）を受ける必要があります。
- クリティカルケア（小児科–クリティカルケア）に入院した子供は、手術（小児科/耳鼻咽喉科–一般外科）を受ける必要があり、その後退院します（サポート部門–閉鎖/ PR）
- 外部の患者は一般医（OPD部門）に相談します。処方された薬（サポート部門–薬局）を取り、立ち去ります。
- 妊娠中の母親が定期検査（婦人科–母子ケア）に来て、処方された薬を服用し（サポート部門–薬局）、立ち去ります。
- 歯科患者は根管治療（歯科部門）を行い、処方された薬を服用し（サポート部門–薬局）、立ち去ります。
- 患者はOPD（一般医）に来て、（産婦人科–高リスク産科）で治療を受け、処方された薬（サポート部門–薬局）を服用して退院します
このようにして、すべてのテスト条件を識別します。部門のほとんどがカバーされる必要があることを覚えておいてください。
RTMを描画して、カバレッジを次のように表示できます。
このようにして、より多くのテスト条件を特定し、RTMを描画して正確な範囲を確認できます。また、RTMに基づいてテスト作業の深さを判断できます。
この例のように、「サポート部門」はアプリケーションのすべて（ほとんど）の出口点であるアプリケーションであることがわかります。したがって、この特定のアプリケーションのテスト作業は、他のアプリケーションと比較して少し多くなります。
課題：
- すべての順列と組み合わせですべてのアプリケーションをテストすることは困難です。
- アプリケーションはさまざまなハードウェア/ソフトウェアの組み合わせで開発され、さまざまな環境にインストールされるため、いずれかの環境がダウンした場合、テストに影響を与えます。
- ソフトウェアと環境が異なるため、テスト戦略を決定して実行すること自体が大きなタスクです。
- テストを実施するための環境を刺激することは、大きな課題です。
- 欠陥がある場合、根本原因分析を行うことは大きな課題です。
- アプリケーションはネットワーク内にあるため、ネットワークがダウンしている場合があります。このため、テストも影響を受けます。
これらの課題をどのように軽減できますか？
1） 次のような高度なテスト手法を使用してみてください。
- OATS（直交表テスト手法）
- 状態遷移図、
- 原因と結果のグラフ
- 等価分割と境界値分析。
これらの手法は、アプリケーション間の相互依存性を特定し、最大のカバレッジを保証するテストケース/条件を特定するのに役立ちます。
2） システムがダウンした状況、動作を再開するのにかかる時間など、いくつかの履歴データを特定してみてください。その場合は、アプリケーションが影響を受けないシナリオを実行するか、時間を利用してシナリオを文書化し、結果を報告してください。さらに、テストを計画またはスケジュールするときは常に、これらの履歴データを見積もりの入力として考慮し、それに応じて計画してください。
3） 予定 - 履歴データ、過去の経験、チームのスキル、環境要因を使用して、テストの戦略を特定します。あなたの計画が良くなればなるほど、あなたの実行も良くなるでしょう。
4） 実際の実行が始まるずっと前に、環境の準備に取り掛かります。言うまでもなく、環境を準備するときの手順を計画してください。実行の開始時に、環境がすべて設定され、準備ができて稼働していることを確認してください。
手動テストのテストケースの例
5） IOTを開始する前に、個々のアプリケーションが完全に機能的にテストされ、欠陥がないことを確認してください。次に、欠陥が発生した場合は、エラーの原因となった環境要因を探すだけで済みます。
6） ポイント2で説明したように、アクティビティを計画します。計画停止の場合は、テストを計画するときにこのダウンタイムを考慮する必要があります。
モバイルでの相互運用性テスト：
モバイルでは、新しいアプリがあればいつでも相互運用性テストを行います（ モバイルアプリ ）が起動します。モバイルデバイスでのこのテストを計画する際に考慮しなければならない領域はたくさんあります。
- 市場で入手可能なモバイルデバイスの種類は膨大です。テストで検討するすべてのタイプのデバイスをリストアップする必要があります。デバイスタイプとそれがサポートするOSをペアリングする必要があります。
- すべてのモバイルOSは、異なるプログラミング言語で開発されています。したがって、アプリはOSのすべてのバリエーションに対してテストする必要があります。
- 法的要因と地域関連の契約を理解する。
- 異なるデバイスのサイズ/解像度は異なります。
- モバイル組み込みアプリへの影響も考慮する必要があります。
したがって、モバイルでIOTを実行するには、コンピューターベースのアプリケーションテストで行ったのと同じように、RTMを計画および作成する必要があります。
意図、戦略、リスク、実行は同じですが、 ツールとテクニック 携帯電話の場合は異なります。
結論：
相互運用性テストは大きなタスクです。この手法には、システムテスト計画の開始時に並行して開始する必要がある適切な計画が必要です。
この手法を実行する際に考慮する必要のある要素はたくさんあります。バグの修正と再テストには十分な時間をとることを忘れないでください。これは多大な労力であるため、欠陥のフォローアップに備える必要があります。
これはあなたが100％を達成しないかもしれないということが起こるかもしれません カバレッジ 、しかし、優れたテストケース作成手法を使用して、ほとんどのアプリケーションが単一のフローでカバーされるように、ケースを選択するのに十分賢い必要があります。
この記事が相互運用性のテスト手法を理解するのに役立つことを願っています。あなたの質問/コメントを教えてください。