I.はじめに
私は最近、「スマート ホーム ミニ プログラム自動テストの設計と実装」[1] という優れた論文を読み、多くの恩恵を受けました。著者の簡潔で美しい言葉のおかげで、ソフトウェア自動化テストについてより明確に理解できました。
2. プロジェクト分析
著者はスマートホームアプレットに基づいて自動テストを推進する理由をまとめ、プロジェクトの実現可能性分析とページ分析を実施します。
1. 自動テストの理由
(1) 複雑なページ要素: アプレットのページは View (ビュー)、Layout (レイアウト)、Menus (メニュー)、Widget (インターフェース) などで構成されており、ページ要素は多く、複雑です。手動テストを使用すると、要素テストを完了するのに多くの時間がかかりますが、自動テストを使用すると、多くの人的資源と物的リソースを節約できます。スクリプトを作成するときは、XPath などのメソッドを使用して要素を見つけることができます。
(2) テストプロセスが複雑：通常、テスト作業はフロントエンドとバックエンドの開発後に実行され、介入が遅く、テスト時間が十分ではないため、テストの保証が困難です。ソフトウェアの品質。したがって、フロントエンド開発とバックエンド開発の間にテスト障壁、つまりインターフェイスのテストが追加されます。バックエンドインターフェース納品後にインターフェース自動化テストを実施し、インターフェースに問題があった場合、フロントエンドを呼び出すことなくバックエンドの問題を事前に発見できるため、時間を節約できます。
2. 実現可能性の分析
(1) 経済的実現可能性: つまり、コストの問題、自動テストで使用されるツールとテクノロジはすべてオープンソースであり、無料です。
(2) 技術的な実現可能性: インターフェース自動テスト設計には JMeter+Ant+Jenkins フレームワークを、ページ自動テスト設計には Appium を使用しており、オープンソースで習得が容易な技術です。
(3) 運用可能性：フレームワークがシンプルで操作しやすく、ページもシンプルでわかりやすい。
3. ページ分析
(1) ページ分類: ミニ プログラム ページは、ネイティブ ページとハイブリッド Web ページに分類されます。自動テスト分析中は、2 種類のページを別々に処理する必要があります。ネイティブ ページの場合は、ページ要素を正確に見つけてページ コントロールを取得できますが、ハイブリッド Web ページの場合は、特別な自動テスト ソリューションをカスタマイズする必要があります。
(2) ページ モジュール: ミニ プログラム ページは、いくつかの機能モジュールに分割できます。自動テスト要件を設計するプロセスでは、各モジュールを最大限に分離し、モジュールごとにテスト ケースを作成する必要があります。これにより、後で変更された場合でも、モジュールのみを変更するだけで影響が最小限に抑えられます。
(3) ページジャンプ: アプレットのページ間には多くのジャンプが発生するため、テストケース設計の過程でジャンプ関係を明確に整理する必要があります。
3. 自動テストフレームワークの分析と設計
1. UI自動テストフレームワークの分析と設計
UI 自動テスト フレームワークは、クリック、スライド、ページの切り替え、ページのジャンプなど、ページ上のユーザー操作をシミュレートします。ページ要素を識別して特定し、それに応じてページ ジャンプ、ページ切り替え、メッセージ ポップアップに対処する必要があります。Selenium、appium、minium (WeChat アプレット自動テスト フレームワーク) など、ページ自動テスト フレームワークは数多くあります。本稿では、著者はAppiumを使用し、Appiumを利用してPycharmと携帯電話ポートを接続し、携帯電話端末上の小型プログラムを制御する機能をテストスクリプトで実現します。
スクリプト アーキテクチャを設計する際に考慮すべき要素:
(1) 小規模プログラムのテストと UI 自動テストのフレームワークは分離する必要があり、一般化することはできません。
(2) テスト スクリプトはプラットフォーム間で使用され、さまざまなアプリケーション システムと互換性があります。
(3) テストスクリプトモジュールは結合度が極めて低いこと、モジュールの更新に複数箇所の修正が含まれないこと、メンテナンスが困難でないこと。
(4) プログラムとデータを分離し、スクリプトの再利用性を向上させます。
要約すると、作成者は機能ブロックに従ってテスト スクリプトを作成します。たとえば、アプレット モジュールに入り、シミュレートされた家電モジュールに入り、モールのホームページに入り、ディスカバリー ページに入り、マイ ページに入ります。そして、スクリプトの設計は、パブリック メソッド層、モジュール ユースケース層、ユースケース実行層の 3 つのレベルに分かれています。次のように：
- パブリック メソッド レイヤー: HTMLTestRunner などの一般的なファイルと関数を保存します。
- モジュールユースケース層: 機能およびモジュールごとに設計し、単体テストモデルを使用し、各機能ブロックは独立しています。
- ケース実行レイヤーを使用します。テスト ケースをロードし、テスト ケースを実行し、テスト レポートを生成します。
2. インターフェース自動テストフレームワークの分析と設計
インターフェイス テストは、ユーザーがバックグラウンドにリクエストを送信することをシミュレートするもので、Postman、JMeter などのツールを使用して実現できます。ここでは、JMeter+Ant+Jenkinsのインターフェース自動テストフレームワークを採用し、インターフェースの自動テストを実現します。JMeter は、サーバーにリクエストを送信する小さなプログラムをシミュレートするインターフェイス テスト用のスクリプトを作成するために使用されます。JMeter は、アサーションを使用してインターフェイスの戻り値が正しいかどうかを判断し、フロントエンド ページに依存せずに順方向および逆方向のテストを発行できます。Ant は、システムが認識できないコードを認識可能なコードにコンパイルできるコード コンパイル ツールであり、テスト スクリプト生成ツールです。Jenkins の主な機能は継続的インテグレーション、スケジュールされたビルド タスクであり、電子メール通知の機能もあります。構造は次のとおりです。
4. 自動テストプロセスの分析と設計
自動テスト プロセスには主に、自動テスト要件分析、テスト計画の作成、自動テスト スクリプト作成、自動テスト スクリプト実行、およびテスト結果分析の 5 つの主要なステップが含まれます。写真が示すように:
(1) 自動テスト要件分析
ソフトウェアテストのユースケースは、ビジネス要件ドキュメントに従って作成されます。ビジネス要件を分析した後は、ビジネス要件をテスト要件に変換し、手動テストで完了できる部分と自動テストで完了する必要がある部分を分析する必要があります。分析後は、具体的なテスト戦略と方法を策定し、最終的に要件を満たす手動テスト ケースと自動テスト ケースを作成する必要があります。
(2) テスト計画を立てる
テスト要件を明確にした後、テスト計画を作成する必要があります。たとえば、テスト範囲、時間、分業、環境展開などです。テスト計画はテストマネージャーによって策定され、テストマネージャーはグループメンバー間の役割分担を柔軟に調整し、プロジェクト計画を調整します。
(3) テストスクリプトを書く
テスト計画が完了したら、テスト エンジニアはプロジェクトの特定のニーズに従ってテスト スクリプトの作成を開始します。テスト スクリプトが完成したら、レビューのためにプロジェクト チームに送信され、テスト シナリオがカバーされているかどうか、改善の余地があるかどうかが確認されます。
(4) 自動テストスクリプトの実行
テストスクリプトをレビューして問題がなければ実行テストの段階に入りますが、テスト前に環境を整える必要があります。テストの実行後、レポートと長いログが作成されます。
(5) 試験結果の分析
テストレポートが発行された後、テストエンジニアはテスト結果をより明確にするためにテストフォームを変更する必要があります。テストに失敗した場合は、ソフトウェア自体の問題なのか、スクリプト設計の問題なのか、テスト環境の問題なのかを分析する必要があります。
参考文献: [1] Deng Meiqi. スマート ホーム ミニ プログラム自動テストの設計と実装 [D]. 南京郵電大学。