まだまだ寒い日が続きますね。冬は大嫌いです。 寝起きも悪くなるし、きっと前世はトカゲなのでしょう。 さて、前回で紹介したテストケースの重要な欠陥ですが それは、「ファイルに対する編集内容が、明確に記載されていない」事です。 Excelで「編集」と言っても、文字列の追加、フォントの変更、 数式の参照元変更、画像の読み込み、オートシェイプの挿入、 マクロの記録など、ユーザーが編集できるものは様々です。 その内容を、テスト設計者や実施者の頭の中で理解できていたとしても、 ドキュメントに残っていなければ、第三者には全く伝わりません。 もし仮に、「フォントサイズを変更して上書き保存しても、再度ファイルを開くと フォントサイズが保存前のまま変わっていない」というバグが後から発覚した場合、 そのテストを本当に実施できていたかどうか、追跡できない可能性があります。 テストケースは単なる手順書ではなく、記録
ORM やウェブアプリケーション関連のライブラリなどのテストケースを書くにあたっては、 RDBMS へのアクセスが必要になります。しかし、SQLite のようなスタンドアローンのデータベースと比較すると、サーバ型データベースである MySQL に接続してテストを書くのは、既存の MySQL の権限設定やデータベース名を気にする必要があったりと、いろいろ不便です。そこで、MySQL のインスタンスをテンポラリディレクトリに自動生成し、テストが終わったら削除してくれる Perl モジュール Test::mysqld を書きました。こんな感じで使います。 use DBI; use Test::mysqld; use Test::More; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '' }, # TCP接続を
Googleのオープンソースプロジェクトは16日、Python用テストフレームワーク「MOX」を公開した。Google Code内のMOXプロジェクトのページよりダウンロードできる。 MOXはPython向けのMockオブジェクトフレームワークで、JavaのライブラリであるEasyMockを基に作られた。データベースやファイルシステム、Pythonのクラスやモジュールといった、テストの際に依存関係があるパーツのMockオブジェクト（ダミー）を作成できる。 Mockオブジェクトとは、実際の処理を行わずに定数値だけを返すオブジェクト。テスト対象モジュールがダミーオブジェクトとして呼び出し、使用する。 例えば入力メソッドの動きをテストする際は、データベースのローカルコピーを作成するかわりにMOXを使うことで、データベースに対する呼び出しや反応をシミュレーションできる。 インストールする場
ソフトウエア・テストの進め方については，「ソフトウエア・テストの基本を学ぼう」で紹介しました。ただ，実際にテストを進めて行く段になると，テスト設計をうまく行うための「技法」や，テスト実施を効率良く行うための「ツール」を使いこなすスキルも求められます。そこで，Part1ではテスト設計技法の全体像を解説し，Part2ではホワイトボックス，Part3ではブラックボックスのテスト設計技法についてそれぞれ解説します。また，Part4ではJUnitとdjUnitを使ってホワイトボックスとブラックボックス手法それぞれについての実践例を説明します。最後のPart5では，テストの効率化を支援するツールについて，どのようなものがあるのかを紹介します。 Part1 テスト設計技法の全体を理解する Part2 ホワイトボックス技法 Part3 ブラックボックス技法 Part4 テスト実行の実践方法 Part5 テ
この文書はVisual Studio 2005 TSかTE for SD(.NET 2.0)をベースに記述されています 。 単体テストを行う場合にもろもろの設定ファイル等が必要になる場合があります。 簡単なファイルだけあればよいなどの場合にはテストの前後で作成/削除を行えばいいのですが、テストデータを持っていきたい場合にはどうすればいいでしょうか。 単体テストの実行は少し複雑な手順を踏みます。 大体のフォルダ構成が以下のような構成をとっていると思います。この文書ではこのフォルダ構成で行われていると仮定します。 実際に実行される順番は以下のようになっています。 この4と5の間で初期設定を行うイメージでファイルを収集することが出来ます。 Solution Itemsの中にあるtestrunconfigファイルを開きます。 ここでファイルやフォルダを指定すると、その指定された内容が実際にテストが
Pex: Automated Exploratory Testing for .NET http://research.microsoft.com/Pex/ Microsoft Resarchのツール。 手書きのUnitTestコードを実行し、実行パスをモニタリングすることによって条件分岐のポイントを発見し、 そのテストでは通らなかったパスを通るような条件のテストコードを自動的に生成する。 生成されたテストコードを再度実行し、それでも実行されなかったパスを通る条件のテストコードを生成する。 さらに。。。。を繰り返し、テストのカバレッジを向上させようとするツール。 自動生成されたコードは、ファイルとして残るので、このコードを修正することで、それぞれのパターンでの期待値も設定することが可能のようだ。 実際の使い方は、こちらのVideoを参照 http://channel9.msdn.com/p
ユーティリティ ウイルスバスター2009 無料体験版" /> 【新発売】 ウイルスバスター2009 無料体験版 「2009」は動作とスキャンが更に軽快になりました！体験版を使うと「お得」なキャンペーンを10/16まで実施！まずは30日無料体験版をお試しください！
Mockpp 導入ガイド Mockppとは… 単体テストのフレームワーク CppUnit による自動テストはモジュールの品質を高め、安全/確実なソフトウェアの構築に大きな効果をもたらします。しかしながら CppUnitがうまく適用できないシチュエーションにも少なからず直面します。 ナビゲータ(class Navigator)の実装を考えてみましょう。ユーザはナビゲータに適当な複数のキーワードを与えます。ナビゲータはあらかじめ用意されたDatabaseにそのキーワードを食わせると、その検索結果としてURLが得られるものとします。さらにWebブラウザを制御するクラス:Browserも提供され、これにURLを与えるとブラウザに引き渡してくれるとしましょう。 つまり、Navigatorはその機能の実現にDatabaseとBrowserを利用することになります。DatabaseおよびBrowserは
///<summary> ///Subtraction (int, int) のテスト ///</summary> [TestMethod()] public void SubtractionTest() { Calculater target = new Calculater(); int i = 0; // TODO: 適切な値に初期化してください int j = 0; // TODO: 適切な値に初期化してください int expected = 0; int actual; actual = target.Subtraction(i, j); Assert.AreEqual(expected, actual, "CodeZineSample_UnitTest_VSTD.Calculater.Subtraction は 予期する値を返しませんでした。"
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 現場で使えるソフトウェアテスト Java編: 町田欣史: 本