18

自動化された受け入れテストのための Robot Framework に関する他の人の経験を聞きたいです。

その主な長所と短所、および他のフレームワーク (主に Fitnesse と Selenium) との比較は何ですか?

テストされるコードは、主に C++ で書かれたリアルタイムのレガシー コードです。

4

3 に答える 3

22

私がこれを書いている時点で、私は3つの異なる会社で約6年間にわたってロボットフレームワークを使用してきましたが、いずれも何らかの形で成功しています。

私の経験

会社1

私がRobotを最初に使用したのは、一流のインターネット旅行会社向けのJavaベースのWebアプリケーションでした。Robot with Jythonを使用しました。これにより、Javaでキーワードを作成し、テスト対象のシステムを直接操作できます。Seleniumを使用してWebブラウザーを駆動し、テストのほとんどはFirefoxで行われました。QA組織ではテスト作業は大部分成功しましたが、開発組織はそれを受け入れることができませんでした。彼らはロボットではなくJUnitを使用することを好みました。

会社2

私が感じる2番目の会社は無条件の成功でした。ロボットはさまざまな方法で使用しました。主な用途は、非常に成功した商用.NETWebアプリケーションの受け入れと回帰テストのためにInternetExplorerを駆動することでした。

また、SeleniumとAppiumを組み合わせてiPadアプリをテストするためにも使用しました。Robotを使用して、アプリにデータを提供するRESTfulサービスをテストしました。画像分析を可能にする特殊なキーワードを作成し、ロボットテストを使用して各トレーニングセッションの前にトレーニング機器をすばやく分析しました。テスト前にデータベースのスナップショットを作成し、テスト後にデータベースを復元できるキーワードがありました。

また、手動テストを支援するためにRobotの使用を開始しました。Robotに手動のテストケースを配置しました。これにより、Robotのレポート機能とタグ付け機能を活用できます。これらのテストが実行されると、テストケース管理ツールまたはWordドキュメントから手動ステップを読み取るテスターがいる場合よりもはるかに効率的であることが証明された手動ステップを実行するようにユーザーに促します。

会社3

3番目の会社は、かなり大規模なITスタッフを抱える大企業（収益10億ドル）でした。彼らには非常に低い技術スキルを持つテスターがいました（コマンドラインが何であるかを知らなかった人を覚えています）。キーワードのコアセットを作成し、他のチームにトレーニングとメンタリングを提供することに専念する1つのチームがありました。ロボットの使用は、最もスキルの低いテスターを活用するのに役立ったと思いますが、高レベルのキーワードを使用しても、テスターとの苦労はありました。

会社4

ごく最近、私はほんの一握りの開発者と専任のテスターがいない非常に小さな会社に引っ越しました。Robot Frameworkでページオブジェクトの使用を採用し、非常に安定した、読みやすい高レベルの受け入れテストのスイートができました。この会社でのロボットの使用は、無条件の成功でした。

強み

ロボットの最大の強みはその柔軟性です。Robotを使用して、手動テスト、SOAPおよびRESTサービスのテスト、WebベースのUIテスト、データベーステスト、画像のテスト、およびモバイルアプリのテストをサポートしました。Robotは追加のライブラリを使用して拡張するのが非常に簡単であるため、袖をまくり上げていくつかのキーワードを記述しても構わないと思っているかどうかをテストできないものはほとんどありません。設定に応じて、Python、Java、.NET、または実際にはRobotリモートAPIを介してほぼすべての言語でキーワードを記述できます。

ロボットのテストケースとキーワードはプレーンテキストで記述されているため、独自のツールを使用してテストを作成または表示することに縛られることはありません。ユーザーは、Visual Studio、Eclipse、Emacs、Notepadなど、選択したツールを選択できます。ロボット固有のIDE（RIDE）もありますが、お勧めしません。また、ファイルはプレーンテキストであるため、他のソフトウェアツールとうまく統合できます。つまり、差分やマージ、検索などが簡単です。

弱点

ロボットを使用すると、低品質のテストを簡単に作成できます。キーワードとテストケースを文書化し、キーワード、テストケース、変数に人間が読める名前を使用する機能はありますが、ベストプラクティスを適用する良い方法はありません。大量のテストとキーワードを書くには、規律が必要です。ことわざにあるように、ロボットはあなたにぶら下がるロープをたくさん与えます。

もう1つの弱点は、ロボットの進行ペースがかなり遅いことです。プラス面として、Robotは堅牢で比較的バグがないため、頻繁にパッチを適用する必要はあまりありません。ただし、問題追跡システムで何年も動きがないまま停滞する機能要求があり、これは落胆する可能性があります。

概要

すべての企業で、Robotの構文によって提供される柔軟性を活用して、データ駆動型テスト、BDDスタイルのテスト、および単純な手続き型テストを作成できることを楽しんでいます。また、すべての場合において、テストはプレーンテキストファイルであるため、テストアセットはSCMツール（Mercurial、Subversion、およびGit）を使用して簡単に管理できました。

私にとって、Robotは使いやすく、拡張が非常に簡単で、Python関数の単体テストから、Webサービスのテスト、ブラウザーベースおよびタブレットのUIテストまで、幅広いテスト業務に役立つことが証明されています。画像のテスト、データベースのテスト、さらには手動テストの効率を向上させるために。

于 2011-04-13T02:19:01.897 に答える
15

私の職場では、Robot Frameworkを1年以上使用しており、中程度の成功を収めています。ポスターのように、C++の作業も行います。ロボットをFitness/Slimに対して評価するのに少し時間がかかりました。当時、両方のソリューションは優れていましたが、決定要因は次のとおりでした（2009年まで）。

  • Robotとそのレポートが大規模なプロジェクトにどのように拡張されるかが明確になりました
  • Fitnesseアーティファクトのバージョン管理方法が明確ではありませんでした

技術的な観点から、私たちはSWIGを使用してRobotとC++の間を橋渡ししてきました。テストフィクスチャをSWIGでラップし、テスト対象の本番コードとリンクします。これにより、RobotでインポートできるPythonモジュールが提供されます。

ロボット入力にはほぼ排他的に.txt形式を使用します。このバージョンの方が制御が良く、読みやすく、HTMLの高度な機能（ここから始めたところ）を使用していなかったことがわかりました。さらに、「BDDスタイル」ロボット構文も使用しています。GoogleMockをいくつかのラッパーとともに使用して、各ロボットテストの分解中にチェックされる期待値を設定できるようにします。

テストを整理する限り、次のアプローチに落ち着きました（ここで与えられたデールエメリーのアプローチからインスピレーションを得て）：

  • 主要な機能階層は、フォルダー構造で表されます。
  • ロボットテストファイル名には、特徴的なサイズのものが記載されています。
  • その機能の各部分の説明は、ロボットのテストケース名で使用されます。
  • テストケースの手順として例を示します。
  • サンプルテキストは、ロボットの「キーワード」を使用してステップに分割されています。
  • テストフィクスチャは、製品コードを駆動します。

たとえば、電話には次のようなものがあります。

//  PhoneProject/MakingCalls/DialAPhoneNumber.txt

*** Test Case ***
A user can dial a US number with an area code, up to 10 digits
   Given a phone without any numbers dialed
   Expect the attempted phone number to be 123-456-7890
   When a user enters the numbers 1234567890


// A separate MakingCallsKeywords.txt or something similar
*** Keyword ***
Given a phone without any numbers dialed                CreateNewDialer
Expect the attempted phone number to be ${phoneNumber}  ExpectDialedNumber  ${phoneNumber}
When a user enters the numbers ${numbersEntered}        DialNumbers ${numbersEntered}

// MakingCallsFixture.cpp  (which gets wrapped by SWIG)

std::wstring MakingCallsFixture::DialNumbers(const std::wstring& numbersEntered)
{
   ... Drive production code ...
}

// CreateNewDialer, ExpectDialedNumber also go here

次に、これをコーナー条件をカバーする単体テストと組み合わせます（たとえば、10桁以下が許可されていることを確認します）-または、テストを読んでいる人とテストに精通している人に応じて、別の受け入れテスト（実行可能仕様）になる可能性がありますドメイン。

これらの仕様のドラフトを作成し、作業を開始する前にドメインの専門家とチームとレビューします。これは、早い段階で多くの誤解を一掃するのに役立ちました。

于 2012-02-19T23:51:09.310 に答える