手動テスターを支援する方法。 Automatorsは救助に急ぎます

テストに適切な時間を割くチームでは、このプロセスの自動化について質問があります。 これはどうですか？ 開発にはいくつかの方法があります。テスター自身が自動化を開始するか、万能薬としてすべての問題を解決しなければならない特別な訓練を受けた人を雇います。 これがどのように起こるかに関係なく、結局、私たちは皆、何が起こっているのか、何が現実なのか、何が行われたのかを何らかの形で示す必要があるという事実に直面しています。 私の同僚の一人が言ったように、「自動化のための自動化は貨物のカルトに似ています」、たまたま自動化部門が存在しますが、結果はありません。



したがって、自動化エンジニアの主なタスクは、生活を楽にすることです。 今回は、手動テスト部門（存在する場合）またはテストプロセス全体が私たちの肩にかかっている場合、私たち自身の生活を簡素化します。

いくつかの構造データ

当社には手動テスト部門と自動化があります。 テストを整理するためのシステムとして、かなり一般的なツールであるTestRailが使用されます。 私の観点からは、便利で非常に機能的です。

自動化は、Ruby + Cucumber + Watir / Selenium（Page Objectパターンに言及できます）+ TeamCityのかなり標準的なセット上にも構築されています。



新しいビルドがテスト用に提供されるとどうなりますか（この場合、リグレッションに対処するたびに）？ テスターは傷の新しいテストを作成します。これには、特定のテストスイートからのすべてのテストケースが含まれます。 すべての要素をクリック/タップして次のテストのステータスを設定することにより、マシン上で4回目のリグレッションまたはスモークを手動で実行したときの感覚を誰もが知っていると確信しています。 この瞬間、すべてが赤目の前に確実に浮かんでおり、頭の中の絵が有名なものを繰り返しています。







そして時々：







今、私たちは救助に来ています。 たまたまアイデアが生まれました。 自動化されている場合、作業の結果を使用して生活を楽にしていないのはなぜですか？ アイデアは、Cucumberでかさばる不明瞭なレポートの代わりに、TestRailでレポートを使用することです。 かなり興味深いタスクは、自動テストの合格方法に応じて、TestRailのテスト自体のステータスを変更することです。



全能のGoogleの検索を通じて、この非常に優れた目的を実装するためのドキュメントがTestRail APIで見つかりました。 まず、自動テストを起動して、テストの現在の状態に関するすべての情報がTestRailに表示されるようにすることにしました。 実際、目標は達成されました-RubyMineのテスト起動ボタンをクリックすることで、新しいtestranを自動的に作成し、結果をサーバーに送信しました。 TestRail Webサイトにある既存の情報を考えれば、非常に簡単です。



結局のところ、これはほんの始まりに過ぎませんでした。



最終的に、かなり良い機能を作ることができました。つまり、TestRail + TeamCity + Automation Frameworkの統合を構成しました。



さて、詳細、ご列席の皆様。

Testral

最初の目的地はTestRailです。



TestRailは、テストからのデータを管理するためのソフトウェアです。 このツールは、プロセスの追跡、ソフトウェアの管理、チームの編成に役立ちます。



TestRailを使用すると、テストケースを作成し、テストスイートを管理し、ソフトウェアテストプロセス全体を調整できます。 TestRailは、生産性を高め、テストプロセスの完全な概要を取得する機会を提供します。



まず、ユーザー/手動テスターが最初に行うべきことは、testran自体を作成することです。これは後で更新に使用します。



要件：

機能：オートテストの実行。

実生活で自動化を使用するため。

ユーザーとして、「自動テストで傷を付ける」魔法のボタンが必要です。







すぐに言ってやった。 TestRailの機能の利点により、独自のコードを統合できます。



結果として、まさにそのようなボタンがあります：







はい、はい-テストを開始します。





1つのスイートのWebとモバイルのテストケースがあるため、最初の段階では、使用されているフレームワークをtestranの名前で確認します。 testranの目的に応じて、TeamCityでビルドを開始します。



ユーザーがボタンをあまり頻繁にクリックしないように、バカに対する保護を組織しました。ボタンをクリックした後、テストランの名前に「進行中」のキーを追加し、自動テストがジョブを完了するまでマジックボタンをブロックします。

自動化フレームワーク

最終段階では、gem /ライブラリが作成されました。これをデプロイすると、サブプロジェクトでTestRailと統合できます。



宝石の作成はまったく別の話であり、別の記事に値します。



つまり、 test_rail_integrationライブラリには、自宅で使用する機能が少しありますが、誰かが役に立つこともあるようです。



最初にインストールする必要があります：

 gem install test_rail_integration
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に追加：

 TestRail::Hook.update_test_rail(scenario)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

あとで|シナリオ| フック。 そしてenv.rbファイルで：

 if ENV['TESTRAIL'] == '1' puts 'Option : TestRail [ON]' require "test_rail_integration" require 'test_rail_integration/generator/test_rail_hooks' end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実行するコマンドは次のとおりです。

 test_rail_integration check_test_run_and_update
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちの場合、テストは6つの異なる場所で実行され、すべての結果は1つのテストランで表示されました。 2つの更新が同時に来たときに状況が発生することがありました。 彼らはお互いに会わず、フェイルパスのステータスが来た後に判明しました。 このオプションは、テストのステータスの全体像を変更しました。 一般に、このチームはすべてのテストに合格し、緑色のテストに赤色の結果がないことと一致することを確認します。 ある場合、テストのステータスを赤に変更します。

 test_rail_integration create_test_run
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが単純です。このコマンドを使用すると、プロジェクトスイートに指定された名前でtestranが作成され、構成ファイルに記録されます。 このコマンドは、作成されたテサンの数を返します。

 test_rail_integration perform
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドはTestRailに関する必要な情報を指定する必要がある構成ファイルを生成するため、最初の起動時に書き込む必要があります。

 test_rail_integration shoot
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、フラグを使用したコア機能です。

 --test_run_id
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、すべてが明確であるため、テスト傷口番号を指定する必要があります。

 --venture
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして

 --env
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実行するコマンドをコンパイルするときに使用される特定の属性（たとえば、特定のコマンドでテストを実行する必要がある場合、構成ファイルでこれらの変数を使用してそれを記述する必要があり、起動時にそれらを指定する必要があります）：

 --showroom
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このフラグも特定のものであり、他の誰にとっても有用ではないと思います。

 --command
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、現在の実行に新しいコマンドを指定できます。

 --auto
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

6つのローカライズにすべての統合を使用するため、testran番号で名前を検索し、パラメーターで解析して、testranに名前（DT SGステージングなど）を付ける必要があります。 ここで、実行に必要な情報を見つけます。

 --simple
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

親愛なる読者、パラメータを検索および確認せずに実行する、これは最も便利なコマンドです。

 --type
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実行されるテストのタイプ番号を決定することもできます。



既存のtestranでテストを実行する完全なコマンドは次のようになります。

 test_rail_integration shoot --test_run_id 1 --simple
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

またはそれ以外：

 test_rail_integration shoot --test_run_id 1 --simple --command <cucumber -t > --type 3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Teamcity

実際、ここではすべてがシンプルです。 便宜上いくつかの変数を追加してコマンドの実行順序を組み合わせることができる場合を除き、ローカルで実行するのと同じ方法でコマンドを書き留めます（ビルドを自動的に開始する場合は、最初にテストを作成するコマンドを指定してから、番号でテストを実行する必要があります）それは以前に私たちに来ました）。



以上です。 記事を書くのはこれが私の最初の経験なので、批判は大歓迎です。 これをすべて明確に書いて、このガイドが誰にとっても役立つことを願っています。





リポジトリリンク： github.com/Kirikami/test_rail_integration

ライブラリへのリンク： rubygems.org/gems/test_rail_integration