この連載は、WebアプリケーションのテストツールであるSelenium（セレニウム）についてサンプルを用いながら概要と基本的な使い方を解説していきます。本連載第1回の今回は、Seleniumの概要について紹介します。 Seleniumとは、Webブラウザを使ってWebアプリケーションをテストするツールです。この「Webブラウザを使って」というのが非常に大きなポイントで、人が手でWebブラウザを操作する代わりにSeleniumがWebブラウザを操作してくれるのです。 そして単純に操作するだけでなく、例えばエラーメッセージが正しく表示されているかといった検証も行うことができます。つまり、今まで人手を必要としていたWebブラウザを使った試験が自動化できるものなのです。そのため数百項目もあるテストも、クリック1回で実施できます。 より重要なことは「自動化することによって試験を繰返し実施できる」こと

Ajax を 使った手書き文字認識です。下のキャンバスにマウスで文字を描いてみてください。 デモ

Selenium automates browsers. That's it!What you do with that power is entirely up to you. Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should) also be automated as well. Selenium WebDriver If you want to create robust, browser-based regression automation suites and tests, scale and di

Actionコマンドは、アプリケーションの状態を一般に操作するものです。Actionコマンドは「このリンクをクリックする」とか「あのオプションを選択する」といった動作を行います。動作に失敗するか、エラーが発生した場合は、現在実行中のテストは中止されます。 多くのActionコマンドは"AndWait"サフィックスを付けることができます(例えば"clickAndWait")。このサフィックスはSeleniumに対して、コマンドを実行してサーバへの通信が行われた後に新しいページがロードされるのを待つように指示するものです。 Accessorコマンドは、アプリケーションの状態を検査して結果を変数に保存します(例："storeTitle")。また、自動的にAssertionコマンドを生成します。 Assertionコマンドは、Accessorコマンドと似ていますが、こちらはアプリケーションの状態

「このままではＷ杯メンバーに入れない」 前半は悪くなかった。後半の１失点目は自分たちのミスから入れられた。２点目も自分がボールとかぶっていたと思う。味方選手がボールを回しているときに、動き出しを増やしていかないといけない。憲剛さんからいいパスが来た場面では、足の先に当たってしまった。冷静さが足りなかったと思う。あそこでゴールを決めていたら、その後の失点もなかった。後半の立ち上がりに流れを悪くしたのは自分。ミスの怖さを知ったし、焦ってしまう部分もあった。自分自身がもっと強くならないと、このままではＷ杯のメンバーに入れないし、世界とも戦えない。そのためにどうするか。オーストラリアはアジアでは強いけど、世界ではそうでもない。こういう試合で負けていたらダメだと思う。 ■玉田圭司（名古屋グランパス） 「日本の持ち味を出せなかった」 （２００６年のＷ杯のオーストラリア戦と）似たような展開になってし

選手たちに関しては、チームとして非常によくまとまってやってくれたと思います。ただ、もう少しマイボールの時間を長くしないと、うちのサッカーをやるには厳しいと。ハーフタイムにも「サイドを変えて、下げてもいいからボールキープを長くするように」と言ったんですけど。なかなか中盤のところで縦に早かった場面が多くて、うまくいかなかったと。ただ、崩される場面はほとんどなくて、やっぱり（危険なのは）セットプレーの高さ。セットプレーを与える回数を少なくする、そのためにもマイボールの時間を長くしないといけないと思っています。とにかく、長い予選でしたけど、選手たちは厳しいスケジュールの中、本当に最後までよく頑張ってくれたと思います。 ――どうすれば日本はケーヒルを抑えられると思うか？（オーストラリア人記者） 今日はセットプレーからやられたんですが、先ほども言いましたように、ＣＫなどの回数を少なくすること、それ

テストファーストは、XP（エクストリームプログラミング）の中でも特に広く浸透したプラクティスの１つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め

「一生懸命テストしたのに、どうしてもバグがなくならない。」これは、すべてのソフトウェア開発者に共通する悩みであろう。 バグのあるソフトウェアでも、リリース前には、膨大なテスト項目をクリアしてきたはずだ。だが、そのほとんどは、仕様書や設計書から書き写しただけの、機能が正しく動くことを確認するものばかりになってはいないか。 テストしても見逃されるバグは、ソフトウェアを使い込んだり、ちょっと変わった操作をしたり、ある特殊な状況でのみ発生するものが多い。このようなバグは、意図的にバグを見つけようとしない限り、見つからないものである。 ソフトウェアテストも、創造性を問われる仕事である。ソフトウェアテストに関する広汎な知識と、豊かな想像力で、バグを見つけられるようなテストを創り出していかなくてはならない。それができなければ、ソフトウェアの品質も向上しない。 確認のためのテストと、バグを見つけるためのテ

テストは、ソフトウェアの品質を高めるために欠かせない、重要なプロセスだ。 規模の小さいソフトウェア開発でも、テスト項目の数は数百、数千にもなることも珍しくない。膨大なテスト項目をクリアして初めて、ソフトウェアは世の中にリリースできる。 肝心のテスト項目には、抜けや誤りがあってはならない。そこで、ふつうはテストを実施する前に、まず、テスト項目のレビューを行っているだろう。 だが、テスト項目をレビューする、という方法は、テスト項目の正しさをチェックする術としては、効率が悪い。どんなに時間や人を費してテスト項目のレビューをしても、どうしても項目の抜けや誤りを見落としてしまう、という人も少なくないだろう。 十分なテストを行うためには、テスト項目を作ってからではなく、項目を挙げる前にレビューを行うべきだ。 テスト項目のレビューは無理 開発も終わりに近づくと、チームの一部のメンバーは、テストの準備に取

ソフトウェアテストを改善する手法として、リスク・ベース・テストが注目されている。 ソフトウェアの開発サイクルが短くなっている現在では、短時間にいかに効率良くテストを行い、ソフトウェアの品質を高められるかが焦点になっている。テスト不足による品質低下に悩む人にとって、リスク・ベース・テストは効果的かつ魅力的な解決策である。 だが、リスク・ベース・テストが改善するのは、テスト・プロセスである。品質低下の原因がテスト・プロセスではなく、テスト項目そのものにある場合は、リスク・ベース・テストを導入しても、品質を高めることはできないだろう。

オラクルがサン・マイクロシステムズの買収手続きを進める中、Java開発者のジェームズ・ゴスリング氏は米eWEEKの取材に応じ、サンのJavaおよび自身の将来について語った。今回で最後になるかもしれない「JavaOne」カンファレンスにおけるゴスリング氏の唯一の公式インタビューは、示唆に富むと同時に感傷的なものであった。 ――サンが新たな時代を迎えようとしている今、Javaの将来はどうなると思いますか。 ゴスリング　まったく予想がつきません。買収が完了すれば、Javaの命運はオラクルとエリソン氏（オラクルのCEO）および同社幹部にかかっています。あなたが知っていること以上のことは、私にも分かりません。 ――オラクルがあなたに何か期待しているような兆候はありますか。 ゴスリング　ありません。 ――Javaはこれまで通り生き延びるのでしょうか。それとも何か変化が起きるでしょうか。 ゴスリング　デ