うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

Webアプリケーションのパフォーマンステストを勉強する方法 #SWTestAdvent

Testing
").prependTo(".entry-content"); } //スクロールを滑らかにする $('.sectionList a').on("click", function() { $('html,body').animate({scrollTop: $(this.hash).offset().top}, 600); return false; }); });

はじめに

これはソフトウェアテストあどべんとかれんだー 2014 の14日目の記事です。

明日は id:kokotatata さんです。

概要

パフォーマンステストを入門するための情報を紹介します。発端は@ryushi さんが次の記事でなにやら不思議な言及をされていたというところです。

正直に申し上げて負荷テストって恐ろしく難しい種類のテストなんですけども、特にその難しさについては書いていませんので、きっと名古屋辺りのうさぎさんが補足資料を提示してくれるでしょう。よろしくお願いします。

注意

ここにあるのはkyon_mmの私見です。なので、「なに、こいつ大げさだな。。。」とか思ったらコメントで「それはお前が勉強不足だからで、世のエンジニアの感覚と違います」とか書いてください。温度感重要です。

参考書籍

基本的にはこれらを読めばいいのかなと思っています。この記事で書くのはこれらで言っていることや僕が考えていることのまとめです。個人的なパフォーマンステストに対する感覚を言うと次がわかりやすいとは思う。

パフォーマンステストはテストエンジニアのパフォーマンスを計測していて、Javaを読んでいたらアセンブラを読んでいるときがあるし、ASP.NETのパフォーマンステスト本は1100ページを超える。ASP.NETのパフォーマンステストだけで。

書籍というかPDF(とWiki形式)なんだけど、次の2つがよかった。

少々古めかしい内容も含まれていてもいろいろ読んでみたいという人はこちらで紹介されているやつにも目を通すといいと思います。

Performance & Software Testing Articles, Columns and Papers -- PerfTestPlus

"最低限数千ページくらいの実行環境に関する知識の上に対象プロダクトに関する知識がないと出来ないテストの世界"。それがパフォーマンステストだと思っています。なので、パフォーマンステストが得意な人には本当に頭がさがる。まぁどの程度までパフォーマンステストを見るかっていう話はあると思うんだけど。

日本語だと次があるんですけど、あまり役に立ちませんでした。

アート・オブ・アプリケーション パフォーマンステスト (Theory in practice)

アート・オブ・アプリケーション パフォーマンステスト (Theory in practice)

パフォーマンステストとはなにか

パフォーマンステストは少なくとも次の3つを達成するためのテストと言えます。

  • 「性能要求に達しているのか評価する」
  • 「システムオブシステムズのボトルネックを明らかにする」
  • 「チューニングの手助けをする」

これらを達成するために数種類のテストがあります。ボリュームテストとかストレステストとかロードテストとか。僕が読んできた書籍ではこれらの総称として「パフォーマンステスト」と説明することが多いように思います。 簡単に言うと「性能に関するテスト」のサブカテゴリに「何に対する性能を見るのか」というものが存在していて、それらに「キャパシティ」とか「ストレス」とかあるって感じです。

  • パフォーマンステスト
    • ストレステスト
    • ロードテスト
    • キャパシティ

パフォーマンステストの手順

先に紹介したPerformance Testing Guidance for Web Applicationsでは、次のように定義しています。

  1. Identify the Test Environment. : テスト環境の特定
  2. Identify Performance Acceptance Criteria. : パフォーマンス受け入れ条件の特定
  3. Plan and Design Tests. : テスト計画とテスト設計
  4. Configure the Test Environment. : テスト環境設定
  5. Implement the Test Design. : テスト実装
  6. Execute the Test. : テスト実行
  7. Analyze Results, Report, and Retest. : 結果の分析、報告、再テスト

極々当たり前ですが、僕としては1,2,7がめっちゃ難しいです。おそらく機能性テストと違ってパフォーマンステストでは「ボトルネックになっているのが「プロダクト」なのか「テスト」なのか「自分たち以外」なのかを正確に判別しながら、設計する必要がある」というのが難しいのだと思います。慣れや知識の問題もあると思うのですが、自分が暗黙に抽象化して扱っているものをいかに明らかにするかの世界です。そしてぶちあたるのが「アンドキュメンテッドな仕様」や「OSSではないもの」との戦いであったり、「再現不可能に対して物量で殴る」という感じです。

目標を達成するための試行錯誤と学習に多くの時間を費やすことになりがちですので、日々少しずつやることをオススメします。僕はプロジェクト末期にやって、死にかけたことがあります。

イテレーティブな手順としてPerformance Testing Guidance for Web Applicationsでは次のように定義しています。

  1. Understand the Project Vision and Context.
  2. Identify Reasons for Testing Performance.
  3. Identify the Value Performance Testing Adds to the Project.
  4. Configure the Test Environment.
  5. Identify and Coordinate Tasks.
  6. Execute Task(s).
  7. Analyze Results and Report.
  8. Revisit Activities 1-3 and Consider Performance Acceptance Criteria.
  9. Reprioritize Tasks.

僕の経験談

僕がつらいのはだいたい次の3つです。

  • GCとメモリモデルについて知らなくて詰んだ。
    • だけどGCを制御するの難しくって更に泥沼。
  • HTTPã‚„FileなどのIOが絡むモジュールはハードウェアをどうやって使っているのか知らなくって詰んだ。
  • クラウドサービスの曖昧なネットワークは信用ならない。

ただ、パフォーマンステストをするとめっちゃ勉強になるのでいいと思います！