原因結果グラフによるテスト設計支援ツール - CEGTest - ソフトウェアテストの勉強室
CEGTestの紹介 CEGTest（セグテスト）は、複雑な論理関係を持つソフトウェア・プログラムの組合せテスト条件作成を支援するツールです。本ツールを用いることで、従来ある程度の経験と知識が必要であったテスト技法「原因結果グラフ技法」を、ブラウザ/JavaScriptベースで直感的に実践することができます。また、成果物であるテスト条件に関する「デシジョンテーブル」は同時に自動生成されるため、作業者はソフトウェア対象・テストベースの分析に集中することができます。よって、本ツールを利用することで、より効果的・効率的なテスト設計が行えます。 原因結果グラフ技法はソフトウェア・プログラム仕様の分析や整理をするためにも用いられます。本ツールはテストエンジニアだけではなく、プログラマやソフトウェアエンジニアにも品質向上の一助になると考えています。 技術解説 デシジョンテーブルの解説 （作成中） 原因
原因結果グラフの「単機能テスト」 - ソフトウェアテストの勉強室
原因結果グラフをテスト設計で利用する場合、「制約のテスト」を事前に行う必要があるということを先日記事にしました。もうひとつ事前に行う必要があるものとしては、 単機能テストは実施済み ということが挙げられます。 例えば、「JaSSTに参加する」という思考について原因結果グラフを以下のように作成したとします。 得られるデシジョンテーブルは以下のようになります。 ここで、勉強会の参加者から「テストに興味があってJaSSTに参加するパターンは網羅してるけど、品質に興味があってJaSSTに参加するパターンは網羅してないですが、いいのでしょうか？」という質問がありました。直感的には僕も同じように感じます。ただし、これは最初にあげた「単機能テストは実施済み」という前提があるので、「確認済み」ということがいえると思います。 原因結果グラフは論理関係を網羅するために合理的にテスト条件を効率的に組み合わせてい
スイッチカバレッジのまとめ - ソフトウェアテストの勉強室
WACATE 2008 冬も無事終了したので、ここらへんで状態遷移テストについてちょこちょこ書いていこうっと。 ということで状態遷移テストで登場するカバレッジ基準をまとめてみる。具体例や図はのちほど。 ノード網羅 システムの仕様書から「状態」を洗い出して、その状態をすべて確認すること。たとえば、バスのボタンを例に取ると「消灯」状態、「点灯」状態が考えられ、それらの状態自体を確認すること。もっともレベルの低いカバレッジ基準。 リンク網羅（0スイッチカバレッジ） システムの仕様書から「状態」と「イベント」を洗い出して、そのイベントの表す遷移をすべて確認すること。たとえば、バスのボタンを例に取れば、イベントとして「ボタンを押す」、「点灯をリセットする」などが考えられ、状態遷移図の中の→をすべて網羅することになる。このカバレッジ基準を確認するとともに、状態遷移図から状態遷移表への変換を行い、「無効
ソフトウェアテストの勉強室
家から確認作業、夜は長いぞ。 == どんな単体テストをしますか？その４の原因結果グラフを修正。 この分岐はいたってシンプルなので、こう眺めてみると原因結果グラフを明記しなくても、デシジョンテーブルに落とし込むことはできそだな。少し余裕が出たときにサンプルの関数全体をホワイトボックステストで設計するのと、グレーボックステストで設計するのをやるかな。グレーボックステストは今までのまとめっぽいけど。 == 例のMC/DCについて。まだ読み中。 引用：NASA/TM-2001210-876, A Practical Tutorial on Modified Condition/Decision Coverage MC/DCというカバレッジ基準は図にあるように比較的高レベルなカバレッジ基準といえる。他の資料には、高信頼性を求めるシステム、リアルタイム性が求められる組込み系ソフトウェアなどで使われるら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
