UA偽装できました! 金曜日に上の人と話し、「自動化するとしたらUA偽装できないと実用価値ないね」という事になり、pythonで偽装できる方法を探したところ、案外あっさり出来ました。 import os from selenium import webdriver options = webdriver.ChromeOptions() #ここにUAを書きます。今回はiPhoneでsafari options.add_argument('--user-agent=Mozilla/5.0 (iPhone; CPU iPhone OS 10_2 like Mac OS X) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0 Mobile/14C92 Safari/602.1') # いつもどおりchromedriverの場所を指定します
テストとかどうでも良いから自動操作がしたい! seleniumは本来phpUnitなどと組み合わせてテストを自動実行するために使われるのだが私はただブラウザの自動実行を体験したいだけ。 なので今回は『とりあえず自動操作を体感』したいという人に向けて発信する。 seleniumとは これをご覧になるのが一番。コマンドを叩くだけで勝手にブラウザが起動して入力・検索を行っている。本記事ではここまでを目指す。 環境構築 今回はPHPで自動操作のプログラムを書き、Chromeで自動操作を実行する。 公式ではphpでSeleniumを動かすドライバーがないため、Facebookの中の人が作ったSeleniumのPHP版、facebook-webdriverを使用する。(SNSのFacebookサービスとは無関係です) 作業ディレクトリの作成 とりあえず実行したいんじゃ、という方のためなので以後はこのフ
こんなん。 解決策(対症療法だけど) 同じ問題になってる方がいた。 Selenium::WebDriver::Error::NoSuchDriverError - Today I Learned Finally, after spotting this comment we’ve reduced chrome window size from 1920,1200 to 1440,900 and the problem is no longer present. 「テストに使うブラウザのサイズを小さくしたら起きなくなった」とのこと。上記のリンクを辿って Chromium のバグリポート読むと、原因不明だけどメモリーが切れ気味になると起こる、みたいな報告がいくつか。Issue 1884: headless : session deleted because of page crash じゃあそ
Seleniumとは Seleniumとは、Webの自動テストのためのライブラリです。 最近では、自動テストのため以外でもスクレイピングのために使用するひとも多いと思います。 かくいう、私もその一人です。スクレイピングのためにこれさえ知っていればできるということを紹介できればと思います。 インストール インストールは以下のコマンドでできます。 実装方法 ブラウザの指定 Seleniumでは、PythonのコードからWEBブラウザを操作します。操作するためには、WebDriverが必要なのですがそれらは各ブラウザの公式サイトからダウンロードしてください。 今回サンプルでは、firefoxを操作する場合と、Chromeを操作する場合のサンプルを記述してみます。 from selenium import webdriver #Chromeを操作 driver = webdriver.Chrome
この記事は、Selenium Advent Calendar 2013の8日目の記事です。 Web+DB PRESS vol.77の特集1「スマートフォンテスト最前線」の第3章で、様々なSeleniumのDriverの紹介をしました。 4章の中でPhantomJSも取り上げることになっていたため、3章ではあえて取り扱いませんでした。 そこで、本記事では、Selenium使いのためのPhantomJS解説と銘打って、PhantomJSDriverの紹介とそのTipsを解説します。 PhantomJS とは PhantomJS は、ヘッドレスなWebKitベースのブラウザで、JavaScriptの実行も可能です。ヘッドレスなブラウザを操作するために、PhantomJSはJavaScriptのインターフェースを提供しています。またそれをラップした様々な関連ライブラリがあります。 GhostDri
システムの開発とか他人の作ったシステムの運用をする中で、サービスの外面だけでも動いているかどうかが常にチェックされているとすごく精神的に安定することがわかってきたので、受け入れテスト的なレベルのテストコードはとりあえずでも積極的に書いていきたいわけです。 1年くらい前に書いたWebアプリケーションを引っ張り出さなければならないことがあったわけですが、このときSeleniumでブラウザを使った自動テストを書いていたおかげで、自動テストで動くChromeの画面を眺めて「ああ、そうそう、こういう操作感のUIだったわ」みたいに思い出せたりします。何よりコードとして自動化されていれば、いつでも動かしておけて、それで安心した分睡眠の質が高まることが期待できます。多分。 そんな中で、ここ最近運用に加わったサービスのテスト、まだあんまり書けてないじゃんと気づいて、JavaかつMavenでSeleniumの
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く