ASP.NETアプリケーションの自動統合テスト

この記事では、Webアプリケーションを統合テストするためのインフラストラクチャを作成した経験を共有したいと思います。 アプリケーションは.Netプラットフォーム上に構築され、ASP.NET MVCアプリケーションとMSSQLのデータベースで構成されます。



統合テストタスクは次のように定式化されました。アプリケーションのインストールとユーザーインターフェイスのテストを自動化して、インストールされたバージョンのアプリケーションが必要なテストシナリオをすべて正常に実行することをすばやく確認できるようにします。



つまり、新しいバージョンを顧客にインストールして作業を開始するとどうなるかをすばやく確認する必要があります。 これらのテストの結果は作成されたアプリケーションの品質の指標であるため、アプリケーションの品質、したがって現在の状況を常に知ることができます。



統合テストではユーザーアクションをシミュレートできるため、ToRの特定のポイントが正常に完了したという事実を検証できると言えます。 TORの各項目のテストを作成し（プログラムとテスト方法論-PMI：を取得）、それらを自動化する場合、正常に完了したテストの数は、TKが何パーセント完了したかに関する実際の情報を意味します。 それ以外の場合、システムの状態の評価は次のようになります。

「まあ、一言で言えば、今日のシステムはどうですか？」

「一言で言えば、...それは機能します。」

-そして、簡単に言えば？

-簡単に言えば、機能しません。



そのようなテスト中に確認する必要があるもの：

-アプリケーションのコンパイルとアセンブリ

-アプリケーションをインストールまたは更新する手順：

-新規データベースのインストールまたは既存のデータベースの更新

-新しいASP.NETアプリケーションのインストール

-それぞれのテストシナリオの実行：

-システムはスクリプトを実行する準備ができています。 各シナリオには前提条件があるため、システムをこれらの条件に適合させる必要があります。 たとえば、ユーザーがシステムで3つの注文を作成する必要があるシナリオの場合、ユーザーデータベースで何らかの方法で3つの注文を取得する必要があります。

-テストスクリプトは、ブラウザーでのユーザーアクションのエミュレーションを通じて実行されます。

-システムは、スクリプトが実行される前の状態、実際にはアプリケーションをインストールした直後の状態に戻ります

-アプリケーション品質の報告

-品質がわかっているアプリケーションを含むインストールパッケージのアセンブリ。







このプロセスを下の図に示します。



このスキームにより、更新されたアプリケーションのインストール中およびインストール後に産業環境で実行されるのと同じアクションを開発者のマシンとContinues Integration Serverで再現できることに注意してください。

基本構成

以下に、統合テストおよび産業用使用中に異なる環境に構成を展開する方法を示します。 すべての環境でのアプリケーションとの相互作用は同じであることにすぐに注意します。 アプリケーションとの対話はブラウザを介して行われ、データベースはデータベース更新スクリプトの形式で更新され、ASP.NETアプリケーションは標準の展開を介して更新されます。

Developer Machineでの構成

開発者の構成では、Visual Studioがメインツールとして使用されます。



この構成では、開発者のマシンでDBMSを使用することになっています。 このオプションは、すべての開発者が1つの共通データベースを使用する場合のオプションよりも優れていると思います。 一方では、共通のデータベースは維持費が安く、すべての開発者は常にデータベースの最新バージョンを持っています。 しかし一方で、そのようなデータベースでは、開発者が何らかの検証を行うのを忘れたため、たとえば、いくつかの誤った注文を入力できるなど、データの整合性の違反を簡単に取得できます。 もちろん、彼は後で検証を行い、より多くの不正な注文がシステムに作成されることはありません。 しかし、別の開発者は、間違った順序で機能をデバッグし続け、多くの隠れたエラーを引き起こす可能性があります。



個人用データ​​ベースの場合、完全なデータを作成するタスクは、明示的で簡単に解決できます。 これについては、「リトルトリック」セクションで説明します。



統合テストの前に、開発者は作業用データベースを産業用サーバーから統合テストDBMSに復元する必要があります。 もちろん、産業用スタンドから作業用データベースを取得するのは非現実的ですが、データベースの更新プロセスを正しく確認するには、可能な限り近いデータベースが必要です。 オプションとして、作業用データベースの匿名化を行うことができます。つまり、作業用データベースのコピーを作成してから、顧客の名前と契約の量を変更して、商用情報が開発者やテスターに​​届かないようにします。



テストの最初の段階は、データベースの展開を検証することです。つまり、開発者はデータベースを公開します。 これを行うには、開発者がデータベースプロジェクトをターゲットデータベースに公開します。 プロジェクトのアセンブリ中に、Visual Studioはターゲットデータベースにクロールし、現在のプロジェクトのスクリプトと比較して、実行される差分スクリプトを作成します。 ここでエラーが発生する可能性があります。たとえば、セカンダリキーが参照するフィールドの作成を忘れたり、初期データの挿入時にプライマリキーの競​​合が発生したりします。 開発者は、実装段階ではなくテスト段階でこれらのエラーをすべて検出して修正することがわかりました。誰もがそれがどれほど神経を節約するか知っていると思います。



次のステップでは、開発者はVisual Studioテストランナーを通じてテストを実行します。 実行中の統合テストは、テストに必要なデータでデータベースを満たし、それによってテストの予備要件を満たします。その後、テストはSelenium RC Serverを介してブラウザーを呼び出し、ユーザーアクションをシミュレートします。 テストの結果はブラウザを介して再度チェックされます。また、参照と比較するためにデータベースからデータを取得することもできます。



テストが完了すると、データベースは元の状態に戻ります。



その結果、テストの実行後、システムの一般的な状態を確認できます。

Continues統合サーバーでの構成

ここでは、Visual Studioの代わりにContinues統合サーバーが使用されますが、すべてのアクションは開発者のマシン上のアクションに似ています

産業用構成

産業環境では、更新プログラムは、統合テストの場合と同じように産業環境で動作するインストーラーを介してインストールされます。 ユーザーは、テストでテストされたのと同じ方法でシステムを操作します。 不快な驚きはすでにあるはずです。

必要なツール

必要なインフラストラクチャを作成するには、次のツールが必要です。



いくつかのプロジェクトを含むVisual Studioソリューション：

-プロジェクト「SQL Server Database Project」。 ご存じのように、このようなプロジェクトでは、データベースの構造と初期コンテンツを開発するために必要なすべてのDDLおよびSQLスクリプトを保存できます。 このプロジェクトの主な利点は、既存のデータベースを最新バージョンに更新するための差分スクリプトを生成できることです。 これにより、既存のデータを削除せずに更新プログラムをインストールできます。 さらに、この操作はMSBuildを介して自動化し、Continuous Integrationサーバーで実行できます。

-ASP.NETアプリケーションを使用したプロジェクト。 アプリケーション自体が含まれています。 このプロジェクトは、サーバーへのWebアプリケーションの展開を確認す​​るためにも使用されます。これもMSBuildを使用して自動的に行われます。

-統合テストを含むプロジェクト。 これはMSTestまたはNUnitプロジェクトです。 このプロジェクトは、テストの実行とテストレポートの作成に使用されます。



これは、自動化された統合テストを編成するために必要なプロジェクトの最小セットです。



もちろん、ソリューションはSVNなどのバージョン管理システムに保存されます。



さらに、ソリューションにはnuGetパッケージ「Selenuim Remote Contol」が含まれています。 残念ながら、Selenim IDEは新しい「Selenium WebDriver」を完全にサポートしていないため、Selenim IDEからC＃コードへのテストスクリプトのエクスポートは、Remote Contolでのみ可能です。 そうしないと、一部のステップがC＃にエクスポートされず、手作業で作成する必要があります。これは、Selenim IDEからのエクスポートよりも著しく遅くなります。



「Selenuim Remote Contol」の場合、Javaアプリケーション「selenium-server-standalone-xxxjar」が必要です



テストをすばやく便利に記録するには、Selenim IDEアドオンがインストールされたFireFoxが必要です。



SVNから常に最新バージョンを取得してテストを実行するには、Continues Integrationサーバーも必要です。

環境設定

上記の製品をさまざまなスタンドでインストールおよび構成する方法を示します。

データベースプロジェクト

データベースの設計から始めましょう。 データベースプロジェクトには、いくつかのpublish.xmlファイルを含めることができます。各ファイルには、データベースの公開場所と公開方法が記述されています。 各開発者のデータベースは独自のアドレスにあるため、これらのファイルはバージョン管理システムから削除し、開発者ごとに個別に構成する必要があります。



データベースを公開するには、Visual Studioでこのファイルを右クリックし、[公開]を選択します。 公開は、展開オプションがプロジェクトプロパティに保存され、公開オプションがpublish.xmlに保存されることを除いて、展開に似ています。



コマンドラインからデータベースを公開するには、次のコマンドを呼び出す必要があります。

> MSBuild / t：発行/ p：SqlPublishProfilePath = beatmypublishfile.publish.xml»DBProject.sqlproj

Webアプリケーション

Visual StudioのASP.NETアプリケーションは、「実行」コマンドを使用して起動するか、標準のVisual Studioツールを使用して展開できます。 Continues Integration Serverでは、これは、xCopyなど、さまざまな方法でも実行できます。 これについてはもう少し詳しく説明しません。なぜなら、一方では非常に多くの資料であり、他方ではインターネット上で簡単に見つけることができるからです。

Seleniumサーバー

ここからダウンロードできるSelenium RCサーバーも必要になります： docs.seleniumhq.org/download



次のコマンドでサーバーを起動します

> java -jar c：\ selenium \ selenium-server.jar -multiwindow



サーバーの実行中に、テストを実行できます。

統合テストを含むテストプロジェクト

これは、MSTestプロジェクトまたはNUnitプロジェクトです。

まず、nuGetパッケージSelenium.RCをインストールする必要があります





各テストの冒頭で既に述べたように、データベースにテスト用のデータを入力するSQLスクリプトを実行する必要があります。 私はSQL Server Management Studioで作成されたスクリプトを頻繁に使用するため、GOコマンドは常にスクリプト内にあります。 このようなスクリプトを実行するには、smoライブラリが使用されます。これらはMSSQL Server SDKの一部としてインストールできるいくつかのアセンブリで、たとえば「C：\ Program Files（x86）\ Microsoft SQL Server \ 110 \ SDK \ Assemblies」にありますが、これらは.Net 2.0用にコンパイルされているため、.Net 4.0以前で動作させることはできません。 したがって、テストアプリケーションでは、通常.Net 3.5用に構成します。



その後、テストプロジェクトでこのような補助クラスを作成できます。

public class TestDBHelper { public static void ExecScript(String scriptName) { string sqlConnectionString = System.Configuration.ConfigurationManager.ConnectionStrings["TestDBConnection"].ConnectionString; FileInfo file = new FileInfo(Path.Combine("SQL", scriptName)); string script = file.OpenText().ReadToEnd(); SqlConnection conn = new SqlConnection(sqlConnectionString); Server server = new Server(new ServerConnection(conn)); server.ConnectionContext.ExecuteNonQuery(script); } public static void BackupBeforeTest() { TestDBHelper.ExecScript("BackupBeforeTest.sql"); } public static void RestoreAfterTest() { TestDBHelper.ExecScript("RestoreAfterTest.sql"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのSQLスクリプトは「SQL」フォルダーの同じテストプロジェクトにあり、各スクリプトの「出力ディレクトリにコピー」プロパティは「新しい場合にコピー」に設定されています。



スクリプト「BackupBeforeTest.sql」および「RestoreAfterTest.sql」の内容は以下のとおりです。



その結果、テストは次のようになります。

 [TestClass] public class SimpleTest { private ISelenium selenium; private StringBuilder verificationErrors; [TestInitialize] public void Init() { TestDBHelper.BackupBeforeTest(); TestDBHelper.ExecScript("CreateTestUser.sql"); selenium = new DefaultSelenium("localhost", 4444, "*chrome", "http://localhost:12945/"); selenium.Start(); verificationErrors = new StringBuilder(); } [TestCleanup] public void CleanUp() { selenium.Stop(); TestDBHelper.RestoreAfterTest(); } [TestMethod] public void TestLogin() { if (selenium.IsElementPresent("link=  []")) { selenium.Click("link=  []"); selenium.WaitForPageToLoad("30000"); } selenium.Open("/"); selenium.Click("link="); selenium.WaitForPageToLoad("30000"); selenium.Type("id=UserName", "TestUser"); selenium.Type("id=Password", "123456"); selenium.Click("css=input.btn"); selenium.WaitForPageToLoad("30000"); Assert.IsFalse(selenium.IsElementPresent("css=div.validation-summary-errors > ul > li"), "  "); Assert.IsTrue(selenium.IsElementPresent("link=  []"), "  "); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この簡単なテストでは、ユーザーのログインを確認します。

テストを実行する前に、バックアップデータベースが実行され、スクリプト「CreateTestUser.sql」が実行されます。このスクリプトは、必要なパラメーターを持つユーザーを作成するだけです。

テストが完了すると、テスト後に残っているデータのデータベースをクリアするために、データベースがバックアップから復元されます。



残念ながら、統合テストを互いに完全に分離することはできません。特に、Seleniunツールを使用すると、「ASP.NET_Session」CookieはHTTPOnlyとしてマークされているため、ブラウザーから削除できません。 このため、ユーザーが最後のテストからログインしたままであるかどうかを確認する必要があります。滞在する場合は、システムからログアウトするユーザーをシミュレートし、セッション状態をリセットする必要があります。



テストの残りの部分はかなり明白です。 ユーザー名とパスワードが入力され、エラーメッセージがないことが確認され、システムを終了するリンクが表示されます。 Selenium IDEを使用してこのようなテストを作成する方法は、以下を参照してください。

FireFoxおよびSelenium IDE。 テスト作成

Seleniumを使用すると、多くのブラウザーでテストを実行できますが、迅速に作成するには、FireFoxに「Selenium IDE」を追加してインストールする必要があります。



このSelenium IDEが優れているのはなぜですか？

まず、テストをすばやく書くのに非常に便利です。 記録モードをオンにしてWebアプリケーションでの作業を開始すると、セレンはすべてのアクションを記録します。 ただし、AJAXアプリケーションの場合、サーバーが応答するのを常に待つ必要があるため、この「Selenium IDE」は自動的には機能しないため、これはうまくいきません。 それでも、この場合でも、テストプロセスにそのような期待を加えることができます。







この図は、ディレクトリ内のエントリの変更をチェックするテストの受け入れを示しています。 このページは、DevExpress MVC拡張を使用して実装され、多くのAJAXコードが含まれているため、「WaitFor ...」などのステップが追加され、必要な更新がブラウザに表示されるのを待ちます。



もう1つの大きな利点は、「Selenium IDE」を使用してテストをすばやくデバッグできることです。 [テストの実行]ボタンをクリックして、すべてが機能することを確認します。



テストのデバッグ後、コマンド「Export Sute As」/「C＃/ NUnit / Remote Control」を使用してc＃ファイルに保存し、テストメソッドの内容をテストプロジェクトにコピーできます。 これにより、テストをすぐにC＃で記述し、MSTestまたはNUnitを実行してデバッグする場合に比べて、テストの作成速度が大幅に向上します。



また、Selenium IDEの最も注目すべき特性は、テスターが独自の目的でこれらのテストを作成できるという事実であり、テストが非常に重要な場合は、開発者に渡すことができ、統合テストのリストに追加できることです。 その結果、テスターはテストの作成を支援しますが、もちろん、テスターはデータベースをテスト用に準備するSQLスクリプトを作成できないことを忘れないでください。これはテストの重要な部分です。

ちょっとしたトリック

データベースでのテストデータの作成と読み込み

テストのデータは、システムをテストの前提条件で説明された状態にするために必要です。 たとえば、3つの注文を行ったバイヤーが必要です。 ユーザーインターフェイスから購入者と注文を作成する最も簡単な方法。 次に、必要なテーブルからSQL Dumpの形式でSQLスクリプトにデータをアンロードする必要があります。 そして、テストの実行時にこのスクリプトを使用します。



そのようなスクリプトの例：

 SET IDENTITY_INSERT [dbo].[User] ON INSERT [dbo].[User] ([UserId], [Login], [Password], [DisplayName]) VALUES (1000001, N'TestUser', N'7dHZDOYgwADlGdinx9u/c4Cmhtc=', N' ') SET IDENTITY_INSERT [dbo].[User] OFF SET IDENTITY_INSERT [dbo].[Order] ON INSERT [dbo].[Order] ([OrderId], [UserId], [Description], [Price]) VALUES (1000001, 1000001, N' №1', 100.0) INSERT [dbo].[Order] ([OrderId], [UserId], [Description], [Price]) VALUES (1000002, 1000001, N' №2', 200.0) INSERT [dbo].[Order] ([OrderId], [UserId], [Description], [Price]) VALUES (1000003, 1000001, N' №3', 300.0) SET IDENTITY_INSERT [dbo].[Order] OFF
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスクリプトは、「SQL Dumper」などのプログラムまたはSQL Server Management Studioから取得できます。SQLServer Management Studioには、テーブルデータを含むデータベースオブジェクトでスクリプトを生成するための優れたウィザードがあります。



-[データベースレコード識別子の管理]-



データ作成スクリプトの識別子が1ではなく1,000,000で始まることにすでに気づいたと思います。

これは、戦闘データベースがある場合、おそらく小さな値の識別子が既に使用されているため、これらの値をスクリプトに挿入しようとすると、識別子の一意性の違反が発生するためです。



これを回避するには、開発およびテストデータベースの識別子ジェネレーターの初期値を100万または10億にすぐに設定する必要があります。

テスト後のデータベースのクリーンアップ

最も簡単で効果的な方法はトランザクションを使用することですが、この構成では、テストとアプリケーションは異なるプロセスで実行され、両方のプロセスで同じトランザクションを簡単に使用することはできません。

それでも、データベースバックアップのシンプルで高速なメカニズムを使用できます。 ただし、通常のバックアップの作成と復元は比較的長いプロセスであることに注意する必要がありますが、スナップショットバックアップがあります。これは、データベースを迅速に作成および復元するためだけに作成されました。



したがって、各テストの前に、「BackupBeforeTest.sql」ファイルからバックアップスクリプトを作成します

 USE [master] GO IF EXISTS (SELECT name FROM sys.databases WHERE name = N'MyDataBase_Spanpshot') DROP DATABASE MyDataBase_Spanpshot GO CREATE DATABASE MyDataBase_Spanpshot ON (NAME = 'DataBase_data_File', FILENAME = 'C:\MyDataBase_TestBU.SNP') AS SNAPSHOT OF MyDataBase;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、テスト後に「RestoreAfterTest.sql」から次のスクリプトを復元します。

 USE master; DECLARE @DatabaseName nvarchar(50) SET @DatabaseName = N'MyDataBase' DECLARE @SQL varchar(max) SELECT @SQL = COALESCE(@SQL,'') + ' BEGIN TRY Kill ' + Convert(varchar, SPId) + '; END TRY BEGIN CATCH END CATCH;' FROM MASTER..SysProcesses WHERE DBId = DB_ID(@DatabaseName) AND SPId <> @@SPId EXEC(@SQL) RESTORE DATABASE MyDataBase_Spanpshot from DATABASE_SNAPSHOT = 'MyDataBase_Spanpshot'; GO IF EXISTS (SELECT name FROM sys.databases WHERE name = N'MyDataBase_Spanpshot') DROP DATABASE MyDataBase_Spanpshot GO
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、復元する前に、テスト後に接続したままのすべてのユーザーを切断する必要があります。 そうしないと、データベースを復元できません。

テスト前のデータベースの増分充填のためのSQLスクリプトの編成

スクリプトを実行する前に、データベースを準備する必要があることを何度か言いました。 しかし、もう少し深く掘り下げると、これらのスクリプトは互いに依存していることがわかります。



ゼロレベルから始めましょう。参照データはデータベースの初期展開の一部として作成され、システム内の多くのエンティティがこの参照データを参照します。 さらにユーザーがいますが、多くのユーザーもそれらを参照しています。 さらなる例として、商品のカタログ、および商品、ユーザー、ディレクトリにリンクする注文を取得できます。



明らかに、注文のテストデータを準備する場合、既存のデータを使用してユーザーと製品カタログを作成するのが合理的です。これにより、少なくとも時間を節約できます。



しかし、実際にはさらに多くの利点があります。 たとえば、ある開発者が製品カタログで作業していて、あるルールを実装するのを忘れて、テストデータを含むいくつかの誤ったデータを作成したとき、上記の例を思い出してください。 注文を処理する別の開発者は、誤った製品データを使用してコードを作成しました。

依存テストデータの場合、最初の開発者がコードとテストデータを修正するとすぐに、2番目の開発者は、このルールが重要である場合、テストをドロップします。 したがって、最初の開発者は、製品のカタログのテストデータをデバッグしている間、実際には注文のテストデータもデバッグするため、注文のエラーがより速くなります。



この原則は他の方法で機能します。 注文の開発者がまだ利用できない製品の新しいテストデータを必要とする場合、そのようなデータを自分で準備し、この新しい製品で注文テストを実行する必要があります。 ただし、この新しい製品は、製品カタログに関連付けられているすべてのテストに合格する必要があることも意味します。 製品カタログのテストが新しい製品で失敗した場合、これは注文開発者が製品カタログの開発者のコ​​ードでエラーを検出したことを意味します。 繰り返しますが、各開発者が自分ですべてのテストデータを準備する場合と比較して、製品カタログのエラーがより早く検出されることがわかります。

おわりに

説明した自動統合テストの編成方法により、安定化段階だけでなく、開発段階全体で作成されたWebアプリケーションの品質を自動的に評価できます。 エラーが早く発見されると、修正のコストが安くなります。最も重要なことは、安定化だけでなく、すぐに、残りの作業量が見えるため、プロジェクトマネージャーは作業をより正確に計画できます。



もちろん、説明したインフラストラクチャを維持するには一定のコストが必要ですが、手動テストのコストが低いため、これらのコストは報われると考えています。