CEGTest にニフティクラウド(mBaaS)からインポートする機能を追加

1

CEGTest はJavaScriptを使って、オフラインでも動作するように実装していますが、ウェブ版ではニフティクラウド(mBaaS)を利用して、いくつかのサンプルデータを取得できるようにしました。

2

サンプルデータは、原因結果グラフの演習で公開しているデータが利用できます。なお、演習問題のページで紹介している模範解答はあくまで「解答例」の一つですので、仕様の考え方や何の検証を優先するのか、などによって原因結果グラフは異なります。

今後は、FacebookやTwitterなどSNSとの連携ログイン機能やログインユーザ毎のデータ保管などを考えてみます。

| | コメント (1) | トラックバック (0)

CEGTestにxlsx形式でのエクスポート機能を追加

Xlsx

CEGTest(セグテスト)のエクスポートに xlsx 形式でのダウンロード機能を追加しました。
1シート目はデシジョンテーブル、2シート目はカバレッジ表です。本当は、3シート目に原因結果グラフの元データを、4シート目に原因結果グラフの画像を張り付けたかったのですが、ちょっとそこまで実装できませんでした。

URL はこちら。

CEGTest(ウェブ版)
CEGTest(ダウンロード版:v1.6-20130907)

| | コメント (0) | トラックバック (0)

CEGTest の js アップデート中

CEGTest の js ファイルをアップデート中ですが、プロパティの衝突か何かを起こしていて、ウェブサイト上で問題発生中です。ご利用の際は、zip ファイル版をご利用ください m(_ _)m

http://softest.cocolog-nifty.com/blog/cegtest.html

| | コメント (0) | トラックバック (0)

原因結果グラフの中間ノードが観測不可な場合について

TEFで原因結果グラフの「観測可能」についての解説があったので、すこしまとめてみました。

==

中間ノードが観測可能であるとは、テスト実施後にそのノード(状態や内部変数)が直接確認(観測)できることを言う。特に内部変数はデバッグ出力などを使わないと観測可能にはならないので、プログラムテストではデバッグ出力を用いて観測可能にすることが多い。

CEGTestでのデシジョンテーブル作成ロジックでは、すべての中間ノードが観測可能という前提で実装されています。グラフの形にもよりますが、デシジョンテーブルの1列が複数の論理関係を検証できるため、カバレッジ表よりもデシジョンテーブルの大きさが小さくなります。

では、観測可能ではない(観測不可)中間ノードがある場合はどう考えたらよいか。

Ceg2

このグラフではAが中間ノードになるので、Aが観測可能であればデシジョンテーブルは以下のように作成できる。

Dt2obs

では、Aが観測不可である場合、他にどんなテスト条件を確認すべきでしょうか。

その前に上記デシジョンテーブルの各列が「何を」検証しているかを再確認。


  • #1


    • a1がTであることによって、中間ノードAがTになることを検証している。

    • A,B,CがすべてTであることによって、結果ノードXがTになることを検証している。


  • #2


    • a2がTであることによって、中間ノードAがTになることを検証している。

    • BがFであることによって、結果ノードXがFになることを検証している。


  • #3


    • a3がTであることによって、中間ノードAがTになることを検証している。

    • CがFであることによって、結果ノードXがFになることを検証している。


  • #4


    • a1,a3,a3がすべてFであることによって、中間ノードAがFになることを検証している。

    • AがFであることによって、結果ノードXがFになることを検証している。


さて、Aが観測不可と考えると、#1は、


  • a1,B,CがTであることによって、結果ノードXがTになることを検証している。


というように見なせる。言い換えれば、a2,a3が結果ノードXがTになることに影響を及ぼしているかについては未検証と言える。さらに、#2~#4でもa2,a3がTになることが結果ノードXをTにする検証にはならない。


したがって、僕の解釈では、2つの列を追加すべきと考える。

Dt2kase

ただ、テスト実施は#6からはじめたほうがいいかもしれないなあ。

| | コメント (1) | トラックバック (0)

原因結果グラフの演習でコツをつかもう

先日2/7に、TEF主催の第3回「ソフトウェアテスト技法ドリル」勉強会がありました。

勉強会は「原因結果グラフ」をテーマにして、講義と演習の2時間でした。2年前に同じようにTEF主催で原因結果グラフ&デシジョンテーブル勉強会をしたときは、講義と演習を用意して全4回(のべ8時間)とかなりヘビーなものでした。ということで、今回はテキストであるドリル本と予習問題を用意して、事前に参加者に学習をしてもらってかなり時間短縮できました。

でも、参加者によってはついていけなかったり、会場ででてきた質問もあまり理解できなかった、といった声も少し聞かれました。ということで、2年前の勉強会で扱った例題・演習問題・宿題をまとめて、参加者の理解度に応じて解いていけるようなページを作ろうと思いました。(アイデアは秋山浩一さん)

原因結果グラフの演習

今のところ、問題数は18問。半分の9問については、解答例を付けました。あとで自分なりの解説も付けようかとは思っていますが、鈴木三紀夫さんが解説ページをつくるかも?!

たまゆら雑記

# このブログタイトルは、テスト技法を勉強している人には有名ですよね。デシジョンテーブルを勉強すると、この名前の旧ブログにたどり着きますから!


ということで、完成までは今しばらくお待ちくださいm(_ _)m

| | コメント (0) | トラックバック (0)

JaSST'11 Tokyo にて「CEGTest」を使って発表してきました。

マイコミジャーナルに記事として取り上げていただきました。

【レポート】「CEGTest」開発者が語る、原因結果グラフ技法の応用テクニック - JaSST


1月25-26日、東京都目黒区の目黒雅叙園にてソフトウェアテストをテーマにした技術カンファレンス「JaSST(Japan Symposium on Software Test) 2011」が開催された。ここでは、25日の午後に行われたニフティ 加瀬正樹 ...... Read more

この場を借りて、発想やアドバイスをいただいた秋山さん、にしさんに御礼したいと思います。

原因結果グラフは、基本的にはツリー構造になっていて、その枝分かれしている中間ノードに着目すると、分割(partitioning)やズームアウトができる、というのが今回の論文の発想です。規模に応じてテスト対象を分割する手法はにしさんのスライドなどによく登場しますし、秋山さんのソフトウェアテストHAYST法入門ではズームインとともにズームアウトが紹介されています。今回、明確な定義を与えて、原因結果グラフを分割し、どんな効果があるかなどを考察しました。考え方自体は、原因結果グラフに特化したものではないので、もう少し考えてみたい。

分割可能点の多い少ないでグラフの複雑度が数値化できるかなあ。


| | コメント (0) | トラックバック (0)

[書籍]ソフトウェアテスト技法ドリル -面で逃さない-

テスト条件がひとつの場合から2個以上になると、テスト設計がぐんと難しくなる。難しくなるというのは、全体のテスト条件の組合せの中から優先的にテストすべきパターンを見つける技法を知らないと、効率が悪くなるということ。第3章で紹介するのは「ドメイン分析テスト」「デシジョンテーブル」「原因結果グラフ」「CFD法」の4つのテスト技法。

実は、このサイトで公開している原因結果グラフの支援ツール「CEGTest(セグテスト)」について、詳しく紹介していただいてます。この場を借りて御礼申し上げます!ありがとうございます!現時点でCEGTestの使い方について最も詳しく書かれているドキュメントだと思います^^;また、CFD法についても書籍として解説しているのはドリル本だけじゃないでしょうか。デシジョンテーブル自体も同じことを言えるのですが、CFD法はテストエンジニアだけでなく実装に携わるエンジニアにも知っておいて損はない技法といえるでしょう。

原因結果グラフのデシジョンテーブル変換については、JaSST'07 Tokyoの「三賢者」資料が一番詳しいです。


==

# 2010/10/10 修正
CFD法については「ソフトウェア開発・検証技法」にも説明があるようです。また、ソフトウェア・テストPRESSにも特集がありましたね^^;すっかり抜けていました。

| | コメント (0) | トラックバック (0)

[イベント]JaSST'10四国 原因結果グラフのワークショップ

日本がんばれ~

==

すでに申し込みは終了していますが、7月2日(金)に香川大学にて「JaSST'10 Shikoku」が開催され、西先生の講演の後、原因結果グラフをテーマにしたワークショップを行います。

 JaSST'10 Shikoku
 http://jasst.jp/archives/jasst10t.html


ここで紹介している「CEGTest」を使って、原因結果グラフを描く練習をしてもらう予定です。何かフィードバックできることがあればブログに書こうと思いますー。

 原因結果グラフによるテスト設計支援ツール - CEGTest
 http://softest.cocolog-nifty.com/blog/cegtest.html

 (ウェブ版)CEGTest-1.3
 http://softest.cocolog-nifty.com/labo/CEGTest/

 (zip版)CEGTest-1.3-20100629.zip
 http://softest.cocolog-nifty.com/labo/CEGTest-1.3-20100629.zip

ちなみに、7月~10月にかけて、四国の他に関西、北海道でもJaSST開催が決定しています。

 JaSST'10 Kansai ~負けないテスト~
 http://jasst.jp/archives/jasst10w.html

 JaSST'10 Hokkaido ゲンバノチカラ ~テスト実装5秒前!そのとき現場が動いた~
 http://jasst.jp/archives/jasst10s.html


| | コメント (0) | トラックバック (0)

原因結果グラフの「制約のテスト」 ONE制約

  • 原因結果グラフの「制約のテスト」

  • 原因結果グラフの「制約のテスト」 その2

  • の続きです。

    ==

    「制約のテスト」を考える上で、どんなバグを検出できるか。まずはONE制約。4つのノード「A」「B」「C」「D」にONE制約がかかっている状態を例にしてみます。

    One_ceg

    4つのノードの必ず一つが真になるので、入力条件空間を平面で表現すると、以下のように4つの領域が隙間なく、境界線によって分割された状態が考えられます。

    One_ok

    任意の入力条件は、4つの領域「A」「B」「C」「D」のいずれかに属することがわかる。これが ONE=(A B C D) が成立する状態です。では、成立しない状態とはどういう状態でしょう?

    1. 領域「A」が領域「B」と一部分重なる場合
    2. One_a_over_b

      領域「A」と領域「B」を分割する境界がバグによって領域「B」側にシフトした場合、ONE=(A B C D)は成立しない。同様に領域「C」側にシフトした場合、領域「D」側にシフトした場合、を考えると以下の3通りの条件の組合せが考えられる。シフトする場合と同様、飛び地で領域が重なりあう場合も同じでしょう。

      One_a_over_b_dt

      例えば、不等号「≦」「<」の誤り、条件となる定数誤りなどがこのバグに該当する。また、何かのイベントがただ一つだけ生じるはずが、同時に2つのイベントが生じてしまうケースも。

      そして、これは他の領域「B」「C」「D」についてもいえるので、同様に3つの条件の組合せが作れて、合計12通りが全部。

      One_over_dt

      同じ条件の組合せが2つずつあるので、半分の6通りにまとまります。

    3. 領域「A」の一部が欠落し、間隙が生じる場合
    4. 領域「A」と領域「C」を分割する境界がバグによって領域「A」側にシフトした場合、領域間に間隙ができてしまい、ONE=(A B C D)は成立しない。

      One_a_gap

      これは、本来はAが真となるべき条件の組合せでAが偽となるパターンで、以下の通り。

      One_a_gap_dt

      先ほど同様、欠損は領域「B」「C」「D」にもありえるので、以下の3通りも考えられるが、結局は一つに集約。

      One_gap_dt

      例えば、不等号に「=」をつけ忘れ、見逃したケースが存在するといった誤りがこのバグに該当する。状態を表すノードであれば、初期状態が未定義・不定値だったりする誤りもこのバグかな。

    ==

    このことから、6+1=7通りの組合せがありえないことを示せば、ONE=(A B C D) が成立することの必要条件となるだろう。

    One_na_dt


    でも、実際にありえないことを確認するのって、難しいよなあ。。。

    | | コメント (0) | トラックバック (0)

    原因結果グラフの「制約のテスト」 その2

    原因結果グラフの「制約のテスト」の続きです。

    ==

    制約を含んだ原因結果グラフをデシジョンテーブル変換する際、制約の成立性もあわせてデシジョンテーブルに変換してみようという試みです。原因結果グラフのメリットのひとつである「テスト条件を削減できる」という効果は薄れてしまいますが、前提条件である「制約のテスト」を網羅しやすくなるので、やる価値はあると思います。

    例題として以下のような原因結果グラフを使ってみます。

    Ceg

    1. 制約全体で考える
    2. この原因結果グラフでは2個の制約があります。


      REQ=(B A)     i.e. Bが真であるためにはAが真であることが必要
      ONE=(B C D)    i.e. BとCとDはいずれかひとつが真でなければならない

      この原因結果グラフにおいて「制約が不成立」というのは「REQ制約が不成立」あるいは「ONE制約が不成立」を意味しますので、これはすなわち、

      Ceg_2

      と表現できます。得られるデシジョンテーブルは以下の通り。

      Dt

      言い換えれば、「REQ制約が不成立」を確認するテスト条件ではそれ以外の制約(ここでは「ONE制約」)は成立すると仮定する必要があります。でなければ「制約が不成立」という結果にどの原因が影響したかが不明確になるからです。逆も同様。3列目については「制約が成立」という結果ですので、はじめてテスト対象の原因結果グラフを意識することになります。

    3. REQ制約について
    4. まず「REQ制約が成立するか否か」の原因結果グラフとデシジョンテーブルを作成します。

      Reqceg
      Reqdt

      明記していませんが、ONE制約は成立していることが前提です。「REQ制約が不成立」を確認したいので、#2を使います。

    5. ONE制約について
    6. 次に「ONE制約が成立するか否か」の原因結果グラフとデシジョンテーブルを作成します。「ONE制約が不成立」を確認したいので、#2#3#4#6を使います。

      Oneceg
      Onedt

    7. テスト対象の原因結果グラフについて
    8. 最後にすべての制約が成立することを前提にして、テスト対象の原因結果グラフとデシジョンテーブルを作成します。

      Dt_2

    9. 最終的なデシジョンテーブルについて
    10. 2~4のデシジョンテーブルを結合するとこのような8個のテスト条件が確認できます。

      Dt2

      テスト対象の原因結果グラフの3個と合わせて5個の「制約不成立」の確認をすることになります。

    もう少し検証したらツールに反映します。

    | | コメント (0) | トラックバック (0)

    より以前の記事一覧