Visual Studio Team Servicesの負荷テストをCI/CD時に実施する(18日目)

はじめに

昨日は単体で実施する負荷テストを紹介しました。たまにやる分にはGUIでちまちま実施しても構いませんが、どうせなら継続的インテグレーション(CI)や継続的デプロイ(CD)に組み込みたいものです。

VSTSのビルドタスクにはVSTSのLoad Testを呼び出す機能があります。今日はそれを紹介します。

負荷テストプロジェクトを登録する

負荷テストのひな型を入手する

VSTSのCI/CDで負荷テストを実施するにはまずロードテストソリューションを登録します。最初から作ってもいいのですが、せっかくなので、GUIで作ったテストをそのまま使いましょう。

Load Testの結果から"Export test to Visual Studio"をクリックすると、負荷テストのソリューションがzipファイルで入手できます。いつも通り右クリックから「ブロックを解除」(もしくはPowerShellでunblock-fileコマンドレット)してから開きます。

ソリューションを開くとこんな感じで負荷テストの設定が一式入っています。

LoadTestProjectを開くとこんな感じでシナリオやWebテスト、負荷をかけるデータセンターの設定が入っています。特に事情がない限り、変更する必要はありません。

Visual Studioで負荷テスト結果を参照する

ちょっと話がずれますが、負荷テストソリューションを開くと、Visual Studio内にロードテストという項目ができます。

ロードテストメニューの「ロードテストマネージャー」を開くと、VSTSで実施したロードテストの結果が見えます。

調べたい結果をクリックするとVisual Studio内で結果が確認できます。Performance,Throughput, Applicationのログが確認できます。

Throughputもこのように確認できます。Applicationを調べるにはMonitoring Agentが必要なので、App Serviceそのままでは確認できません。

ソリューションを追加する

開いた負荷テストソリューションはもちろんソース管理の対象にできます。ここではチームプロジェクトのGitリポジトリに登録します。

こんな風にWebサイトのプロジェクトと同じリポジトリで管理してみました。負荷テストを設定する都合上、同じチームプロジェクトであれば、異なるリポジトリでもOKです。

VSTS負荷テストをCI/CDで呼び出せるように設定する

VSTSのビルドパイプラインで負荷テストを呼び出せるようにするには、サービスのエンドポイントに登録しなくてはなりません。まずはPersonal Access Tokenを設定します。All scopeで構いません。APIKEYはなくさないようにしましょう。

ServicesからNew Service Endpointをクリックします。Genericをクリックして、以下の指定をします。

• わかりやすい名前
• Server URL:自分のVSTSのホスト名
• User Nameには管理者のアカウント名
• Token Keyには先ほど作ったAPI KEY。

ビルド定義に追加する

簡単なURLテスト

ビルドもしくはReleaseのタスクにCloud-based Web Performance Testを追加するとCI/CDでURLへのアクセステストができます。例えば、デプロイして特定のURLに一定数のユーザーがアクセスしても例外が起きているかどうか、という用途に使えます。

• VS Team Services Connection : Servicesで追加したエンドポインt
• Website Url : アクセスするURL
• Test Name : テスト名
• User Load : ユーザー数
• Run Duration : 実行時間
• Load Location : アクセス元データセンター
• Run load test using : 負荷テストをかけるのを自動管理か自前管理か

ビルドをキューに入れるとこんな感じで結果が出ます。アクセス例外が出なかったので、ビルドが成功したことになっています。

VSTSの負荷テストをビルド時に実施する

次はVSTSの負荷テストと同等のテストを実施します。毎回ビルド時に実施すると時間がかかりすぎるので、工夫が必要になります。

例えば、特定のスケジュールでリリースする前に実施するとか、不定期にブランチを作って、そのブランチを検証用の環境にデプロイしてやってみるとか、といった感じでしょうか。

ビルドタスクを作ってみました。負荷テストソリューションをビルドして、publishしてから、Cloud Load Test タスクを実行します。

• Test settings file:ソリューション内にある拡張子testsettingファイルです。VSTSが作ったものであればCloud.testsettingというファイルです。
• Load test files folder:負荷テストソリューションがあるフォルダ名です。
• Load test file : 負荷テストシナリオを登録しているWeb Performance Testプロジェクトです。VSTSが作ったものであれば「テスト名+WebTest.loadtest」となっています。
• Number of permissible threshold violations : 何回以内の例外であればOKとみなすかという判定です。

ビルドログでは例外が3回だったので、問題ないと判定されます。

ということでビルドも成功しました！

まとめとRelease Managementでの補足

VSTSの負荷テストをCI/CDで実施できるのは定期的に負荷テストをかけたいというシナリオにおいてとても便利です。特に大きな改造をした場合は、ビルドやリリースタスクに追加しておくといいでしょう。

今回リリースでの組み込みは(時間の関係でｗ)実施しませんでしたが、コツとしては変わりありません。

必ずビルド時のartifactsに負荷テストソリューションを追加しておかないと、Release Managementで負荷テスト実施のシナリオが参照できないという点に注意してください。

Visual Studio Team Servicesを使ってWebサイトの負荷を簡単に計測する(17日目)

はじめに

Webサイトをリリースして、著名なメディアに取り上げられるなどの何らかの事情で、突発的にアクセスが増えてダウンした、ということはよくあります。そういうことがなくても、導入の要件で最低アクセス人数を指定されているということもよくあります。

Visual Studioの負荷テスト機能をはじめ、Load Runnerなどの商用製品やjmeterのオープンソースのツールを使うこともあるでしょう。VSTSはクラウドサービスらしく、Azureのデータセンターから負荷をかけるという機能があります。

何度か@ITなどで紹介したこともありますが、さらに進化を遂げています。今日は簡単なURLを指定して負荷をかける機能を紹介します。

URLベースのシナリオを作成する

Load Testをクリックすると、初期画面が表示されます。今日紹介するのはURLとhttp archiveです。

右から二番目にあるURLの下にあるCreate testをクリックすると、シナリオ作成画面になります。

アクセスをかけるURLおよび、httpヘッダ、クエリパラメータを指定します。

こんな風にトップページ、About, ContactのURLを順番にアクセスするというシナリオを作りました。

Settingsで負荷の設定を行います。

• Run duration:負荷をかける時間です
• Load pattern:均等にかける(Constant)、徐々に上げる(step)
• Max vusers:シナリオにおける最大ユーザーです。20000ユーザー/月まで無償で実行できます。ただし、負荷の時間によって、25×実行時間でユーザー数を消費します。ちなみにこのパターンでは250ユーザーを消費します。
• warmup duration:負荷をかけるまでの待機秒数です
• Browser Mix:ChromeとIEのアクセス比率を指定します。
• Load location:どのデータセンターから負荷をかけるかという指定です。東京と大阪も指定できます。

負荷をかけるとこのような結果が表示されます。chartをクリックすると、グラフで表示されます。

性能、スループット、エラー数が表示されます。

Diagnosticsでは発生した例外、情報が表示されます。これはAzure App ServiceのBasic B1で動いているので、CPUが1つです。Basic B2の2CPUに変更して同じ負荷をかけてみます。

数値とグラフも変わっています。

しかし、このような数値だけではわかりづらいですね。そういうときのために設定前後の実行結果を選択して、"Compare two runs"をクリックすると、チューニング前後で比較できます。

baseline(最初に取得したデータ)と現在のデータで比較して、どのくらい負荷が減ったか一目でわかります。

…減ったと言いたいところですが、App Serviceのスケールを変えた後の再起動後の初回起動で性能が悪化してますね(^^;。負荷テストのときはこういうことがあるので、気を付けてください。

ブラウザのリクエストをそのまま使用する

har(HTTP archive)を取得する

負荷テストのリクエストの作成はいつも結構苦労します。fidderでキャプチャして、リクエストを見ながらということが多いのではないでしょうか。

VSTSの負荷テストではブラウザが発行したリクエストを保存して転用する機能があります。

Chromeのf12ツールのネットワークタブでリクエストを右クリックして、「生を付けて保存」すると、該当リクエストをharファイルとして保存できます。

Edgeでも同様にf12開発者ツールで保存できます。

HTTP Archive based testを作成

Newから"HTTP Arvhice based test"をクリックします。

ダイアログが表示されるので、保存したharファイルを指定します。

リクエストが追加されます。追加されるリクエストは外部のCDNなども入っているので、不要なリクエストは消してください。

こんな風に同じリクエストが作れました。http headerとかQueryStringも入るので、便利です。ただし、リクエストごとに保存して追加という手順を踏まないといけないんですかね？この辺は拡張機能か何かあってもよさそうに思いますが…。

自動的にリダイレクトするようなサイトだと難しいかもしれませんが、自分でヘッダやQueryString設定しなくてもいいのは便利だと思いますので、使ってみてください。

Visual Studio Team Servicesで顧客に手軽にフィードバックを入力してもらう(16日目)

はじめに

フィードバックがほしい、とお願いしても、VSTSのWeb UIに不慣れな人ではなかなかチケットを作ってもらうことは難しいです。もう少し気軽にフィードバックするための仕組みとして、VSTS/TFSには専用のフィードバッククライアントが用意されています。

フィードバッククライアントそのものは無償で使えるので(VSTSの接続ユーザーにも入りません)、気軽に試してもらう場合有効です。

フィードバックをお願いする

ダッシュボードの設定

ダッシュボードにあるRequest feedbackというリンクをクリックすればいい…のですが、ダッシュボードに存在しないことがあります。

このような場合、ダッシュボードを編集して、Other Linksというボックスを選択して、Addで追加します。

Other Linksが追加されたので、Request feedbackをクリックして、フィードバックのお願いを開始します。

フィードバック依頼

まず、フィードバックがほしいStakeholder(利害関係者)をSelect Stakeholderで選択します。

次に、試したいアプリケーションの種類を選択します。ここではWeb Applicationを選び、URLを指定します。Stakeholderではクリックすればそのまま開くので、手間がかかりません。

注意してほしいことなどがあれば下に捕捉します。

フィードバックがほしい項目について一つずつ記載します。Add Itemをクリックすると、要求項目が増えます。ここでは2件のフィードバックを依頼しました。

選択した人のところにはこのようなメールが届きます。フィードバッククライアントをインストールしている場合、Start for feedback sessionをクリックすれば始まります。

そうでない場合は、install the feedback toolをクリックします。

こんな風にクライアントが起動するので、インストールしてください。

フィードバック開始

指示内容とURLを確認して、「次へ」をクリックします。

フィードバック依頼項目が二つあるので、１と２を確認します。

項目1のUIについては悪くないので、そのまま「悪くないね」というコメントと、評価(問題なかったので★5)を記載しています。

フィードバックのとき、基本的に問題なければ一番いいレートにしておくと、受け取る側のモチベーションにもつながります。ダメだったらダメでいいのですが、どこがどういう風にダメだったか、あるいは改善してほしいか、ちゃんと書きましょう。

フィードバック項目2ではAbout画面がデフォルトのままだったので、スクリーンショットの添付と、コメント、ダメだったので、★1を付けています。

★1は致命的で、業務上どうしようもないところとかにつけるといいでしょう。

フィードバックの結果が問題なければ、「送信して閉じる」をクリックします。

開発側

フィードバックはWorkのQueriesから確認できます。自分が送ったフィードバックはAssign to meで見えますし、チーム全体のフィードバック項目をみたければ、Shared Queriesにある、feedbackを選べばチーム全体に送られてきたフィードバック項目が全部確認できます。

まとめ

フィードバッククライアントは無償で使えるし、簡単に画面上のここというところを指示できるし、開発側もフィードバックというカテゴリーで一元管理できるのでとても便利だと思います。

ぜひ使ってみてください。

Visual Studio Team ServicesとChromeで未知のバグを発見する(15日目)

はじめに

テストケースだけでバグが検出できればいいのですが、そんな甘いものではなく、何気なく操作しているタイミングで出ることがよくあります。中には「神の手」を持つ方がいて、「この人が操作するときだけ起きる」というある意味素晴らしいバグハンターという方もいらっしゃいます。

特に開発時には無意識によけることもあり、こういうバグはテストケースでは救えません。どうするかといえば、「普段から記録しておけばいいんじゃね？」ということになります。

そういう操作を支援するのが「探索テスト(Exploratory testing)」機能です。ChromeのFeedback & test拡張機能および、Test Managerがサポートしています。

Chrome拡張機能

操作を記録する

Test & Feedback拡張機能を起動して、左端の△をクリックすると記録を開始します。

左端が赤枠の□になると記録開始です。以下の機能があります。

• テスト中(クリックすると停止)
• スクリーンショット
• メモ
• 動画
• VSTS/TFSにタスク/バグ/テストパターンを作成
• 操作タイムラインを見る
• Work Itemにリンクする
• デバイスに接続する
• 設定
• About画面

スクリーンショット＆メモ

画面に対するフィードバックをしたい場合、スクリーンショットを撮って、補足項目を文字入力します。

履歴

操作した履歴やスクリーンショットが確認できます。

作業項目と関連付け

特定の作業項目と関連付けておくことで、探索テストがどの作業に関連しているものかわかりやすくなります。

バグの作成

画面に問題があったので、バグとして登録します。Create bugで新しいバグとして登録します。特定の手順で再現することがわかるバグであれば、Create test caseで新しいテストケースを作れば今後再現テストに役立ちます。

バグ作成時、記録した操作及び、スクリーンショット、レスポンスの時間が全部記録されています(Chromeの機能でとっています)。

VSTSでのバグ確認

作成したバグはチームのバックログに登録されて、すぐに確認できます。

スクリーンショットが添付されているので、迷うことはありません。

添付されているhtmlにはChromeの開発者ツールで見える、応答状態もhtmlとして記録されています。

htmlをダウンロードして開くとこんな感じで確認できます。

Test Managerで探索テスト

Test Managerで起動する

Test Managerを使っても同様のことができます。こちらはどちらかといえばリッチクライアントアプリで探索テストするときに使うといいでしょう。あと、マイクも使えるので、音声で「どんな操作をした」という記録も採取できるのがいい点です。

探索テスト対象のビルドと環境に関連付けます。Test settingsやEnvironmentはSystem Center Virtual Machine Managerと連携した自動テストをするときに用意するので、ローカルテストの場合はデフォルトで構いません。

開始すると、このようなウィンドウが出てきます。タスクバーと同様のウィンドウ領域に影響するウィンドウなので(これは画像編集で小さくしています)、クライアントエリア全体＝フルスクリーンであると仮定するようなアプリはちょっと気を付けてください。

記録が終了するとこのように探索テストの結果が記録されます。

記録の日数について

Testの設定で保持日数の既定値が決まっています。長期間放置すると、VSTSが自動的に消してしまうので、注意しましょう。

まとめ

業務アプリであれば、普段から使って「あれここ変？」というような調査は難しいと思いますが、サービスや日常のアプリであれば、探索的テストを常時実行しておけば、ふとしたときでもバグが発生したときの操作記録が残るため、便利です。

特にChromeの拡張機能はとても便利ですね。VSTS/TFSにつながなくてもキャプチャや記録はとれるので、単独でも使いたい一品です。はやくEdgeやFirefoxにも(ry。