Microsoftツールを使用したテスト-フィールドエクスペリエンス

この記事は、Kaspersky Labの友人とパートナーによって作成され、Microsoftのテストツールを使用した実際の経験を推奨事項とともに説明しています。 著者は、イゴール・シュチェグロヴィトフのカスペルスキー研究所のテストエンジニアです。

みなさんこんにちは。 Kaspersky Labのテストエンジニアとして、Microsoft Azureクラウドプラットフォームでサーバー側のクラウドインフラストラクチャを開発するチームで働いています。



チームは、開発者とテスターで構成されています（約1〜3人）。 開発者はC＃でコードを記述し、TDDとDDDを練習します。これにより、テストに適したコードと疎結合が実現します。 開発者が作成するテストは、Visual Studioから手動で実行するか、TFSでビルドをビルドするときに自動的に実行されます。 ビルドを開始するには、Gated Check-Inトリガーがインストールされているため、ソース管理をチェックインすると開始されます。 このトリガーの特性は、何らかの理由（コンパイルエラーまたはテストの失敗）でビルドが失敗した場合、ビルドを起動したチェック自体がSourceControlに入らないことです。

コードをテストするのは難しいという声明に出会ったでしょうか？ ペアプログラミングに頼る人もいます。 他の会社には専用のテスト部門があります。 私たちにとって、これは必須のコードレビューと自動化された統合テストです。 単体テストとは異なり、統合テストは専任のテストエンジニアによって開発され、私も所属しています。



クライアントは、リモートのSOAPおよびREST APIを通じて私たちとやり取りします。 サービス自体はWCF、MVCに基づいており、データはAzure Storageに保存されます。 Azure Service BusとAzure Cloud Queueは、長いビジネスプロセスの信頼性とスケーリングに使用されます。



少し歌詞：テスターは開発者になるための特定のステップであるという意見があります。 これは完全に真実ではありません。 プログラマとテストエンジニアの間の境界線は毎年消えています。 テスターに​​は、技術的な背景が必要です。 しかし同時に、開発者とは少し異なる考え方を持っています。 テスターはまず破壊を目指し、開発者は作成を目指します。 一緒に、彼らは高品質の製品を作ろうとするべきです。



統合テストとメインコードは、C＃で開発されています。 エンドユーザーのアクションをシミュレートすることにより、構成され実行中のサービスでビジネスプロセスをテストします。 これらのテストを作成するには、Visual StudioとMsTestフレームワークを使用します。 開発者も同じものを使用します。 そのプロセスでは、テスターと開発者がコードを相互に接続するため、チームメンバーは常に同じ言語を話すことができます。



テストスクリプト（テストケース）はライブであり、MTM（Microsoft Test Manager）を介して管理されます。 この場合のテストケースは、バグまたはタスクと同じTFSエンティティです。 テストケースは手動または自動です。 システムの仕様により、後者のみを使用します。



自動テストケースは、フルCLR名とテストメソッド（1つのケース-1つのテストメソッド）で接続されます。 MTM（Visual Studio 2010）が登場するまで、テストはモジュール形式で実行され、スタジオに限定されていました。 テストレポートの作成、テストの管理は困難でした。 現在、これはMTMを介して直接行われます。



これで、テストケースをテスト計画に結合し、計画内でTestSuiteを使用してフラットで階層的なグループを構築できます。



Feature Branch開発、つまり 主な改善点は、個別のブランチ、安定化およびリリースで行われます。 各ブランチに対して、テスト計画を作成しました（混乱を避けるため）。 Feature Branchブランチで安定化が完了すると、コードはmainブランチに転送され、テストは対応するテスト計画に転送されます。 テストケースをテスト計画に追加するのは非常に簡単です（Ctrl + C Ctrl + V、またはTFSクエリ経由）。



いくつかの推奨事項。 個人的には、各ブランチの安定したテストを新しいテストから分離しようとしています。 これは、TestSuiteを使用して簡単に実行できます。 ここでの特徴は、安定（または回帰）テストが100％に合格する必要があることです。 そうでない場合は、検討する価値があります。 さて、新しい機能が安定した後、対応するテストは単に回帰テストスイートに転送されます。



私個人にとって、最も退屈で日常的なプロセスの1つは、テストケースの作成でした。 自動テストを開発するプロセスは、すべての人で異なります。 最初に誰かが詳細なテストスクリプトを作成し、それに基づいて自動テストを作成します。 私は反対を持っています。 （テストクラス内の）コードにダミーテスト（ロジックなし）を記述します。 次に、ロジックの実装、テストコンポーネントのアーキテクチャ、テストデータなどがあります。



テストを作成したら、TFSに転送する必要があります。 10のテストがある場合、それは1つのことです。50または100の場合、各新しいテストケースをテストメソッドにリンクして、手順を定期的に完了するのに多くの時間を費やす必要があります。



このプロセスを簡素化するために、Microsoftはtcm.exeユーティリティを考案しました。このユーティリティを使用すると、TFSでテストスクリプトを自動的に作成し、テスト計画に含めることができます。 このユーティリティにはいくつかの欠点があります。何らかの理由で、異なるアセンブリのテストを1つのテスト計画またはステップに追加できず、テストケースに通常の名前を設定できません。 さらに、ユーティリティ自体は比較的最近登場しました。 まだ存在していなかったときは、テストスクリプトの作成プロセスを自動化する自己記述ユーティリティを作成しました。 テストスクリプトの名前と手順を指定するために、特別なカスタム属性TestCaseNameとTestCaseStepも開発されています。



ユーティリティ自体は、テストスクリプトの更新と作成の両方を行うことができ、必要な計画に含めることができます。 このユーティリティはサイレントモードで動作でき、その起動はWorfklow TFSビルドに含まれています。 したがって、自動的に起動し、既存のテストスクリプトを追加または更新します。 その結果、実際のテスト計画があります。

テスト計画のテスト実行のステータス（コードの品質と同等）は、特別なレポートに表示されます。 TFSには既製のレポート用のテンプレートセットがあり、OLAPキューブに基づいて、テストケースとテスト計画のステータスの図を作成します。 しかし、私たちは自分で書いた簡単なレポートを持っています。 私たちは、それを見た誰もがすぐにすべてを理解できるようにしました。



以下に例を示します。





レポートの特徴は、キューブに基づいて構築されていないことです。キューブは同期的に再構築されず、まだ関連のないデータが含まれている場合があります。このレポートは、MTM APIから直接取得したデータを使用します。 したがって、いつでもテスト計画の現在のステータスを取得できます。

レポートはHTML形式で作成され、SmtpClientを介してチーム全体に送信されます。 これはすべて、シンプルなユーティリティの助けを借りて行われます。このユーティリティの起動は、ワークフロービルドに直接含まれています ： ユーティリティをダウンロードします 。



テストシナリオの管理に加えて、MTMはテスト環境を管理し、テストを実行するエージェントを構成するためにも使用されます。 テストの実行を高速化するために（ここでは長い非同期ビジネスプロセスをチェックするテストについて説明しています）、6つのテストエージェントを使用します。 エージェントの水平スケーリングにより、並列テストを実現しています。



自動統合テストは、MTMとVisual Studioの両方で手動で実行できます。 ただし、デバッグ中に手動で開始されます（テストまたはコード）。 私たちのチームでは、ほぼすべてのバグに対して再現テストが開始されます。 次に、テストと一緒にバグが開発に転送されます。 また、開発者は問題の状況をシミュレートして修正するのが簡単です。



次に、リコースプロセスについて説明します。



プロジェクトには、完全なテスト実行を開始する特別なビルドがあり、ローリングビルドのようなトリガーで実行されます。 つまり、高速ゲートチェックインビルドが成功した場合、ローリングビルドが開始されます。 このビルドの特徴は、一度に最大1つのビルドが収集されることです。



このビルドの最初は前のビルドと同じです。テストとメインプロジェクトの最新バージョンを収集し、単体テストを実行します。



すべてがうまくいけば、収集されたサービスのパッケージをAzureにデプロイする特別に記述されたPower Shellスクリプトが起動します。 展開管理はAzure REST APIを使用します。 展開自体は、クラウドサービスの中間展開で実行されます。 展開が成功し、ロールがエラーなしで開始された場合、構成検証スクリプトを開始します。 すべてが順調であれば、ロールが切り替えられ（中間展開が主な役割になります）、統合テスト自体が起動されます。

テストの実行後、テストのステータスに関するレポートを含むレターがチーム全体に送信されます。



古典的な単体テストと統合テストの両方のテストを作成する前に、The Art of Unit Testing and xUnit Test Patterns：Refactoring Test Codeを読むことをお勧めします

これらの本（私は個人的に最初の本が大好きです）には、xUnitフレームワークでテストを作成する方法としない方法に関する多くのヒントとコツが含まれています。



私たちのチームで自動テストコードを書くための基本的な原則を列挙して、私の記事を終わりたいと思います。

• 「フレンドリーな」CLRは、テストメソッドの名前です 。 ここでの主なアイデアは、テストの名前を1つ調べることで、プログラマーがどのデータで、何が期待されるかを確認することを理解できるということです。 テストの名前は、アンダースコアで区切られた3つの部分で構成され、次のようになります。FunctionalUnderTest_Conditions_ExpectedResult
• テストの厳密な構造はArrange-Act-Assertです。 データの準備、いくつかのアクションと検証。 ポイントは、テストが最も簡単で最もコンパクトな構造であり、基本的には前述の3つのステップで構成されることです。 これにより、テストのサポートとデバッグが容易になるだけでなく、読みやすさが向上します。
• テストには条件付きロジックとループを含めるべきではありません 。 ここで、コメントがなければ、そのようなテストがあれば、テスト用のテストを作成する必要があります。
• 1つのテスト-1つのテスト 。 多くの場合、人々はテストに多数のAssertを挿入しますが、その後、テストがどのテストに当てられたのか理解できません。 テストで1つのテストを実行してください。これにより、デバッグとトラブルシューティングが大幅に簡素化されます。 ここで少し追加しますが、場合によっては、1つのアクションの後、いくつかのオブジェクトの状態を確認する必要があり、各オブジェクトの状態は多くのプロパティによって特徴付けられます。 この場合、2つのテストを実行し、すべてのプロパティのプロパティを別のメソッドのヘルパー、通常の名前のヘルパーで確認し、Assert.IsTrueの代わりに再定義されたアサートを呼び出すことをお勧めします。 また、プロパティチェックを記述するときは、読み取り可能なエラーメッセージを記述してください。 ここで、例を挙げました。 実際、さまざまなパターンがたくさんあります。
• テストは、統合テストであっても、迅速でなければなりません 。 これを念頭に置いて書いてみてください。 このような挿入を使用したテストの多くの例を見ました：Thread.Sleep（60000）。 これを避けてください。 何らかの非同期アクションの実行が予想される場合は、その実行を追跡する方法を見つけてください（たとえば、非同期プロセスがデータベースの状態を変更するなど）。 それとも、テストをいくつかに分割する価値があるのでしょうか？
• おそらくこれをまだ行っていないが、テストではスレッドの安全性を観察してください。 なぜなら 将来的には、テストの実行をスピードアップしたいと思うようになる可能性が最も高く、マルチスレッドはこの高速化を達成するためのほぼ1つの方法になります。
• 独立 。 テストは、実行の順序や相互に依存するべきではありません。 この原則に基づいてテストを作成します。 多くの場合、さまざまな予期しない結果につながり、テストの実行が遅くなるため、テストデータをクリーンアップしてください。

最後に、適切なテストにより、開発が迅速になり、コードの品質が向上することを付け加えます。