サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
softest.cocolog-nifty.com
デシジョンテーブルとは デシジョンテーブルとは、決定表(JIS X 0125)[1]として規格が定義されています。論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールの組合せます。プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。 図1. デシジョンテーブルの例（駐車場料金の割引計算） デシジョンテーブルを作成する手順は一般的に以下の通りです。 分析対象・テスト対象の持つ条件・原因を洗い出し、それぞれを行として追加します 処理・動作・結果を洗い出し、それぞれ行として追加します 起こりうる条件・原因の組合せを作成し、それぞれ列として追加します 作成した列のうち、集約可能な列の組を圧縮します 組合せの作成と圧縮についての検算をします デシジョンテーブルを使うことで以下のようなメリットが挙げら
このエントリーは、「Software Test ＆ Quality Advent Calendar 2011」の12/23分として書いています。 前日の12/21は、@takanorig さんによる「JaSST 10th Anniversary」でした。 僕は普段はソフトウェア開発とそのマネジメントをしていますが、ソフトウェアテストに関する活動・勉強会をしています。その中で「WACATE」と呼ばれる若手テストエンジニア向けのワークショップの実行委員をしています。今回のエントリーは、昨年のワークショップで少し話をした「技と術と芸」について個人の考えとしてまとめたものです。 同値分割やデシジョンテーブル、直交表などを一般的にはテスト技法と呼びますが、「技法」ってなんだろう？ とふと思ったのがきっかけでした。そして、技法、技、技術、・・・、といろいろな言葉を調べていて、「技」「術」「芸」の3つに
お知らせ CFDを描画するツール(プロトタイプ)。 例題 ニックネームは、以下の条件を満たす場合に文法が正しい。 文字数は4文字以上8文字以下 文字種別は、英数字のみ 解答例はこちら お問い合わせは、加瀬まで softest@nifty.com
今日は「ソフトウェアテスト技法ドリル」勉強会でした。 第4回「ソフトウェアテスト技法ドリル」勉強会 http://togetter.com/li/118911 今回は、松尾谷徹氏が考案したCFD法(Cause Flow Diagram)というテスト設計技法がテーマ。デシジョンテーブルを作成するので、実装（特に処理順序や判定順序）がわかっていてはじめて効果が発揮される技法といえます。開発者向けのテスト技法かな。 勉強会をするにあたって、入力条件の同値図と結果を処理の流れで結んだ「原因流れ図」を描くのですが、これが意外にめんどくさい！ ということでCEGTestの要領で描画ツールを作ってみました。 drawCFD - CFD(Cause Flow Diagram)からテスト条件を作成するツール http://softest.cocolog-nifty.com/labo/drawCFD/ 現時点
原因結果グラフ技法を使いこなすためには、グラフをたくさん描くことが大事です。ここでは、2009年からTEFが主催する勉強会で紹介した演習問題を取り上げます。難易度（★～★★★★★）のやさしい順にひとつずつ原因結果グラフを作成して、模範解答と見比べて、違いを見つけてみましょう。 この演習問題のもとになった勉強会は、秋山浩一さん、鈴木三紀夫さんのご協力によるものです。この場を借りて御礼申し上げます。 また、原因結果グラフは仕様の曖昧さや作成者の解釈によって異なることがあり、softestが作成した解答例と一致しなくても不正解ではありません。ノードのつけ方や制約のつけ方の違いを確認してみましょう。 原因結果グラフ テスト支援ツール CEGTest（セグテスト） 解答例についての問い合わせ 本ページのコメントでお問い合わせいただくか、メールアドレス宛てまでお願いいたします。 難易度：★☆☆☆☆ 迷
ソフトウェアテストには7つの原則(*)があって、そのひとつに「テストは欠陥があることしか示せない」という原則がある。これはどういうことかというと、テストというプロセスでは「不具合がない」ことは示せない、示せるのは「不具合がある」ことだけだ、ということを意味している。つまり、テストの目的＝不具合を見つけ出すことなので、より多くの不具合を見つけられるテストケースが優秀といえる。 テスト仕様書に「正常系/異常系」のカテゴライズは必要？ by クライングドーベルマン 第三者テスト、とかソフトウェアテスト専門部隊、に属する僕個人の意見としては、「正常系/異常系」のカテゴリーはテスト仕様書には特に必要ないように感じる。多分、「正常系/異常系」というカテゴリーはテスト実行の優先度として使用する目的で設定していると思うが、「とりあえず正常系から先にテストする」という戦略は時として重大なテスト漏れを発生させ
[例題]テニスのスコアボードのテストをしてみるのだが、まずテスト対象の分析をしてみる。分析をしてどんなテスト設計をするのか、テスト技法を使うのか、などなどを検討する。今回は、ソフトウェアテストPRESS Vol.2 「3色ボールペンで読む仕様書」にならってやってみようかな。 赤 － 客観的に見て、最も重要な箇所 今回は、同値分割や境界値などに使えそうな箇所もあげてみた。 青 － 客観的に見て、まあ重要な箇所 実は微妙に青色って難しい。。。 緑 － 主観的に見て、おかしいと感じた箇所 おかしいというか仕様があいまいであったり、矛盾がある箇所としてみた。 次回はマインドマップを分析ツールとして使ってみる。予定。
テスト技法といえば、G・J・マイヤーズの「ソフトウェア・テストの技法」やボーリス・バイザーの「ソフトウェアテスト技法-動化、品質保証、そしてバグの未然防止のために」など古典が有名。理論的な内容だけど、なかなか難しいという印象が強いともいえる。それに対して、この本が「ドリル」という形で読者に訓練・経験を促すのは、勉強しただけで使えていないテスト技法をより実践的なスキルにするため。テスト技法はそれひとつでは銀の弾丸にはなり得ないが、組み合わせて使えば十分強靭な武器になる。自分も含めて、知ってると思っている技法についても振り返りながら演習を解いてみたい。 第1章は「点に注意を向ける」という副題。章のトビラページにはポリアの「いかにして問題をとくか」の言葉が添えられている。ここでは問題解決のための突破口となるコツが「例示」「間」「類推」「外側」「意地悪」というキーワードで紹介されている。こういった
CEGTestの紹介 CEGTest（セグテスト）は、複雑な論理関係を持つソフトウェア・プログラムの組合せテスト条件作成を支援するツールです。本ツールを用いることで、従来ある程度の経験と知識が必要であったテスト技法「原因結果グラフ技法」を、ブラウザ/JavaScriptベースで直感的に実践することができます。また、成果物であるテスト条件に関する「デシジョンテーブル」は同時に自動生成されるため、作業者はソフトウェア対象・テストベースの分析に集中することができます。よって、本ツールを利用することで、より効果的・効率的なテスト設計が行えます。 原因結果グラフ技法はソフトウェア・プログラム仕様の分析や整理をするためにも用いられます。本ツールはテストエンジニアだけではなく、プログラマやソフトウェアエンジニアにも品質向上の一助になると考えています。 技術解説 デシジョンテーブルの解説 （作成中） 原因
最近、テスト駆動型開発（TDDあるいはBDD）についての雑誌を買ったり、他のブログに感化されたりしたので軽い考察を。 == 実装とテストを繰り返しながら設計をすすめる、といった形でコーディングするとき、みなさんはどんな手順ですすめますか？僕はこんな感じでやってます。（僕はC言語をベースに開発することが多いので、C言語をサンプルに） 骨組みだけの関数を作成する /** * func1(); ○△×をする関数 * 引数 * 復帰値 * 0 正常 * -1 エラー */ int func1( const char* str1, char* ptr2, int num3 ) { return(-1); } モジュール設計に基づいた関数の骨組みだけを記述する。ただし、復帰値がvoid以外ならばエラー復帰をまず記述しておく。 テストスイートを作成する - 引数チェック - 正常系ケース - 限界値ケー
原因結果グラフによるテスト設計支援ツール CEGTest（セグテスト）ウェブ版は以下の URL に移動しました。 原因結果グラフによるテスト設計支援ツール CEGTest 5秒後にリダイレクトしない場合は、リンクをクリックしてください。
CEGTest はJavaScriptを使って、オフラインでも動作するように実装していますが、ウェブ版ではニフティクラウド（mBaaS）を利用して、いくつかのサンプルデータを取得できるようにしました。 サンプルデータは、原因結果グラフの演習で公開しているデータが利用できます。なお、演習問題のページで紹介している模範解答はあくまで「解答例」の一つですので、仕様の考え方や何の検証を優先するのか、などによって原因結果グラフは異なります。 今後は、FacebookやTwitterなどSNSとの連携ログイン機能やログインユーザ毎のデータ保管などを考えてみます。
ソフトウェア開発の品質向上を目指して、勉強するブログ。プログラマも、テストエンジニアも、QAも、みんな勉強しようぜ。書籍やセミナー、イベントも紹介。 perl少し覚えた。 == 技術評論社のサイトに組み合わせテストをオールペア法（ＰＩＣＴ）で試す、という記事が掲載されています。なかなか時間が取れなくて読めていないですが、ＰＩＣＴ初心者としてはありがたい特集です！ 特集：組み合わせテストをオールペア法でスピーディに！ 第1回 組み合わせテストの技法 第2回 PICTの基本的な使い方 もう少しきちんと読めたら、記事書こうっとー。 しつこいようだが、ソフトウェアテストは、いかにして少ない手数で多くの欠陥を見つけるか、がキーである。 どこに欠陥が入り込みやすいか、という問いにはいくつかの解答があるだろうが、直交表・HAYST法・All-pair法などを勉強する場合、勘所は組み合わされる条件の個数に
WACATE 2008 冬も無事終了したので、ここらへんで状態遷移テストについてちょこちょこ書いていこうっと。 ということで状態遷移テストで登場するカバレッジ基準をまとめてみる。具体例や図はのちほど。 ノード網羅 システムの仕様書から「状態」を洗い出して、その状態をすべて確認すること。たとえば、バスのボタンを例に取ると「消灯」状態、「点灯」状態が考えられ、それらの状態自体を確認すること。もっともレベルの低いカバレッジ基準。 リンク網羅（0スイッチカバレッジ） システムの仕様書から「状態」と「イベント」を洗い出して、そのイベントの表す遷移をすべて確認すること。たとえば、バスのボタンを例に取れば、イベントとして「ボタンを押す」、「点灯をリセットする」などが考えられ、状態遷移図の中の→をすべて網羅することになる。このカバレッジ基準を確認するとともに、状態遷移図から状態遷移表への変換を行い、「無効
自分はまだまだ熟練エンジニアとはいえないのだが、チーム内では比較的経験年数が多いほう。なので、レビュアーをお願いされることが多い。主に、設計レビューやコードレビュー、テストケースレビュー、メンテナンス手順レビュー。そういうレビュアーをするときに意識していることをQC7つ道具になぞらえて、レビュアー7つ道具という名目でまとめてみた。 チェックシート 「チェックシート」は2つの用途で使います。一つ目はレビュー観点をまとめたシートです。それはコーディング規約の類であったり、仕様書であったり、過去の指摘項目リストであったりします。例えば、コードレビューにおいて、変数の初期化、スコープが適切であるか、などなど。もうひとつはレビュー対象リストです。基本的にはある程度細かい単位でレビューすることが多いですが、関数や処理といったリストを使う場合もあります。 「チェックシート」の目的は、実施漏れをなくしたり
家から確認作業、夜は長いぞ。 == どんな単体テストをしますか？その４の原因結果グラフを修正。 この分岐はいたってシンプルなので、こう眺めてみると原因結果グラフを明記しなくても、デシジョンテーブルに落とし込むことはできそだな。少し余裕が出たときにサンプルの関数全体をホワイトボックステストで設計するのと、グレーボックステストで設計するのをやるかな。グレーボックステストは今までのまとめっぽいけど。 == 例のMC/DCについて。まだ読み中。 引用：NASA/TM-2001210-876, A Practical Tutorial on Modified Condition/Decision Coverage MC/DCというカバレッジ基準は図にあるように比較的高レベルなカバレッジ基準といえる。他の資料には、高信頼性を求めるシステム、リアルタイム性が求められる組込み系ソフトウェアなどで使われるら
ソフトウェア開発の品質向上を目指して、勉強するブログ。プログラマも、テストエンジニアも、QAも、みんな勉強しようぜ。書籍やセミナー、イベントも紹介。 試しに、直交表に割りつけてみた。 「今、食べたいラーメン」 腹が減りました。とてもラーメンが食べたいです。でも、どんなラーメンでもいいわけではありません。以下の条件を参考に、食べたいラーメンになるように原因結果グラフを作成してください。 味はしょうゆか塩か味噌のいずれかが良い。普通の胃袋なので1 杯で十分です。 昨日はステーキを食べたので、こってりではないほうが良い。 しょうゆか塩の場合は、とんこつベースが良い。 味噌の場合は野菜がたっぷり入っているものが良い。 トッピングは絶対に付けたい。金に糸目はつけないので味玉、刻み玉ねぎ、焼き海苔の中から最低１つは付けたい。 16番目の組合せだけが説明文通りの「食べたいラーメン」だけど、他の15通りで
単体テストレベルでは、「コードカバレッジ」を意識しながら（基準にしながら）テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。 2008/03/12更新 サンプルプログラムで解説を追加 サンプルプログラムは、以前例題として作成したテニスのスコアボードについて [例題]テニスのスコアボード ステートメントカバレッジ 命令網羅。テスト対象となるプログラム中のステートメント（命令文）をどれくらい実施したかどうかをあらわす基準。すべてのステートメントを最低1回実施した場合に、ステートメントカバレッジ100%という。もっとも基本的なカバレッジ基準で
ある意味、餃子ブームだ。 == メールサーバって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言語ばっかの開発をやってるので、ここでもC言語をベースにしていろんなことを書きます。あしからず。 リリース後の欠陥発覚は手戻り工数が最もかかるものだが、その多くは単体テストで発見可能なものが多い。某静的解析ツールのベンダー資料によるとその割合は40%近くになるらしい。定量的な資料は持っていないが、僕も単体テストの質がシステム全体やプロジェクト全体の質を大きく左右すると考えている。 そこでだ。僕の考える、上質な単体テスト for C言語はこんな感じ。 テストしやすいという、テスタビリティ まず、基本的な関数の型はint型がいろいろ都合がいい気がする。エラー番号を復帰したり、errnoを復帰したり、直感的なものがよいと思う。例１のように、文字列格納先の先頭ポインタを引数渡しする場合は、呼び元で確保したサイズも合わせて引数渡しすること。（ちなみによく
こんばんは。細谷です。 CUnitのテストコードを単体テストと見た場合、書いてくださっている通り、ボトムアップの単体テスト、結合テストを繰り返すことで問題ないと思います。 Kent Beckが著書で述べている「TDD」のテストコードは単体テストというよりは「最後の設計を具現化したもの」という位置づけであり、「テスト駆動開発入門」の中でも実装段階でクラスを追加したり、既に実装済みのクラスを消してしまったり、という様子が書かれています。 このようなダイナミックなリファクタリングを行いながらの開発ではまず全てのテストが容易に実行可能である必要があります。 また、TDDのテストコードは「今、自分が考えなければいけない範囲」を規定する意味もあります。この範囲を狭めて集中することによって誤りが減るということが主張されています。 範囲を狭める上では、スタブを用いて他の関数の実装に影響を受けないテストとす
試しに、直交表に割りつけてみた。 「今、食べたいラーメン」 腹が減りました。とてもラーメンが食べたいです。でも、どんなラーメンでもいいわけではありません。以下の条件を参考に、食べたいラーメンになるように原因結果グラフを作成してください。 味はしょうゆか塩か味噌のいずれかが良い。普通の胃袋なので1 杯で十分です。 昨日はステーキを食べたので、こってりではないほうが良い。 しょうゆか塩の場合は、とんこつベースが良い。 味噌の場合は野菜がたっぷり入っているものが良い。 トッピングは絶対に付けたい。金に糸目はつけないので味玉、刻み玉ねぎ、焼き海苔の中から最低１つは付けたい。 16番目の組合せだけが説明文通りの「食べたいラーメン」だけど、他の15通りで「食べたいラーメン」があるかもしれないー。 HAYST法も、デシジョンテーブルや原因結果グラフ、CFD法なども、どちらも組合せテストの一種ととらえるこ
自動で単体テスト、ステートメントカバレッジ、そしてテストケースレビューで、適当な関数を作って、適当な単体テストの条件を作ってみた。この中で「指定日が元旦から何日目かを返答する関数（daycount）」についてもう少しきちんとテストしてみようかと。 == ブラックボックステストの観点 ブラックボックステストなので、基本的には「指定日が元旦からの日数」が正しく計算できるか、という仕様からテストケース・テスト条件を洗い出す。でもまずは関数インターフェースを眺めてみる。 int daycount( int year, int month, int day ); 引数は、 year（西暦） month（月） day（日） の3つ。西暦はここでは「1900年～2100年」という範囲に限定する、という（かくれ）仕様。月は「1月～12月」、日は「1日～31日」である。これは自明な仕様とでもいうのだろうか。
ソフトウェアテストの専門誌の総集編。過去の記事（1号～10号）を含めてCD-ROMに収録。巻頭企画は、大西さん、細川さん、町田さん、湯本さんによる特別座談会。座談会って面白いですね。Software Testing ManiaX でも確か座談会のところがありました。 特集２では、テストエンジニアのためのテスト駆動型開発入門と題して「検証指向TDD」などの記事が掲載されています。スピード感（駆動力）を損なう、単体テストはTDDとは別で実施している、前からこの考え方でTDDを実践している、といった指摘もされますが、プログラミングスキルとテスティングスキルを一緒に伸ばすという意味では十分面白い試みだと僕は思っています。例えば小さなロジックを組んで、そこでの最低必要なテスト条件数が見えていれば、必ずソフトウェア品質も上がるし、他者のコードの気持ち悪いところが見えやすくもなるでしょう。 TDD研究会
TEFでもTDDや単体テストの話題で持ちきりですが、 極力ユニットテストを書かずに品質を確保する方法 by ひがやすを blog やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 後述にもありますが、「ユニットテストは工数がかかる」という意見に対する対案のようなもので、せっかく書いたテストコードをより効果的・効率的にするための工夫ですね。 事実、ここ数年、「ユ
久しぶりに直交表/HAYST法関連のブログ記事～。 == 以前ご紹介したブログで直交表やHAYST法についての考察が出された。 マイリストに「ソフトウェアテストにおける直交表(HAYST法、All-pair法)の利用」をアップ by つれづれなる技術屋日記 ・ソフトウェアテスト開発技術者やソフトウェアテスト技術者にとって未知の世界 ・タグチメソッド自体が賛否両論 ・直交表自体の学習の難しさ ・実験計画法の記述のほとんどが、数式と表 ・ベースとなる統計や代数・幾何 直交表とかタグチメソッドとかいう名前を会社の上司に話したとしても、知ってる程度で実際に直交表の書かれた紙や画面を見せると、苦笑い、といったことが多い。これは指摘の通り、未知の世界だということが大きいかも。今や大学在籍時の専攻が理学系だったとしても、なかなか数学って敬遠されがちな分野。行列とかベクトル空間とかあんまり記憶にないのが現
次のページ
このページを最初にブックマークしてみませんか？
『ソフトウェアテストの勉強室』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
