Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

なんちゃって個人情報は「Generator of the Year」にて【便利賞】を受賞いたしました!! 投票して下さったみなさま、本当にありがとうございました。 今後もどんどん使ってやって下さい。 プログラム等に使えるかもしれない個人情報のテスト用データを作成できます。特に説明が必要なものでもないので、とりあえずやってみていただければわかると思います。 念の為書いておきますが、生成した偽個人情報により発生したいかなる損害も当方は一切関知しません。たまたま名前が実在の人物と同姓同名になってしまうかもしれませんし、特に電話番号や携帯については実際に使われている番号と重なることがありますから、扱いには十分注意して下さい。 何かご要望とかありましたらお気軽にブログまでコメント下さい。 HTML シンプルなHTMLのテーブルで出力します。 XML ルートを<records>、各レコードを<reco
オープンソースのブラウザテストツール「Selenium WebDriver」の使い方と、テストスクリプトを効率よくメンテナンスする方法について、実際にプログラムを書きながら学べるチュートリアル形式教材です。 前半は、Selenium入門ドリルです。基礎から丁寧に解説されているので、Seleniumは初めての方でもテストが書けるようになります。 後半では、テストのメンテナンス効率をあげるための技法「ページオブジェクトデザインパターン」の習得を目指します。こちらも基礎から解説していくので、Seleniumが初めての方でも大丈夫です。 プログラミング言語Javaでテストスクリプトを作成するので、Javaで基本的なプログラムが書ける必要があります。 自習教材として利用する場合 前提知識・事前準備手順ドキュメントの手順に従い、必要な事前準備とインストールを完了させます。作成したEclipseプロジェ
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら=原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
はじめに この記事ではVisualStudioを使用して、どのように単体テストを自動化していくかを記述します。 この記事では「単体テストの自動化?なにそれおいしいの?」とかいう感じの組織で、現実的な妥協点を探っていくという、縛りゲーをやるクソゲーマー向けて、ファミ通程度の攻略情報をお届けするのが目的です。 あと「単体テスト」を自動でやるという枝葉の話でしかないので、「テスト?なにそれおいしいの?」とか「品質管理?わいには関係ないで」とかいう方は「自動」云々でなく、まず基本的なソフトウェア技法から調べた方がよろしいです。 「まっとうなソフトウェアテストの知識」を持っている人が、ツールを駆使して、作業の効率化をもとめ品質を上げるってのが重要で、「まっとうなソフトウェアテストの知識」がない人が、手順だけを自動化するのは本質を踏み外しています。 JSTQBの教科書とか、ソフトウェアテストの本とかで
経験ゼロでもできるプログラミング現場の単体テストを読んだので、そのまとめ はじめに 著者曰く、 初めて導入する単体テストの指南書 を目指した一冊。 単体テストを書いたことが無かったり、書いたことがあっても書き方の方針が定まっていない人にはおすすめの本。 逆に既にバリバリテストコードを書いてる人に、再確認的な内容になるかも。 単体テストについて基礎知識 アプリケーション開発では設計に時間がかかりすぎて、テストに時間をかけられないことがある。 致命的な障害発生する可能性がある。 とはいえすべてを想定してテストを実施することはできない。 テストケースを絞る必要がある 各テストフェーズの礎となる単体テストが重要になる 高品質なシステム ユーザーを満足させ、不安や不満をいだかせないこと システムエラー:データの破損などの心配が生まれる 応答が遅い:いらいら・二度と使わなくなる まとめてテストはダメ
先日、会社のメンバーからテストの自動化に苦労しているという話を聞きました。 そういえば、一言で「テストの自動化」といっても結構奥が深いので、自動化テスト初心者が注意すべき点や重要なポイントをちょっと考えてみました。 自動化テストの注意点 どのような処理でもプログラムとして自動化できるプログラミングスキルを実装者が持っていること。 結局、手作業でやっていることのほとんどをプログラムとして実装する必要があるからです。 いつでも、どこでも、誰が実行しても同じテスト結果が返ってくるようにテストを作成すること。 たとえば、テストの成功・失敗がシステム日時や外部ファイルやデータベース等に格納された不安定なデータに依存しているとテストがすぐに壊れます。 壊れたテストを放置しないこと。 少なくともソース管理システムにコミットしたファイルはすべてパスするようにしましょう。 壊れたテストを放置すると、誰も自動
1.V字開発プロセスモデルによる分類 1.1.要件定義 VDM 形式手法(Formal Methods)により仕様の自動検証などを行う。 1.2.システム設計 モデル検査 Spin モデル検査により状態遷移図の状態で自動検証を行う。 LTSA モデル検査により状態遷移図の状態で自動検証を行う。 NuSMV モデル検査により状態遷移図の状態で自動検証を行う。 モデル駆動 ZIPC(商用:キャッツ株式会社) 状態遷移図による検証が可能 MDA モデルを実際に動かして動作検証する。Executable Umlなどを使用して仕様を記述。 IAR visualSTATE(商用:IAR SYSTEMS) ステートマシンを設計、検証、実装できるツール。20ステートまでの無料の評価版あり 1.3.詳細設計 Enterprise Architect(商用:SPARX SYSTEMS) テストツールではないが
最近のRuby on Railsプロジェクトで使ってるもの・やっていることを紹介します。 rake setupちょっと前にこの記事を読んでやりたかったやつです。 Setting up a new machine for Ruby development by David of 37signals $ git clone git@your-server:you/your-repo.git $ rake setup すると、開発に必要な環境ができあがるというrake task。今いるプロジェクトではデータベースを作りなおして、開発環境用のテストデータを投入。テストデータのまとめ、各種URLなどを表示しています。 何かデータが変になったとか、まっさらの状態から動かしたいとか、そういう時はとにかくrake setupすればOK。 rake setupを一発叩けばアプリがそれなりに動く状態になる、っ
自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
YJTC19 B-5 Kubernetesで実現したYahoo! JAPANの次世代開発環境 ~ 100以上のクラスタを少人数で運用する秘訣 ~ #yjtc
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや?TDD とは何ぞや?ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは?」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
はじめに 各地でTDD Boot Camp(TDDBC)が開催されるようになり、このところTDD(テスト駆動開発)が注目を浴びています。ただ、自分でも試してみようと思った時に目につく書籍や記事などは、Java、Ruby、PHPといった、いわゆるオープンソース系の言語ばかり。.NET Framework(Windows)で開発の仕事をしているとTDDは関係ないんだろうか、…とさえ思えてくるかもしれません。 しかし、そんなことはありません。.NET FrameworkでのTDDに必須のユニットテストフレームワークとして有名なNUnitの最初のバージョンは、Visual Studio .NET 2002がリリースされる以前の2001年に公開されています。.NET Frameworkは、生まれたときからTDDと共にあると言っても過言ではないでしょう。 この記事では、TDDとTDDBCについて簡単に
このまえ登り坂の途中でロードバイクのタイヤが破裂しました。ながたです。 今回はバッチ処理について書いてみようと思います。 バッチ処理? Webサービスの処理開始条件は、大まかに次の2つに分けることができます。 ユーザーのアクションに起因するもの ユーザーのアクションに起因しないもの このうち後者の処理をバッチ処理が担当することになります。 バッチ処理の担当分はさらに、 特定の条件(時間やサービスの状態)で実行するもの 手動で実行するもの の2つに分けられます。 今回はこの「手動で実行するもの」について書きたいと思います。 バッチを手動実行するのはどんなとき? バッチ処理を手動で実行するのは、十中八九イレギュラーな状況が発生したときです。 ルーチンワークや実行の条件が決まっているものは何らかの方法で自動化できるはずです。 そしてイレギュラーな状況のほとんどは不具合が発生したとき。 つまり 重
TDD(テスト駆動開発)のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ(OmniGraffle)が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記2 このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く