インタフェースの自動化テストについて


昨夜、あるテスト交流グループで、テストのベテラン運転手がインタフェースの自動化テストの内容を共有することを聞いて、インタフェースの自動化に対してもっと深い認識を持って、次の会社のインタフェースの自動化の実施のために、もっと多くの構想を提供しました.
このブログでは、インタフェースの自動化への機能テストの段階と、インタフェースの自動化について説明します.の
前言
自動化テストは、近年比較的熱い話題となっています.もちろん、ソフトウェアテストの将来の発展傾向です.将来、機能テストなどの非核心的なテスト作業は、アウトソーシングされます.
ソフトウェアテストという業界を前進させるには、核心競争力を持ち、自動化テスト技術を身につけなければならない.
「Googleソフトウェアテストの道」という本には、Googleでは70%の自動化テストがユニットテストに集中し、20%がインタフェーステストに集中し、残りの10%がUIテストであると紹介されています.
確かに、私たちはGoogleほど完璧なメカニズムとエンジニア文化を持っていないので、すべてGoogleをそのままにする必要はありませんが、Googleはインターネット2.0時代で最も輝かしい会社として、その技術発展の方向、プロセス管理などは近い将来と言えます.
私たちも到着する方向です.自分に合ったアプリケーションを選ぶのは、今私たちがすべきことです.
現在、国内のインターネット業界、大環境にとって、まだ急速な発展にあり、プロセス化の標準化が必要な時期にあり、どのようにして絶えず変化する発展のリズムに追いつくかは、新しいものに触れるだけでなく、絶えず勉強し、自分を向上させる必要がある.
の駆動力は、時代の波に追いつく.潮を引くことができなくても、時代淘汰のロットにはなれない.ここまで言うと、2冊の本をお勧めします:呉軍の著作《波の頂》、《シリコンバレーの謎》、興味のある子供靴は行ってみることができます...
一、インタフェーステストの必要性と意義
インタフェース、すなわちAPI、アプリケーションプログラミングインタフェース、インタフェースについての紹介、前のブログで詳しく紹介したことがありますが、興味のある子供靴は見てみましょう:インタフェーステストの概要
ここでは主にインタフェーステストの必要性と意義について説明します.
インタフェーステストはマルチシステムのプラットフォームアーキテクチャの下で実施され、極めて効率的なコスト収益比を持っている(もちろん、ユニットテスト収益はもっと高いが、ユニットテストを実施するコスト投入はもっと大きく、技術要求はもっと高いので、自分にもっと適した案を選ぶべきだ).
インタフェーステストは生まれながらにして高複雑性のプラットフォームに効率的な欠陥検出と品質監督能力をもたらし、プラットフォームが複雑であればあるほど、システムが膨大であればあるほど、インタフェーステストの効果は明らかになる.
総じて言えば、インタフェーステストは高複雑性システムの品質を保証する内在的な要求と低コストの経済利益駆動作用の下での最良の方案であり、主に以下の3つの方面に体現されている.
1、テストコストを節約
データモデルの推定によると、最下位のプログラムBUGは上位の8つ程度のBUGを引き起こす可能性があり、最下位のBUGはネットワーク全体のデッドラインを引き起こしやすい.インタフェーステストは、システムの複雑さが上昇した場合の低コストで効率的なソリューションを提供します.
2、インタフェーステストはユニットテストと異なる
インタフェーステストは、ユーザーの観点からシステムインタフェースを全面的に効率的に継続的に検出するものです.
3、利益がもっと高い
インタフェーステストを自動化と持続的な統合に実現し、システムの複雑さと体積が大きいほど、インタフェーステストのコストが低くなり、それに対応して、利益の産出が高くなります.
二、インタフェースのテストをするにはどのようなスキルが必要ですか.
この点については、前のブログでも言ったように、転送ドア:インタフェーステストにどのようなスキルが必要か
インタフェースのテストをするには、必要なスキルは、基本的に以下の点です.
ビジネス・フロー:システムと内部の各コンポーネント間のビジネス・ロジックのインタラクションを理解します.
データストリーム:インタフェースのI/O(input/output:入出力)を理解する;
プロトコル:httpプロトコル、TCP/IPプロトコルファミリー(以前のブログではプロトコルを紹介したことがありますが、転送ゲート:httpプロトコル:菜鳥入門シリーズ)
ツール:ツールは、jmeter、loadrunner、soapui、postmanなど、より効率的な作業を支援します.
データベース知識:データベースから知識を取得しても、データの到着を確認しても、インタフェースがデータに対してどのような操作を実行しても、確認する必要があります.そのため、データベース知識(実際には削除・変更)が必要です.
補足:インタフェースドキュメントのいくつかの必要点:完全性、一貫性、許容誤差;
三、インタフェースの自動化テスト
1、どのように展開するか
まず、単一のインタフェースをデバッグし、単一のインタフェースの正確さとスムーズさを保証します(性能テストのベンチマークテストと似ています).
次に、データストリーム、業務フローを明確にする.
最後に、N個のインタフェーステストスクリプトを直列に接続し、実行すればよい.
最も重要な点は、あまり複雑に考えないで、まず最も基礎的な最も簡単なことをすれば、大半が成功します.拡張性のあるサードパーティインタフェース、https、タイミングタスク、自動テストレポート、自動メールなどの機能については、これは絶えず累計され、最適化されています.
行動すればいいのに、考えすぎるより行動して、インタフェースの自動化テストを着地させることが、私たちがまず考えなければならないことです.
2、展開する前に知っておくべきこと
現在のテストオブジェクトにはいくつのページが含まれていますか?
各ページにはいくつのインタフェースがありますか?
それぞれどのステップで呼び出しますか?
各インタフェースにはどのフィールドが含まれていますか?
各フィールドはデータベースのどのテーブルに対応しますか?
各テーブルの各フィールドはどういう意味ですか?
各インタフェースはテーブルに対してどのような操作を行いますか?
3、自動化フレームワーク
フレームワークとは?完全なループとして理解したり、インタフェーステストスクリプトを実行させる環境、プラットフォーム、何でもいいと理解したりすることができます.一般的な自動化テストフレームワークには、次の点があります.
≪データ・プール|Data Pool|emdw≫:テスト・データのストレージ管理です.一般的には、次のようなdataパッケージに統合されています.
   log(    )、report(      ,   xml  )、
         case-data(         ,   json  )、server-data(         ,   excel  )

スクリプト管理センター:インタフェーステストスクリプトの統一管理、記憶、スケジューリングセンター、よく使われるツールはmaven、antなどがあり、あるいはプログラミング言語のユニットテストフレームワークが提供する機能を使用して、自分が適用するものを選択すればよい.
実行プラットフォーム:一般的にツールを使用してこれらのテストスクリプトを実行します.ツールは上記のいくつかの(jemter、loadrunner、soapuiなど)を使用することができます.同様に、適切なものを選択することが重要です.
持続的な統合ツール:最も一般的なのはJenkinsで、その役割は外部プログラムの呼び出し実行、タイミングまたはスケジューリングタスクのトリガ、テストスクリプト実行などの機能を監視することです.
通信サービス:dubbo、spring_boot、thriftなどのRPC、REST同期呼び出しサービス;
テスト結果統計管理センター:例えばtestlinkは、テスト結果が自動的にアップロードされ、テスト結果をよりよく統計し、後期の最適化を行うことを目的としています.
以上述べたように、実際には、データとスクリプトを分離し、テスト結果を自動的に通知し、テストスクリプトとテストデータのメンテナンスの便利さを高めるなどの意味があります.
私が使っているフレームワークは、jemter+maven+Jenkins+dubbo+MySQLです.
インタフェースの自動化テストについては、基本的に上記の内容ですが、もちろん、自分の実際の状況に合ったフレームワークを選んで、着地して実施することがポイントで、行動してこそ、塩漬け魚が寝返りを打つことができます.の
転載リンク:https://www.cnblogs.com/imyalost/p/7430126.html