テスト関連の記事に関するページ †
記事（Wiki化以前） †
blog / Web サイト †
- KGussan Webpage / ソフトウェアテスト
- 吉田誠一のホームページ / ソフトウェア工学 / 技術コラム
- IT 技術情報 整理サイト / ソフトウェアテスト
記事（Wiki化以後） †
- 私たちの活動はこうして始まった
- TestLink日本語化部会
- 2007/7/14
- gihyo.jp / DEVELOPER STAGE / テストエンジニアのコミュニティ活動のススメ
- http://gihyo.jp/dev/serial/01/te_community/0001
- （引用）本連載では，このTestLink日本語化部会のメンバーが分担して，ソフトウェアテストエンジニアのコミュニティ活動についてご紹介します。初回である今回は，そもそもTestLinkとは何かということや，部会発足の経緯などについてご紹介していきたいと思います。
- 継続的テスト
- 松野 徳大
- 2008/7/14
- gihyo.jp / DEVELOPER STAGE / Happy Testing Perl
- http://gihyo.jp/dev/feature/01/test-perl/0005
- （引用）今回は継続的なテストという話題についてお話したいと思います。本稿では，少人数のチームによるWebサイト開発というケースにフォーカスして論じていきます。本稿で取り上げる継続的テストとは，端的にいえば「自動でテストを定時実行させる」ということです。 make testするのをうっかり忘れたりしていませんか？ テストを動かすのを面倒がってテスト動かさずにコミットしていませんか？ そして，そのままデプロイしたりしていませんか？
- キャプチャ／リプレイツールによる機能テストの自動化
- コピー＆ペーストでテスト仕様書を作っていませんか？
- 鈴木 三紀夫, 池田 暁
- 2008/7/14
- gihyo.jp / DEVELOPER STAGE / 新人注目！ テストを極める最初の一歩
- http://gihyo.jp/dev/serial/01/test_newface/0003
- （引用）過去の成果物を活用して仕事を早く終わらせることは大切です。しかし，新人の皆さんにとって，今は基礎を固めるという大事な時期でもあります。基礎固めをおろそかにしてしまうと後々つらい目に遭ってしまいます。テストにおける基礎固めとはテスト設計です。テストにも「設計」があります。新人の皆さんが第一に覚えて，身に付けなければならないことは，テスト設計なのです。第3回は，仕様書の読み解き方と，テスト設計の初歩について説明します。
- 「懐石料理」でインドの「スパイス」をうまく使う方法
- PMP──Project Management Professional
- やみくもにテストをしていませんか？
- 鈴木 三紀夫, 池田 暁
- 2008/7/4
- gihyo.jp / DEVELOPER STAGE / 新人注目！ テストを極める最初の一歩
- http://gihyo.jp/dev/serial/01/test_newface/0002
- （引用）頭を使わずやみくもに手を動かすテストが必要な局面というのはあります。しかし，新人でその局面に遭遇するケースというのはあまり無いでしょう。やみくもなテストではなく，やらなくてはいけないテストを任されることが多いはずです。第2回は，この「やみくもなテスト」の問題点と「やるべきテスト」との違いを説明します。
- アジャイルとシステムテストの新たな関係（後編）
- Mary Ellen Kerr, Curt J. Rousse, Donna P. Dynes, Dave Booz
- 2008/7/1
- @IT / 情報マネジメント / アーキテクチャ / The Rational Edge
- http://www.atmarkit.co.jp/im/carc/serial/redge/74/01.html
- （引用）前回は、アジャイル開発プロセスにシステムテストのサブセットを含めた経緯、作業の経過、および結果としてうまくいった点について解説した。今回は、逆に今後の課題として残った点と、開発以外のプロセスに与えたメリットについて説明する。
- テスト環境の構築に使用できる仮想ツールにはどのようなものがあるのか？
- Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介
- アジャイルとシステムテストの新たな関係（前編）
- Mary Ellen Kerr, Curt J. Rousse, Donna P. Dynes, Dave Booz
- 2008/6/24
- @IT / 情報マネジメント / アーキテクチャ / The Rational Edge
- http://www.atmarkit.co.jp/im/carc/serial/redge/73/01.html
- （引用）自社製品の品質改善とタイムリーなリリースを行う手段の1つとして、多くの企業がアジャイル開発手法の採用を進めている。どの会社やチームも、アジャイル開発環境においてシステムテスト戦略を最良の形で実行に移す方法を見つけたいと考えている。（略）本稿は、あるチームがわれわれのアジャイル開発環境の一環として、コード開発と並行してシステムテストの一部を含める際に取ったアプローチを解説する。
- 単体テスト
- 加藤 智巳, 町田 欣史
- 2008/6/24
- gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
- http://gihyo.jp/dev/serial/01/tech_station/0005
- （引用）今回は，テスト工程の1つである単体テストにフォーカスを当てます。前回，前々回ではテストケースを作成する技法を見てきましたが，そこで作ったテストケースをどのように実行するかという観点で，単体テストの基本的な進め方と，ツールを用いた単体テストの実行方法について解説していきます。
- 最初の仕事にとまどっていませんか？
- 鈴木 三紀夫, 池田 暁
- 2008/6/24
- gihyo.jp / DEVELOPER STAGE / 新人注目！ テストを極める最初の一歩
- http://gihyo.jp/dev/serial/01/test_newface/0001
- （引用）国内の開発現場においては，新人の現場配属時の最初の仕事として，テストのお手伝いを指示されることが多いようです。プログラムが書けると思って期待していたらテストの手伝いだったため，勝手が違ってしまい仕事のミスをしてしまう人もいます。この最初の仕事で大きなミスをしてしまうと職場からの印象が悪くなってしまい，将来やりたかった仕事にまで影響してしまうかもしれません。そんなことにならないように，第1回は，新人がおろそかにしがちな準備・確認事項・心構えについて，最低限押さえなければならないポイントを解説していきます。
- 会社のシステムインフラをテスト環境にレプリケートする方法
- Test::Declareの紹介
- 小林 篤
- 2008/6/18
- gihyo.jp / DEVELOPER STAGE / Happy Testing Perl
- http://gihyo.jp/dev/feature/01/test-perl/0003
- （引用）今回は私が開発したPerlモジュールのTest::Declareについて紹介します。Test::Declareには，以下の特徴があります。・テストコードをDSL風に（宣言的に）書く事を重点に置いている。・それによりテストコード自体の見やすさを向上させることができる。・宣言的にテストを書く事により，一体なにを目的としたテストなのかがわかりやすくなる。
- JSTQBテスト技術者資格認定
- 正木 威寛
- 2008/6/13
- gihyo.jp / DEVELOPER STAGE / これだけはとっておきたい「テスト技術者」の資格
- http://gihyo.jp/dev/serial/01/se_skilup/0001
- （引用）本連載では，テスト技術者やテストに関係するSEのスキルアップに役立つ資格を紹介していきます。まず第1回目にご紹介するのは，ズバリ“テスト技術者”のための資格「JSTQB認定テスト技術者資格 Foundation」です。
- Test::Baseの紹介
- 伏原 幹
- 2008/6/11
- gihyo.jp / DEVELOPER STAGE / Happy Testing Perl
- http://gihyo.jp/dev/feature/01/test-perl/0002
- （引用）今回Test::Baseというモジュールを紹介させてもらいます。Test::Baseは，Kwikiなどの作者として知られるIngy döt Net氏が作成した“Data Driven Testing Framework（データ駆動型テストフレームワーク）”です。
- 「バッファ込み」の工数がスケジュール遅延の原因
- 新楽 清高
- 2008/6/4
- @IT / 自分戦略研究所 / スキル創造研究室 / システム開発プロジェクトの現場から
- http://jibun.atmarkit.co.jp/lskill01/rensai/pgenba15/pgenba01.html
- （引用）最初に立てたスケジュールどおりにプロジェクトが進行せず、だんだんと遅れていく……。そんな経験はありませんか？今回は、すでに稼働しているシステムへの機能（サブシステム）追加開発プロジェクトでの経験を基に、プロジェクトのスケジュール管理の難しさについてお話しします。（略）プロジェクトは開発・単体テストくらいまではさほど問題なく進んでいきました。しかし、最初の分類の結合テストを開始したころから、徐々に遅れが出始めました。遅延理由の代表的なものは、「イレギュラーケースに対応できていなかった」「想定する必要がないケースのテストを実施していた」などです。
- WindowsアプリのUIテストを自動化しよう
- 亀野 弘嗣
- 2008/6/3
- @IT / Insider.NET / UIオートメーションによる自動UIテストの実践
- http://www.atmarkit.co.jp/fdotnet/special/uiautomation/uiautomation_01.html
- （引用）読者の方々は、UI（ユーザー・インターフェイス）にかかわるテスト（以下UIテスト）を自動化できているだろうか？ UIテストを自動化しようとしても、UIテストのコードは記述しにくく、記述方法に一貫性がない、などの理由から、自動化をあきらめる場合が多いのではないだろうか。.NETの開発においても単体テストの自動化は一般的に行われるようになってきているものの、UIテストの自動化はそういった理由で実現が難しく、あまり行われていないのが現状だ。そこで本稿では、標準的で一貫性のある記述ができるMicrosoft UIオートメーション（以下UIオートメーション。詳細後述）と、テスト・ツールであるNUnitを使用して、UIテストを自動化する方法を紹介する
- 開発者のためのスケーラビリティテストとゴールテスト
- Michael Ault
- 2008/5/23
- CodeZine / ツール / テスト
- http://codezine.jp/a/article/aid/2494.aspx
- （引用）多くの場合、開発者はコードを記述するだけでなく、コードがアプリケーション環境で適切なスケーラビリティを持ち、適切に動作することを保証しなければなりません。本稿では、スケーラビリティテストとゴールテストの違いを取り上げ、手動テスト向けの擬似コードテストハーネスの例を紹介し、実際にQuest SoftwareのToadという自動テストインターフェイスを使用してOracleプロシージャのテストを行う例を示します。
- ソフトウェアテストを分類する
- 町田 欣史
- 2008/5/13
- gihyo.jp / DEVELOPER STAGE / ソフトウェアテスト基本テクニック
- http://gihyo.jp/dev/serial/01/tech_station/0001
- （引用）今回からソフトウェアテストに関するテクニックについて連載していきます。ただ，一口にソフトウェアテストといっても，非常に幅広いものです。そこで，ソフトウェアテストを分類，整理した上で，そのうちの主なテストの種類について取り上げていきたいと思います。そこで今回は，まずソフトウェアテストの分類について解説していきます。
- Spring Frameworkによるソフトウェアテスト
- Srini & Kavitha Penchikala
- 2008/4/8
- InfoQ
- http://www.infoq.com/jp/articles/testing-in-spring
- （引用）ソフトウェアテストを開発プロセスに統合する強力なサポートを提供するよう、徹底的に構築されたJ2EEフレームワークがいくつかある。Springは、そのようなjavaエンタープライズアプリケーション開発フレームワークの1つである。（略）この記事では、単体/統合テストの分野でSpringフレームワークが提供するサポートの概要について説明する。一般的なJava EEアプリケーションでのアジャイルテスティングフレームワークの実装と、Springテストクラスを使用したアプリケーション機能のテスト方法について、読者の方の参考となるように、ローン処理のWebアプリケーションの例を取りあげる。
- 第5回 PICTの機能説明と使用例 （後編）
- 鶴巻 敏郎
- 2007/12/12
- gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに！
- http://gihyo.jp/dev/feature/01/sp-test/0005
- （引用）PICTの使いやすさがおわかりいただけたでしょうか。同様なことを直交表ベースで行おうとすると，専用のソフトウェアを自力で開発しなければ不可能だと思われる機能がほとんどです。人手でもやれる機能もありますが，その場合でもPICTに比べてはるかに時間がかかってしまいます。
- 第10回 テスト方法−−品質とコストに大きく影響するテスト方法を決める
- 第9回 テスト範囲を最適に決める：本番リリースは開発者以外が行う
- 第2回 PICTの基本的な使い方
- 鶴巻 敏郎
- 2007/11/21
- gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに！
- http://gihyo.jp/dev/feature/01/sp-test/0002
- （引用）PICT（Pairwise Independent Combinatorial Testing tool）はMicrosoft社が開発したソフトウェアテストツールです。Microsoftでは2000年からこのツールをテスト業務に使用しています。ツール開発者はPICTが備えている柔軟性のおかげでテスト担当者がテスト対象を抽象化し，モデル化するレベルを向上させ，組み合わせテストが実施しやすくなったと述べています。PICTは，複数のパラメータの組み合わせテストケースを，オールペア法（ペアワイズ法ともいう）を用いて自動生成します。（略）PICTはフリーソフトウェアです。（略）今回はPICTの基本的な使い方を説明するとともに，日本語を扱えるようにする方法についても説明します。
- 第8回 テスト範囲を最適に決める：シナリオや環境整備でテストを効率化する
- 第1回 組み合わせテストの技法
- 鶴巻 敏郎
- 2007/11/14
- gihyo.jp > DEVELOPER STAGE > 組み合わせテストをオールペア法でスピーディに！
- http://gihyo.jp/dev/feature/01/sp-test/0001
- （引用）この特集では，ソフトウェアの組み合わせテストについての技法である「オールペア法」と，オールペア法を採用したテストケース作成ツール「PICT」の機能，およびその効果的な使い方を，多くの例を用いて解説していきます。（略）ソフトウェアはさまざまな因子（パラメータ）の組み合わせにより，その挙動が違ってきます。これらパラメータの組み合わせを総当りで行うことはテスト件数の爆発を招き，実際に行うのは多くの場合，不可能です。（略）こうした課題を解決するために考え出された効率的な組み合わせテスト技法は，大規模，複雑化するソフトウェアの組み合わせテスト件数を大幅に削減することが可能な技法です。この技法には，直交表と，オールペア法の2つがあります。
- 第7回 テスト範囲を最適に決める：過去のテスト項目集めて漏れを減らす
- 第2回 ソフトウエア改造力が足りない：工数膨らませる影響調査と確認テスト
- 森山 徹
- 2007/11/13
- IT Pro / 情報システム / ソフトウェア改造力
- http://itpro.nikkeibp.co.jp/article/COLUMN/20071102/286259/?ST=system
- （引用）改造ならではの難しさとは，「既存システムへの影響調査」と「“他に影響がない”ことを確認するテスト」の二つに集約できる。（略）「テストにより現行機能を保証する必要があることが新規開発との違い。新規に比べてテスト時間は長くなる」（略）「新機能がきちんと動くことを確かめる“オモテ”のテストと，これまで動いてきた機能に影響が無いことを証明する“ウラ”のテストが必要。ウラのテストをやっていないときに限って，後からトラブルになる。テスト・パターンが膨大なので，これをいかに効率化するかが課題だ」。
- 第9回 テスト計画−−品質管理方針を基にプロジェクト全体のテスト計画を作成する
- 第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む
- [テスト編]すべての結合テストを自動化してはいけない
- [テスト編]本番環境でいきなりテストしてはいけない
- 第7回 問題管理と変更管理--プロジェクトで生じた問題と仕様変更をコントロールする
- ソフトウェアテスト技術
- 大塚 俊章, 荻野 富二夫
- 2007/8
- ユニシス技法 / 93号「ソフトウェアエンジニアリング」
- (PDF)http://www.unisys.co.jp/tec_info/tr93/9306.pdf
- （引用）テスト技術に関する誤解や認識の違いが、ソフトウェア品質の低下を引き起こしたり、場合によってはプロジェクトの成否すら左右する場合があることが、日本ユニシス品質保証部が実施している第三者レビュ等の品質保証活動を通して明らかになってきた。オフショア企業に開発委託しているプロジェクトで特にその傾向があるが、昨今のシステム構築プロジェクトが抱えている共通の問題とも思われる。本稿では、特に誤解が生じやすく、よって委託先と共通理解を確立しておくべきテストの考え方と技術について述べる。
- Ajaxアプリケーションのユニット・テスト
- Andrew Glover
- 2007/7/24
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq07247/
- （引用）Ajax アプリケーションを作るのはワクワクすることですが、そのアプリケーションのユニット・テストには実に四苦八苦します。今回の記事で Andrew Glover が取り上げるのは、そんな Ajax のマイナス面 (マイナス面のひとつである)、非同期 Web アプリケーション特有のユニット・テストの問題です。彼が発見したように、Google Web Toolkit の助けを借りれば、この非同期 Web アプリケーションのコード品質の問題を思ったより簡単に解決することができます。
- 第3回 品質管理計画−−プロジェクト全体を通じた品質基準や方針を策定する
- SeleniumとTestNGを使ったプログラムによるテスト
- Andrew Glover
- 2007/4/3
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq04037/
- （引用）Selenium は、Web アプリケーションでのユーザー受け入れテストを簡単に実行できるテスト用フレームワークです。Andrew Glover が今月紹介するのは、この Selenium のテストを、TestNG をテスト・ドライバーとして使い、プログラムによって実行する方法です。TestNG の柔軟なテスト機能 (パラメーターを使ったフィクスチャーを含め) を Selenium 固有のツールキットに加えれば、後は DbUnit と Cargo の助けをほんの少し借りるだけで、完全に自動化した、しかも論理的に反復可能な受け入れテストを作成できます。
- TestNG-Abbot による GUI テストの自動化
- Andrew Glover
- 2007/2/27
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq02277/
- （引用）TestNG-Abbot は、GUI コンポーネントのテスト方法に新風を吹き込むテスト用フレームワークです。今月は Andrew Glover が、TestNG-Abbot による GUI テストで最も難解な部分、つまりユーザー・シナリオがどのように展開するかを把握すること、について説明します。これさえ理解してしまえば、このフレームワークの便利なフィクスチャー・オブジェクトを使って GUI コンポーネントを分離して検証するのが、どれほど簡単であるかがわかるはずです。
- JUnitPerfによるパフォーマンス・テスト
- Andrew Glover
- 2006/11/29
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq11296.html
- （引用）パフォーマンス・テストは通常、アプリケーション開発サイクルの最後まで棚上げにされます。パフォーマンス・テストが重要でないというわけではなく、不明な変数がありすぎるため効率的にテストするのが困難だからです。今月の「コード品質を追求する」シリーズでは、Andrew Glover が開発サイクルの一環としてのパフォーマンス・テストを提案し、2 つの簡単なテスト方法を紹介します。
- Part 1: ソフトウエア・テストがなぜ重要なのか
- 湯本 剛
- 2006/11/9
- ITpro / SkillUP / 日経ソフトウェア：ソフトウェア・テストの基本を学ぼう
- http://itpro.nikkeibp.co.jp/article/lecture/20061109/253147/?ST=lecture
- （引用）ソフトウエアの開発プロジェクトを，サッカーにたとえると，テスト担当者はゴールキーパーに相当します。サッカーでは，メンバー全員が「攻め」だけではなく「守り」もできなくてはなりません。この，サッカーで言う「守り」がソフトウエア開発におけるテストに当たります。（略）実際にテストはどのようなことをどんな順序で行っていくのでしょうか。その疑問に答えてくれるものの一つが，開発工程とテストとの関係を表す「Vモデル」です。（略）ソフトウエア・テストを行うために必要な五つの知識や技術を分類してみましょう。
- テストのカテゴリー化による素早いビルド
- Andrew Glover
- 2006/10/31
- developerWorks Japan / Java technology
- http://www-128.ibm.com/developerworks/jp/java/library/j-cq10316/
- （引用）開発者によるテストが重要であることは誰もが認めていますが、テストの実行にはどうしてそんなに時間がかかるのでしょうか。今月の記事では、Andrew Glover がエンド・ツー・エンドのシステムの安定性を確実にするために必要な 3 つのテスト・カテゴリーにスポットライトを当て、テストを自動でカテゴリー別に分類して実行する方法を紹介します。これにより、今日の膨大なテスト・スイートでさえもビルド時間が劇的に短縮されることになります。
- ファズ・テスト
- Elliotte Rusty Harold
- 2006/9/26
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-fuzztest.html
- （引用）ファズ・テストは単純な手法ですが、コード品質に与えるその影響は計り知れません。この記事では Elliotte Rusty Harold が、障害部分を調べるためにランダムな不良データを故意にアプリケーションに注入すると、どのような結果になるかを説明します。また、チェックサム、 XML データ・ストレージ、そしてコード検証など、ランダム・データに対するプログラムの脆弱性を解消するための防衛的コーディング手法についても説明しています。そして最後に、コードを守るための決定的手法として、コード・クラッカーとしての思考を持つ訓練で記事を締めくくっています。
- 反復可能なシステム・テスト
- Andrew Glover
- 2006/9/26
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq09266.html
- （引用）論理的再現性を持つテストの作成は、特にサーブレット・コンテナーを組み込む Web アプリケーションのテストとなると、とりわけ困難です。この記事では、コード品質の改善を追求し続ける Andrew Glover がコンテナー管理を汎用手順で自動化する Cargo を紹介します。このオープン・ソース・フレームワークによって、毎回論理的に反復可能なシステム・テストを作成できるようになります。
- JUnit4対TestNG
- Andrew Glover
- 2006/8/29
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq08296/
- （引用）新たなアノテーション・ベースのフレームワーク、JUnit 4 には TestNG の選り抜きの機能がいくつか含まれていますが、それによって TestNG が使われなくなることを意味するのでしょうか。この記事では、Andrew Glover がそれぞれのフレームワークの特徴を検討し、まだ TestNG にしか見当たらない高度な 3 つのテスト機能を明らかにします。
- テストのマネージメントとレポート(2)
- 湯本 剛
- 2006/6/5
- ITpro / ITレポート / 基礎から学ぶソフトウエア・テスト
- http://itpro.nikkeibp.co.jp/article/COLUMN/20060605/239909/?ST=develop
- （引用） たいていの場合，ソフトウエア・テストというと，どうやってテストをするのかといったテストの実施部分だけを思い浮かべるのではないでしょうか。しかし，テストを実施面だけでとらえていると，効果的なテストはできません。そこで，米国のソフトウエア技術者であるAndreas Spillner氏が提唱している「Wモデル」という考え方を紹介しましょう。このモデルでは，開発とテストは最初から並行して進んでいくプロセスとして表現しています。先ほど，「テストは同時並行的に進めるライフサイクルプロセスである」という定義を引用しましたが，まさにそのイメージがWモデルになるわけです。
- 今こそテストの基本技術を学ぼう！(3)
- 湯本 剛
- 2006/5/31
- ITpro / ITレポート / 基礎から学ぶソフトウエア・テスト
- http://itpro.nikkeibp.co.jp/article/COLUMN/20060531/239593/?ST=develop
- （引用）テスト設計には図のようなポイントがあります。テストはやろうと思えばきりがありませんから，最小限の労力で最大の効果が得られるように知恵を絞ろうというわけです。（略）テスト固有の技術の二つ目は，いかにテストを効率化して実施するかという技術です。（略）テスト固有の技術の三つ目は，テスト・ベースをレビューする技術です。テスト・ベースとは，テスト設計に使う設計資料一式のことを指します。テストベース・レビューの狙いは三つ，テスト設計の効率化，テスト実施の効率化，テストしやすさの設計への反映です。（略）テスト固有の技術の四つ目は，バグ報告の技術です。これは，バグを見つけたら，バグ・レポートを作成して，修正されたことを再テストして確認するまでを意味します。
- ConTestを使用したマルチスレッド・ユニットのテスト
- Yarden Nir-Buchbinder, Shmuel Ur
- 2006/4/4
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-contest/
- （引用）並列プログラミングは、バグが発生しやすいことで有名です。さらに悪いことに、並列プログラミングで発生したバグは開発プロセスの終わり近くになって発見されることが多く、この段階でのバグは開発プロセスに深刻な影響を与え、修正することも困難です。従来の単体テスト手法をどれだけ徹底的に実行しても、並列プログラミングにおけるバグをなくすことは困難です。この記事では、並列プログラミングに詳しいShmuel UrとYarden Nir-Buchbinderが、こうしたバグはなぜ見つけるのが難しいのかを説明し、IBM Researchによる新しい解決策を紹介します。
- レガシー・コードのテスト
- Elliotte Rusty Harold
- 2006/4/4
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq09266.html
- （引用）オブジェクト指向プログラミングの登場以来、テスト駆動プログラミングは最も効果的なコーディング技法となっていますが、この技法はコードが何もない状態からのスタートを前提としています。もしすでにコードが存在しているとしたら、どういう作業になるでしょうか。人気の高いオープン・ソースのJava™ ツールを例に取り、これまでにテストされたことのないレガシー・コードのテスト・スイート（テスト・セット一式のこと）を作成する方法について、 Elliotte Rusty Haroldが紹介していきます。
- FITで解決する
- Andrew Glover
- 2006/2/28
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq02286/
- （引用）JUnitでは、テストはすべて開発者の領域であると考えます。一方、FIT（Framework for Integrated Tests）を利用すると、要求を記述するビジネス顧客と、そうした要求を実装する開発者の間で協力してテストを行うことができます。では、FITと JUnitは競争相手なのでしょうか。絶対にそんなことはありません。この記事では、コード品質の完璧主義者であるAndrew Gloverが、FITとJUnitの良いところを組み合わせてチームワークを改善し、効果的なエンド・ツー・エンド・テストを行うための方法を解説します。
- カバレッジ・レポートに騙されないために
- Andrew Glover
- 2006/1/31
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq01316/
- （引用）テスト・カバレッジ・ツールを使うとユニット・テストに深みが増しますが、このツールは多くの場合、誤って使われています。今回はAndrew Gloverが、この領域での彼の長い経験を生かして、新しいシリーズ、『コード品質を追求する』を開始します。第1回目である今回は、カバレッジ・レポートに表れる数字が実際に何を意味するのか、また逆に数字に意味がない場合について詳しく見て行きます。そして、カバレッジ・ツールを初期段階で頻繁に使用してコード品質を向上するための、3つの原則を提案します。
記事（Wiki化以後・TDD関連） †
- なぜ従来のテスト自動化ツールはアジャイルを抑えつけるのか
- ビヘイビア駆動開発を舞台にした冒険
- Andrew Glover
- 2007/9/18
- developerWorks Japan / Java technology
- http://www.ibm.com/developerworks/jp/java/library/j-cq09187/
- （引用）テスト駆動開発 (TDD) は実際には素晴らしいアイデアですが、一部には、テストという言葉に結び付けられた考え方の飛躍にどうしてもついていけないという開発者もいます。そこでこの記事では、より自然な形で TDD のこの考え方をプログラミング・プラクティスに取り入れる方法を紹介します。JBehave を使ったビヘイビア駆動開発 (BDD) を試して、結果ではなくプログラムの振る舞いに重点を置くと、どんな変化が生まれるのか自分自身で確かめてください。
- テストファーストによるソフトウェア開発の衝撃（後編）
- テストファーストによるソフトウェア開発の衝撃（前編）
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
