-フォームの正確性は重要ではありません！ そして、彼はすべてを順不同に円状に並べました。 誰もコマンドを与えませんでした-誰もが望むときに走りました。
L.キャロル、「不思議の国のアリスの冒険」
テスト自動化を開発することにより、努力を注ぐための多くの場所を見つけることができます。 努力を吹き込み、誤った目標を追求することで、時間とリソースを無駄にするだけでなく、開発に害を与えます。
プロジェクトのテストの自動化が現在どのような開発レベルで行われており、そのような状況にどこに投資すればよいかを知っていれば、より大きなリターンを達成できるだけでなく、開発全体を改善できます。 リソースへの投資の基本原則は、短いマニフェストとして定式化することができます。
テスト自動化マニフェスト
テストへの自信とそのサポートが最も重要です。
テストの速度と拡張性は 、 信頼とサポートがある場合にのみ重要です。
製品全体をテストでカバーし、自動化と手動テストを統合することは、テストの信頼性、サポート 性 、速度 、および拡張性が達成された場合にのみ意味があります。
批評
おそらく、テスト自動化の分野で最も一般的で広く認識されているマニフェストは、2003年にGerard MesarocheとClearStream Consultingの同僚によって作成されたものです。
彼らの声明では、彼らは個々のテストが満たさなければならない12の要件を宣言しています。 たとえば、これらの要件の1つは簡潔さです。 テストはできる限り単純にする必要がありますが、単純ではありません。
将来、説明されたアイデアは、本「xUnit Test Patterns。」で開発されました。 xUnitテストパターンテストコードのリファクタリング 。 これは開発者にとって価値のあるガイドであり、Mesarosはユニットテストに関連する多くの問題を詳細に調査し、それらを解決するプログラミングテンプレートを提供します。
ただし、個々のテストの開発方法を理解するだけでは、自動化の開発を成功させるのに十分ではありません。 リソースは常に制限されています。 したがって、そもそもどのような資質を開発する必要があるかを理解することも重要な成功要因となります。
健康コンプライアンス
テストの基本的な品質は信頼と持続可能性です。 そもそも提供する必要があります。
信頼 -ローンチの結果で自動化されたテストを使用するすべての人の完全な信頼。 グリーンテストでテストが機能したことが保証されない場合、手動テスト担当者はそれらを信頼しません。 赤いテストで問題が示されない場合、プログラマーはそれを信じません。 テストがランダムに赤、緑の場合は、誰もが等しく無視されます。
サポート可能性 -稼働状態の既存のテストをサポートするために容認できないほどの労力を費やすことなく、開発者がアプリケーションコードを操作する能力。
テストをサポートするための作業量とコードの変更の量の不均衡は、開発の崩壊につながります。 あるケースでコードを変更するには、1つのテストクラスを変更する必要があり、もう1つのケースでは、数百のテストクラスを変更するか、テストの100行を修正する必要があるコードの変更された行ごとに変更することを想像してください。 その後、開発コストが急騰し、開発者はコードの変更を最小限に抑えるよう努めます。 その結果、製品コードがフリーズし、開発が中止されます。
特定された問題の本質である「期待された真は偽」を明らかにしなかった倒れたテストでは、それを解決するためにテストコードを詳細に調査する必要があります。 そのような努力は常に無駄になり、本当に重要なタスクから時間がかかります。
テストとそのサポートの信頼性を提供することは、技術的に複雑で骨の折れる作業ですが、その解決策は目に見える効果をわずかに与えます。 多くの人がこれらの資質を当たり前だと思っています。 ただし、テストがサポートされていないか信頼できない場合、他の自動化イニシアチブは失敗する運命にあります。
開発者のメリットを最大化
衛生基準の順守に成功したら、テストが開発にもたらすメリットを最大限に活用することができます。 これを行うには、最大化する必要がありますが、安定性を損なうことなく、テストの実行を高速化し、 拡張性 -新しいテストを作成する機能を保証します。
速度 -テストの実行に必要な合計時間。定性レベルでの適用性を決定します。
可能な限り早い段階でエラーを検出することは、問題が発生したときに問題を修正することが常に容易であるため、開発の生産性を大幅に高めることができる原則です。 そして、これを確実にするための簡単なテストです。
クイックテストは、開発者がまだゲームにいる間にエラーに注意を向けます。 テストが長時間実行される場合、開発者は他のタスクに切り替えた後にエラーを検出します。 問題に戻るには追加の努力が必要になるため、手遅れです。 時間の無駄。 うるさい。 やる気をなくします。
拡張性 -開発者が新しいテストを迅速かつ効率的に作成する能力。
各テストの作成が、「メソッドの動作を置き換える方法」、「テストユーザーを作成する方法」、「ページのスクリーンショットを撮る方法」などの精神で自転車の発明に変わる場合、テストでのコードの範囲が拡大する可能性は低いです。 むしろ、それは忍び寄るでしょう。
すべての新しいコードのテストカバレッジは、テストの記述を最大限に活用するための主要な方法です。エラーや改善の影響を最も受けやすいのは新しいコードだからです。 ただし、テストの拡張性の問題を解決せずにこの原則を実装することは非常に困難です。
テストの実行速度とその拡張性を確保することは、自動化から具体的なメリットを得る方法であり、開発者にとって意識的に魅力的なテストを作成する方法です。
手動テストの観点からは、この段階で作業は間接的に削減されます。 自動テストで見つかった問題は、開発者がすぐに修正し、手動テストの参加を必要としません。 これは良いことですが、これはテストで得られるものとはほど遠いものです。
開発サイクルの短縮と手動テスト
自動テストを使用し、同時に手動テストを続けながら、これらのプロセスを自然に組み合わせて、それぞれが他のプロセスから最大限の利益を得られるようにします。 そのためには、自動化プロセスと手動テストプロセスを統合し、製品がテストでカバーされるようにする必要があります。
カバレッジ -製品全体または個々のモジュールの少なくともすべての手動ケースの自動検証。
自然な方法で完全なテストカバレッジを実装するには、新しいテストを作成する必要があります。 テストの拡張性の問題が解決されない場合、そのようなプロセスは不当に高価になり、結果として得られるテストは維持するのが困難になります。 多くのテストの拡張は、常に実行時間の増加につながります。 ここでは速度が重要です。低速なテストは、たとえ多くのテストがあっても、かなりの代価を失います。
手動テストとの統合 -手動テストの一部を自動テストの実行に置き換えます。
理想的には、「変更されていないもの」が手動で再テストされないように努力する必要があります。 もちろん、これを達成するのは最も困難です。
手動スクリプトの自動化が適切な程度に不可能になるため、テストの拡張性が保証されない場合、テストを手動テストプロセスに統合するという考えも意味をなしません。 テスト速度も同様に重要です。 自動テストの実行が遅すぎると、自動化が完了するのを待つよりも、テスターがすべてを手で確認しやすくなります。
カバレッジを提供し、手動テストと統合することにより、自動テストの概念が全体的で完全な外観になります。
長期的には、テストの自動化が必要であり、それを保証するためのリソースのコストは避けられません。 ただし、定性レベルで結果を達成できれば、少なくとも手動テストのコストを削減できます。 これにより、開発サイクルが短縮されます。
私たちはテストを書くことを余儀なくされているので、これらの努力がすべての人に最大の利益をもたらし、仕事がより速く動くことを保証する必要があります。
ドミトリー・マモノフ
開発部
マスターのマージ部門、
gitの作業部門、
コンソールコンソール2の主要なオペレーターカテゴリ