c# - コード化された UI テストの自動化が重要な理由

Question

私はアプリのテストの主題に不慣れです。役立つチュートリアルを見つけるために、インターネットをサーフィンし始めてから数日が経ちました。正直なところ、コード化された UI テストの自動化、データベース ユニット テスト、および MS Visual Studio 2010 を使用したユニット テストを作成する方法についての全体像を示す良いビデオを見つけました。たとえば、CUIT の自動化は、アプリケーションを実行して自分でテストしたことを記録しているだけです。だから何..？それは私の行動を記録するだけです。これは、実際にアプリケーションを伝統的にテストする私です。私が気づいていない何らかの理由があるに違いないことを私は知っていますし、確信しています！自動化されたコード化された UI テストがどのように役立つのか、誰か説明してもらえますか? 一方、データベース単体テストについても同様の質問があります。私' YouTube で、この例を説明するビデオ チュートリアルを見つけました。ストアド プロシージャが正しく動作するかどうかをチェックするだけです。明らかに、アプリケーションを実行している (F5 キーを押す) ときに、Insert SP が完全に機能しているかどうかを簡単に理解できます。繰り返しになりますが、データベース ユニット テストの役割がわかりません。誰かが私にアイデアや有用なリンクを提供してくれれば、事前に感謝します. ありがとうございました、

Answer 1

テストを自動化することの大きな利点の 1 つは、何かが壊れたり、予期しない副作用が発生したりする可能性を心配することなく、自信を持って変更や修正を行ったり、機能を追加したりできることです。変更のたびに事前にコード化されたテストを実行するのは簡単かつ安価であるため、開発サイクルの後半であっても最もリスクの高い変更を加えても、アプリケーションがまだ良好であることを確信できます。

別の利点は次のとおりです。新しいコードを作成すると、既存の機能が壊れたり変更されたりするとします。次に、何が変更されたかを正確にリストする簡単な方法があり (自動テストを実行して結果を確認するだけです!)、これらの変更について推論し、バグ、実際に必要な副作用/変更のいずれかに分類できます。 、など。 そうしないと、開発はすぐに "1 歩進んで 2 歩下がる" という混乱になります。チェックインのたびに 1 つの問題が修正され、2 つの新しい問題が発生する可能性があります。開発者が 2 つの新しい問題を認識していても (常にそうであるとは限りません)、最善の意図にもかかわらず、後でこれらの新しい問題に対処することを忘れてしまいます。

「SPを実行するだけ」またはUIを「実行するだけ」できると言っています。しかし、それはスケールしません...繰り返しになりますが、理想的には、変更のたびに何千ものテストを無料で自動的に実行できるようにする必要があります。つまり、テストを自動化する必要があります。また、アプリケーションを実行するだけで SP が機能しているかどうかがわかるとおっしゃっていますが、データベースとアプリケーションがますます複雑になるにつれて、実際にテストするためにアプリケーションで何をしなければならないかがますます明白ではなくなります。あなたのデータベースを正しく。また、後で同じデータベースを使用する 2 つ目のアプリケーションを作成する必要がある場合はどうすればよいでしょうか? (たとえば、Web サイトを持っていて、後で管理者用のコマンドライン ツールを作成する必要がある場合など)。

明らかな理由から、複数の人が同じコードで作業している場合、これらすべてがより重要になります。適切な自動化されたテスト カバレッジがなければ、複雑なコードはすぐに 1 人のドメインになります (「Joe と話さずにそのコードに触れないでください!」)。

もちろん、これは、利用可能なすべてのテスト技術をすべてのプロジェクトにやみくもに適用する必要があるという意味ではありません。特に、CUIT のような比較的「高価な」技術を適用する必要があります (プロジェクトの過程で UI が大幅に変更される場合、このタイプのテストは高価になる可能性があります)。更新が難しくなる可能性があります)。代わりに、プロジェクトの実際のリスク領域 (そうするなら「バグ ファーム」) を適切に評価し、サイクルの適切なタイミングで各タイプのテストを導入する必要があります。つまり、実際のテスト計画を立てる必要があります。この最後の段落は私の意見です。明らかに、何を、どのように、いつテストするかを選択するには、さまざまなアプローチがあります。

Answer 2

アクションを記録するテスト ソフトウェアに関する注記に関連して、これはバグを再現しようとする場合、特にテストを最初に書き始めるときに非常に便利です。

ユージーンが指摘したように、複数のコーダーを取得すると物事はより複雑になりますが、ソフトウェアが他のコンポーネント (サーバー、他のソフトウェア パッケージなど) とやり取りする必要がある場合、非常に急速に複雑になることも付け加えたいと思います。他のコンポーネントが完全であると仮定することは、常に安全な賭けではありません。したがって、テストを自動化するという考え方は、ソフトウェアを書き続けている間に、何もせずに以前に行ったすべてのことに対してテストできるということです。たとえば、Bluetooth を使用して接続するプログラムを作成しますが、WiFi を追加すると、Wifi に対してこれらの Bluetooth テスト ケースのほとんど (すべてではないにしても) を使用できます。UI の例で、10 個のボタンがあり、新しいボタンとは関係がないため、古いボタンを誤って壊してしまう新しいボタンを追加するとします。

テストについてさらに正当化する必要がある場合は、継続的インテグレーションを読むことを強くお勧めします。これは、テストする必要がある理由とその利点を示し、その方法の例を示しています。また、DB テストに関する例もいくつかあります。

これがお役に立てば幸いです。私もテストは初めてですが、短期間で多くのことを学びました。

Answer 3

これをどこで見たか思い出せませんが、単体テストをうまくまとめています。

「よく書かれた単体テストはバグを見つけることができません...しかし、それは確かに回帰を見つけることができます」