テスターカレンダーシリーズの4月の記事は、メトリックに焦点を当てています。 Kontur.EkternaのテスターであるKirill Ratkinが、極端なことではなく、彼らの助けを借りてテストの有効性を高める方法を説明します。

どれくらいの頻度で何かを評価する必要がありますか？ おそらく毎日。 今日の天気は良くも悪くも、猫は容赦なく振る舞います、このTシャツは好きですか？ 職場では、あなたは自分の目標と結果を評価します。それはうまく行われましたが、ここではより良くなる可能性があります。 このような評価は、多くの場合、主観的な感情に基づいています。 しかし、これらの推定値はプロセスの効率を高めることはできず、より高い詳細が必要です。 その後、メトリックが役立ちます。

作業プロセスと業務をどのように特徴付けることができますか？ 彼らは良いですか 悪い？ いくら なぜそう決めたのですか？

ケルビンLordの言葉に抵抗して引用することはできません。

「あなたが話していることを測定し、それを数字で表すことができれば、この主題について何かを知っています。 しかし、それを定量化できない場合、知識は非常に限られており、不十分です。」

プロセスが透明で管理可能になるまで、成熟したプロセスと見なすことはできません。

私は2つの極端を見ました：

1. 人々はすべてが良い/悪いとレーダーなしであると信じています。 「まあ、これは理解できる」（c）。
2. 各ステップには数字が付いていますが、それらのほとんどは自重であり、いかなる方法でも使用されていません。

真実は、いつものように、真ん中にあります。 それに近づくには、基本的なことを理解する必要があります。メトリックはファッションへのオマージュではなく、悪いプロセスに対する万能薬でもありません。 メトリックスは単なるツールであり、このツールの結果はそれ自体では目的ではなく、さらなるステップの基礎にすぎません。

メトリックは次の場合に必要です。

• 客観性の向上。 たとえば、完了率のドライ数値よりも正確に自動テストの安定性を特徴付けることはできません。
• レンダリング。
• 変化のダイナミクスの推定。 計画したすべてを実行できない場合は、リストからより効果的なタスクを選択します。 十分な情報に基づいた意思決定を行うには、どのプラクティスの効率が高いかを理解する必要があります。

メトリックを正しく切断するのは簡単ではありません。 まず、因果関係を明確に示し、プロセスに影響を与えるすべての要因を特定し、それらに重みを付ける必要があります。 次に、コレクション自体を技術的に実装します。

自動テストメトリック

自動テストでメトリックを入力することを計画している場合、これがなぜ役立つのかを理解する必要があります。

自動テストの詳細：

• 男のユーザーシナリオの存在。
• サードパーティサービスのテストスタンドとの統合チェック。
• ブラウザー間の互換性。
• CIを構成し、virtualaをテストします。
• 製品ATを他のサービスチームに提供する。

安定性と速度のサポートに多大な労力を費やし、自動テスト用のデューティアシスタントを任命しました。 すべてがどれだけ良いか悪いか、どれだけのリソースを費やしているかを理解するのをやめたとき、システムをメトリックで包み始めました。

自動テストアテンダントメトリック

テストの安定性と実行時間だけでなく、次の点にも注意を払い始めました。

• 赤い実行時間
  
  テストの期間を示します。 長時間にわたって実行されるランは、仮想マシンの順番を維持します。 WebDriverが例外をスローする場合があり、そのようなテストは数時間ハングする可能性があります。 このような状況はすべてのテストでより高いレベルで解決されますが、特定のテストに触れることによってのみ、誤ったタイムアウトと期待を解消できます。 このメトリクスが20分を超える実行には必ず対処します。
• 長期にわたるテストの有効性
  
  エージェントが不安定ではなく実際の実行に費やす金額。 このメトリックは、ノイズの多いテストに関するものです。 緑と赤の実行に費やされる時間を理解し、比率を計算したかったのです。 低効率のテストは、リファクタリングの最初の行です。
• 失われた相対時間
  
  このメトリックは、不安定性のためにこのテストの実行ごとに失われる分数を示します。 私たちのチームでは、彼女は安定性に次いで2番目に重要だと考えられています。

さらに、私たちはいくつかの特定の機能を考慮しました。

• 私たちにとってユニークなキーは、テストの名前ではなく、ブラウザのテストのペアでした。
  
  同じUIテストは、高速ブラウザーと低速ブラウザー、異なるJSインタープリターなどで異なる動作をします。 したがって、テスターはTest1を編集せず、Browser1のTest1を編集します。
• 一見同一の環境（OS、ブラウザなど）を持つ一部のエージェントは、テストの安定性が互いに異なっていました。
  
  まったく同じ環境を生成するのは困難です。 さらに、仮想マシンは、「何かを保護する」ことを望む開発者やテスターから閉鎖されていません。 したがって、これらの問題が解決されるまで、各エージェントのコンテキストでテスト実行のサンプルを作成する必要があります。 特定のエージェントのテストが著しく悪化すると、この仮想マシンとのより緊密なコミュニケーションを担当者がトリガーします。

破損した仮想マシンを検索する

ほとんどのチームは、CIを使用してメトリックを収集できます。 これは私たちにとって十分ではありませんでした-私たちはカテゴリとスターターを設定するのが面倒です。 TearDownですべてのインジケーターを含むメタビルドをデータベースに送信する小さなラッパーを作成する必要がありました。

私たちの目標：

1. 状況の評価
2. アドレス応答情報

指標により、どの指標が低下しているかを理解することができました。 次に、重み、ベンチマークを設定し、目標を達成するための順序を開発します。

2週間に1度、任務官とのフライトで、私たちは：

• 最初に影響する特性を選択します。
• 不安定性の原因について話し合う。
• タスクの優先順位付け。
• 作品の前面を推定します。
• ターゲットを計画します。

これらのメトリックは、夜間に実行された後、毎朝自動的に収集され、多数のテストが繰り返し実行されます。

オートテストのカバレッジ評価

もう1つの大きな課題は、カバレッジの評価です。 この指標を計算するための単一のオプションが私に完全に適しているわけではありません。 どのような報道を考えていますか？ コメントで共有します。

手書きのケースを対象とする人がいます。 いくつかの欠点があります。 まず、それは人的要因です。 代表的な統計に頼る有能なアナリストがタスクを引き受けるのは良いことです。 ただし、この場合、考慮せずに何かをスキップできます。 第二に、テスト対象のシステムが成長するにつれて、このアプローチはサポートするには費用がかかりすぎます。

誰かがコードカバレッジを検討します。 ただし、どのパラメーターを1つまたは別のメソッドと呼ぶかは考慮されていません。 確かに、いくつかの「安全な」引数を使用してAをBに分割するメソッドに入ることにより、そのメソッドがカバーされテストされているとは言えません。 そして、ゼロによる除算の場合は？ そしてオーバーフローした場合は？ また、カバーされていないコードの重要性は考慮されていないため、このカバレッジを増やす動機は不明です。

私たちにとって理想的なオプションは、一般的なユーザー事例の範囲を考慮することです。 さらに、システムの状態とそれらの間のアトミックな遷移を考慮します。 最初の計算オプションとの主な違いは、人的要因がないことです。 ケースはスクリプトによって生成されます。 つまり 特定のページに移動するか、そのページで何らかのアクションを実行すると、メトリックサービスにリクエストが送信されます。 これはテスト対象のシステムの機能であるため、統計は自動的に収集されます。

原理は簡単です：

• 戦場からテスト済みシステムの上位N個の人気のある状態を計算し、
• これらの状態間のペアワイズ遷移を検討し、
• トランジションの数で並べ替え、
• 上から下に移動して、ATに移行するかどうかを確認します。

このアルゴリズムは、トップを更新するために月に一度再起動されます。 欠落しているすべてのテストについて、タスクはバックログで開始され、別のストリームでレイクされます。

リリースサイクルメトリック

メトリックを適用するもう1つの場所は、リリースサイクルです。 あなたについては知りませんが、私たちのチームのテスターのリソースは限られています。 そのため、更新をすぐにテストするのではなく、遅らせる準備を整えます。 ある時点で、このタイムラグが不快感を引き起こし始め、状況を評価することにしました。

リリースサイクルの各段階でのタスクの時間を計算し始めました。

YouTrackリリースサイクルメトリックの収集

このすべてから、次のことができました。

• リリースのリリースに取り組む必要があるテスターの数、およびATのリファクタリング、インフラストラクチャの仕上げ、ツールなど、他のタスクに切り替えることができるテスターの数を計算します。
• 役割の最適な比率を理解し、その結果、空席数を予測し、
• 1時間以内に技術リリースなどのチーム内目標の力の適用ポイントを決定します。

現在、開発者とテスターを発行するテスターの比率は3（±0.1）の領域にあり、2.5は快適と見なされています。 リリースサイクルの継続的な自動化を考えると、3.5と3の比率に到達したいと考えています。

メトリックコレクションの実装は、チーム内バグトラッカーのルールエディターに基づいていました。 これがYouTrackワークフローです。 チームでは、トラッカーと同様の機能を使用したり、Webフックを使用して自転車を作成したりできます。

タスクのプライベートカウンターフィールドを設定し、1時間ごとに値を増やしました。 メーターは、営業時間中と平日のみチェックする必要があることを考慮しました-これが作業スケジュールです。 すべてがトリッキーです！ =）

メトリックのメトリック

典型的なアンチパターンは「メトリックのメトリック」です。 上で述べたように、メトリックは、目標をどれだけうまく達成しているかを定量化するのに役立つツールにすぎません。

テストの数などのメトリックを理解したことがないと仮定します。 何のために？ 一部のチームには12345のテストがあることをインジケーターは何を示しますか？ 彼らはうまくテストしていますか？ 事実ではありません。 自動テストは信頼できますか？ 彼らがチェックしていることさえ知っていることはありそうもない。 これはオートテスターのパフォーマンスを示していますか？ おそらく、サポートよりもマイナスのほうが利益より多いのではないでしょうか。どのような効率性について話しているのでしょうか？ 実際、このメトリックは、テストシステムのカバレッジと信頼を意味します。 しかし、いまいましい、これは同じものではありません。 カバレッジについて話したい場合は、それを操作します。

メトリックの収集には、ある程度の労力と時間がかかることを常に覚えておいてください。 それに感謝し、賢明にこの実践にアプローチしてください！

私たちは、あなたがどのメトリクスを使用し、反対にあなたが拒否したかについて非常に興味があります。 コメントを書いてください！

カレンダー記事のリスト：

別のアプローチを試してください

合理的なペアテスト

フィードバック：発生方法

テストを最適化する

本を読む

分析テスト

テスターはバグをキャッチし、Canerを読み、移動を整理する必要があります。

ロードサービス

QAサービスメトリック

セキュリティをテストする

顧客を知る

バックログを取る