開発と成長の過程にあるプロジェクトはすべて、新しい機能で満たされています。 QAプロセスは、たとえば、あらゆる種類のテストの数を増やすことにより、これに迅速かつ適切に対応する必要があります。 このレポートでは、高品質の製品を作成する上で重要な役割を果たすUIテストについて説明します。 UIテストの自動化システムは、回帰テストの時間を大幅に短縮するだけでなく、継続的インテグレーションやリリースエンジニアリングなどの開発ツールやプロセスの効果的な運用も保証します。
テストの数は1000から3000、6000から9000+などに徐々に増加しているため、この「なだれ」がQAプロセスをカバーしないように、自動化プロジェクトの開発の非常に早い段階からシステム全体と各テストの有効性を考慮する必要があります彼女の中で。
このレポートでは、ビジネスからの要求に対してシステムを柔軟にする方法と、各テストの効果的な使用について説明します。 さらに、自動化プロセスだけでなく、QA全体の評価とメトリックについても説明します。
レポート概要：
- 「テストの構築」の原則から始めましょう。これは、システムをできるだけ使いやすくするものです。
- UIテストシステムをQAチームのプロセスに統合する方法を分析します。
- 各テストの効果を改善するための特定の方法を見てみましょう。
- UIテストシステムのメトリックと、継続的インテグレーションおよびリリースエンジニアリングプロジェクトとの関係についてお話しましょう。
UIテストシステムの要件と「テスト構築」の原則
UIテストの自動化システムには、次の要件があります：システムは使いやすく、直感的であり、テストカバレッジのサポートに時間がかかりません。システムはテストコードのエラーに耐性があり、最後に、システムは非常に効率的である必要があります。
これに基づいて、最初で最も重要な原則は、テストの知覚の最大の容易さです。 これは、英語を読める従業員が各テストを理解できるようにするために必要です。
高レベルの抽象化と関数、変数などの正しい命名を使用し、コードレビュー中にこれに注意してください。
次の原則-各プロジェクトは他のプロジェクトから可能な限り独立している必要があります。 これは、各プロジェクトが個々の目標と目標を設定し、作業中に他のプロジェクトの開発を妨げないようにするために必要です。
コードに対するすべての変更は、コード制御システムを使用してコードレビューに合格する必要があります。 チームの開発者が使用するシステムを使用することをお勧めします。
プッシュ前およびコミット後のフックを使用して、システムの「コア」の健全性を保護します。 少なくとも、それらで単体テストを実行します。
単体テストは、プログラムのソースコードの個々のモジュールの正確性を確認できるテストです。 ユニットテストとUIテストを混同しないようにすることが重要です。これらは互換性がなく、相互に補完します。
プロジェクトのコア部分全体がユニットテストでカバーされており、現時点では500を超えています。リポジトリにプッシュおよびコミットするたびに実行します。
QAチームプロセスでのUIテスト
UIテストシステムをチームおよび製品プロセスに統合する方法。 主な目標は、すべてのテストが開発の初期段階から役立つことです。 テストが作成されると、すぐに継続的インテグレーションシステムに入ります。 テストカバレッジサポートは、タスクのテストの標準的な部分である必要があります。 したがって、Tutu.ruには、手動テストのみに従事するテスターはいません。 当社のすべてのスペシャリストは、あらゆる種類のテストに従事しています。
タスクがテストを破った場合、タスクはmasterで「点滅」してはなりません。 お客様が急いでいる場合でも、常にこのことを念頭に置いています。
QAプロセスの各段階の人件費を監視する必要があります。
スケジュールのいくつか：リリースサイクルの人件費とチームの1つの主要な段階を工数で詳述します。 チームによって異なる結果が示されますが、目標は1つあります-指定された品質レベルを維持しながら人件費を削減することです。
いずれかのチームのリリースサイクルを工数で詳述する
いずれかのチームのリリースサイクルの主要段階の人件費
リリースサイクルのUIテスト
最も重要なことは、タスク開発の段階に応じて、テストをできるだけ頻繁に開始することです。 各ステージは、最も「グリーン」なテストに合格する必要があり、これに従っています。 一部のステージでは、特別にコンパイルされたテストスイートを使用しますが、各キットは共通のテストプールからの選択であるため、異なるスイートのテストが重複する可能性があります。
すべての開発は、 「ストーリーブランチ」ステージから始まります。 この段階で、テスターによって形成されたテストスイートを実行します。 開発者、テスター、アナリストなど、誰でも起動できます。 テストカバレッジが更新されており、このタスクのテストを担当するQA部門の従業員が関与しています。
次のステップはPre-rcです。 これらは「ナイトリービルド」です。 特別なブランチが毎日テストベンチに行きます。 テストプール全体を実行しますが、そのうちの9000以上があります。各チームはこの作業の結果を使用します。 この段階で、テストカバレッジの最終的な完了。
次のステップはRCです。 これはリリースプロセスであり、週に2回リリースされます。 これには特別なリリーステストスイートが使用されます。このステップでは、テストは実質的にすべて「グリーン」である必要があります。何か問題がある場合、これは修正されます。
最終リリース（安定版） 。 リリースでは、リリーステストスイートも使用します。
プロジェクト支援
別の役割は、QAチームの問題を迅速に解決するプロジェクトサポーターです。 チームにとって、ツールのパフォーマンスに対する継続的なサポートは非常に重要です。 システムを使用するときにすべての従業員がサポートを受けることができるように、サービスデスクを使用します。
各テストの有効性を改善する
このセクションでは、UIテストを段階的に使用して、システムの効率を向上させた特定のツールについて説明します。
コンテナ制御および管理プロジェクトのテスト
多くのテストがあります。 マルチスレッド起動システムは、監視する必要がある150以上のテストコンテナで構成されています。 テストフローの管理、ワークロードに関する情報の提供、ランナーモジュールとの最適な統合を可能にするツールを作成しました。
UIテスト用のコンテナ管理システムインターフェイス
カスタムランナーテスト
Runner UIテストを作成しました。 私たちにとって、リソースの低消費が最重要でした。 開発の柔軟性は私たちにとって重要です-ビジネス要件に対応する必要があります。 Runnerは、起動の優先順位を考慮して、システムの負荷を分散できます。 リリースサイクルと開発環境サイクルの起動には、異なる優先順位があります。 これらの条件を考慮して、ランナーはそれらのバランスをとります。 また、システムの他のモジュールとの統合が向上します。
内部デバイス
特別なphpスクリプトがリポジトリからテストキューを形成します。 マルチスレッドの起動モジュールに入り、個々のテスト（PHPプロセス）に分岐します。 このような個別のプロセスはそれぞれデータベースにアクセスし、そこでテストが実行されるユーザーデータを受け取ります。
ランナーモジュールの回路図
テストケースとテストスイート管理
テストドキュメントをテストコードの隣に保存するため、UIテストとテストケースを1つの全体にバンドルします。これは、レポートを生成する場合に特に便利です。各テストには、対象となるリスクを正確に理解できる説明があります。 PHPDocを使用してこの機能を実装しました。
すでにカバーされているテストケースの場合、 ケースタグが使用されます。
コードにまだ実装されていないテストケースの場合、 todocaseタグは次のとおりです。
手動でのみ実行する必要があるテストケースの場合、 manualcaseタグは次のとおりです。
テストカバレッジの計算
また、タグメカニズムを使用して、各プロジェクトのUIカバレッジを自動的に計算します。 式による計算：
Percentage_coating =（1-（number_todocase-tests + number_manual-tests）/ total_number_tests_in_project）* 100％
プロジェクト「Buses」のカバレッジUIテストの割合を含むコンソールの結論
テストスイートの管理
テストスイートの管理にも同じメカニズムを使用します。 たとえば、特定の機能にテストスイートを使用します。リリース用のスイート、RCサイクルがあり、一般に、スイートの作成はQAスペシャリストの想像力によってのみ制限されます。 各テストは複数のセットに含めることができ、 @ labelsタグを使用してそれらを指定します。
テストは、リリーステストスイートを指します。
成功テストページ機能テストスイートの実行例
HTMLレポート
レポートは、起動ごとに個別に作成されます。 テストを実行するたびに、テスターは自分の手でレポートの形式でHTMLページを取得できるため、QAスペシャリストは製品の品質をすばやく評価できます。 HTMLレポートにより、テストの更新時間が短縮されます。 レポートはCIツールにありますが、テスト担当者が作業コピーでレポートを見ると便利な場合があります。
「ソフトアサート」
PHPUnitは、アサーションを使用する他のユニットテストシステムと同様に、次のように動作します。アサーションでデータの不一致が発生した場合、テストは続行されません。 このパラダイムを変更しました。 ソフトアサーションは、問題が発生した場合、テストアサーションと呼ばれますが、テストの実行を中断せず、他のすべてのアサーションを使用して実行を継続します。最終的に、テストはティアダウン段階でエラーで実行を完了します。 したがって、ソフトアサーションを使用すると、このブロックに問題がある場合でも、1回のテストでブロック全体の品質に関する情報を提供できます。 このようなアサーションは、複雑なテストロジックではより安全です。 たとえば、実際のお金で銀行カードから注文するテストがあり、このテストが注文後にどこかに「落ち」て、キャンセルする時間がないことを望んでいません。
柔軟なランチャー設定システム
QA専門家のニーズを満たすため、つまりCIとの最適な統合を提供するために作成されました。 Symfonyコンソールを使用して作成され、現在30を超えるパラメーターがあります。
それらのいくつか：
オンデマンド。 非常にリスクが高く、自動的に開始されないテストがあります。 テスターが起動パラメーターで「オンデマンド」を示している場合に起動されます。
バグをスキップしたテスト。 製品の問題によってブロックされたテストには、特別なラベルを付けることができ、これらのテストはCIシステムで実行されません。 製品が何かを修正し、テストをすでにオフにすることができる状況をキャッチするために、週に1回実行する特別な計画があり、現在無効になっているテストのみを実行します。
JSエラーシーカー。 このテストは、特にフロントエンドレンダリングに役立ちます。 フロントエンドの入札者とテスターは、この機能を使用して、テスト中にjsエラーをチェックします。 このメカニズムを使用すると、テストパス全体でjsエラーをキャッチできます。
通知保守者。 各テストにはマイナーを設定できます。 これは、このテストの責任者であり、このテストが失敗した場合に通知を受け取りたい人です。 上記のフラグにはこの通知が含まれています。
指標
テストコンテナを監視および管理するプロジェクトは、システムの負荷を監視できるため、システムの成長点を示すことができます。
異なるスタンドでテストに合格するための時刻表。 プロジェクトがこの時間を超えた場合、60分という制限を設定しました。これは、プロジェクトにアクセスして、テストスイートに時間がかかる理由を理解する機会です。
生産プロジェクトのテスト時間
リリースエンジニアリング
ここでは、UIテストツールがリリースエンジニアリングプロジェクトとどのように相互作用するかについて説明します。
多数のUIテストシステムとBambooでできること：ビルドの実行、レポートの生成、リリースプロセスのサポート、スケジュールに基づいたビルドの自動実行。 スモークテストスイートが何か問題が発生したことを示した場合、リリースを自動的に「ロールバック」する可能性もあります。
CIシステムには多数の異なるプランが存在する可能性がありますが、これは絶対に正常な動作であり、恐れることはありません。
結論
- 各テストはできるだけ頻繁に実行する必要があります。
- UIテストシステムのモジュールの相互統合は非常に重要です。このため、独自の実装を作成する価値があります。
- システムは柔軟でサポートされている必要があります。既製のツールはこれらの要件を常に満たすわけではありません。
- QAプロセスのパフォーマンスを追跡し、何か問題が発生していることがわかったらすぐに改善します。
- QAは開発プロセスの一部である必要があり、ツールはこれをサポートする必要があります。