CI＆CDについて話すとき、ビルド、テスト、アプリケーション配信を自動化するための基本的なツールに深く入り込むことがよくあります。ツールに焦点を当てていますが、リリースのカットと安定化中に発生するプロセスについては説明していません。ただし、すべての既製のツールが同じように役立つわけではなく、一部のカスタムプロセスはそれらの範囲に適合しません。プロセスを調査し、それらを自動化して最適化する方法を見つける必要があります。
当社では、手動および探索的テストを自動テストに置き換えることができないため、QAエンジニアはZephyrを使用して回帰の進行状況を追跡します。しかし、それにもかかわらず、自動テストはここで大量に追跡されることが多いので、自動化されたいくつかの平凡なチェックを省略して、テスターがより生産的で有用な作業を行えるようにしたいと思います。
完全なテストスイートが追いかけられているナイトランがあります。しかし、Zephyrをマスターする黎明期に、回帰中に、テスターはxcresult、さらには以前のplist、またはjunit xmlをダウンロードし、マシュマロの緑と赤のテストの対応を手で書き留める必要がありました。これはかなり日常的な操作であり、手作業で500〜600のテストに合格するには長い時間がかかります。あなたはそのようなものを魂のない機械に翻弄されたいのです。これがZERGの誕生です。
Zergが生まれる
Zephyr Enterprise Report Generatorは、最初はテストレポートで一致するものを検索し、現在のステータスをZephyrに送信する方法しか知らなかった小さなユーティリティです。その後、ユーティリティは新しい機能を受け取りましたが、今日はレポートの検索と送信に焦点を当てます。
Zephyrでは、テストケースのバージョン、ループ、および実行を操作するように求められます。各バージョンには任意の数のサイクルが含まれ、各サイクルにはケースパスが含まれます。このようなパスには、タスク（zephyrはjiraと完全に統合され、テストケースは実際にはjiraのタスクです）、作成者、ケースのステータス、このケースに関与しているユーザー、およびその他の必要な詳細に関する情報が含まれます。 。
上で概説した問題を自動化するには、ケースのステータスを設定する方法を理解することが重要です。
コードの操作
しかし、コードテストとマシュマロテストをどのように相関させますか？ここでは、かなり単純でわかりやすいアプローチを採用しています。テストごとに、コメントセクションにjiraのタスクへのリンクを追加します。
追加のパラメータをコメントに配置することもできますが、それについては後で詳しく説明します。
したがって、コード内の1つのテストで複数のタスクをカバーできます。ただし、逆のロジックも機能します。1つのタスクのコードで複数のテストを記述できます。レポートを編集する際に、それらのステータスが考慮されます。
ソースコードを調べ、すべてのテストクラスとテストを抽出し、タスクをメソッドにリンクして、これをテスト合格レポート（xcresultまたはjunit）と関連付ける必要があります。
コード自体はさまざまな方法で操作できます。
-ファイルを読み取り、正規表現で情報を取得するだけです
-SourceKitを使用します。SourceKitを使用
している場合でも、コメント内のリンクからタスクIDを抽出するための正規表現がないと実行できません。
この段階では、詳細には関心がないため、プロトコルを使用して詳細
を確認します。テストを取得する必要があります。これを行うには、構造について説明します。
次に、テストの合格に関するレポートを読む必要があります。 ZERGはxcresultに移行する前に生まれたため、plistとjunitを解析できます。この記事の詳細にはまだ関心がありません。コードに添付されます。したがって、プロトコルをフェンスで囲みます
残っているのは、コード内のテストをレポートのテスト結果にリンクすることだけです。
クラス名とテスト名（異なるクラスに同じ名前のメソッドがある場合があります）と、テストにリファクタリングが必要かどうかによって対応を確認します。必要な場合は、信頼性が低いと見なし、統計から除外します。
マシュマロを使っています
テストレポートを読んだので、それらをzephyrコンテキストに変換する必要があります。これを行うには、アプリケーションのバージョンに関連付けられたプロジェクトバージョンのリストを取得する必要があります（これがこのように機能するには、マシュマロのバージョンがアプリケーションのInfo.plistのバージョンと一致している必要があります、たとえば、2.56）、ダウンロードループとパス。次に、パスを既存のレポートと関連付けます。
これを行うには、ZephyrAPIに次のメソッドを実装する必要があります。
仕様はここで確認できます： getzephyr.docs.apiary.ioであり、クライアントの実装はリポジトリにあります。
一般的なアルゴリズムは非常に単純です。
パスとレポートを照合する段階では、考慮しなければならない微妙な点があります。zephyrapiでは、実行更新をバッチで送信するのが最も便利です。ここで、一般的なステータスとパスIDのリストが送信されます。 。チケットレポートを拡張し、nm比を考慮する必要があります。マシュマロの1つのケースでは、コードに複数のテストが存在する可能性があります。コード内の1つのテストで、いくつかのケースをカバーできます。 1つのケースでコードにn個のテストがあり、そのうちの1つが赤である場合、そのような場合の一般的なステータスは赤ですが、そのようなテストの1つがm個のケースをカバーし、それが緑である場合、残りのケースは赤くなりません。
したがって、セットを操作して、赤と緑の交点を探します。交差点に該当するものはすべて、緑色の結果から差し引き、編集した情報をzephyrに送信します。
また、チーム内で、次の場合にzergがパスのステータスを変更しないことに同意したことにも注意してください
。1。現在のステータスがブロックまたは失敗した（以前は失敗のステータスを変更していましたが、現在はあきらめています）テスターに回帰中の赤い自動テストに注意を払ってもらいたいので、練習してください）。
2.現在のステータスが合格であり、それがzergではなく人によって設定された場合。
3.テストが点滅としてマークされている場合。
ZephyrAPIの関心事
ループをリクエストすると、jsonを受け取ります。これは、一見、逆シリアル化のために体系化することはできません。重要なのは、バージョンのループを取得するリクエストは、ループの配列を返す必要がありますが、実際には1つのオブジェクトを返します。各フィールドは一意であり、ループ識別子と呼ばれ、値に含まれます。これを処理するために、単純なハックを使用します。
テスト合格ステータスは、リクエストオブジェクトの横にあるリクエストの1つにあります。ただし、事前に列挙型に移動できます。
ループを要求するときは、プロジェクトのバージョンと整数の識別子を要求パラメーターに渡す必要があります。ただし、ループのパスの要求では、同じプロジェクト識別子を文字列形式で渡す必要があります。
結論の代わりに
日常業務が多い場合は、おそらく何かを自動化できます。自動テストの通過をテスト管理システムと同期させることは、そのようなケースの1つです。
したがって、毎晩完全なテストが実行され、リグレッション中にレポートがQAエンジニアに送信されます。これにより、回帰時間が短縮され、探索的テストの時間が与えられます。
androidソースパーサーを正しく実装すると、2番目のプラットフォームにも同じように適用できます。
私たちのZergは、テストの比較に加えて、初期の影響を分析することもできますが、それについては、おそらく次回に詳しく説明します。