« 2007年1月 | トップページ | 2007年3月 »

テストオラクル -コードであってはならない-

JSTQBテスト技術者資格認定の試験は今週末3/2です。

==

ソフトウェアテスト標準用語集 日本語版Ver 1.1 (PDFファイル) by JSTQBテスト技術者資格認定ホームページ

test oracle(テストオラクル): テスト対象のソフトウェアが実際に出力した結果とを比較する期待結果のソース。オラクルは、実在する(ベンチマーク用の)システム、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。[After Adrion]

「コードであってはならない」というのはどういうことなのだろうか。比較対象がコードの場合、それ自体の正当性を示さなければならないからか。W.R. Adrion氏の言葉の引用(?)かと思われるが、ちょいと調べても不明。

前に見つけたMinUnitの使い方は見方によってはコードにテストオラクルが含まれているような気がする。テストコマンドやテストツールも。どういう意図の注意喚起なのかを知りたい。深く考えすぎかもしれないが。

ちなみに、「oracle」は神のお告げとか神託とかっていう意味らしい。知らなかったあ。

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

結合基準・結合計画

テスト計画の中で、結合計画というポイントがあるとしたら、そこではスモークテストに注目してみるのはどうだろうか。「どんな機能、どの程度の性能をクリアしたか」という基準を設定し、「それがクリアすれば結合テストが可能」という目安を検討しておく。その目安は前工程の単体テストでも意識されることになる。

==

2007/02/25追記。
IEEE829のテスト計画の中に「Item pass/fail criteria(テストアイテム合否判定基準)」というのがあるから、これにあたるのか。でも、これはマスターテスト計画のことだしな。

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

スモークテストのありがたみがようやくわかった

今まで事務所内のプロジェクトメンバーでのシステム開発が多かったのでなかなか気づけなかったこと。

  • どこまでを単体テスト、どこからを結合テストにするか

  • 単体テスト完了モジュールの結合テストの前のスモークテスト
  • 今更ながらこの2点の重要度が身にしみてわかった。スモークテストすら合格しないモジュールを結合しても、先に進まんぜ。

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

    単体テスト技法を図解してみる

    インフルエンザが流行っています。

    ==

    単体テストを効果的にする手法をグラフィックで表現してみる。間違った解釈も含んでいそうだが。。。

    1. テスト空間U関数func1を写像としてイメージした図。
    2. 関数func1の結果は結果空間Vの部分集合、といったイメージ。


    3. 関数の引数チェックを行い、テスト空間Uを小さくする手法をイメージした図。

    4. 引数チェックをすることで、テストケースを少なく効率的なテストを行う、という感じ。点線に関する実質的な検証をすることがなくなる。JaSST'07で松尾谷さんが使った造語を使えば、「無則」と「有則」の識別、になると思ってます。
      2007/02/17修正。無則の識別とか関係なさそう。


    5. ちょいと苦しいが、デシジョンテーブルのつもり。

    6. func1の逆関数をとり、そのカーネル原像を利用してテストケースを設計する図。


    7. 同値分割の図。


    8. テスト空間をある規則で分割し、その代表元についてだけ検証する。関数func1が連続性を持ち、代表元の検証結果がテスト空間全体での検証と同程度の結果を得る、という意味。


    9. これも苦しいが、境界値分析のつもりの図。


    10. 境界(boundary)あるいはその近傍の元について検証し、効率よく欠陥を見つける手法。


    ==

    グラフィックにしてみて、ふと思ったのだが、同値分割って概念と、単体を小さくしてテストすることって、似てるんじゃないかって思った。関数をどんどん小さくして、テストしやすくしていく手法があると思うが、これの究極形が代表元だけ検証して、それに対する単体テストの検証結果と同一視するってことなんじゃないかと。

    なーんて、午前0時を回ってからぼんやり考えてみました。

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

    C言語における単体テスト テスタビリティを重視した関数設計

    今日は社外WGに参加。春の嵐だ!

    ==

    僕はC言語ばっかの開発をやってるので、ここでもC言語をベースにしていろんなことを書きます。あしからず。

    リリース後の欠陥発覚は手戻り工数が最もかかるものだが、その多くは単体テストで発見可能なものが多い。某静的解析ツールのベンダー資料によるとその割合は40%近くになるらしい。定量的な資料は持っていないが、僕も単体テストの質がシステム全体やプロジェクト全体の質を大きく左右すると考えている。

    そこでだ。僕の考える、上質な単体テスト for C言語はこんな感じ。

  • テストしやすいという、テスタビリティ
  • (例1)
    int
    func1(
        int a1,
        char* a2,
        int a2size )

    (例2)
    foor_obj_t*
    func2(
        var_obj_t* b1 )

    まず、基本的な関数の型はint型がいろいろ都合がいい気がする。エラー番号を復帰したり、errnoを復帰したり、直感的なものがよいと思う。例1のように、文字列格納先の先頭ポインタを引数渡しする場合は、呼び元で確保したサイズも合わせて引数渡しすること。(ちなみによくあるライブラリによっては文字列の先頭ポインタとサイズを構造体にしているものも多い。)サイズを引数指定することで、データコピー時のバッファチェックがしやすくなる。

    例2のような引数や復帰値に構造体を使った関数は、関数内で動的確保を行い、呼び元の責任で開放する。構造体の初期化がしやすくなる(と、僕は思ってる)。

  • テストケースを作成しやすいという、テスタビリティ
  • 例3
    int
    func3(
        int c1,
        const char* c2,
        char* c3,
        int c3size )
    {
    /* (A)引数チェック */
        if( c1 <= 0 || c2 == NULL || *c2 == 0x00 || c3 == NULL || c3size <= 0 ){
            return(ERR_ARGV);
        }

    /* (B)本体処理 */

    /* (C)エラー処理 */
    retired:
        /* 事後処理・初期化・開放処理 */
        func_free();
        return(ERR_SYSTEM);
    }

    実装は(A)引数チェック(B)本体処理(C)エラー処理の3部で構成すると、テストケースが作成しやすいのではないかと思っている。(A)引数チェックは必須。ここでのチェックがこの先のテスト空間を限定してくれるから。あるいは、ここに欠陥を紛れ込ませて、テストのテスト(テストが無作為で紛れ込ませた欠陥を検出できるかの検証)ができるかも?引数によっては関数の旅をするものもいるだろうが、
    僕の場合はすべての関数に対してここは必ずテストケースとして設定する。

    (B)実装部分については、割愛。

    (C)C言語で「goto文は使わない」というしきたりがあるかもしれないが、エラー処理については使ったほうがフローが簡潔になるし、開放漏れ・クローズ漏れを起こしにくいんじゃないかと思います。開放漏れ・クローズ漏れはなかなか単体テストでは発見しずらいか。

    てな感じで僕は設計してます。

    ==

    さあ、実装とテストを駆動させるのだが、ご紹介するのは、僕が単体テストで使う3つのツール

    • minunit(自作改良版) - 単体テスト用テストコマンド自動生成
    • minunitというたった3行のユニットテストツール。これをベースにテストコマンド用ソースを自動生成するツールを自作して利用。

    • gcov - プログラムコードカバレッジ測定ツール
    • GCCのプロファイリング機能で「-fprofile-arcs -ftest-coverage」を指定してコンパイルする。詳しくはここで。分岐網羅の測定も可能か。

    • lcov - テストカバレッジ情報グラフィック化
    • gcovで測定した結果をHTMLと画像に変換するツール。詳しくはここ。Linux用だが、Solarisにも移植はできるよ。

    これらのツールについては、もう少し勉強・改良してみたいと思っています。

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

    C言語における単体テスト、あるいはTDDについての考察

    今日はあったかかった。というか昼間は暑かった。

    ==

    単体テストといえばjavaのためのJUnitが有名だが、C言語でもCUnitCUnit for Mr.AndoEmbeddedUnitCCUnitなどいくつか世の中に出回っている。

    C言語におけるTDDの問題点と解決方法

    (1) スタブと実体の競合
    他の関数をテストするために作成したスタブと、関数の実体が競合を起こします。

    (中略)

    (2)スタブ同士の競合
    テスト対象の関数に応じたスタブを作成した場合にスタブ同士が競合を起こします。

    ここではスタブの競合という問題を、関数の別名宣言、関数ポインタの設定などの手順を使って回避しています。あるいはコンパイル環境を分ける、という解決法も示されています。

    これって、ボトムアップの単体・結合テストを繰り返すことでも回避できるんじゃないかと思ってるんだけど、どうなんだろう。最下部のコンポーネント(C言語であれば、システムコール標準関数にあたるか)については単体テスト実施済みというスタンスをとれば、ボトムアップの結合テストを繰り返していけば、すべてのコンポーネント(C言語であれば、ユーザ関数)の単体テストとみなせるのでは?という考え方。

    実際に僕がやっている単体テストってこのやり方なのだ。正確には単体テストの進捗具合によって単体(コンポーネント)の単位が大きくなっていくので、見方によっては結合テストともとれるか。

    詳細についてはいずれまた。今日はこれくらいで。


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

    プロ野球キャンプとテスト工程

    3連休最終日はのんびり過ごした。

    ==

    2月にはいるとプロ野球12球団のキャンプがはじまり、スポーツニュースでもその話題が多くなる。ふと、ニュースで「今日から野手と連携プレーの練習」というフレーズが聞こえてきた。ウォーターフォール型システム開発のテスト工程とプロ野球のオフシーズンって似てるかも。自主トレや個人練習が単体テストに似てるし、それから連係プレーの練習という結合テスト、実践練習・紅白戦・オープン戦なんかが統合テストやシステムテスト

    ただ、システム開発と違うのは、テスト工程がうまくいったからといって、秋に美酒を味わえるとは限らないことだな。

    ==

    そういえば3/18から首都圏ではJR東日本のsuicaカードが私鉄・バスでの利用が可能になる。このテストってどんな感じなのだろう。ガス・水道・電気なんかと一緒で規模も品質もこれだけ大きくなると~っ、すごいな。大変だろうし、やりがいもあるだろうし。

  • 期間・工数はどのくらいなのか?

  • テスト用環境・擬似システムはどのくらいの規模?

  • 品質基準の決定方法は?

  • どういうテストを実施して、どういうテストを実施しないのか?
  • などなど。やりがい、とかいっちゃったけど、大変さのほうが大きいね。

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

    JSTQBテスト技術者認定資格

    この記事がちょうど100件目。ご意見・ご指摘・ご感想などなど、レスポンスがあると意外に続けられるみたい。

    ==

    僕は主に仕事はWebやメールサーバ関連のシステム開発をやっているが、来月の第2回JSTQBテスト技術者認定試験は、ソフトウェア全般のテスト技術に関する認定試験。

    業界によってはシステムトラブルという報道・ニュースが頻繁なところもある。僕らの住処であるWeb関連サービスは比較的システムトラブルが多い業界かも。サーバ負荷問題、セキュリティホールからユーザビリティ・アクセシビリティなど、自動車業界・医療・社会インフラなどと比較してもまだまだ技術ノウハウ・プロセスなど成長過程な気がする。

    この認定試験は「テスト」という視点でシステム開発プロセスを改善するための、一種の基礎知識を習得するためのスコア試験と僕は思っている。この試験を合格することが直接的に自分の携わるシステムの品質を向上させるわけではない。ここで学んだ知識や技術を実際に活用し、経験し、振り返り、可能であれば改良する。ちょっと、ソフトウェアテストについて勉強してみようかな?といった腕試し感覚でもいいね。

    私見だけど、ソフトウェアテストの勉強ではあるが同時にプロセス改善・経営やプロジェクトマネジメント(PMBOK)の勉強にも通じるものがあると信じてます。

    教科書的な使い方ができるこの本。がっちり勉強したいって方は「買い」ですね。著者の大西さんは先月末のJaSSTの中の人。2/7今日発売だ。

    あるいはベーシックな知識を、という方にはJSTQBテスト技術者資格シラバスも。

    さあ、腕試し模擬試験もやってみようぜ。

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

    [JaSST '07]第2日目 賢人パネラー

    Amazonでソフトウェア・テストPRESSを購入予約したが、まだ届かない。JaSSTの会場で買ったほうがよかったなあ。

    ==

    JaSST'07の第2日目はパネルディスカッションやテスティングライブなど、論文発表以外にもイベント系のセッションが多かった。

    ソフトウェアテストの展望:SW機能テストから、システム挙動の評価へ

    ソフトウェアの品質を効率的・効果的に向上させるために、今まではどういうアプローチをしていたかなど。上流工程アプローチは「下流工程に潜在する欠陥の数を減らす」ということに関しては貢献したが、それは直接的に下流工程(特にテスト工程・手直し工程)の効率化につながったとはいえない。上流工程アプローチではテスト対象を絞り込む(テスト空間を小さくする)取り組みをすることで、直接的なコスト削減につながる。

    講演中に登場した「禁則」「無則」「有則」といった考え方。テスト空間を小さくする、というのは、「無則」部分を小さくすることになる?


    "Taming a Monster" - 品質をいかにコントロールするか

    松尾谷氏、山浦氏、ヨードン氏が、それぞれ、品質コントロールにおける3つのプラクティスを提案。チーム成熟の説明ででてきたタックマンモデルはもう少し調べてみたい。

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

    « 2007年1月 | トップページ | 2007年3月 »