2012-10-22

Jenkins勉強会#6でお話させていただきました。(スピーカー体験編)

「如何でしょうか?」と、お誘いをいただいたのが9月末。
LTでもいいから、いつか『こんなにお世話になってるんです!』という気持ちを伝えたいなあとは思っていたのですが、まさか一枠いただけるとは思っていませんでした…。

勉強会が夜なので、最大の難関は家人の協力を得ること。そして、子どもたち、家族みんなの当日のコンディションが万全であることでした。

幸いにも、家人に了解をもらうことがてきたので、この機会を無駄にしないように精一杯スライドを作ってみました。

#職場の皆様すみません…。この件でずいぶんエネルギー使ってしまってしまいました…。

それにしても、30分もお話するのは初めてでしたので、内容はともかく、お話をするという経験(体験)について書いてみます。
  • 18時会場ではありましたが、わたしの到着は17時45分くらい。川口さんはすでに会場でプロジェクタのチェック済みでした。
  • 川口さんへのご挨拶のあと、最前列に座らせていただき、電源確保、通信手段の確保のあと、プロジェクタ/スクリーンのチェックをしました。
    (時間ギリギリで会場入りして、会場の皆さんの前でスライド数枚を映す..というのは、さすがに恥ずかしかったし、ネタバレも恥ずかしかったので)
  • 恐れていた『スクリーンの縦横比が違っていた (16:9だった)』ということも無く、安心しました。
    ※ この件に関しては、パワポ職人の@tomohnさん(長沢さん)の資料が非常に参考になります
  • USTがあるということで、多分小さすぎて幾つかの図は潰れて見えないだろうと思いました。そのため、事前にスライドをSlideShareにアップして、同時にそちらも見ていただこうと思ったのですが、フォントの関係か、なかなかうまくSlideShareでの変換が出来ませんでした..。
  • 会場内スクリーンについては、後方にもう1つ設置して下さっていたので、そちらの写りもチェックしたところ、スタッフの方も一緒に確認して下さり、表示の微調整をして下さいました。
  • 自分の番になって、UST用のクリップ型マイクを付けて下さいと言われたのですが、うまい位置に付けられず、手間取ってしまいました…。
    結局首元にくっつける形で、みっともない思いをしてしまいました…。
    お話をする時には、胸ポケットのある服か、襟のついたシャツでないとダメですね(^^;
  • 実は、スライドはiPod touch(iPhoneじゃないのです) をリモコン代わりにして操作しようと考えていたのですが、前日に入れたi-Clickrを何度使っても途中のスライドでiPod側のi-Clickrが落ちてしまうので、欲は出さずに講演台でお話をすることにしました。
  • お話については、「もしかしたら時間あまるかな?」と思っていましたし、話す前に、23分でタイマーをセットしたのですが、ラスト1章のところでその時間を使い切っていました…。前半のんびりしすぎてしまったようです..。
残念だったのが、お話の最中に、会場の皆さんの表情とか様子を伺う余裕が持てなかったこと。

スライドのお話をするのが精いっぱいで、どうしても視線が手元のPCと、背後のスクリーンの方に行ってしまいました。(たぶん情けない姿をして話しているのではないかと…)

スライド棒読みではなくて、もっと余裕を持って、会場の皆さんの雰囲気や反応を掴みながらお話が出来るようになりたいなあ…としみじみ思いました。

想いを詰め込み過ぎたので、『継続的プレゼンテーション』はもちろんのこと、『継続的イベント参加』はでき無さそうです(^^;

* * *

備考になりますが….。今回のお話を頂く以前に、たまたま三省堂で目にした下記の本。 この本が、私の 『初めて勉強会で一枠話す』 ことへの不安に立ち向かうための、お守りみたいなものになってくれました。
なお、スライドの作り方や記述方法・話し方に関する本ではなく、プレゼンテーションに臨む際の心構え、不安・トラブルへの対応の仕方について書かれている本です。
  • 困った質問者がいたらどうしよう?
  • 突然PCの調子が悪くなり、スライドが映せなくなったらどうしよう?
  • 会場にほんの少ししか人がいなかったらどうしよう?
  • キャンセルしないといけなくなったらどうしよう?
  • どんな服装が良いだろう?
  • etc…
実際には、幸いトラブルもなく自分の枠をやり過ごすことができました。(時間とか自分の話はさておき…)
会場提供をして下さったNTTデータさまを始めとする、スタッフのみなさま、快適で立派な設備を利用させていただき、本当にありがとうございました!

2012-10-03

Oracle Application Testing Suiteハンズオンセミナー

先月、購読しているニュースレターで、Oracle社のハンズオンセミナーの案内を目にしました。

Oracleでは管理者系の無償セミナー、オンライントレーニングも多いので、そちらの面では以前お世話になりましたが、開発者向け・テストツールのセミナーは初めてです。やはりツールはデモやハンズオンでないとイメージがつかみにくいので、これは良いかも、と思い参加させていただくことにしました。

会場は青山のセンターで、人数は20名ほど。13時半~17時半の午後いっぱいのハンズオンでした。

実は、いつもお迎えの関係で、平日イベント等は17時15分には退出しないといけません。今回もとても面白いところだったのですが、中座する形となってしまい、主催して下さったOracleの方には大変申し訳ありませんでした…。
それでも、十分に『受けて良かった!』と思えるハンズオンでした。講師の方、スタッフの方、本当にありがとうございました!

では、以下レポートを。

* * *

Oracle Application Testing Suiteは、Enterprise Manager製品のうちの1つになります。

かいつまんでいうと、下記のことができます。(認識不足でしたらごめんなさい!)

1. Webアプリケーションの機能テスト/回帰テストの自動化

  1. シナリオに沿ったオペレータのWebからの操作をキャプチャ、解析し、テストコードに落とします。
  2. 落としたテストコードを、パラメータを調整したり、追加のテスト項目を加えたりして簡単に加工できます。
  3. CSVやDBなどのデータを元に、何十件もの機能テスト・回帰テストを自動実行できます。
    (コードを実行すると、Webブラウザが自動で起動し、入力やクリックといった操作を自動で行います)
  4. もちろんコマンドラインからの実行も出来ます。
  5. SoapやFlexのAMFプロトコルにも対応しています。

2. Webアプリケーションの負荷テスト

  1. シナリオに沿ったオペレータのWebからの操作を解析し、テストコードに落とします。
    (単純な負荷テストだと、いくつかの決まったURLを叩いてレスポンスを計測するといったものになりがち。このツールは、ユーザの操作に
    沿ったHTTPリクエストを発生させるコードを自動生成
    し、Javaのコードからリクエストを発生して負荷テストを行います)
  2. Cookieやセッション情報が必要なリクエストも生成できます。
  3. 段階的に負荷をかけていく(5分おきにリクエストを10%ずつ増加させていく)といったテストを実施できます。
  4. テストのソースコードを共有し、複数クライアントから効率的に多数の負荷を書けることができます。
  5. テストクライアントを拠点間に配置し実験することで、どの拠点・ネットワークがボトルネックになっているかもわかります。
  6. 負荷テスト中、対象サーバに対してSSHやSNMPのセッションを張り、サーバ側のCPUやIOといったメトリクスを収集することが出来ます
    この結果、テストの進行状況、結果とサーバ側のメトリクスを同時に時系列でチェックすることが出来ます。

あとは、ソースコード、テスト中のインシデント、不具合改修といった情報を一元管理できる情報共有基盤(コラボツール)としての機能もあります。

(MicrosoftのTFSのような機能?こちらはハンズオンでは紹介程度でした)

自分の社内でも、業務アプリがWebベースというものが少なくないので、これはなかなか良いかなと感じました。

ハンズオンの内容は、下記の通りです。

  1. ツールの紹介
  2. OpenScript(EclipseベースのIDE)を使ったWebの機能・回帰テストの作成
  3. OpenScript(EclipseベースのIDE)を使ったWebの負荷テストの作成

ハンズオン用のPC (Windows7) に、IDEとMedRecというデモ用のWebLogicが起動しており、このデモアプリに対してテストを行う形になっています。

下記に、簡単な図(メモ)をアップしておきます。残念ながらIDEは手元にありませんので、サンプル画面ではなくイラストで。見にくくてすみませんが…。


1. Webアプリケーションの機能テスト/回帰テストの自動化

まずはユーザ(テスター)が自然な流れに沿って入力を実施します。そこからキャプチャ、コードの自動生成をします。

まずはユーザ(テスター)が自然な流れに沿って、ブラウザで入力を実施します。そこからキャプチャ、コードの自動生成をします。

画面遷移するまでを1単位として、操作を記録しスクリーンショットも自動で所得されます。

ツールはEclipseをベースにしたものになっています。生成されるコードはJavaベースなので、Javaのソースコードとしてスクリプトを修正することも出来ます。(GUIでも問題無しです)

機能テストの自動実行

テストコードが生成されたら、条件を加えたり、テストを反復させたい場合のデータソースを指定して、あとは開始ボタンを押すだけ。テストがサクサク進みます!Seleniumでも同じことができますが、ポイントは、データソースを指定すれば、簡単に複数回のテストが自動で実行できる点です。


2. Webアプリケーションの負荷テスト

負荷テストのコード生成

負荷テストも、自然な操作に沿った順番でのリクエストを生成できます。まずはユーザ(テスター)が自然な流れに沿って入力を実施します。そこからコードの自動生成をします。

負荷テスト実施

負荷テストの場合はブラウザからの操作ではなく、JavaのプログラムがHTTPリクエストを生成し、流れに沿ってリクエストを発生させる事になります。

一気に負荷をかけたい場合、クライアント側でリクエストをたくさん発生させたくても、ネットワークインタフェースや帯域による制限で負荷をかけられないケースがあります。この場合は、テストコードをリポジトリに配置し、複数・異なる拠点から分散させて負荷をかけることが出来ます。

サーバの負荷は問題なけれど、ある拠点ではレスポンスが悪い…というパターンがあれば、ネットワーク的な問題を疑うことも出来ます。


3. 負荷テストといっしょにサーバのメトリクス収集・レポート

メトリクス集計

テスト担当者とサーバ管理者はふつう別々で、テスト実施後にログをもらって解析しないといけません…。
Oracle Application Testing Suiteの場合、テストを実行し、その記録をしつつ、ツールから対象サーバ側にSSHやパフォーマンスモニタ、SNMPといった方法でアクセスし、メトリクスを一緒に収集することが出来ます

ここは便利!

OSがLinuxだったらSSHで接続して、vmstatやiostatを実行する、OracleのDBならv$表のデータを収集する…といった定義がすでにあるので、対象OSと収集したいメトリクスを指定すればOKだったりします。

* * *

今回、内容ついていけるか心配だったのですが、前日にたまたまSeleniumを試していたことと、Jenkinsでの自動化にも慣れていたので、特に問題無しでした。

それどころか、負荷テストのコードが自動生成できてメトリクスも併せて収集できるというのは、非常に魅力的に思えました。ツールではありますがコマンドラインでの実行ができるので、Jenkinsと組み合わせて利用するといった例も紹介していただきました。

OracleとJenkinsか…と、なんとなく微妙なものも感じますが、それはさておき、こうなると、やってみたくなりますね。

* * *

また、こうしたツールの事例としては、『テスト』ではなく、『複雑なビジネスロジックを経由しないとデータを登録できないようなシステムに対して、大量のデータを手作業ではなく自動で登録するために使っている』、というようなケースもあるそうです。

私がなんとかうまく利用できないかな~と思っているのが、まさにここ。
ソフトウェア・プロダクト開発の現場が一番進んでいると思いますし、「そんなの当然じゃない!」と言う声が聞かれそうですが、そこから生まれたノウハウは、どこにでも応用できると思っています。

ヒューマンスキルで言えば、アジャイル開発とかスクラムの手法とか。
テクニカルスキルで言えば、テストや自動化の手法とか。

もちろんお値段もそれなりにしますので、実際に使うかどうかは判りませんが、Seleniumやその他のツールを利用して行くヒントにもなりました。

最後に、講師の方いわく、『4回同じことをする可能性があるなら、自動化するメリットがある』と仰っていました。この辺をキーにして、色々考えていけそうな気がしています。


なお、Oracleさまも含め、テストツールベンダがソフトウェアテストの普及のために立ち上げた、NPOの『ソフトウェアテスト技術振興協会』という団体があるそうです。

こちらで、「テストツールまるわかりガイド(入門編)」 (PDF) という資料も紹介していただきました。テスト関係の書籍は色々ありますが、ツールの視点ではあまりないので、わたしののような、ツールから興味を持つというタイプにはとてもいいかもしれません:)