« 2006年10月 | トップページ | 2006年12月 »

ブラックボックステストは、缶詰とビン詰か

昨日のグレーボックステストについての続き。というか思いつき。

==

ブラックボックステストといっても、全くソース構造を知らないままで行う真っ黒なブラックボックステストと、ソース構造を把握した上で(例えば実装担当者がテストケースを作成する場合など)行うブラックボックステストでは、手法・効率・精度などで違いが出てくる。一般的に前者は「ブラックボックステスト」と呼ばれ、後者は「グレーボックステスト」と呼ばれる。

そこで。

高校のときに見た(確か旺文社の問題集)名前付けを思い出したのだが、「缶詰テスト」「ビン詰テスト」という表現はどうか。「缶詰」は中身が全くわからない。「ビン詰」は中身が一応見える。でも両者ともに機能は一緒。

名前なんてどうでもいい、か。。

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

凄いテスター・凄いテストツールよりも均質なスキル

実家に電話したら、地デジが映るようになったらしい。おめでとう。

==

凄いプログラマはバグを多数見つけられる by Geekなぺーじ

凄いプログラマな方がテストを行うと、大量にバグを発見してくれる凄いテスターになってくれます。

(中略)

凄いプログラマな人がホワイトボックステストをしてくれて、バグが潜んでいる行まで示して「バグってない?」と言われてしまうと「ごめんなさい。ありがとうございます。」以外に何も言えなくなります。 そのような方法でバグ指摘をしてくれると、何が原因でバグっているかを調べる時間が軽減されてコード書きが非常に迅速になります。

凄いプログラマーは経験的に・無意識的に効率的な欠陥発見スキルを持っていて、どんどんバグを釣り上げる。それは体系的な品質工学やテスト技法を学んでいるわけではない。しかし、そういったプログラマーはほんの一握りであって、プロジェクトメンバー内には凄くないプログラマーは僕を含めて数多くいる。そういった僕らは人の真似をしたり、勉強をしたりして、意識的に効率的な欠陥発見スキルを磨かなければならない。

個人的には、超凄いプログラマ数人と、きっちり網羅的にテストを出来る性格のテスターさんの組み合わせが最強な気がします。 ただ、超凄いプログラマをテストに投入するよりはコード書きに投入するという場合が多いとも思います。

著者のご指摘のとおり、凄いプログラマ+地道な網羅的手法が得意なテスターのコンビネーションが最強とは思うし、凄い人はコーディングに投入してしまう。ということは、現実的にはわれらのような凡人的プログラマでもブレ・ムラのない品質を保てるようなツールやスキル習得方法、文化が求められると思う。まさにベストではなくグッドプラクティス

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

グレーは白と黒をあわせたもの?

今日は休暇。久しぶりにまともな更新。

==

ふと、グレーボックステストってどういうものだろう?と思って調べてみた。

第13回 「ソフトウェアテストの設計 その5」

ある程度、作りが分った上で実施するテストをグレーボックステストといいます。

(中略)

グレーボックステストはアーキテクチャが分っていることに意味のあるに時に用いるやり方で、ユーザビリティテストの様に仕組みを知ることがかえってマイナスとなるテストでは適用すべきではありません。「こう作っているのだから、そう動くべきだ」という見方と、「こう使いたいのだから、(作りがどうであろうと)そう使えるべきだ」とでは検証で目指すところが違うからです。

この定義だと、ホワイトボックステストでもなく、ブラックボックステストでもない検証項目、といったイメージ。ホワイトボックステストケースとブラックボックステストケースを優先順位で並び替えた総合テストケース群、ということではない。

しかしだ。

例としてABS(アンチ・ロック・ブレーキ・システム)の動作確認をするケースで考えてみましょう。構成を何も知らず、要件として「ABSスイッチがONの時は、急ブレーキをかけてもタイヤがロックしないこと」ということだけを知っていて、検証するケースがあるとします。

この場合と「ABSスイッチがONで、時速XXkm以上にて走行時、踏力XX㎏以上でブレーキングされ、タイヤのロックがセンサにより検出された場合にはABSを作動させる...」という仕様をテストで確認するケースとでは、検証の詳細度がかなり異なります。

グレーボックスは後者に当たり、

ここでは「ABSスイッチがONで、時速XXkm以上にて走行時、踏力XX㎏以上でブレーキングされ、タイヤのロックがセンサにより検出された場合にはABSを作動させる...」をグレーボックス的なテストケースと位置づけている。

でも、これはABSスイッチの状態、走行速度、ブレーキの踏力、センサーの感知といった条件での動作確認であって、仕様書に載っている条件と思われる。それってブラックボックステストケースになるんじゃ?

黒と白の中間」と表現されることが多いグレーボックステストだが、意外にわかりにくい定義な気がする。

==

今、自分なりのTDDっぽい開発をしているが、そこでのテストケースはグレーボックスだなあと思っている。が、それってもしかしたら黒と白をあわせただけのテストケースなのかも。これってどうなのだろうか。

====================================================================
2006年11月29日 追記。

JUnitと単体テスト技法―JUnit4対応 by それはBooks

このブログではコンピュータ書籍, デザイン書籍, ビジネス書籍, その他の書評を行っているようで、

このJUnit の使い方と単体テストについての書籍中では以下のように解説している。

ブラックボックステスト

 ブラックボックステストは、プログラムの仕様を元にテストを行うものです。プログラムの内部構造は考慮せず、入出力の仕様に注力します。
 ブラックボックステストとして、次の4つのテストがあげられています。

  ・同値クラステスト
  ・境界値テスト
  ・デシジョンテーブルテスト
  ・強制エラーテスト
  ・グレーボックステスト

ここではグレーボックステストは、ブラックボックステスト技法のうちのひとつになっている模様。


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

勉強会参加できず。

仕事が長引いて、先週末に開催された社外の勉強会に参加できず。残念。。。

==

テスト駆動型開発(TDD: Test Driven Development または BDD: Behavior Driven Development)は、シンプルさを追求した設計フレームワークである。このキーワードで何か記事を書く予定。

ちなみにTDDに関する最近の記事。
http://www.atmarkit.co.jp/fdotnet/nagile/nagile05/nagile05_01.html
http://blog.goo.ne.jp/wildriver_1977/e/0712f31a16f0c959d7a132136ac40582

コメントは後ほど。

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

ソフトウェア品質を高めるには(2)〜カイゼンを実践するマインド

今日は外出。エリック・オールマン氏の講演も聞いてきます。

==

カイゼンを実践するマインド by @IT ソフトウェア品質を高めるには(2)

システム内部の設計を変更しても、外部に提供しているサービスには影響がないことをテストで証明し、品質の劣化が発生していないことに注意を払う必要があります。従って、進化を続けるためには、常に多くのテストを行う必要があります。そこで有効な手段としては、テストの自動化があります。テストを自動化することで、人的工数を下げることができます。しかし、テストを自動化することは、一朝一夕に実現できるわけではありません。テストを自動化するためには、設計段階からテストすることを前提にして開発を行うことが重要です。また、すべてのテストを自動化することを目的にすると挫折してしまうので、自動テストできる範囲を広げることを目的にすべきです。

「すべてのテストを自動化する」というのは過度の期待であって、システム開発者を惑わす。今ははっきりと認識しているが、以前の僕も「テストを自動化する」を「テストを自動化するので手動テストは不要」といったような誤認をしていた。このパラダイムを持っていると、テストケースをすべて自動化しなくちゃならないと考えてしまい、逆にテストツールが複雑化してしまい本末転倒になってしまう。それに、自動化したことで品質が保たれていると勘違いしてしまい、単体テストや手動でするべきテストを怠ってしまう、といったエラーを引き起こす。(実際に引き起こした。)著者のいうように進化を続けるシステムではテストの自動化はかなり効果的な手法ではあるが、目的をきちんと明確にしておくのも忘れないように。



システムを高い品質に保ち、その品質を維持したまま、さまざまな機能拡張を繰り返すシステムに対して、テスト容易性を指針とすることは大変有効です。それは、良いテストが良い設計を証明することや、品質を維持したまま設計を改善するための重要な武器になるからです。

新規システム開発ではそういった指針が重要かも。ただ、既存のシステムがすでにある場合って思った以上にプロセス改善やテスト改善、指針に準規するって難易度が高そう。



最近、脚光を浴びているDIコンテナでは、独立性の高いコンポーネントの開発と、そのコンポーネントの組み立てを分離することで、コンポーネント単体のテストやコンポーネントの関連テストを容易に実現することができ、自動テストの範囲を広げることができます。一部の開発者は、DIコンテナをテストコンテナと呼んでいます。

DIコンテナってなんだろう?javaの世界の話?調べてみようっと。

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

lcovでテスト・カバレッジ状況をグラフィック化

GNU CC についてくる gcov を使ってテストコマンドのテスト・カバレッジを測定してみた。このデータは lcov というツールでグラフィック化ができるらしい。

Lcov

ちなみに、「_sutest」ではじまるソースは単体テストコマンド用ソース。「util.c」は今作りかけなのでカバー率が低い。これ、日本語化とかうちの会社向けに改造しちゃおうかな。

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

テスト駆動型開発 -WEB+DB PRESS

テスト駆動型開発について知識不足なので買ってみた。JUnitではレッドとグリーンとリファクタリングという3つのキーワードがあるらしい。Cの単体テストにもその色をあててみようかな。

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

7つの習慣の研修

昨日と今日で、社員全員対象の「7つの習慣」の研修にいってきた。理解するだけでなく実践せねば。

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

Stack Unit Testing Framework for C (SUtest)

MinUnitを改良して、C言語用の単体テストツールを作ってみた。判定ロジックはMinUnitの3行マクロでそのまま使わせてもらって、

  • テストスイート読み込み

  • テストコマンド用ソース作成

  • テストコマンドコンパイル

  • テストコマンド実行&結果出力

  • という一連の作業を自動化してみた。

    テストスイートはテキスト形式の超簡単な形式で、どんどんテストケースを積み上げられる形。積み上げるのでStack Unit Testing Framework for C(SUtest)なんて名付けてみた。笑

    自分で試しに導入してみたんだが、コレが意外にも使える。社内で誰か試してみて感想が聞きたいぜ。

    テストスイートはこんな感じ。関数名、復帰値の変数型、条件式、引数、・・・

    /*
    # cat2string(); 文字列と数字を結合して文字列にする
    cat2string|char*|result == NULL|NULL|0
    cat2string|char*|result == NULL|NULL|1024
    cat2string|char*|result == NULL|NULL|-1
    cat2string|char*|result == NULL|NULL|-1024
    cat2string|char*|strcmp(result, "abc0") == 0|"abc"|0
    cat2string|char*|strcmp(result, "abc1024") == 0|"abc"|1024
    cat2string|char*|strcmp(result, "abc-1") == 0|"abc"|-1
    cat2string|char*|strcmp(result, "abc-1024") == 0|"abc"|-1024
    */


    んで、テストコマンド用ソースはこんな感じ。

    #include "hoge.h"
    #include "sutest.h"

    int tests_run = 0;

    static char* test_sutest0(){
        char* result = (char*)cat2string(NULL, 0);
        su_assert("error!!: LINE=[41]", result == NULL );
        return 0;
    }

    static char* test_sutest1(){
        char* result = (char*)cat2string(NULL, 1024);
        su_assert("error!!: LINE=[42]", result == NULL );
        return 0;
    }

    static char* test_sutest2(){
        char* result = (char*)cat2string(NULL, -1);
        su_assert("error!!: LINE=[44]", result == NULL );
        return 0;
    }

    static char* test_sutest3(){
        char* result = (char*)cat2string(NULL, -1024);
        su_assert("error!!: LINE=[45]", result == NULL );
        return 0;
    }

    static char* test_sutest4(){
        char* result = (char*)cat2string("abc", 0);
        su_assert("error!!: LINE=[47]", strcmp(result, "abc0") == 0 );
        return 0;
    }

    static char* test_sutest5(){
        char* result = (char*)cat2string("abc", 1024);
        su_assert("error!!: LINE=[48]", strcmp(result, "abc1024") == 0 );
        return 0;
    }

    static char* test_sutest6(){
        char* result = (char*)cat2string("abc", -1);
        su_assert("error!!: LINE=[50]", strcmp(result, "abc-1") == 0 );
        return 0;
    }

    static char* test_sutest7(){
        char* result = (char*)cat2string("abc", -1024);
        su_assert("error!!: LINE=[51]", strcmp(result, "abc-1024") == 0 );
        return 0;
    }

    int testcase_count = 63;

    static char* all_tests(){
        su_run_test(test_sutest0);
        su_run_test(test_sutest1);
        su_run_test(test_sutest2);
        su_run_test(test_sutest3);
        su_run_test(test_sutest4);
        su_run_test(test_sutest5);
        su_run_test(test_sutest6);
        su_run_test(test_sutest7);
        return 0;
    }


    int main(int argc, char **argv) {
        char *message = all_tests();
        if (message != 0) {
            printf("%s\n", message);fflush(stdout);
        }
        else {
            printf("ok\n");fflush(stdout);
        }
        printf("Testcase : %d\n", testcase_count);fflush(stdout);
        printf("Tests run : %d\n", tests_run);fflush(stdout);

        return message != 0;
    }

    このテストコマンド用ソースをコンパイルして、実行するのだ。
    # コンパイルが system() なんでちょいとしょぼい感じかも。

    自作のヘッダーを使ったり、memset()などを指定したりすればかなり守備範囲が広がる。

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

    MinUnit -- a minimal unit testing framework for C

    C言語のxUnit系テストツールを探していたら、こんなのを発見。

    MinUnit -- a minimal unit testing framework for C

    /* file: minunit.h */
    #define mu_assert(message, test) do { if (!(test)) return message; } while (0)
    #define mu_run_test(test) do { char *message = test(); tests_run++; \
        if (message) return message; } while (0)
    extern int tests_run;

    たったこれだけ。少し書き加えてチーム内のツールにできそう。

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

    テストを自動化して何をしたい VS テストを自動化したら何ができる

    先日、包括的なテスト管理と目に見える品質分析の実現セミナーに参加した。

    ==

    社内でもテスト自動化したい、をキーワードにしていろんな要望があるが、もしかしたら「したいこと」と「できること
    との間にはギャップがあるのではないか。プレゼンターの加藤大受氏もおっしゃっていたが、テストの自動化は魔法の杖でも銀の弾丸でもないし、テスト工数を減らすとかテスト単価を減らすとかの目的を必ず達成できるとはいえない。テストツールを導入したら、それなりに育成コストもかかるし、テストスクリプトを作成するのにも第1回目では手動以上に時間もかかる。もしかしたら納品したらはいそれまで、といったプロジェクトであればそもそもテストを自動化して、何度もテストスクリプトを実行させるメリットがなかなか享受できない。テストの自動化で期待することは、「品質の数値化」や「他のテストをできる」とか「長期的なテスト工数削減」でしかない、のだから。(byセミナー)

    先日から少しずつ読んでいるインターネットアプリケーションのためのソフトウェアテスト 体系的ソフトウェアテスト入門
    にも似たようなことが掲載されているが、「テストを自動化すること」が目標ではないし最重要ではなく、「テスト自動化で何がしたいかを検討し、それには何が必要かを吟味する」ことも重要なことだと思う。手垢のついた表現だとプロセスが重要、ってこと。

    ==

    ずっと前にいろいろ調べてみようと思っていたC言語の単体テストの手法をまた勉強しはじめてみるかな。
    CCUnit/CUnitとか。

    CCUnit
    CUnit


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

    複雑な状態遷移による不具合

    1週間が早い。水曜日と木曜日は仕事を早めに切り上げて休息。。。金曜日最後がんばるぞ。

    ==

    社内でアクティブな開発者を集めて開発標準化/自動化といったWGが発足し、そのメンバーに入ることになる予定。ソフトウェアテストというややピンポイントな勉強を続けていたが、プロセス改善活動といったもう少し広範囲の
    勉強も必要かも。

    ==

    状態遷移図やグラフを使ったり、ユースケースを使って、機能テストをしたとしても複雑な状態遷移で発生する不具合をなかなか見つけられない、といった経験が多い。

    例えば「迷惑メールフィルタリングを設定する」という機能テストをする場合、「キーワード条件」や「有効/無効」や「ブラウザ/OS」といった設定に関する条件の組み合わせは自然と網羅していることが多い。が、ユーザ自身に関する条件ってなかなか網羅しにくかったりする。ユーザの「契約状態」とか「他の機能の設定状況」とか。例えば「他の機能の設定状況」では、その機能Xが有効/無効の2種類だけの水準値だったとしても、テストケースは2種類ではなかなか不具合を見つけられない。「有効から無効に変更後の」とか「デフォルト状態」とか。設定有効日時や設定無効日時といった日付情報を持っている場合は、デフォルト状態ではどんな日付が入っているのかなどをきちんと考慮する必要がある。

    # それともここらへんは基本中の基本で、僕がおろそかにしてるだけなのだろうか。。。

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

    3因子間組み合せのリストアップは意外に大変?

    3因子間組み合せ表を視覚的に表現する前に、まずは3因子間組み合わせを洗い出す方法が必要だ。

    2

    上図のように因子ABCDがあり、それぞれ3水準3水準2水準2水準だった場合は、2次元マトリックスを作成して、クリーム色のマス目をカウントすればよい。この図では合計37通りとなる。

    では、3因子間組み合わせ数はどうなるか。まずは3因子の選び方。これは4因子の中から3因子を順序なしで選択するので4通り。高校で習った順列組み合せと同じだ。実際には下図の(0、1、1、1)、(1、0、1、1)、(1、1、0、1)、(1、1、1、0)の組み合せが3因子の取り方になる。4パターンそれぞれで組み合せ数を計算し、合計した60通りが3因子間組み合せ数となる。

    3

    余談だが、因子数が3のときは3因子間組み合わせは2因子間組み合せよりも少なくなる。2007/11/07訂正

    あきやまさんからのご指摘。 因子数が3の場合は、

    2因子間組み合せ数 = 3×k×k
    3因子間組み合せ数 = k×k×k

    となるので、k=2、3のときは3因子間組み合わせが2因子間組み合せ以下、k≧4のときは必ず3因子間組み合わせは2因子間組み合せ数よりも大きくなる。

    # これはまだ視覚的には複雑すぎる。どうにかしてわかりやすい表ができないものか。
    # もう少し考えてみる。


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

    テストの自動化の落とし穴

    自動テストツール導入時の注意点 by ただいま修行中...

    テストを自動化することで、生産性は向上するのか?

    自動化に向くテストは、同じテストを繰り返し行うテストである。
    自動化に向かないテストは、1回しか実施されないテストである。

    (中略)

    自動化することで、逆に効率が低下することもあるので、慎重に検討し、実施する必要がある。

    テストを自動化することで得られる最も大きなテストは「回帰テスト」だと思っている。日々テストケースを積み上げていき、それを回帰テストという形で何度も繰り返すことで、一定の品質を低コストで保証できること。例えば製品として世の中に送り出してしまったら、はいそれまで、といったプロダクトに関しては、テストの自動化はあまり適さない。

    先日の勉強会に参加していた方も「思ったよりも自動化によるコスト削減は望めないのが実情」といっていた。逆にテストの記録(テストスクリプトの作成)が第1回目のテストでは必要になるためコストがかさむ、という。世の中にはうまい話はないのだ、テストツールの宣伝文句を鵜呑みにしないように気をつけたほうがいいかも。

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

    社外の勉強会に参加

    先週は社外で開催されたテスト関連の勉強会に出席してきた。JRが遅延してたため途中からの参加になってしまったのがちょいと残念。

    社内でもけっこう関心の高い内容だと思われるので、あとでまとめて社内で発表できたらいいな。で、モデレータや講師が推薦していたのがこの本。

    僕の会社はWebアプリケーションを利用したサービスがほとんどなので、これは読んでみたい。

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

    せっかく平日はブログ更新してたけど、昨日でストップ

    勉強するというモチベーションを維持する目的もあったのだが、平日はブログ更新するように心がけていたが、昨日具合が悪くて記録もストップ。

    ==

    今週はなんだか勉強が進まないので、自分が毎日チェックしているソフトウェアテスト関連のブログを紹介してみようかと。(順序はブックマークした順、最近更新されているブログを抜粋)


  • あるSEのつぶやき

  • 直交表についてブログ検索してたときに見つけたところ。ソフトウェアテスト/品質についての記事以外にも最新の技術やサービスを紹介しています。

  • An Agile Way

  • マインドマップとテストケース作成について調べているときに見つけたブログ。設計→分析→実装→テストというモデルが僕にとってはわかりやすかったです。

  • 今日思うこと

  • 何度か記事にトラックバックさせていただき、自分なりの所感も書かせていただきました。僕なんかよりも経験量が豊富でためになる記事を毎回読ませてもらっています。

  • つれづれなる技術屋日記

  • こちらも現役技術者のブログ。直交表の功罪についてかなり深い考察が書かれています。

  • ただいま修行中...

  • 自分と同じ修行の身といった感じですが、僕なんかよりも深い知識を持っているので、わからない単語などを調べながら毎回読ませてもらっています。直交表に興味をもってくださっているので、一緒に勉強できたら〜と思ってます。

  • ソフトウェアエンジニアの日記

  • ちょうど社内勉強会で話した内容と同じ記事が載っていたので発見。

  • 今日とは違う明日

  • 最近見つけた。まだじっくりと読ませてもらっていないですが、興味引かれるキーワードが載ってます。

  • チームリーダー日記

  • 最近見つけた。自分はまだまだチームリーダではないが、プロジェクト管理という視点でも勉強になりそう。


    いやー、最近のネットは便利だなあ。

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

    « 2006年10月 | トップページ | 2006年12月 »