HTTP負荷テストをしよう·Vegeta MOONGIFT
VegetaはGo製のオープンソース・ソフトウェア（MIT License）です。 HTTPの負荷テストツールは幾つかありますが、今回は最も新鋭と思われるVegetaを紹介します。コマンドラインで動作するのでインストールも簡単ですぐに使い始められます。 オプションです。基本的にはアクセス先のURLをファイルに記述するのみです。 実行例。デフォルトで10秒間に500リクエスト行います。 アクセス先のURL指定はメソッドとURLを指定します。GETはもちろんPOSTやHEADアクセスによる負荷も計測可能です。レポートはテキストの他、SVGでの出力もできます。VegetaはGoで作られており、Goのプログラム中でライブラリとして呼び出して使うこともできます。 MOONGIFTはこう見る WebサービスがメディアであればGETリクエストが最も多くなります。コミュニティサービスであればGETはもちろ
テストエンジニア | クックパッド株式会社
クックパッドは「毎日の料理を楽しみにする」ことをミッションとして、日々サービスやアプリケーションの開発に取り組んでいます。クックパッドがユーザーにとって価値あるサービスでありつづけるために、品質という視点は欠かすことができません。 クックパッドのテストエンジニアは、ユーザーの価値である品質を達成するためのあらゆる活動について、ソフトウェアテストという専門技能によって貢献する役割です。プロジェクトに参画し、テスト計画の策定からテスト実施、テスト自動化などを担当します。 仕事内容 サービスやアプリケーションのリスク分析、テスト計画、テスト設計、テスト実装 テスト自動化、テストツール開発 テスト戦略、テストプロセスの改善
/etc/hosts はホスト数が増えるとDNSより遅くなる
/etc/hosts にホスト名を書いて配るというのは、数台のマシンを管理する状況では誰しもやったことがあると思います。DNSクエリが発生しないのでとても早く、また単一障害点が発生しないメリットがあります。その反面、台数が増えてくると全部を更新するのがとても大変になるだけでなく、致命的な速度低下をもたらします。 テスト環境は OS: CentOS 6.4 64bit, Linux 3.10.2 CPU: Intel Core i7-2600 @ 3.4GHz です。 テストにはひたすら getaddrinfo(3) し続けるプログラムを作成し、名前を解決しました。 /etc/hosts には 10.234.130.1 host1301 10.234.130.2 host1302 10.234.130.3 host1303 のように適当なアドレスとホスト名を並べたものを作り、利用しました。な
Webサイト負荷テストツール記事まとめ要約
急ですが、webサービスやwebサイトの負荷テストは行っていますか?どの程度のアクセスがあった場合にサーバが遅くなってしまうのかをバズる前に検証しておくべきです。 現在、Yahoo、はてブ以外にもGunosy等に載る事で簡単にバズり(普段のPV数 ＋ 想定PV数5000〜30000)その時にサーバが同時アクセスに耐えられなくなり、かなりの機会損失を被ってしまいます。自分のサーバ、または借りているレンタルサーバの能力値を理解していればそれなりの対策が打てるようになるのかなーっと。そうゆう事で負荷テストをオススメします。 今回は記事を書くというよりは負荷テストが出来るwebサービス、ツール、ソフトを紹介している記事をまとめて紹介して最後に要約していきたいと思います。 負荷テストツールをまとめている記事ベスト3 負荷テストを出来るサービスやツールを紹介しているまとめ記事を厳選して紹介したいと思い
CI で稀に失敗してしまうテストへの対処方法 - クックパッド開発者ブログ
技術部の福森です。 クックパッドでは RSpec と Jenkins を利用して CI による自動テストを行なっています。 テストの数は 12000 examples を越えていて、テストによっては稀に失敗する物が出てきています: 時間帯依存で失敗してしまうもの 他に同時に実行されるテストに依存しているもの (並列実行で組合せが変わり再現する) インテグレーションテストでの ajax リクエストの微妙なタイムアウト etc また、本番環境を壊さないよう、 CI で成功したリビジョンのみデプロイ可能となっており、開発者が push しデプロイしたいと思っている時に無関係な原因で失敗する事を避けたいという欲求があります。 なぜなら、再度ビルドを実行する時間 (およそ 10 分) の間待たされる事になるからです。 そこで、そのようなテスト起因での失敗を減らし、かつ開発者にそれらを修正してもらうた
テストにコケる度にシーザーが死ぬ仕組みを作りました - その手の平は尻もつかめるさ
タイトルは釣りです。 App::WithSound をリリース致しました。 https://github.com/moznion/App--WithSound https://metacpan.org/module/MOZNION/App-WithSound-v1.0.2/with-sound (2013.03.06 追記) App::WithSound はv1.1.0 にバージョンアップしました。 コマンドの成功・失敗時だけでなく、コマンドの実行中にも音声を再生出来るようになっています。 https://metacpan.org/module/MOZNION/App-WithSound-v1.1.0/with-sound (追記ここまで) App::WithSound? コマンドが成功するか失敗するかによって、その結果に対応した音声が流れるアプリケーションです。 まず、このモジュールはm
RailsでJavascript/CoffeeScriptをテストするときの決定版（にしたい）！Konacha - リア充爆発日記
というわけでKonachaです。https://github.com/jfirebaugh/konacha なにこれ、粉茶？ JavascriptのテスティングフレームワークとしてはJasmineやらMochaあたりがメジャーどころのようだけど、セットアップが難しかったりして「これだ！」というものがなかった。個人的には。 で、今回、よーし、お父さんCoffeeScript書いちゃうぞー！というタイミングにあたって、もう一回いろいろ探してみたところ、これが一番スジがいいっぽかった。 KonachaはRailsでMochaとchaiを使いやすくしたGemらしい。Mochaとchaiは使ったことなかったけど、公式を5秒ほどみたところ、nodeでうごくrspecライクなテスティングフレームワークということでJasmineとかとあんまかわらないんじゃないかと推測。chaiはマッチャーのライブラリのよ
SeleniumでiOSシュミレーターを動かし、iPhoneのブラウザ越しのテストをする - Yamashiro0217の日記
テストしてますか！ スマホブラウザ対応の結合テストとか辛いですね。そうですね。 というわけでSeleniumでiOSシュミレーターのブラウザを動かして見ました。 Seleniumには、iPhone driverというのがあるのでそれを使いますです。 http://code.google.com/p/selenium/wiki/IPhoneDriver 以下の行動をとります。もちろんMac上です。 XCode の4.2以上を入れます #git clone https://code.google.com/p/selenium/ #cd selenium #./go iphone #open iphone/iWebDriver.xcodeproj #Xcode が立ち上がるはずなので、適切なiPhoneを選択し、Runします 上記が全部うまくいくと、Xcodeのシュミレーター上で、RemoteD
GREEにおけるJenkins, その2 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsをつかった品質管理について紹介します。 hourlyビルド 岡崎がGREEに入社したのは1年半前ですが、そのときから感じているのがGREEの開発速度は非常に速いことです。ソースコードレポジトリには多くの優秀なエンジニアが日々数百以上のコミットしています。 GREEのシステムは多くのサブシステムを組み合わせたものですが、手元の些細な変更が全く予想しない別のプロジェクトで問題を起こすことがあります。こういった問題は通常、リリース前の結合テスト等の段階で検出します。 リリース前のテストで問題が発覚すると、当然その修正をして再度修正をリリースプロセスにのせるということになるのですが、これには他のエンジニアの作業を止めてしまったりリリースの順序を調整が必要になることがあります。 こういった事態を防ぐために単
何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops
テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても本当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jenkinsがテストこけているのにグリーンになる件解決 - shokosブログ
Charming Python: Functional programming in Python, Part 3