テストに関するmq2006のブックマーク (7)

  • ソフトウェアテストでマインドマップを使うといいらしい: ある SE のつぶやき

    ソフトウェアテストとマインドマップのちょっとイイ関係(gihyo.jp) この記事は、なかなか興味深いです。 システム仕様書や基仕様書は,複数人の設計者がよってたかって,頭を使うだけ使って,再三にわたるレビューをくぐり抜けた末に,ようやくできあがります。まさに設計者の英知の結晶とも言えるでしょう。 つまり,テストではある意味設計者以上に「よーっく考える」ということが大事なのですが,この「よーっく考える」というプロセスはマインドマップとちょっとイイ関係なのです。 テスターは、設計者よりも「よーっく考える」ことが必要で、テストを行うにはマインドマップが良い感じだそうです。 で、マインドマップがテスト時の「モデリング支援ツール」になるという発想がおもしろいですね。 テストでモデリングするとは、今まで考えたことがないですが、ちょっと試してみたいですね。 ■関連エントリー mind42.com -

  • .NET Tools : テスト駆動開発ツール最前線(後編)(2/3) - @IT

    これが意味するところは、従来はテスト対象のメソッドの表側しかチェックしていなかったものが、メソッドの裏側からもチェック可能になることを意味する。表側のチェックは、メソッドがすべての処理を終了してから結果をチェックすることになるので、メソッドのどこで問題が起きたか分かりにくい。 それに対して、裏側のチェックは、パラメータに渡したMockオブジェクトのメソッドが呼び出されるときに行われるので、テスト対象メソッド実行の途中で意図した呼び出しシーケンスから外れた瞬間にそれを検出することができる。それにより、問題発生個所の検出精度がアップするとともに、より具体的に問題の内容を把握できる可能性が出てくる。 では、具体的に、このようなMockオブジェクトをどのように用意すればよいのだろうか。もし、あまりに膨大な手間がかかるのであれば、いくらメリットがあろうと現場では実践できないことになる。果たして、どの

  • コンピュウェアーのセミナー: 知識ゼロから学ぶ ソフトウェアテスト

  • 【中級】無駄なく確実にテストする I 単体テスト

    図5●静的解析の効果は高い<BR>静的解析とは,プログラムを実行せずにソースコードの内容をチェックする作業。バグを生みやすいコーディングはしていないか,可読性や保守性が下がるコーディングはしていないか,などの観点から解析する。コーディング終了時にレビューとして実施することも多い。レビュアのスキルが高ければ,メモリー・リークやマルチ・スレッドのバグも発見できるなど,より効果が高まる テストの最初に位置する「単体テスト」(モジュール・テスト,ユニット・テスト)は,すべてのシステムで実施されるべき基的なテストである。実装された関数やメソッド(以下,プログラム)の内部構造のバグを取る。通常,コンパイルした直後に実施され,デバッガなどを用いるケースもあるため,プログラマ自身が実施することも多い*2。後工程になるほどバグの修復コストが高くなることを肝に銘じて取り組みたい。単体テストで実施するテストに

    【中級】無駄なく確実にテストする I 単体テスト
  • ページが見つかりません | 無料ブログ作成サービス JUGEM

    //次のことをお試しください ページアドレスが正しいかをご確認ください ブラウザの更新ボタンをクリックし、ページの再読み込みをお試しください

  • NUnitのテストコード自動生成ツール - NAgiler航海日誌v2

    興味深いツールをみつけました。NUnitのテストコードを自動生成してくれるツール、その名も「NUnitGenAddIn」です。テストコードが無い既存のコードに対してテストを追加する場合に利用するものだそうです。 NUnitGenAddIn http://developer.novell.com/wiki/index.php/NUnitGenAddIn で、さっそく試してみました。 【利用手順】 1.まずは上記サイトにある「NUnitGenAddIn4VS2005-bin-v0.1.1.zip」をダウンロードします。 2.次にダウンロードした圧縮ファイルを解凍し、VS2005アドインフォルダへコピーします。 VS2005アドインフォルダ \My Documents\Visual Studio 2005\Addins 3.NUnitGenAddIn.AddInファイル内の/Extensibli

    NUnitのテストコード自動生成ツール - NAgiler航海日誌v2
  • 「テストしやすい」ことが、良い設計(EoT=Ease of Testing) - An Agile Way [ITmedia オルタナティブ・ブログ]

    良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。 ぼくは、 EoT(*1)の高い設計が、よいオブジェクト指向設計である。 と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、

    「テストしやすい」ことが、良い設計(EoT=Ease of Testing) - An Agile Way [ITmedia オルタナティブ・ブログ]
  • 1