SeleniumとXPathのまとめ１

エレメントロケーターって？

 

Seleniumを使い始めたときに、まず最初につまづくのがElementLocatorです。

ElementLocatorとは、Selenium実行時にElement（HTMLの要素）を特定するための方法のことです。

Domで指定したり、FormのIDで指定したりといろいろな指定方法があるのですが、やはり一番便利なのはXPathです。

XPathを使えば、特定のテキストに部分一致する要素をピンポイントで抽出したり、

並列に並んだ要素の最後から2番目を持ってくるなど、特殊な条件で位置の特定が可能です。

欠点は慣れるまでに少し時間がかかることと、HTMLの構造をある程度理解している必要がある点です。

今回紹介するのは、FirebugとSeleniumIDEを使った超簡単なXPathの確認方法です。

Step by step

１．Firefoxで位置を調べたいページを開きます
２．Firebugを起動（F12）してHTMLタブを選択状態にします

３．Firebugの左上 虫アイコンの右にある「カーソル選択」アイコンをクリック

4．位置を特定したい部分をクリックすると該当のHTMLが選択状態になります

５．Firebugの窓で、選択されたHTMLの部分にカーソルを移動して右クリック
６．「xPathをコピー」を選択します

すると、こんな感じのPathが取れます。

/html/body/div/div[2]/div[3]/div/div/div[2]/div/div/ul/li/a

７．次にSeleniumIDEを起動します（自動保存はOffにします）

８．コマンドリストの一番上の部分をクリック

９. コマンドには何も入力しないで「対象」に 対象に先ほどのPathをコピーします

１０．そのままだとエラーになるので  /html/body の部分を / に変更します。
結果例→ //div/div[2]/div[3]/div/div/div[2]/div/div/ul/li/aとなります。

１３．SeleniumIDEの対象の右にある検索ボタンをクリックすると
Yahooトップページのトピックの最上位の部分が点滅します。

これだけです。

HTMLの構造を一切意識しないでXPathを使うことができました。

さらに進んだ使い方

XPathは相対指定ができるので、例えば 

//div/div[2]/div[3]/div/div/div[2]/div/div/ul/li/a/../../li[2]
のように書くと、トピックの最上位の<a>を起点に
2階層移分上に移動した場所にある、2番目の<li>（トピックの2番目）が選択範囲になります。

まれにHTML構造上の理由から、上記の方法では期待する位置が特定できない場合もあります。

そのときは、XPathの最後の要素をひとつずつ消しながらIDEの「検索」ボタンと押すと、

Locatorがどこを見ているのか一目で分かります。

目当ての要素が選択範囲に含まれたら、今度はFirebugのHTMLタブをみながら、

要素をひとつひとつ追加していくと、最後には目当ての要素にたどり着くことができます。

属性を指定したり、テキスト部分一致を利用したXPathの書き方に関しては、また後日まとめたいと思います。

Selenium IDEの実行とログ保存ガイド

Selenium IDEの実行とログファイルを保存する方法をまとめます。

（初心者向けに書きました）

・ テストケースを実行

１. Selenium IDEを起動して、ファイル（F）→テストケースを開く（O）をクリック

２．テストスクリプトを選択して開く

３．テストケースが読み込まれることを確認

４．実行ボタンとクリック

５．テストケースが全て実行できて失敗しなければ、Runs:1と Failures:0　と表示される

・ログウィンドウからコピーする場合

１．スクリプト実行後にフィルタしたいログ情報を選択

２．ログウィンドウにカーソルを移動して範囲選択（Ctrl+A）してコピー（Ctrl+C）する

特定の情報のみログとして出したい場合は、一度変数に格納して、
Jsから警告として表示させることで、きれいに情報を取り出すことができます。

※デバック、情報、エラーだと、ほかの情報と混在する可能性が高いので、警告が一番無難です。

例）
storeEval LOG.warn(storedVars['STORED_VAL']);

※log.debug、log.info なども有効です。

・ログが保存できて何がうれしいのか？


Seleniumの利用方法を考えたときに、テストだけでなくWebの情報を自動収集することにも応用できます。
（例えば特定クエリで表示されるGoogleのランキングを上位n件まで表示する　など。）


PythonやJavaでゴリゴリ書きますってひとには、あまり価値のない情報ですね、、、＾＾；


しかし、プログラムを全く知らない人でも、やり方さえわかればWebの情報収集が半自動化できることがSeleniumのいいところです。

5分でできるWebテスト自動化 - Jenkins x Selenium

いろいろあって、しばらく投稿さぼってました、、、＾＾；
ここ最近アウトプットをさぼり気味なので、今日からまた再開します。


さて、テストクラスタの方やWeb系エンジニアであれば、SeleniumというWebテストの自動化ツールについて聞いたり、実際に利用したことがあると思います。


Selenium IDEなどを使ってテストスイート単位で自動化することもできますが、JenkinsというCIツールを使えば、テスト実行およびレポーティングまで完全自動化することができます。


JenkinsはWindowsマシンでも簡単に構築できます。
今回はツールのセットアップ（Windows版）と基本的な使い方まとめたいと思います。


尚、Seleniumはスタンドアローン版がセットアップされていることを前提にしています。
（セレマニア｛注：Seleniumオタク｝のひとは、特に説明不要だと思うので、JavaやPythonなど、各自好きな言語でかかれたテストコードを直接起動してください＾＾； ）

環境構築

 

参考サイト

JenkinsにSelenium Html Reportをいれてみた。 | SeedsLight:

http://seedslight.com/wp/archives/185

１.JDKインストール＆環境変数設定

https://www.google.co.jp/search?q=JDK

※JREではなく、JDKが必要なので注意（DL前にOracleに登録が必要）

JAVA_HOME=C:\Program Files\JavaFX\javafx-sdk1.3

SDK直下のbinにもパスを通す。

２．JenkinsのDL

http://jenkins-ci.org/

Windows版をDL

３．ダウンロードした jenkins.war を直接起動

java -jar jenkins.war

→デフォルトでは　http://localhost:8080　にサーバーが立つので、ブラウザからアクセスして確認。

※セキュリティーソフトなどでブロックされる場合は、適宜設定変更してください。

ジョブ作成

次に自動実行のためのジョブを作成します。

１．新規ジョブ作成

とりあえずフリースタイルを選択します。

２．作業用フォルダの設定

スクリプトを実行する場合は、カスタムワークスペースを設定。
※スクリプトをフルパスで指定する場合は必要ないかもしれませんが、一応設定します。

３．ソースコード管理

利用しない場合は「なし」を選択

４．ビルドトリガ設定

ここではスクリプトの実施タイミングを設定します。

     
↓書き方の例（詳細はJenkinsのヘルプを参照）

# 1分ごとに
* * * * *
# 毎時5分(1時間に一度)

5 * * * *

# 30分に一回
*/30 * * * *

５．ビルド手順追加

Windowsバッチからのスクリプト実行の場合は、「Windowsバッチコマンド」を選択する。

以下はSeleniumスタンドアロンサーバーの例。

rem Firefox

java -jar selenium-server-standalone-2.18.0.jar -htmlSuite "*chrome" "http://www.google.com" "C:\selenium\suite02.html" "c:\selenium\result01.html"

rem Chrome(日本語が化ける？)

java -jar selenium-server-standalone-2.18.0.jar -htmlSuite "*googlechrome" "http://www.google.com" "C:\selenium\suite03.html" "c:\selenium\result02.html"

＊＊＊

手始めに以下のようなサンプル用コマンドを書いて、ジョブの実施のみを確認してもOKです。

echo im enjoying testing with Jenkins!

date /T

＊＊＊

６．成果物保存

作業ディレクトリにあるスクリプト実行結果ファイルをバッチ実行毎にアーカイブする場合は、「成果物を保存」にチェックを入れて、

**/result*.html

のような形式で保存ファイルを指定します。

上記例ではファイル名がresultで始まり、拡張子がhtmlであるファイル（サブディレクトリも含む）をアーカイブします。

実行結果確認

１．ルートメニューで確認

２．プロジェクトメニュー

直近のビルド成果物や、即時実行、設定などが可能です。

３．ビルドログ

プロジェクトメニューの左側ににある「ビルド履歴」から遷移します。

「コンソール出力」でこのビルド実施時に出力されたコンソールのログ情報が確認できる。

また、「ビルドの成果物」で、バッチ毎に保存したファイルがDLできる。

最後に

JDKインストールに時間がかかるかもしれませんが、びっくりするぐらい簡単に自動テスト環境が構築できますので、ぜひ試してみてください。

いやー　このシステムは開発してくれた神プログラマに感謝感激ですね。

テストにおけるヒューマンリソースの効率性

最近悩みがあります。

それはテストにおける人の管理についてです。

狼を撃つ銀の弾丸がないのは、ソフトウェアテストにおいても同じです。

でも、”テストを実施する”という作業自体には、プログラマほど専門知識がなくてもこなすことはできることは事実です。（意味のある、効率の良いテストを実施できるか否かは別にして、、、）

テストに関して経験の浅い組織では、「テストなんて誰でもできるでしょ」と安易に考えがちですが、

それはテストを設計したり、管理したりする人の負担を無視した危険な発想です。

そして"狼を..."の話に戻りますが、やっぱりそれなりの経験があるひとをアサインし、効率の良い配置で、コミュニケーションを十分にとりながら進行していくことで、初めて意味のあるテストができるようになります。

前置きが長くなりましたが、用は「それなりの経験があるひとをアサインし、効率の良い配置」という部分が悩ましい点なんですね。

当然テストを管理する人間だけでなく、テストを実行するためのリソースは必要です。ではテスト実施のための専任担当者がいたとして、テストが終わった後に、彼らは何をすればいいのでしょうか？

ソフトウェアや開発の勉強？ テストの上流プロセスの勉強？

ともかく人数が多すぎると、あぶれてしまうんですね。。。。

今の時代、品質にそれほどお金を掛ける余裕はない組織が多いと思います。そんな状況でテスト担当がいっぱいいても、単にコスト部門と見なされる可能性が高いです。

すぐに思いつく対策はいくつもありません。

１．より効率的なテストを実施するために勉強する時間が必要であると上層部を納得させる

２．単発で仕事してくれる派遣会社に頼る

３．努力と根性を武器に最少人数で乗り切る

４．ほかの部署から人を借りる

一番最悪なのは3番でしょう。離職率が跳ね上がり、それに反比例して品質は下落します。

品質の重要性を意識している会社なら、1番の選択肢もありえるのではないでしょうか？

2番は結局管理のコストがかかりますね。

４番は表面上は金のかからない方法ですが、そもそもテストに関してネガティブな先入観を持ってる人が多い組織では、どの部署も人を出すことを渋るでしょう。

4番が良い気がしますが、プロセスをスムーズにまわすためには、啓蒙活動を通して正しいソフトウェアテストの知識を広めてからでないと、うまくいかない気がします。

どれも一長一短ですね。

20

JSTQB カンファレンス in 2010

JSTQB カンファレンス in 2010
http://jstqb.jp/event/conference2010.html

10月14日開催です。

Rex Blackさんいらっしゃるみたいですが、同氏のチュートリアルは大人気で、発表後すぐに締め切ってしまいました。

セッションには参加する予定なので、そのうちまとめなど書こうと思います。

ソフトウェアテストメトリクス

最近ソフトウェアメトリクス収集に関するQAガイドラインを作ったので、
その内容を少しだけ書こうと思います。

 「計測できないものは制御できない」とは、著名なソフトウェア工学者トム・デマルコさんの言葉です。
 メトリクスとは指標を意味し、ソフトウェアメトリクスとは「ソフトウェア開発プロセス全般に亘って、定性的な情報を数値化して計測管理すること」を指します。

品質管理はプロセス管理であるという原則に従って、QAプロセスもある程度数値化して管理
するとこが重要だと考えます。たとえば何か問題が発生したとき、数値化して管理していないと上層部に対する報告も主観的であいまいなものになり、本来のQAの目的である「リスク管理」が正しく実施できなくなってしまいます。またメトリクスをほかの部署に対するマーケティングに利用したり、上層部対する予算確保の根拠などにも利用できます。

このメトリクスを決めるにあたって、注意するべきポイントがあります。

1. メトリクスの評価対象はあくまでプロセスそのものであり、個人の業務評価に使用してはならない
2. 収集の目的を明確にしなければならない
3. メトリクス用データ収集作業が、実務を阻害してはならない

まず１番に関して補足すると、特にマネジメント層にある人は部下の業務評価の材料としてメトリクスを利用しようと考える傾向があるのではないかと思います。しかしこれは大きな間違いで、そんなことをしたら、部下は積極的にメトリクス導入に賛成せず、また正直にデータを集計したりもしないでしょう。メトリスクの収集はあくまでプロセスの管理・向上を目標としていることを明確にすることが大切です。
２番はあえて言及するほどことではないかもしれませんが、メトリクスの収集にあたってはその指標をどんな目的で使うのかを共通認識として持つことが大事です。データの意味や目的がはっきりしていないと、それを有効に使うことはできません。
３番も非常に重要で、メトリクス収集は通常業務の妨げにならないように、その仕組みを体系化し、簡単に繰り返し実行できるようにすることが求められます。つまり最初から欲張って完璧なデータを収集しようとせずに、簡単に実践できて結果が見えやすい指標から試すことが大事です。

ここまでが、ソフトウェアテストメトリクス導入のおおまかな指針です。実際にどのような値を収集するかは、その会社のビジネスモデル、開発プロセス、品質管理方針などによって千差万別だと思います。一般的な指標としては、DRE（欠陥除去率）やTCE（バグの総数に占めるテストケース貢献率）などがあります。


それぞれの指標をどのように収集・活用していくかに関しては、また後日書きたいと思います。

60

上司から与えられたミッションに対して、その有効性や意義に疑問を感じた場合

プレジデント 5.17号から。

上司から与えられたミッションに対して、その有効性や意義に疑問を感じた場合、QAマネージャーはどうすればいいのでしょうか？

選択肢はいろいろあると思いますが、最も重要なことは、まわりの状況をよく観察しその命令の背景を探ることです。

命令の内容が一見無計画で場当たり的に見えても、実際に調べてみると、その裏には、ステークホルダー（主に経営者、投資家、親会社など）の意向や政治的な妥協が潜んでいる可能性もあります。そのような場合に、「この計画は欠陥だらけで会社にとっても不利益にしかならない」などど声を張り上げても、まったく無意味です。

批判した本人は会社やユーザーを第一に考えて、論理的、道義的に意義を唱えたつもりでも、他人にとっては単なる戦略に対する批判者ぐらいの印象しか持ってもらえないでしょう。命令した本人でさえも、問題を分った上で自覚的にやっている場合もあります。

批判を繰り返していると、次第に周りから疎まれてしまいます。私も一度このような状況に陥ったことがあります。

大事なことは「合理的な理由を論理的に主張したとしても、それが会社（上司）の意図と合わなければ会社組織の中では何の価値も生まない」ということを理解することです。息苦しいですね、、、、

もちろんいざという時は、戦うことも必要でしょう。でも、負け戦をやるのは賢い方法ではありません。

とは言っても、無理難題を全て引き受けていたら、自分も部下も潰れてしまいます。そうならないためにできることは４つあります。

１．直属の上司または同僚に命令の背景に関して相談すること
２．自分はどの程度裁量を持てるのか確認すること
３．責任の範囲を明確にすること
４．リスクに関して事前に言及しておくこと

１に関しては、やはり命令の背景を知ることで、その本質が見えてくる場合があるためです。知ってみると実は命令そのものは重要ではなく、単なる政治的理由でやるということが決まっただけのケースもあります。つまり、単に実行すればいいだけでその内容までは問わない、というようなまったく無意味なケースもあるということです。

このような場合に、正面きって批判することは体力のムダでしょう。会社にとっても不利益にしかならないので、いかにコストを抑えて"やったことにするか"を真剣に考えましょう。


２と３は命令を遂行するにあたって、自分の責任はどこにあるのか、またどの程度裁量を発揮できるのかを明確にすることで、後々の"被害"を最小限に留めることができます。責任＞裁量の関係になっていないか、またそうなっていれば、具体的に何が必要なのか事前にはっきりさせておきましょう。いくら無茶な命令だったとしても、それを実現するために現実的に解決しなければならない問題があれば、上司も協力してくれるはずです。

４は欠陥だらけの計画が破綻した場合を想定して、事前に「こんな可能性がありますよ」と上司に伝えておくことです。これを行うことによって、仮にプロジェクトが失敗した場合でも、自分はこの可能性に関して言及していたと言い訳をすることができます。ズルい方法ですが、組織の失敗を個人の責任にさせないために、事前に準備しておくことは重要です。


トップのリーダシップが欠如した組織は往々にして、このように理不尽な状況になりがちです。
しばらく様子を見てまったく改善しないようであれば、履歴書を書き始めたほうが賢明かもしれません。

76