タグ

testに関するitengineerのブックマーク (38)

  • HttpUnitを利用したWeb画面テストの自動化

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

    HttpUnitを利用したWeb画面テストの自動化
  • なんちゃって個人情報

    なんちゃって個人情報は「Generator of the Year」にて【便利賞】を受賞いたしました!! 投票して下さったみなさま、当にありがとうございました。 今後もどんどん使ってやって下さい。 プログラム等に使えるかもしれない個人情報のテスト用データを作成できます。特に説明が必要なものでもないので、とりあえずやってみていただければわかると思います。 念の為書いておきますが、生成した偽個人情報により発生したいかなる損害も当方は一切関知しません。たまたま名前が実在の人物と同姓同名になってしまうかもしれませんし、特に電話番号や携帯については実際に使われている番号と重なることがありますから、扱いには十分注意して下さい。 何かご要望とかありましたらお気軽にブログまでコメント下さい。 HTML シンプルなHTMLのテーブルで出力します。 XML ルートを<records>、各レコードを<reco

  • Watij API

    <H2> Frame Alert</H2> <P> This document is designed to be viewed using the frames feature. If you see this message, you are using a non-frame-capable web client. <BR> Link to<A HREF="overview-summary.html">Non-frame version.</A>

  • Investigative Tester (調査型テスト担当者) - masayang's diary

    開発チームとテストチーム(QA: 品質保証)とを分けるかどうかというのはAgileコミュニティの中でもよく議論になる。 "Craftsmanship over Crap!" と叫んだBob Martinは品質保証を他人に任せることに大反対。 が、GDD(Geographically Distributed Development: 地域分散開発)に関して話してくれたScott Amblerは面白い考え方を提示してくれた Investigative Tester ある程度規模が大きくなり、複数チームで開発を進めることになっても、テストを記述するのは開発者。これは原則。*1 ただし、Investigative Tester(調査型テスト担当者)を用意するのは悪いことではない。 調査型テスト担当者は開発者が見落としているテストを探し、実行する。 バッファオーバーフローとか トラップされてないエラ

    Investigative Tester (調査型テスト担当者) - masayang's diary
  • 第3回 オンライン活動を活発に行うためのコツ | gihyo.jp

    オンライン活動を活発に行うためには さて、他のコミュニティとの比較により、TestLink日語化部会の特徴が明確になったところで、この特徴に合わせてオンライン活動を活発に行うためのコツを紹介していきたいと思います。 TestLinkに特化 → 目的の明確化 TestLink日語化部会の目的は、もちろんTestLinkを日語化し、日で普及させることです。このように目的が明確になることが、オンライン上で活発に活動を行ううえでの第一歩だと思います。モチベーションを維持していくためには、何かの目的を一緒に達成していくことが大切です。オフラインで集まる場合は、集まる楽しさ、その場で議論する楽しさなどがあります。オンラインではそのようなメリットは享受できないので、それ以外の目的がないと活動が停滞してしまうでしょう。 私たちの場合は、一番初めの目的が明確であったことが活動を一気に推し進めたのだと

    第3回 オンライン活動を活発に行うためのコツ | gihyo.jp
  • 第5回 記録や報告書をおろそかにしていませんか? | gihyo.jp

    A君はK先輩に教えてもらったテストケースの書き方を参考にしながら、なんとかそれなりのものを作成することができました。これでようやくテストケースを実行できるところまでたどりつきました。A君にはとても長い道のりのように思えましたが、少し感慨深くもありました。 A君「よし!頑張ってテストケースを実行するぞ!」 A君が意気込んでいると、おもむろにK先輩が来てこう言いました。 K先輩「あ、このPCにテスト環境を作ってあるから使うといいよ」 来ならば、テスト実行の前には、テスト環境の構築という作業を行う必要があります。テスト環境の構築は、テスト対象となるソフトウェアをインストールするだけではありません。 今から実行するテストケースが、さまざまなテスト観点を効果的に実行できる環境を作り上げる必要があります。来はテスト環境仕様書などを作成する必要があるのですが、これらについてはこの連載の範囲を超えます

    第5回 記録や報告書をおろそかにしていませんか? | gihyo.jp
  • 第7回 キャプチャ/リプレイツールによる機能テストの自動化 | gihyo.jp

    これらのツールは単独でも利用可能ですが、今回はSelenium IDEとSelenium Coreを組み合わせてテストを進めていきます。例として、名前を入力して画面遷移すると、入力した名前が表示されるという簡単なWebアプリケーション(図1)を使って、Seleniumを使用したテストの手順を見ていきましょう。 図1 テスト対象のアプリケーション Selenium IDEで画面操作を記録 Selenium IDEのインストール まず、Selenium IDEをインストールします。Selenium IDEはFirefoxのアドオンとして提供されていますので、事前にFirefoxをインストールしておく必要があります。 Firefoxを起動したら、Selenium IDEのダウンロードページにアクセスし、執筆時点の最新版である「Version 1.0 Beta 2」の「Firefox extens

    第7回 キャプチャ/リプレイツールによる機能テストの自動化 | gihyo.jp
  • 第3回 コピー&ペーストでテスト仕様書を作っていませんか? | gihyo.jp

    仕様書の読み方がわからない! A君は、ソフトウェアテストは単純にプログラムを動かすだけではなく、 明確な目的を持つこと その目的を達成するために事前の準備が必要であること を学習しました。では、テストの準備とはどういうことをしなければならないでしょうか。 A君はその後、K先輩に質問を行い、次のようなアドバイスをもらいました。

    第3回 コピー&ペーストでテスト仕様書を作っていませんか? | gihyo.jp
  • ウェブログ適齢期: jWebUnit ~インストールと使い方~

    ●jWebUnitとは Webサイトの機能テストを行うテスティングフレームワークです。例えば、「このリンクをクリックしたら、このページに移動する」といったテストが行えます。 ●jWebUnitのインストール jWebUnitはHttpUnitのラッパーとして実装されています。そのためJUnit、ならびにHttpUnitがインストールされていることが前提になります。インストールとは言っても必要なjarを任意のディレクトリにコピーすればいいだけです。 1:JUnitのインストール JUnitよりzipファイルを手に入れます。最新バージョンは3.8.1なので(2004/07/31現在)落としてくるzipファイルは「junit3.8.1.zip」になります。 手に入れたzipを適当な場所に解凍します。 今回はeclipseのプロジェクトで用いるので解凍したディレクトリに含まれていた「jun

  • JWebUnit - JWebUnit

    Home User documentation Installation Quick start Migration guide Articles FAQ Developper documentation Building JWebUnit How-To contribute How-To release Sourceforge Project page Download Modules Code Generator Core - API Commons Tests HtmlUnit Plugin Webdriver Plugin Project Documentation Project Information About Project Team Mailing Lists Project License Issue Tracking Source Repository Project

  • 2008-07-09

    せろり(id:cero-t)の娘さんが「ぽっちゃま」が大好きということで、 調べてしまったw 続きを読む 今回はUTについてです。 ここでいうUTは主にxUnitの話です。 フレームワークのようなある程度期間が長くいろいろなコンテキストで使われるものの場合、 自動回帰テストは欠かせません。これをUTレベルでサポートするのがxUnitです。 また、開発促進のためのやりたい事を明確にするのもxUnitあってのことです。 TDDのような手法を実現しようとすると事前にテストを何かの形で明記しておく必要があり、 それが動く仕様となって仕様の番人となります。 続きを読む 0.3である、コードネーム「Diet」に向けての絶賛調整中です。 機能のブラッシュアップとサブプロジェクトの分離が目下の課題。 「Diet」は機能を極小化するのを目標にしてて、こいつをまずはリリース対象としたいなと考えてます。 リリー

    2008-07-09
    itengineer
    itengineer 2008/07/09
    「仕様の番人」とは面白い表現!
  • 知っておきたいテストの“イロハ”(1):ITpro

    テストの基的な知識は、あまねくITエンジニアが持つべきだ。しかし実際には、当に基的な知識でさえ浸透していないのが現状である。そこでこの記事では、ITエンジニアが最低限知っておくべきテストの基知識と、その活用方法を解説する。 社会的なインフラとして構築された大規模システムで,大きな障害が多発している。こうした問題を防ぐためにも,高品質なシステムを開発する必要性がますます高まっていることは言うまでもないだろう。 システムの品質を向上させるためには,しっかりと設計を行い,それに基づいて正しく実装する必要があるのはもちろんだが,最終的にはシステムを動作させてテストするしかない。 テストで品質を検証するためには,周到なテスト計画やソフトウエアの特性に合わせたテスト設計,効率的なテスト管理が必須となる。そのためには,品質管理の担当者だけではなく,プロジェクト・マネジャーやリーダー,SEにも,テ

    知っておきたいテストの“イロハ”(1):ITpro
    itengineer
    itengineer 2008/07/09
    タスクを全部追っておこう
  • 2008-07-06

    さすがにOSI参照モデルまで疑おうとすると範囲が広すぎてしまいますが、 (X)HTMLJavaScriptCSSに絡むテストケースはいわばクライアントの影響を もろに受ける部分な訳で(Flexならなおのこと)、これを業務ロジックとかRDBMSとの連携の部分と いっしょくたに取り扱おうとしても、そもそもがきれいに結びついてくれないと思います。 という訳で、プログラム自体をなるべく小分けにして、個別にテスト出来るようにすることでまずテストケースの組み合わせ爆発を防ぎ、かつクライアント向けのコードとサーバ・サイドのコードと同じ視点で扱わなくても良いような設計にしてあげないといけないな、と。 (途中略) それよりも、フレームワークという単語が指し示す「枠組み」としての側面を強調して、生産性というか作業効率に寄与するようなものを目指さないと、ですね。 http://d.hatena.ne.jp/

    2008-07-06
    itengineer
    itengineer 2008/07/07
    まぁ、王道が通っていない土地もある訳で。。。
  • Google Code Archive - Long-term storage for Google Code Project Hosting.

    Code Archive Skip to content Google About Google Privacy Terms

  • 第5回 単体テスト | gihyo.jp

    今回は、テスト工程の1つである単体テストにフォーカスを当てます。前回、前々回ではテストケースを作成する技法を見てきましたが、そこで作ったテストケースをどのように実行するかという観点で、単体テストの基的な進め方と、ツールを用いた単体テストの実行方法について解説していきます。 単体テストとは 単体テストとは、ソフトウェアを構成する最小単位である関数やメソッドに対して品質を確認する作業です。ソースコードレベルでのテストと考えるとわかりやすいでしょう。 一般的なテストにおいては、先入観なくテストするためには、テスト対象を作った人以外がテストをすることが望ましいのですが、単体テストに関しては、作業効率を考慮して、ソースコードを作ったプログラマ自身が実施するのが一般的です。 また、単体テストはツールを用いることで効率よく実施できます。よく使われるツールには、xUnitと呼ばれる単体テスト用のテスティ

    第5回 単体テスト | gihyo.jp
  • 第1回 最初の仕事にとまどっていませんか? | gihyo.jp

    新人研修も終わり、晴れて配属となったA君。不安と期待を胸に職場のドアを開けました。 A君「Aです!はじめまして!」 M先輩「私が君の教育担当となるMだ、頑張ってな。」 A君「はい!」 M先輩「じゃぁ早速だけれど簡単な仕事をやってもらおうかな?」 (うわー、早速プログラムを作れるんだ!) A君は期待に胸を膨らませながら先輩の次の一言を待ちました。 M先輩「仕事に取りかかる前に、プロジェクトについて説明しよう。このプロジェクトは○×社様向けのソフトウェアを作っているんだ。ちょうど先週からテスト工程に入ったところだ。Aさんにもテストをやってもらおうと思っている」 A君「え、プログラム作るんじゃないんですか?」 M先輩「まぁ配属されたばかりだし、ちょうど人手が足りなくてね。ここにテスト手順書があるから、このとおりにテストやってくれれば大丈夫だから。この部署の雰囲気になれるためにも、ひとつよろしく頼

    第1回 最初の仕事にとまどっていませんか? | gihyo.jp
  • アジャイルとシステムテストの新たな関係(前編)

    The Rational Edgeより: 自社製品の品質改善とタイムリーなリリースを行う手段の1つとして、多くの企業がアジャイル開発手法の採用を進めている。どの会社やチームも、アジャイル開発環境においてシステムテスト戦略を最良の形で実行に移す方法を見つけたいと考えている。 [Mary Ellen Kerr(System Test, IBM), Curt J. Rousse(System Test, IBM), Donna P. Dynes(Development Manager, IBM), Dave Booz(Development Manager, IBM),@IT] 稿で使う「システムテスト」という言葉は、ソフトウェア製品を顧客に提供する前に行われる最終製品テストを指す。このテストは、開発と機能検証テスト終了後に行われるのが一般的だ。コードのシステムテストが実行できるかどうかを判断

  • 僕的な理解のTDD - 404 じゃばてないわー Not Found(一部X-RATED)

    何となくTDDわっしょいわっしょいするのも良いんだけど、実際のところ私がどうやってるのかなーというのを書いてみます。えーそんなんかよーって思うかもしれないのだけど、つまりはこう進めるんでしょ?っていう自分なりの理解を書いてみる。まずアイデアが必要とにかくちょーおぼろげでもいい。YAGNI・・・じゃねーや・・・えーとWYSIWYGでもないなーなんかなんとか言う原則。見ないことには何が欲しいかわかんないよねーというやつ。とっかかりのアイデアを膨らませていくと、自分の場合どこまでも広がっていって破綻してしまうので、とりあえず一番おおざっぱな「あーこんなことしたい」って言うのを考える。今回はアノテーション使ってコマンドラインオプションをうまいことビーンにマッピングできないかなー位のことを考えてみた。どういう風なプログラムを書きたいか考える自分と会話というとてもネクラなアクティビティを実施します。陰

  • ウノウラボ Unoh Labs: テスト担当者のモチベーション #2

    こんにちは! やまもと@テスト番長です。 今年も梅雨の季節になりました。これから毎日じめじめするのかと思うと、どうしてもテンションが下がりがちになりますね。前回モチベーションのお話をしたのですが、その後で良い記事を見つけたのでご紹介したいと思います。 Out of the Rut By Michael Bolton テストに飽きてしまったらどうしたらよいか?という問題について筆者の経験から色々とアドバイスをしてくれています。詳細は記事を読んでいただくとして、見出しだけちょっとまとめてみましょう。 担当箇所を取り替えてみる 担当箇所を他のメンバーと交換すると、より上手くいくようになるかもしれません。 変化をつける いったん手を止めて、今と違うアプローチの仕方を考えてみましょう。 他の人々とコミュニケーションする プログラマとチャットしたり、ハマる箇所についてユーザーと話したり、他のテ

    itengineer
    itengineer 2008/06/03
    良いアドバイスをいただいた
  • テストにも多角的な視点を(218~224日)

    前回に続き、「テスト」を巡るさまざまな事項や課題を取り上げる。テストにも顧客の立場に立った、多角的な視点が欠かせない。そして稼働後の事故防止につながるバグ情報の分析と活用も重要だ。 テスト中に偶然、変な現象が発生したが、発生条件や経緯が不明確で不良とは断定しにくい場合も出てくる。それでも、「こんなあいまいな事故報告では設計者も納得しないから報告しないでおこう」と無視するのはやはりよくない。あいまいな事象でもせっかく見つかったのだから問題点として取り上げ、報告しておく必要がある。 確認のため再テストしても再現せず、原因究明もできなくて、最終的には何の対策も打てないかもしれないが、重大な事故の前兆である可能性もあるのだから、見つけたものは根拠薄弱でも設計者にきちんと伝えたいものだ。 総合テスト段階になると、システムの品質は安定してくるが、それでも週に1回とか、月に1回とか事故が発生し、顧客から

    テストにも多角的な視点を(218~224日)