Canvasでのテストアプリケーションの自動化方法

私の同僚は、すでにCanvasでのTeamLabオンラインエディターの開発について書いています。 開発者の観点から製品が選択された技術により革新的であるだけでなく、製品の品質をチェックするタスクは新しいものであり、誰もまだ解決していないため、今日、テストの専門家の目でワークフローを見ていきます。





私の人生の最後の8か月間、同僚と私は、HTML5で書かれたまったく新しいドキュメントエディターのテストに費やしました。 革新的な製品をテストするのは、誰もこれをやったことがないという理由だけでは難しいのです。



すべてのアイデアを実装するには、サードパーティのツールが必要でした。

• 自動化のためのRuby言語。 それはスクリプト化されており、大量のデータでうまく機能します。
• テスト実行用のGem Rspec
• ブラウザーを操作するためのSelenium Webdriverドライバー

そして、それは最も重要で興味深いものから始まりました。 ボタンをクリックしてテキストを入力するのは非常に簡単ですが、作成されたものを確認する方法は？ 自動テストによって実行されたすべてが正しく行われたことを確認するにはどうすればよいですか？

1.検証

標準との適切な比較方法を見つける過程で、多くのコピーが破損しました。 その結果、実行されたアクションに関する情報、したがって、テストに合格したことに関する情報は、次の2つの方法で取得できるという結論に達しました。



1.アプリケーション自体のAPIを使用します。



2.独自のドキュメントパーサーを使用します。

API

肯定的な側面：

• クイック結果、として 文書をダウンロードするときにサーバーに不必要にアクセスする必要はありません。
• API関数を直接操作する機能。 私たちにとってこれが最良の解決策でした-私たちはプログラマーと友好的な環境で仕事をしており、彼らはすぐにこれらの機能を提供してくれました。

マイナス面：

• プログラムのバグを明確にローカライズする機能の欠如、つまりエディターのコード、またはインターフェイスの呼び出し/実装時、つまりインターフェイスコードのバグ。
• プログラマーへの依存。 開発者が、APIメソッドが大幅に変更されるか、まったく動作しなくなるような状況にある場合、自動テストプロセスも開始されます。 ただし、サーバー側のAPIパッチは優先順位からはほど遠い場合があります（これはパブリックAPIではなく、テストにのみ使用されるため）。
• 既存のアプリケーションアーキテクチャのすべての機能のテストを自動化できない。

ダウンロードしたドキュメントの解析

肯定的な側面：

• アプリケーションの最終結果を確認するため、信頼できるアプローチです。
• 開発者からの独立。 私たちは、ツールを使用してdocx形式のオープニングを記述し、比較的言えば、独自の小さなドキュメントコンバーターを作成しました。
• 任意の難易度のテストを実装する機能。 アプリケーションに存在するすべての機能がサポートされています。

マイナス面：

• 実装の難しさ。

最終検証

その結果、両方のオプションを選択しましたが、異なる割合で使用しました。テスト検証の約90％はパーサーを通じて実装され、APIを通じては10％のみが実装されました。 これにより、APIを使用して最初のテストを迅速に記述し、パーサーの開発と連動して機能テストを徐々に開発することができました。



解析の形式としてDOCXが選択されました。 これは、次の事実によるものです。

• エディター自体では、DOCX形式のサポートが最適に実装され、機能の最大数がサポートされ、それに保存することが最も質的かつ確実に実行されました。
• DOCとは異なり、DOCX形式自体はよりオープンで、構造が単純です。 本質的に、これはXMLファイルを含むZIPアーカイブです。

必要な一連の機能をサポートするDOCXを解析するためのサードパーティライブラリが見つかりませんでした。 その後、別の形式で同様の状況が発生し、テーブルエディターをテストするときにXLSXパーサーが必要になりました。



パーサーの担当者は1人だけです。 機能の主なバックボーンは約1か月で実装されましたが、引き続きサポートされています-バグは修正され（既存の機能にはほとんどバグがありません）、ドキュメントエディターで導入された新しい機能のサポートが追加されました。



例：



単純な例を考えてみましょう。テキストサイズが20の単一段落ドキュメント、Times New Romanフォント、および太字と斜体のオプションセット。 このようなドキュメントの場合、パーサーは次の構造を返します。







ドキュメントは一連の要素（要素）で構成されます。これらはテキスト、画像、表の段落にすることができます。



各段落は、いくつかのcharacter_stylesで構成されます-特定のセクションで完全に同一のプロパティを持つテキストの断片。 したがって、1つの段落ですべてのテキストが同じスタイルで入力された場合、その中に1つのcharacter_styleしかありません。 たとえば、段落の最初の単語が太字で強調表示され、残りが斜体である場合、段落は2つのcharacter_styleで構成されます。1つは最初の単語、2つ目は他のすべての文字です。



character_style内には、size = 20-フォントサイズ、font = "Times New Roman"-フォントタイプ、font_style-フォントスタイルプロパティ（太字、斜体、下線、取り消し線）、および他のすべてのプロパティなど、必要なすべてのテキストプロパティがあります。ドキュメント。



その結果、このドキュメントを検証するには、次のコードを記述する必要があります。



doc.elements.first.character_styles_array.first.size.should == 20

doc.elements.first.character_styles_array.first.font.should == "Times New Roman"

doc.elements.first.character_styles_array.first.font_style.should == FontStyle.new（true、true、false、false）

2.ドキュメントジェネレーター

DOCX形式のファイルを代表的に選択するために、DOCXファイルジェネレーター-任意のコンテンツと任意のパラメーター値を持つドキュメントを作成できるアプリケーションを作成する必要があることが決定されました。 このために、1人の専門家も割り当てられました。 ジェネレーターは、テストシステムの重要な部分ではなく、テスト範囲を拡大できる一種の補助ユーティリティと考えられていました。



その開発に基づいて、次の結論が下されました。



テストを作成または自動化する場合、可能なすべてのフォーマット機能を一度にカバーしようとしないでください。 これにより、特にテスト対象のアプリケーションの開発の初期段階で、さらに困難が生じます。



機能がアプリケーションでまだサポートされていないテストと誤った結果を区別することは困難です。



そして、前の段落の結果として：ジェネレーターを書くことは、エディターの機能の最大数が実装されるとき、テスト中のアプリケーションの開発の終わりに近づくべきです（そして、始めにではありません）。



上記にも関わらず、ジェネレーターは手動テスト中に見つけることがほとんど不可能なエラー、たとえば許容値のセットに値が含まれていないパラメーターの誤った処理を見つけることを可能にしました。

3.テストを実行するためのフレームワーク

セレンとの相互作用

フレームワークの基礎として、Selenium Webdriverが採用されました。 Rubyには素晴らしい代替手段があります-Watir、しかし、たまたまフレームワークの作成時にそれについて知りませんでした。 Watirを使用しなかったことを後悔したのは、テストをIEのお気に入りで最高のブラウザに統合したときだけでした。 Seleniumはボタンをクリックして何もすることを単に拒否し、最終的にIEでテストを実行する場合にWatirメソッドが呼び出されるように松葉杖を作成する必要がありました。



このフレームワークの開発前は、WebアプリケーションのテストはJavaで構築され、すべてのXPath要素と他のオブジェクト識別子は別のxmlファイルに移動されたため、XPathを変更するときにプロジェクト全体を再コンパイルする必要はありませんでした。



Rubyでは、再コンパイルでこのような問題は発生しませんでした。そのため、すでに次の自動化プロジェクトで、単一のXMLファイルを放棄しました。



1200 xPath要素を含むファイルを操作する必要があるため、Selenium Webdriverの関数はオーバーロードされていました。 私たちはそれらを作り直しました：



だった

get_attribute(xpath, attribute) @driver.find_element(:xpath, xpath_value) attribute_value = element.attribute(attribute) return attribute_value end get_attribute('//div/div/div[5]/span/div[3]', 'name')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

になっています

 get_attribute(xpath_name, attribute) xpath_value =@@xpaths.get_value(xpath_name) elementl = @driver.find_element(:xpath, xpath_value) attribute_value = element.attribute(attribute) return attribute_value end get_attribute('admin_user_name_xpath', 'name')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちの意見では、自動化を開始する前に、ページ上のオブジェクトの識別子を分析することが非常に重要であり、それらが自動的に生成されることがわかる場合（「docmenu-1125」のようなID）、変更しないIDを追加するように開発者に依頼してください。新しいビルドごとにXPathをやり直す必要があります。



より具体的な関数がSeleniumCommandsクラスに追加されました。 そのうちのいくつかはデフォルトでWatirにすでに存在していましたが、たとえば、いくつかの要素の1つのシリアル番号をクリックして、複数の要素から1つの属性を一度に受け取るなど、まだわかりませんでした。 SeleniumCommandsなどの重要なクラスで作業できるのは1人のテストスペシャリストのみであることが重要です。さもないと、些細なエラーでもプロジェクト全体がドロップされます。もちろん、これはすべてのテストをできるだけ早く実行する必要があるときに正確に発生します。

メニューの相互作用

より高いレベルのフレームワークは、プログラムメニュー、アプリケーションインターフェイスと連携しています。 これは、クラスに分散された非常に大きな（約300）関数のセットです。 それらのそれぞれは、ユーザーが利用できるインターフェースで特定の機能を実装します（たとえば、フォント選択、行間隔など）。



これらの関数はすべて、最も単純な説明的な名前を持ち、最も単純な形式で引数を取ります（たとえば、クラスだけでなくStringオブジェクトだけを渡すことができる場合、それらを渡す必要があります）。 これにより、テストの記述がはるかに簡単になるため、プログラミング経験のない手動のテスターでも処理できます。 ちなみに、これは冗談や誇張ではありません。プログラミングがまったくゼロの人が書いた作業テストがあります。



これらの関数を作成する過程で、Smokeテストの最初のカテゴリが作成されました。すべての関数のスクリプトは次のようになります。



1.新しいドキュメントが作成されます。



2. 1つ（1つだけ）記述された関数が呼び出され、特定の正しい値（ランダムではなく、特定の正しい値が渡されます。このステップで、可能な値の一部でのみ正しく機能する関数を破棄します）



3.ドキュメントをダウンロードする



4.確認する



5.レポートシステムに結果を入力します



6.利益！

4.テスト

要約するために、プロジェクトに存在するテストのカテゴリを見てみましょう。



1.煙テスト

彼らの目標は、少量の入力データで製品をテストすることであり、最も重要なことは、フレームワーク自体が新しいビルドで正しく動作することを確認することです（xPath要素を変更し、アプリケーションインターフェイスメニューを構築するロジックを変更します）。





このカテゴリのテストはうまく機能しますが、一部のインターフェイス要素を見越して、理解できない瞬間にテストがフリーズする場合があります。 テストスクリプトを手動で繰り返すと、たとえば、フォントのリストを開くボタンが押されたときにリスト自体が表示されないなど、メニューインターフェイスのエラーによりテストがクラッシュすることが判明しました。 したがって、テストの2番目のカテゴリが発生しました。



2.インターフェイステスト

これは、すべてのコントロールをクリックしたときに、このコントロールが（インターフェイスレベルで）担当するアクションが発生することを確認することをタスクとする非常に単純なテストのセットです。 つまり、太字ボタンをクリックしても、選択が太字で機能するかどうかはチェックせず、ボタンが押された状態で表示されるようになったことを確認するだけです。 同様に、すべてのドロップダウンメニューとすべてのリストが開いていることを確認します。





3.すべてのパラメーター値の列挙

各パラメーターについて、可能なすべての値が設定され（たとえば、すべてのフォントサイズが検索される）、これが検証されます。 1つのドキュメントでは、1つのパラメーターへの変更のみが存在し、バンドルはテストされません。 その後、これらのテストからテストの別のサブカテゴリが登場しました。



3.1視覚レンダリング検証

すべてのパラメーター値をソートするテストを実行する過程で、すべてのパラメーター値のレンダリングを視覚的に検証する必要があることに気付きました。 テストはパラメーター値を設定し（たとえば、フォントが選択されます）、スクリーンショットを撮ります。 出口には、スクリーンショットのグループ（約2,000枚）と、大きなスライドショーを見る必要がある不快なハンドブレーキがあります。

その後、標準のシステムを使用してレンダリングの検証を行い、回帰を追跡できるようにしました。





4.機能テスト

テストの最も重要なカテゴリの1つ。 アプリケーションのすべての機能をカバーしています。 最良の結果を得るには、テスト設計者がスクリプトを作成する必要があります。





5.ペアワイズ

パラメータバンドルをチェックするためのテスト。 たとえば、すべてのスタイルとサイズ（パラメーターを持つ2つ以上の機能）のフォントヘッドセットの完全なチェック。 自動的に生成されます。 期間（少なくとも4〜5時間、さらにはそれ以上）のために起動することはほとんどありません。





6.本番サーバーでの定期的なテスト

最初のリリース後に登場したテストの最新カテゴリ。 基本的に、これはコンポーネントの通信の正しい動作のチェックです。つまり、すべての形式のファイルが編集のために開かれ、すべての形式に正しくダウンロードされるという事実です。 テストは短いですが、1日に2回実行されます。

5.レポート

プロジェクトの開始時に、すべてのレポートは手動で収集されました。 テストはメモリからRubyMineから直接実行され（またはコード内のメモ、コメント）、新しいビルドが以前のビルドよりも悪化したか改善されたかが判断され、結果はテストマネージャーに渡されました。



しかし、テストの数が増えると（これは十分に迅速に行われました）、これが長く続くことができないことが明らかになりました。 メモリはゴムではなく、紙片に大量のデータを保持したり、電子タブレットに手動で入力したりするのは非常に不便です。 そのため、レポートサーバーとしてTestrailを選択することが決定されました。これは、エディターの各バージョンのレポートを保存するというタスクにほぼ最適です。



レポートの追加は、testrail APIを介して行われます。 Rspecの各テストの開始時に、TestRunをTestrailに初期化する行が追加されます。 Testrailにまだ存在しない新しいテストが記述されている場合、そこに自動的に追加されます。 テストが完了すると、結果が自動的に決定され、データベースに追加されます。



実際、レポート作成プロセス全体が完全に自動化されているため、Testrailにアクセスして結果を取得する必要があります。 次のようになります。







結論として、いくつかの統計：



プロジェクトの年齢-1年



テストの数-約2000



完了したケースの数-約350 000



チーム-3人



見つかったバグの数は約300です