「Javaの鉱脈」でGatlingの記事を書きました | さにあらず
WEB+DB PRESS の Vol.83 で、負荷テストの記事を書いたので是非読んで頂きたい。 2014/10/24 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.83@Gihyo Digital Publishing今回の記事における対象読者について#JMeter だ、JMeter を撃滅せよ。 負荷テストスクリプト書くのに GUI なんぞいらないのですよ。 素人騙すんなら、それでいいかも知らんけども、そういう事じゃないでしょう。 GUI なしでも書けますよって、そのヤヴァイ XML を俺に見せるな。 負荷かけてる最中にサーバより先に死んだりするような負荷テストツールを後生大事に使うのをやめて欲しいのです。 今回は、新進気鋭のツールであるところのGatlingを紹介し
テストケースを動的に生成してJUnitで実行する | DevelopersIO
AWSチームに参画して2ヶ月ほど経ちました。ところが、AWSの構築などにはあまり関わらず、ひたすらAWSに関連するプロダクトの開発を行う毎日です。そんな折、ボスより次のようなリクエストをいただきました。 ユーザが参照できない情報について、参照できないことを検証して欲しい ・・・「出来ないことの検証」です。 「出来ることの検証」であれば、その例をテストケースとして記述してテストを実行すれば検証出来ます。しかし、出来ないことを証明することは非常に困難です。ただ、情報は有限なんで、総当たりにでもやればできるかもしれません。 ！？ システムのインフラは当然のようにAWSです。テストのためのリソースが足りなければ増やせばいいじゃないですか。時間がかかるならば並列化すればいいじゃないですか。テストの時だけ増やせばいいんです。 ならば、総当たりでテストしよう という方針になりました。そして、ブログのネタ
「ソフトウェアテスト勉強会〜テストコードのテストケースを考えてみよう！〜」に行ってきた - marsのメモ
http://tohoku-dev.jp/modules/news/article.php?storyid=221 （※図はイメージです） 先週のTDDBCで [twitter:@nemorine] が [twitter:@t_wada] に「TDDは不安をテストする？不安だなんて不確かなものは信じられない」ってゆってたので、どんな事するのか楽しみだったので参加してきたよ。 今日の本命は策士 [twitter:@i_takehiro] がTDDBCで仕掛けた課題1-3のテストケースの洗い出し。 課題1-3 閉区間が別の閉区間と等しいか (equals) 判定しよう 閉区間が別の閉区間と接続しているか (isConnectedTo) 判定しよう で、そのテストケースとして以下の8つを導き出せれば正解なのだけれど、あたしを含め参加者の多くは7つしかケースを導出できなかった（みんな8番目のケース
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
