まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:test

ソフトウェア開発時の、特に機能検証テストを意識した開発手法である TDD(Test-Driven Development : テスト駆動開発)をサンプルを含めて紹介します。 一応、自分の業務で使っている手法であり、ブログという形でアウトプットすることで自分の理解を深めることも目的の1つです。向き不向きあることは理解した上で「こういう開発手法もある」と理解してもらえればと。


【TDD とは?】
文字通りの「テスト中心に進めていく開発」手法です。具体的な例は後述しますが、「開発してからテストを考える」のではなく、「テストありきで開発する」というものです。

ここでの「テスト」とは「開発したソフトウェアプログラムが意図した通りに動くことを確認・検証すること」です。作って終わり、だとバグが多く残っていて、酷い場合はまともに動かないケースもあったりするのですが、そういったことがないように開発作業の一部としてテストを行います。テスト結果の評価方法にもよりますが、許容できないと判断された場合はテスト結果を元にプログラムを修正する必要が生じます。

また多くの場合、自動化できることを意識してテストを準備/実行します。自動化されたテストを CI/CD の環境に組み込むことで「テストに通ったものだけがデプロイされる」ことを実現します。

TDD はフロントエンド(UI)/バックエンドに共通した考えですが、個人的には API を中心としたバックエンド開発に向いている手法だと感じています。理由はテスト自体をアプリケーション開発の一部のように(同じプログラミング言語で)開発でき、テストを作ること自体がプログラミングの一部となり、バージョン管理を含めたソースコード管理がしやすくなるためです。またフロントエンドのテストは同一プログラミング言語では難しかったり、別ツールを使う場合は前述のメリットを享受しにくくなると感じています。 といったこともあり、以下はバックエンド開発を前提とした TDD の説明を行います。

TDD のフレームワークはプログラミング言語ごとに多くあります。後述のサンプルではプログラミング言語環境として一般的な Node.js + Express を使う前提で、テストフレームワークには Mocha(mochajs.org) を、またテスト中のアサーションと呼ばれるメソッドを実行するための Chai(chaijs.com) を併用した例を紹介します。


【TDD をサンプルで実践】
今回、以下のような REST API を開発することになった、とします。社内で多く使われるアプリケーションの機能の一部として「ユーザーの登録、検索、更新、削除」が必要で、これらを実現するような REST API を開発することになりました(認証や認可の話は今回の対象外とします):
REST API機能説明
POST /api/userユーザーの登録POST データを使ってユーザーを新規に登録する。既存ユーザーIDが指定されている場合はエラーとする
GET /api/user/{id}ユーザーの検索{id} で示されるIDを持つユーザーを検索する。存在しないIDが指定されている場合はエラーとする
PUT /api/user/{id}ユーザーの更新{id} で示されるIDを持つユーザーの情報を POST データを使って更新する。存在しないIDが指定されている場合はエラーとする
DELETE /api/user/{id}ユーザーの削除{id} で示されるIDを持つユーザーの情報を削除する。存在しないIDが指定されている場合はエラーとする


ユーザー情報自体は id(string) と name(string) だけを持つものとします:
 例: { id: "001", name: "木村桂" }

例えば POST /api/user を実行して id="100", name="K.Kimura" のユーザーを作成する場合のポストデータは以下のような JSON オブジェクト(の文字列)となります:
 例: { id: "100", name: "K.Kimura" }

同じ id="100" の既存データを name="Kei Kimura" に更新する場合は PUT /api/user/100 の REST API を実行し、以下のようなデータを送信します:
 例: { id: "100", name: "Kei Kimura" }

また全ての REST API の結果は HTTP レスポンス本文内に JSON 文字列で返され、結果の JSON オブジェクトには status 属性が付与されます。この status 値が true の場合は成功、false の場合は何らかのエラーが発生しているものとします:
 成功例: { status: true }
 失敗例: { status: false, error: "エラーの詳細・・" }


これらのような仕様の REST API を実装することが目的であるとします(本ブログでは上2つの GET および POST の API 開発に絞って紹介します)。以下では TDD 手法でこれらの API を開発する様子を紹介します。



【TDD 手法による開発手順】
では上述の REST API を TDD 手法を使って開発してみます。まずは検索機能である GET /api/user/{id} の API を作ってみることにします。

TDD では文字通り "Test-Driven" な開発を行っていくことが特徴です。具体的にはいきなり API の開発に取り掛かるのではなく、最初に「これから作るもののあるべき挙動」を考え、その内容をテストケースとしてプログラムに記述します。まずは GET /api/user/{id} のあるべき挙動を考えることにしましょう。

この API は id を指定して、その指定された id を持つユーザーが登録されていたら status=true でユーザー情報を返す、指定された id を持つユーザーが登録されていなかったらエラー扱いとして status=false でエラー情報を返す、という挙動になるはずです。

例えば既に id="001" というユーザーが登録済みで id="100" というユーザーは登録されていなかった場合のそれぞれの挙動としては、以下の (1), (2) のようになるはずです:
(1) GET /api/user/001 → 成功する(status=true の結果が返る)はず
(2) GET /api/user/100 → 失敗する(status=false の結果が返る)はず


この (1), (2) それぞれの実行とその予想される結果をまずテストとして記述します。 その次に該当の API を開発し、完成したら最初に記述したテストを実行して期待通りの結果になるかどうかを検証します。これが TDD による開発の基本的な流れとなります。


【TDD の準備】
上述の順序に従って実際の開発を行うのですが、その前に各種フレームワークの準備となる作業を紹介しておきます。

TDD による開発をはじめる直前までを実装したプロジェクトをこちらに用意しておきました:
https://github.com/dotnsf/tdd-sample.git


git clone するか、ダウンロード&展開してプロジェクトを展開します。またこの後すぐにテストが実行できるように必要なライブラリをインストールしておきます:
$ npm install


まずは package.json ファイルの説明をしておきます:
{
    "name": "tdd-sample",
    "version": "0.0.1",
    "scripts": {
        "start": "node app.js",
        "lint": "eslint",
        "test": "mocha --exit **/*.spec.js"
    },
    "dependencies": {
        "body-parser": "1.17.x",
        "cf-deployment-tracker-client": "^0.1.4",
        "express": "4.17.x"
    },
    "repository": {},
    "engines": {
        "node": "8.x"
    },
    "devDependencies": {
        "chai": "^4.2.0",
        "eslint": "^6.8.0",
        "mocha": "^7.0.0",
        "supertest": "^4.0.2"
    }
}

TDD に関わる部分を青字にしておきました。まず dependencies に cf-deployment-tracker-client モジュールを、devDependencies に chai, mocha, supertest モジュールを追加しています。これらを使ってテストを記述および実装します。 また scripts の中で "test": "mocha --exit **/*.spec.js" という要素を記述していますが、これは「**.js というファイル向けのテストが **.spec.js というファイルに記述されていて、これを実行して npm test コマンドでテストする」ことを宣言しています。

実際のソースコードに関わるファイルは app.js と routes/users.js の2つです。app.js には Express を使って HTTP サーバーとして稼働するための最小限のコードが書かれています:
//. app.js
var express = require( 'express' ),
    app = express();
var users = require( './routes/users' );

//. ユーザー関連 API を /api/user 以下にルーティング
app.use( '/api/user', users );

//. ポート番号を決めて起動
var port = process.env.port || 8080;
app.listen( port );
console.log( "server stating on " + port + " ..." );

最小限のコードに青字で書かれた部分が追加されています。青字部分は routes/users.js ファイルを読みこみ、その中に書かれている内容を使って /api/user 以下へのリクエストのルーティングを処理する、という定義になっています。端的に言うと今回テストしようとしているユーザー登録関連 API の中身が routes/users.js に書かれている、という定義をしていることになります。

そしてその routes/users.js ファイルの中身が以下のなります:
//. users.js
var express = require( 'express' ),
    bodyParser = require( 'body-parser' ),
    router = express.Router();

//. ポストデータを JSON で受け取る
router.use( bodyParser.urlencoded( { extended: true } ) );
router.use( bodyParser.json() );

//. 検索 API : GET /api/user/:id
router.get( '/:id', function( req, res ){
});

//. 新規作成 API : POST /api/user
router.post( '/', function( req, res ){
});

module.exports = router;

この中では '/:id' への GET リクエスト(GET /api/user/:id)と '/' への POST リクエスト(POST /api/user)へのハンドラが定義されています(中身がないので、このまま実行してもエラーになります)。本来は PUT や DELETE についてもここで記述するべきですが、本ブログではこの2つまでを TDD で開発する様子を紹介するので、この2つを記載しておきました。続きを自分で作る場合は是非追加してチャレンジしてみてください。


【テストケースの実装】
では実際に TDD を使って開発作業の続きを行っていきます。API そのものは routes/users.js の中身(route.get ハンドラと route.post ハンドラの中身)を書いて実装していくことになるのですが、前述のように TDD ではテストケースを先に定義します。上記の緑で書いた (1), (2) のテストケースを先に作って、その後で routes/users.js を作っていく、という順序になります。

ではまずはテストケースを用意します。users.js のテストケースは users.spec.js に作る、という宣言をしているので、routes/users.spec.js というファイルを以下の内容で新規に作成します:
//. users.spec.js
var request = require( 'supertest' ),
    chai = require( 'chai' ),
    app = require( '../app' );

chai.should();

/* (1) のテスト */
describe( 'GET /api/user/001', function(){
  it( 'should return user object', async function(){
    var result = await request( app ).get( '/api/user/001' );
    result.statusCode.should.equal( 200 );
    result.body.status.should.equal( true );
  });
});

/* (2) のテスト */
describe( 'GET /api/user/100', function(){
  it( 'should return 404 for non-existing user', async function(){
    var result = await request( app ).get( '/api/user/100' );
    result.statusCode.should.equal( 404 );
    result.body.status.should.equal( false );
  });
});

特に緑で記述した部分で実際にテストを行っています。ここでの記述方法についての詳細は別途参照いただきたいのですが、実際にテストしたい内容と照らし合わせてなんとなく理解できるのではないかと思っています。(1) のテストでは(id="001" というユーザーが存在している前提で) GET /api/user/001 という API を実行し、その結果はステータスコードが 200 で、実行結果の JSON に { status: true, .. } という要素が含まれていることを確認してテスト成功とみなす、という内容を記述しています。 また (2) のテストでは(id="100" というユーザーが存在していない前提で) GET /api/user/100 という API を実行し、その結果はステータスコードが 404 で、実行結果の JSON に { status: false, .. } という要素が含まれていることを確認してテスト成功とみなす、としています。GET /api/user/{id} の API が正しく動いていればこうなるはず、という仕様を JavaScript で記述した例だと思ってください。

このテストケースを用意した上で実際の API を開発します。実際の API は routes/users.js ファイルの router.get( '/:id', ... で始まるハンドラーの中身として記述していきます。今回は以下のような内容の routes/users.js にしました(元のファイルに追加した部分をで記載しています):
//. users.js
var express = require( 'express' ),
    bodyParser = require( 'body-parser' ),
    router = express.Router();

//. ポストデータを JSON で受け取る
router.use( bodyParser.urlencoded( { extended: true } ) );
router.use( bodyParser.json() );

//. 本来は RDB などに格納するべき情報だが、この例では配列変数を使って簡易的に保存する
var users = [
  { id: "001", name: "K.Kimura" },
  { id: "002", name: "dotnsf" }
];

//. 検索 : GET /api/user/:id
router.get( '/:id', function( req, res ){
  var id = req.params.id;
  if( id ){
    var user = findOne( id );
    if( !user ){
      return res.status( 404 ).json( { status: false, error: 'user with id ' + id + ' not existed.' } );
    }else{
      return res.json( { status: true, user: user } );
    }
  }else{
    return res.status( 404 ).json( { status: false, error: 'parameter id required.' } );
  }
});

//. 新規作成 : POST /api/user
router.post( '/', function( req, res ){
});

//. id からユーザーを検索して返す
function findOne( id ){
  var u = null; //. 見つからない場合は null を返す
  users.forEach( function( user ){
    if( user.id == id ){
      u = user;
    }
  });

  return u;
}

module.exports = router;

まずこの API で扱うユーザー情報ですが、本来はデータベース等に格納したり、そこから取り出して取得するものだと理解しています。もちろん実際にそのように記述してもいいのですが、今回は TDD の解説を主目的としており、直接関係ない部分でコードを複雑化することは目的ではないため、この部分を簡易的に実装することにしました。具体的には上述のようにコード内に users という配列変数を用意し、この変数の中にユーザー情報が格納されていて、必要に応じて追加・更新・削除ができるような形で API を実装しています(この仕様によりアプリケーションを再起動するたびに中身は初期化されます)。またテストは id="001" のユーザーは存在していて、id="100" のユーザーは存在していない前提で実施されるため、id="001" のユーザーははじめから作っておくことにしました(同じ理由で id="100" のユーザーは作らないようにしてください)。

その上で router.get( '/:id', ... で始まるハンドラーの中身を API の実装として記述しています。まず URL の一部として指定される id の値を取得し、その値を id として持つユーザーを(findOne 関数で)検索し、null でないオブジェクトが返ってきたら、その結果を実行結果として { status: true, user: (実行結果) } の形で返すようにしています(特に指定していない時のステータスコードは 200 です)。指定した id のユーザーが存在しなかったり、id が指定されていなかった場合はステータスコード 404 を返しつつ、{ status: false, error: (エラーの原因) } という結果を返すようにしました。これで GET /api/user/{id} の実装例としては最低限動くものが作れました。

この後は実際にテストを実行するのですが、その前に app.js にも一箇所変更の必要があります。テスト時にはアプリケーション本体である app.js が実行された上でテストケースを確認することになります。この作業を効率的に行うために app.js をテストケースから呼び出して実行できるように最後に数行コードを追加します(赤字部分を追加):
//. app.js
var express = require( 'express' ),
    app = express();
var users = require( './routes/users' );

//. ユーザー関連 API を /api/user 以下にルーティング
app.use( '/api/user', users );

//. ポート番号を決めて起動
var port = process.env.port || 8080;
app.listen( port );
console.log( "server stating on " + port + " ..." );

//. テスト用に app 全体をエクスポート
require('cf-deployment-tracker-client').track();
module.exports = app;

【テストの実行】
ではテストケースと API 両方の準備ができたので、実際にテストを実行してみます。package.json 内にテスト用の scripts が用意されているので "npm test" コマンドを実行することで *.spec.js というファイルを見つけて *.js のテストを行います(青字部分がテスト結果です。またこの段階のプロジェクトでは routes/users.spec.js というファイルを見つけて、routes/users.js ファイルのテストだけが行われますが、ファイルが増えても同様のコマンドでまとめてテストできます):
$ npm test

    :

server stating on 8080 ...


  GET /api/user/001
    ✓ should return user object

  GET /api/user/100
    ✓ should return 404 for non-existing user


  2 passing (53ms)

この結果にはテストファイル(routes/users.spec.js)内の describe 関数で書かれた実行内容と、it 関数で書かれた期待結果が2つずつ表示され(つまり2つのテストが実施され)、どちらも pass したことを意味しています。つまり用意したテストに耐えうる API が開発できた、ということになります。

ちなみにわざとエラーを起こすようなテストケース(実在する id="002" のユーザーが見つからない想定)を用意して実行すると次のような結果になり、テストに通らなかったことがわかります:
npm test

    :

server stating on 8080 ...


  GET /api/user/001
    ✓ should return user object (40ms)

  GET /api/user/002
    1) should return 404 for non-existing user


  1 passing (82ms)
  1 failing

  1) GET /api/user/002
       should return 404 for non-existing user:

      AssertionError: expected 200 to equal 404
      + expected - actual

      -200
      +404

      at Context. (routes/users.spec.js:21:30)
      at 
      at process._tickCallback (internal/process/next_tick.js:189:7)



npm ERR! Test failed.  See above for more details.

【API の拡張とテストの再実行】
一応、ここまでの手順で最小限度の TDD が体験できているのですが、少しだけプラスアルファの要素を含めてみます。先程は GET (検索)の API を作ったので、続いて POST (新規作成)の API も TDD で開発してみます。

GET の時と同様にして、まずは POST API の仕様を考え、その仕様をもとにテストケースを考えます。先程作成済みの GET API とそのテストケースを使って、今回は以下のような挙動になるべきである、と考えたとします:
((2) で id="100" のユーザーが存在していないことを確認しているので、ここに続けて)
(3) POST /api/user/100 → 成功する(status=true の結果が返る)はず
(4) GET /api/user/100 → 成功する(status=true の結果が返る)はず

つまり (2) で id="100" のユーザーが存在していないことを確認した上で、(3) で id="100" のユーザーを作成し、(4) で (2) と全く同じテストを実行して今度はユーザーが見つかる、という挙動になることをテストで確認することにします。

この仕様のため、routes/users.spec.js を以下のように変更します(書き加えた部分を赤字で示しています):
//. users.spec.js
var request = require( 'supertest' ),
    chai = require( 'chai' ),
    app = require( '../app' );

chai.should();

/* (1) のテスト */
describe( 'GET /api/user/001', function(){
  it( 'should return user object', async function(){
    var result = await request( app ).get( '/api/user/001' );
    result.statusCode.should.equal( 200 );
    result.body.status.should.equal( true );
  });
});

/* (2) のテスト */
describe( 'GET /api/user/100', function(){
  it( 'should return 404 for non-existing user', async function(){
    var result = await request( app ).get( '/api/user/100' );
    result.statusCode.should.equal( 404 );
    result.body.status.should.equal( false );
  });
});

/* (3) のテスト */
describe( 'POST /api/user', function(){
  it( 'should create user object', async function(){
    var result = await request( app ).post( '/api/user' )
      .send( { id: '100', name: 'Linux' } );
    result.statusCode.should.equal( 200 );
    result.body.status.should.equal( true );
  });
});

/* (4) のテスト((2) と全く同じ内容で結果が異なるはず) */
describe( 'GET /api/user/100', function(){
  it( 'should return user object', async function(){
    var result = await request( app ).get( '/api/user/100' );
    result.statusCode.should.equal( 200 );
    result.body.status.should.equal( true );
  });
});

このテストケースを満たすように POST の API を開発していきます(場合によっては GET API にも手を加えていきます)。今回はポストされたデータから id を取り出し、既存ユーザーが存在していないことを確認した上で users 変数に push するだけの実装にしてみました:
//. users.js
var express = require( 'express' ),
    bodyParser = require( 'body-parser' ),
    router = express.Router();

//. ポストデータを JSON で受け取る
router.use( bodyParser.urlencoded( { extended: true } ) );
router.use( bodyParser.json() );

//. 本来は RDB などに格納するべき情報だが、この例では配列変数を使って簡易的に保存する
var users = [
  { id: "001", name: "K.Kimura" },
  { id: "002", name: "dotnsf" }
];

//. 検索 : GET /api/user/:id
router.get( '/:id', function( req, res ){
  var id = req.params.id;
  if( id ){
    var user = findOne( id );
    if( !user ){
      return res.status( 404 ).json( { status: false, error: 'user with id ' + id + ' not existed.' } );
    }else{
      return res.json( { status: true, user: user } );
    }
  }else{
    return res.status( 404 ).json( { status: false, error: 'parameter id required.' } );
  }
});

//. 新規作成 : POST /api/user
router.post( '/', function( req, res ){
  var id = req.body.id;
  if( id ){
    var user = findOne( id );
    if( user ){
      return res.status( 400 ).json( { status: false, error: 'user with id ' + id + ' already existed.' } );
    }else{
      users.push( req.body );
      return res.json( { status: true } );
    }
  }else{
    return res.status( 400 ).json( { status: false, error: 'parameter id required.' } );
  }
});

//. id からユーザーを検索して返す
function findOne( id ){
  var u = null; //. 見つからない場合は null を返す
  users.forEach( function( user ){
    if( user.id == id ){
      u = user;
    }
  });

  return u;
}

module.exports = router;

そして開発したコードをテストし、全てのテストコードが期待通りに動くことを確認します:
$ npm test

    :

server stating on 8080 ...


  GET /api/user/001
    ✓ should return user object (49ms)

  GET /api/user/100
    ✓ should return 404 for non-existing user

  POST /api/user
    ✓ should create user object (120ms)

  GET /api/user/100
    ✓ should return user object


  4 passing (203ms)

動きました!これで POST の API も開発できました。 以降、同様にして PUT(更新)や DELETE(削除)の API も、まず仕様を決めて、その仕様が満たすべきテストケースを考えて routes/users.spec.js に記述してから routes/users.js で API を開発してテスト、、、を繰り返す形で開発を進めていきます。これが TDD の典型的な開発手順となります。


【TDD への印象】
上でも少し触れていますが、この TDD という開発手法に対する自分の印象を記載しておきます。

まず開発体制が開発者とテスターとにきっちりと別れていないような場合(開発者=テスターの場合)であっても、この方法であれば、ある程度は客観的なテストが成立すると考えています。開発したものに対して、開発者がテストケースを考えるとどうしても漏れが出てしまったり、そもそも同一者によるテストを信用していいかどうかの問題も出てきます。その点 TDD では開発する前にテストケースを考えることで、同一者であってもある程度客観性が担保されたテストが可能になります。

また開発者とテスターが別れているケースでもメリットはあります。テスターを「開発トレーニングの一環」として考える場合、テスターもプログラミングによってテストを記述することになり、開発環境の構築や開発、デバッグの経験を積むことができるようになります。

一方で、特にこの手法の場合は REST API 開発のテストには向いていると思うのですが、フロントエンド側のテストを行うことが難しくなります。フロントエンドの HTML を取得して、その中身を解析して正誤を判断する、ことができないことはないと思いますが、そこまでのテストケースを作ることが大きな開発内容となってしまい、テストケースそのものが正しく作られているかどうかの問題も出てきてしまうと考えました。どうしてもバックエンド(REST API)向けのテストだと感じています。



IBM Bluemix のサードパーティサービスの1つである Load Impact を紹介します:
2015092400


このサービスは単純にウェブサイト/ウェブサービスに負荷をかけて、その時のパフォーマンスを測定するサービスです。負荷をかける対象は Bluemix 上のランタイムでも、そうでなくても構いません。


Load Impact サービスは Bluemix 上では "DevOps" カテゴリに分類されています。このサービスは特定のランタイムにバインドして利用するものではないので、カタログページから直接選択して追加することで利用可能になります:
2015092401


Load Impact サービスの説明ページです。"Free"(無料)利用の条件が表示されているので確認して追加してください:
2015092402


Load Impact サービスを追加した後、ダッシュボード画面から追加した Load Impact サービスを選択すると、このような画面が表示されます。"OPEN LOAD IMPACT DASHBOAD" と書かれた箇所をクリックして、Load Impact のダッシュボード画面に移行します:
2015092403


サービスを利用するには最初にログインする必要があります。ここでは新規にアカウントを作成することもできますし、既にアカウントをお持ちであればそれを指定することもできますし、また Google や Github といったソーシャルサイトのアカウントをお持ちであればそれらとの OAuth を使ってログインすることもできます。お好きな方法でログインしてください:
2015092404


ログイン直後にこのような画面が表示されるはずです。この画面をスキップして詳細なテスト設定を行うこともできますが、まずはこの簡易機能を使ってテストしてみましょう:
2015092405


今回、テストする対象はこちらのサイトとします(皆さんがお作りになったサービスを指定しても構いませんが、他の方が作ったウェブサイトの URL を勝手に指定することはご迷惑をかけることになりかねないので控えてください):
http://fx.mybluemix.net/
2015092406


このサービスは先日、私が作って紹介したリアルタイム為替情報の REST API サービスです。IBM Bluemix 上で動いています。一般的には「ウェブサイト/サービスはリクエストからレスポンスまで2秒待つと、ユーザーは長く感じる」と言われているので、レスポンスタイムが2秒を確保できているかどうかをテストしてみたいと思います。また最大同時接続ユーザー数は30を想定します(つまり30ユーザーが同時にアクセスしてきても、このサービスは2秒以内にレスポンスを返せるか?をテストで計測する指標とします)。

では、このサービスの URL(http://fx.mybluemix.net/) を URL フィールドに入力します。同時に最大接続ユーザー数(Max VUs)を "30" に、Duration(mins) を "3" にします(つまり3分間で30ユーザーのテストをする、という指定をします)。最後に "Run test" と書かれたボタンをクリックして、テストを開始します。作業はこれだけ、簡単ですね:
2015092407


しばらくするとテストが始まります。最初に同時接続(仮想)ユーザーの準備を行います:
2015092401


テストが始まると、このサービスを提供している場所(バージニア州 Ashburn)から、目的のサーバー(下図ではテキサス州 Dallas)までの地図が表示されます。このレイテンシーがテスト結果に影響することを考慮してください:
2015092402


またテスト途中までの結果も順次表示されていきます。少しずつ接続ユーザー(青)を増やしながら、それぞれの回でどれくらいのレスポンスを実現できたのか(緑)が分かります:
2015092403


今回の設定ではテスト開始から3分後に最大接続ユーザーのテストが行われ、その後少しずつユーザーを減らしてテストが終了します。終了すると左上に "Finished" と表示されます:
2015092404


画面を下にスクロールすると、最終テスト結果がグラフ表示されています。一瞬危ういテスト回もありましたが、どうやらこのサービスは30ユーザー程度であれば、2秒どころか1秒以内にレスポンスを返せることがわかりました。リアルタイム性を重視するサービスなので、これは一応合格だと思います。さすが Bluemix 、という所?
2015092405


更に下にスクロールすると、更に細かなテスト結果も表示されています。ほぼ何の準備もせずに、URL と最大接続ユーザー数の指定をしただけで、このレベルの負荷テストが実現できた、ということがわかります:
2015092406


Load Impact はもっと細かなテスト項目の指定などもできますが、そこまでしなくてもある程度の負荷テストが実現できるツールです。Bluemix のようにアジャイルに機能を追加してアプリケーションを開発できる環境ですと、ついつい変更による負荷の影響を忘れがちになってしまいますが、そのようなことがないように Load Impact サービスを1つアクティブにしておくといいかもしれません。


Apache jMeter を使ったウェブサイトの負荷テストの手順を一通り紹介します。


今回の紹介するシナリオでは、以下の目的および前提でテストを行います:
(1) ウェブサイトは(一応)完成している
(2) ユーザーの想定挙動(「トップページを見て、検索をして、検索結果ページをいくつか閲覧して、・・」という導線)は決まっている
(3) 1つのページあたりのユーザーレスポンスタイム(ユーザーがそのページを開き始めてから反応が返り切るまでの時間)を3秒以内にしたい
(4) この条件で、1秒あたりに何ユーザーのアクセスまで耐えられるシステムなのかを測定したい

アプリケーションのテストには色々な種類がありますが、今回は上記のように「どれだけのユーザーアクセスにまでは耐えうるシステムなのか」を検証するテストを行います。そしてそのようなテストではこの Apache jMeter は便利です。


まずは Apache jMeter をインストールします。jMeter は Pure Java アプリケーションのため、前提として Java の実行環境が必要になります。JRE または JDK を導入して、実行可能な状態にしておいてください。その上で公式サイトから Apache jMeter の最新版バイナリをダウンロードし、展開します。展開後、jMeter の起動ファイル(Windows であれば bin/jmeter.bat)を実行して、jMeter を起動します:
2014102701


次に、このテスト計画にスレッドグループを追加するのですが、その前に今回のテスト目的をおさらいします。一覧のページビューにおいて、そのユーザーレスポンスタイムを3秒(この数字は変更しても構いません)以内にする前提で、1秒あたりに何ユーザーのアクセスまで耐えられるシステムなのかを測定したい、というものでした。 

というわけで、今回のテストでは、あるユーザーシナリオを元に、最初は1ユーザーで実行、次に2ユーザー同時に実行、その次は3ユーザー同時に、、、、と少しずつユーザー数を増やしていきながら、(例えば)20ユーザー同時にアクセスするところまでを実行して、それぞれのページビューアクションでのレスポンスタイムを計測する、という流れになります。そして(今回の場合であれば)3秒以内のレスポンスを期待できるのは何ユーザー程度の同時アクセスまでか、を調べることになります。

つまり今回のテストでは最初は1ユーザーでアクセスし、1分後に1ユーザー増やして2ユーザーでアクセス、更に1分後に1ユーザー増やして3ユーザーでアクセス、、、といった具合に1分ごとにユーザー数(ユーザースレッド)を増やして負荷を加えていきます。そして開始から19分後に20ユーザーでの同時アクセスとなり、ここでのレスポンスタイムを計測して終了、というテストを行います。 なお、1ユーザー増やすタイミングを1分後にする必要はありませんが、後から結果を確認しやすい(開始から何分経過したかで何ユーザーでのアクセスかを推測できる)のでこのようなテストシナリオにしています。

ではこのテストシナリオに従ってスレッドグループを定義します。jMeter の「テスト計画」と書かれた箇所を右クリックして、 追加 > Threads(Users) > スレッドグループ を選択します:
2014102702


テスト契約の下にスレッドグループが追加されます。これをクリックして選択し、以下の内容を入力します:
 スレッド数: 20
 Ramp-Up期間(秒): 1200
 ループ回数: 無限ループ
2014102703


スレッド数はユーザー数です、なので20。Ramp-Up はこの20スレッドをどれだけの時間かけて生成するか、という期間の数字です。今回は1分毎に1スレッドずつ、20スレッドまで増やしていくので 60 x 20 = 1200(秒)を指定します。そして各スレッドは無限に処理を繰り返し実行してほしいので、ループ回数は「無限ループ」を指定しています。

次に、各ユーザースレッドで実行する内容を定義します。「スレッドグループ」を右クリックして、 追加 > サンプラー > HTTPリクエスト を選択します。
2014102704


HTTP リクエストが追加されたら、その中身を実際のテストシナリオに合わせて変更します:
 名前: 何のアクションが分かる名前に変更(どのアクションに時間がかかっているのかを区別できるように)
 サーバー名: テスト先アプリケーションサーバー
 ポート番号: テスト先アプリケーションサーバーのポート番号(80の場合は省略可)
 パス: アクセスする URL のサーバー名以降の部分
2014102705


HTTP リクエスト1つがユーザーの1回のアクセスを定義します。「このページを見て、次にこのページを見て、その次にこのページを見て、・・」のように複数のページを巡回するシナリオで計測する場合は、必要なだけこの HTTP リクエストをスレッドグループに追加していきます。この例では4つのページを巡回するシナリオを定義しています:
2014102706


テストシナリオの定義はこれで終わりです。最後に結果を一覧表で確認できるようにします。スレッドグループを右クリックして 追加 > リスナー > 結果を表で表示 を選択します:
2014102708


これで最小限必要な設定ができたので、メニューから ファイル > テスト計画を保存 を選択して、このテスト計画を保存します。

テストの実行はメニューから 実行 > 開始 を選択するだけです。実行中に「結果を表で表示」をクリックすると、次々に実行されるテストの結果を参照することができます:
2014102707

この "Sample Time(ms)" 列が各アクションのレスポンスタイムになります。スレッドが増えていった時にこの数値がどのように増えていくのかを参照することで(今回の例であれば3秒以内に収まっているかどうかを確認することで「どの程度の同時アクセス数までは期待通りのパフォーマンスを維持できているか」を調査していくことになります。












 

このページのトップヘ