タグ

testに関するpukumanのブックマーク (10)

  • test-unit - Ruby用単体テストフレームワーク

    test-unitRuby用のxUnit系の単体テストフレームワークです。Ruby 1.8まではRuby体に標準添付されていましたが、Ruby 1.9.1からはminitestというフレームワークが標準添付されています。test-unitRuby 1.8に標準添付されていた頃はほとんど機能拡張などがされず、RSpecなどより新しいテスティングフレームワークから見劣りするものになっていました。しかし、Ruby標準添付ではなく、1つのプロジェクトとして開発が進められるようになってからは活発に開発が進められています。Ruby体のバージョンアップに関係なく新しいバージョンをリリースできるようになったことも開発が活発になった理由の1つです。Ruby標準添付の頃のtest-unitしか知らない人は、一度、最新のtest-unitを使ってみてはいかがでしょうか。とても使いやすくなっていることを実

  • 「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは?

    「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは?:誰にでも分かるSEのための文章術(11)(1/2 ページ) 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな

    「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは?
  • C言語における単体テスト テスタビリティを重視した関数設計 - ソフトウェアテストの勉強室

    今日は社外WGに参加。春の嵐だ! == 僕はC言語ばっかの開発をやってるので、ここでもC言語をベースにしていろんなことを書きます。あしからず。 リリース後の欠陥発覚は手戻り工数が最もかかるものだが、その多くは単体テストで発見可能なものが多い。某静的解析ツールのベンダー資料によるとその割合は40%近くになるらしい。定量的な資料は持っていないが、僕も単体テストの質がシステム全体やプロジェクト全体の質を大きく左右すると考えている。 そこでだ。僕の考える、上質な単体テスト for C言語はこんな感じ。 テストしやすいという、テスタビリティ まず、基的な関数の型はint型がいろいろ都合がいい気がする。エラー番号を復帰したり、errnoを復帰したり、直感的なものがよいと思う。例1のように、文字列格納先の先頭ポインタを引数渡しする場合は、呼び元で確保したサイズも合わせて引数渡しすること。(ちなみによく

    C言語における単体テスト テスタビリティを重視した関数設計 - ソフトウェアテストの勉強室
  • C言語の単体テスト、いろいろ - ソフトウェアテストの勉強室

    ある意味、餃子ブームだ。 == メールサーバってCだから、C向けのテスト手法はいろいろと調べたりすることが多いし、自分でツールを作ったりします。せっかく調べたので、C言語をターゲットとした単体テスト/ユニットテストツールを枚挙してみる。 CUnit http://sourceforge.net/projects/cunit/によるユニットテストフレームワーク。出力に「__FILE__」「__LINE__」を記載して、分析しやすく結果を表現する。XML出力モード(Automatedモード)で実行し、DTDとXSLスタイルシートによって、統計情報が見やすくなる。 CUnit for Mr.Ando 安藤利和さんによる「言語技術者のC言語技術者によるC言語技術者のための C言語テスティングフレームワーク」。ソースはhttp://sourceforge.jp/projects/cunitforan

    C言語の単体テスト、いろいろ - ソフトウェアテストの勉強室
  • TDD談義への反応に対する雑感(テスト駆動開発を取り巻く誤解等) - 千里霧中

    先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基的にKent Beckや和田さんが使われているQAテストの定義によるもの(http://gihyo.jp/dev/serial/01/tdd/0003)。 この定義で「品質保証のための単体テスト

    TDD談義への反応に対する雑感(テスト駆動開発を取り巻く誤解等) - 千里霧中
  • InfoQ: より良いユニットテストためのガイドライン

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    InfoQ: より良いユニットテストためのガイドライン
  • コードカバレッジのまとめ - ソフトウェアテストの勉強室

    単体テストレベルでは、「コードカバレッジ」を意識しながら(基準にしながら)テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。 2008/03/12更新 サンプルプログラムで解説を追加 サンプルプログラムは、以前例題として作成したテニスのスコアボードについて [例題]テニスのスコアボード ステートメントカバレッジ 命令網羅。テスト対象となるプログラム中のステートメント(命令文)をどれくらい実施したかどうかをあらわす基準。すべてのステートメントを最低1回実施した場合に、ステートメントカバレッジ100%という。もっとも基的なカバレッジ基準で

    コードカバレッジのまとめ - ソフトウェアテストの勉強室
  • Visual Studio 2008単体テスト機能のすべて ― @IT

    Visual Studio 2008単体テスト機能のすべて:特集:Visual Studio 2008単体テスト機能徹底活用(前編)(1/4 ページ) 連載目次 Visual Studio 2005(以下、VS 2005)では上位エディションであるTeam Developerでのみ利用可能だった単体テスト機能が、Visual Studio 2008(以下、VS 2008)からは、Professional Editionでも利用可能になった。 VS 2008の1機能として導入されるほど単体テストが脚光を浴びるようになったのは、やはりアジャイル開発の普及だろう。アジャイルで開発する場合、単体の品質が非常に重要になる。また、リファクタリングなどで繰り返しテストが必要になるケースが多いため、テストを自動化するという考えが生まれ、単体テストの注目度はさらに増している。 稿では、このVS 2008

    Visual Studio 2008単体テスト機能のすべて ― @IT
  • ウノウラボ Unoh Labs: 見ないと損する ソフトウェアテスト関連サイト色々

    こんにちは!やまもと@テスト番長です。 今回は自分が普段チェックしている、ソフトウェアテスト系のサイトを色々ご紹介してみようと思います。既にご存知のサイトもあるかと思いますが、宜しくお付き合いください。 swtest.jp/wiki http://www.swtest.jp/wiki/index.php?swtest.jp/wiki 最近wiki化され、情報更新が活発になっています。必見です。 StickyMinds.com http://www.stickyminds.com/ コラムなどの読み物が充実しています。 Google Testing Blog http://googletesting.blogspot.com/ グーグルのテストチームのブログです。面白くないはずがありません。 Open source software testing tools http://www.

  • テスト技法ポジショニングマップ

    This domain is registered at Dynadot.com. Website coming soon. hayst.com 2023 著作権. 不許複製 プライバシーポリシー

  • 1