ソフトウェアテストの分類
静的テスト／動的テスト （ ※↓ ） 1.静的テスト、2.動的テスト モデルベーステスト ／ モデルベースではないテスト （ ※↓ ） モデルベーステスト モデルベースではないテスト 2.1. アドホックテスト、2.2.探索型テスト ホワイトボックス・テスト ／ ブラックボックス・テスト ／ グレーボックス・テスト （ ※↓ ） ホワイトボックス・テスト （ ※↓ ） 1.制御パステスト、2.データフロー・パステスト ブラックボックス・テスト （ ※↓ ） 入力値および出力値の項目を決定する方法 1.同値分割、2.境界値分析 テストケース（テストを行う入力値と出力値の項目とその組み合わせ）を決定する方法 ディシジョンテーブルを使った方法 1.単純なディシジョンテーブルの使用、 2. 原因結果グラフ、3. 実験計画法、4. 原因流れ図（グレーボックステストの一種） 状態遷移テスト ファズ・テ
ジョジョの奇妙なTDD
何かの間違いで、LT王になってしまったTokyuRuby会議05の発表資料。 人類共通言語のジョジョでTDDを伝える試み。 色々とアウトな感じなので、 お咎めを受けたら消します・・・。 7/30追記: 拡散の勢いがかなりのものだったので、カット版に差し替え。
Getting Started with ABAP Testing and Troubleshooting | SCN
Last edit: October 19, 2023 The Application Server ABAP supports not only development, but the whole development life cycle with a rich set of integrated ABAP testing and troubleshooting tools. Using the ABAP suite of testing tools, you can verify the formal and functional correctness of your programs. ABAP Unit testing makes enables you to employ test-driven development models. In the case of pro
第5回 BDDとATDD | gihyo.jp
はじめに 本連載では、「透明性」というキーワードで、アジャイル開発について説明しています。前回は、テスト駆動開発(TDD)の持つ、開発を促進する設計作業としての側面にスポットを当てて説明しました。今回は、それらの考えを展開させてみたいと思います。具体的には、振る舞い駆動開発(BDD)と受け入れテスト駆動開発(ATDD)という二つのトピックを、ご紹介します。 テストのレビュー 前回、テスト駆動開発におけるテストを、設計作業であるとする考え方をご紹介してきました。これは、個々のクラスのインターフェース(=振る舞い)を、テストにより明確にしてゆくというものです。結果的に、作られたテストは、実装との乖離を自動的に検出できる設計書となります。 仕様変更やリファクタリングに伴うソフトウェアの改変に際して、バグの混入を自動的に検知できるので、実装と設計の同期が取れるという大きなメリットがあります。 し
「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない」 - カレーなる辛口Javaな加齢日記
注：テスト本リストは加筆修正した上で，改めて独立した項目に作り直した． → http://d.hatena.ne.jp/JavaBlack/20150926/p1 http://www.publickey1.jp/blog/12/8585.html http://www.keyman.or.jp/at/dev/debug/30004610/ 数値の正確さはともかく，だいたいそんなもんでしょう． 「スキルがないからPHP使ってます」「Javaは使ってるけどオブジェクト指向って何ですか？」みたいな現場だと，テストするスキルも人手も足りない． そもそもテストを知らない．テスト＝手動テストだと思っている． デバッグといえばデバッガでするものだと思っている． 導入するメリットが理解できない． テストをする人に，プログラミングのスキルや経験がない．ひどい場合には素質が無い．*1 導入するスキルがない．
Content Unavailable
We're sorry, but you're attempting to access SCN content that was not migrated to the new SAP Community experience. Only SCN discussions with replies moved to the SAP Community archive as read-only content. If you wish to restart a discussion, feel free to ask a question or participate in the Coffee Corner area. Before posting anything, however, please make sure you are familiar with our rules of
TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組
@t_wada「TDDはスキルです。量は質に転化する」 TDD Advent Calendar2011の記事になります。 TDD Advent Calendar jp: 2011 : ATND 前：@irof テストと言うパートナー #TddAdventJp - 日々常々 次：@yuya_takeyama さんです。 はじめに これは僕の主観であって、間違いもあると思います。それは僕の勉強不足から生じるものです。 どちらかというと、これを読んだ方に「そこはちょっと認識が一般的じゃない」「そもそも違うよ」って突っ込んでもらうためのものです。 「TDDよくわからないので教えてください」っていう記事です。 TDDをはじめたい人、TDDに行き詰まっている人 TDDがどんなものかよくわからない人、とりあえずテストコードって書いているけど毎回つまずいて成長が実感出来ない人、現場に導入したいけど伝え方が
TDD Boot Camp 東京 1.6に参加してきた #tddbc - Diary of absj31
TDD Boot Camp 東京 1.6 #tddbc on Zusaar Togetter - 「TDD Boot Camp 東京 1.6 #tddbc」 関東地方久々のTDDBC 1.5 in Tokyoが告知即定員オーバー瞬殺且つ定員の3倍近い募集が殺到(定員36名:募集114名)し、改めて関東/東京の需要の高さを実感。 TDD Boot Camp in Tokyo #tddbc : ATND TDDBC in Tokyo 1.5 主催レポート #tddbc | Act as Professional - プロとしての行為 勉強会主催者はなかやん・そるじゃー・ゆーき(TwitterID:@pocketberserker) さん。開催に至るまでの経緯は下記ブログに記載されていますが、彼のおかげでこうしてイベントに参加＆貴重な体験をする事が出来ました。ありがとうございます！ TDD Bo
いにしえの開発環境
This document summarizes the author's history with home computers starting in the 1980s. It mentions owning an MSX computer in the 1980s and 1990s, participating in the MSX community through a magazine called MSXFAN, and links to websites about MSX games and a 1-chip MSX computer project. It also references owning a Commodore PET computer.Read less
ＴＤＤ（テスト駆動開発）は怪しいな - Javaの日々
テストコードを書きながら開発することでバグの発生低下と生産性の増大が見込める ということだが、かなり怪しい。 １．テストコードの対象はメソッド・関数の単位であること。 それらのメソッドが複数使われるアルゴリズム全体の流れの検証はできない。 しかしこれが仕様を満たしているかどうかの最も大切なテストとなる。 この最も大切なテストについては完全に沈黙しているように見える。 ２．オブジェクトの状態を制御するようなメソッドの検証の困難性 単に入力と出力があるメソッドならばテストコードを書くことは可能だろう。 しかし複数のメソッドで制御されるオブジェクトを触るようなメソッドを 検証するようなテストコードは難しいだろう。 しかもそのようなメソッドは決して珍しいものではない。 ３．テストコードの複雑さについての対処法がない 複雑なメソッドのためのテストコードは複雑になるだろう。 その場合のテストコードが正
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです！ 次の形式で書いています。 WEBサイト名、資料名：発表者（敬称略）：URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
Database Refactoring
3. Avoid overspecialization --- BARRIER --- Application Developer Database Developer Communication Collaboration Understanding Knowledge-exchange New skills Developer Developer 3 4. Refactoring In Maths, to “factor” is to reduce an expression to it's simplest form In CS, is the disciplined way to restructure code ● Without adding new features ● Improving the design ● Often making the code simpler,
データベースの不吉な臭い | system-enablers日記
近頃はドメイン駆動に興味の中心があるせいか、RDBの論理設計についての話をあまり聞かなくなってきた。 では、みんなよい設計ができるようになったのか？いやいやそんなことはない。よくひどい設計に当たったりもする。 よいデータベースの論理設計って何か？という問いに対しては、「データベース・リファクタリング」の「データベースの不吉な臭い」がとても参考になる。今まで見てきたひどいデータベース設計のほとんどがこのアンチパターンに入っているように思います。 複数の目的に使われるカラム データベースリファクタリングで挙げている例は、顧客の場合には誕生日を、従業員なら雇用開始日を格納する開始日付項目。「そんなことしないよ」と思われるかもしれませんが、経験上、この手は以外に多い。 たとえば、テーブルにありがちなシステム管理上の「データ作成日時」を、運用上一致するからといって「申込日」といった業務上の日付として
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
より良いテスト駆動開発を行うためのチートシートの紹介
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
Login | Microsoft 365
ABAP Unit について: NetWeaverなブログ