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

自分のモチベーションがどんどん下がっていくのがわかる -回帰テスト-

忙しくてブログネタが見つからないのと、モチベーションが下がり気味なので更新が停滞中。。。まあ、波の激しい僕にしては3ヶ月以上モチベーションを上げ続けられたので、進歩かな。

==

今やってる作業は回帰テストツールのメンテナンス。個人的には回帰テストの自動化はアリだと思っているのだが、「知識ゼロから学ぶ ソフトウェアテスト」(翔泳社)のブログでは、基本的に自動化に向かないとの評価。

回帰テスト2 by 知識ゼロから学ぶ ソフトウェアテスト

基本的に回帰テストは自動化に向かない - 回帰テスト設計というエリアがない。テスト設計なしに自動化するというのは、混乱を招く。パフォーマンステストと機能テストとユーザビリティテストをなんら戦略もなくただバグだからといって回帰テストとして自動化するととんでもないことになる。

(中略)

- 多くの直し壊しバグは、以前出た部分ではなく、そのちょっと横とか、似たファンクションで起こりがちである。なので回帰テストの自動化に大きなコストをかけたとしてもコストメリットは出ない。だいたい重要バグなんて数百件
なんてケースがほとんどなんだから(そのうちほとんどがsmoke testでわかるもの)、それを手で回帰テストやっても一日でおわっちゃうでしょ。それなのに、高いツール買ってきて、その高いツールの使い方覚えて、テストケースを書くの時間の無駄である。Cem Kanerだって、意味ないって言ってるし〜。修論に回帰テストの自動化について書いたら怒られたし〜。

この文章を読んでみて思ったのは、自分が使っているツールでは回帰テストというよりもスモークテストのほうがしっくりくるのかな。ちなみにこのツールはメールをSMTPで送信してPOPやIMAP4でチェックするという基本的な機能テストに特化したツール。手動で実施していたのだが、Received行のチェックであったり、タイミングによっては若干の遅延が発生したりするので、何度かテストを実施する日羽陽があるため、ツール化した経緯がある。

「デグレードを防止する」という目的のテストって「回帰テスト」なんだろうか?「スモークテスト」なんだろうか?基本的なことかもしれないが、自分の頭の中ではイマイチ明確化されてないかも。

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

風邪で寝込んだり

ノロウイルスではなかったらしいが、風邪で寝込んでたので更新なしでした。仕事ミスったり婚約したりで今年の師走は超特急だ。。。

==

最近のマイブームは graphviz 。なんかいろいろできそう。ソフトウェアテストという観点でも何かできないかな。

Ajaxでgraphviz
http://ashitani.jp/gv/

今日はコレだけ。

==
2006/12/20 加筆。
ソフトウェアテストにgraphvizが使えるというのは間違いかも。ソフトウェア品質向上に使える、が正しいか。会社で一緒にシステム開発している方は、doxygenと合わせてソースのドキュメント化をしてた。

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

バグの巣を探る - 「AgitarOne」for Java自動テスト生成

今日は社外の勉強会にはいけませんでした。残念!

==

自動テスト生成によって、既存コードの質を上げる--アジター社CEO語る by ITPro

これまでも、開発者はユニット単位で動作を検証するのが普通だった。しかしそれは、コードが「何をすべきか」ということについての検証しかしないことが多い。つまり、想定外のコードや例外となるケースのテストを記述するのは難しい。

(中略)

その通りだ。旧版に搭載していた「アジテーション」という、おかしな振る舞いをするケースを見つける機能を応用して、いろいろな入力データに対する出力結果のフローを見て、どのように振る舞うかを解析する。その結果からテスト・ケースとすべき状態を抜き出して、テスト・コードを自動生成する。

自動的にバグのありそうな条件を見つけ出すって、どうやってるんだろう?truss/strace/ltraceをして出現したシステムコールについて自動分析して怪しい条件を作成してるのかな?



--ほかのプログラミング言語へ対応することは考えているのか。

いや。全く考えていない。CやC++、Visual Basicはミッション・クリティカルな言語ではない。C#は可能性があるが、製品で対応しなければならないほどの市場ではない。

C言語も作ってください~~メールサーバとかけっこうミッション・クリティカルなものもありますよん。

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

考慮漏れのディメンジョン

今日は自分のプロジェクトでのトラブル対応に終始。「何故」を5回以上繰り返して、根本原因を突き止めろ。

==

このトラブルを見つけたときの第一声は、「あ、その場合か!」でした。つまり、考慮にすらされてなかった条件で欠陥が見つかったというケースになるかと思います。ただ、「考慮漏れ」というくくりではまだ浅い。以下、
思ったことをつらつらと・・・。落ちがない状態で終わる可能性大。



  • 考慮漏れ、をフェーズによる切り口で見てみる
  • 仕様考慮漏れ、システム/モジュール設計考慮漏れ、設計カバレッジ考慮漏れ、リスク分析考慮漏れ、あたりか。要求仕様にない機能は設計、実装、テスト設計ではほとんど見つけ出すことができない致命的な考慮漏れ。でも、設計考慮漏れであれば、テスト設計において仕様書をベースにすることで漏れに気づくことが可能かもしれない。リスク分析で考慮されなかったリスクについても、それ以降の工程で見つけるのは難しくなりそうだ。


  • 考慮漏れ、をディメンジョン(次元)という切り口で見てみる
    • ディメンジョンとは、考慮漏れのレベル、と位置づけてみる。実験計画法の用語を使ってみる。

    • 提供機能考慮漏れ

    • 高レベルの考慮漏れであるが、システムテスト・ユーザー受け入れテストで比較的見つけやすいか。ここまで大胆な考慮漏れは途中で気づくもの。

    • 因子考慮漏れ

    • レベル高い。直交表で言うと1列なくなる。影響かなりあるし、意外に気づきにくいか。気づくための手法としてはマインドマップなどのブレーンストーミング、信頼できる仕様書の作成か。

    • 水準考慮漏れ

    • レベル中度。直交表で言うとテストケース数が小さくなるか、あるいは考慮された水準についてはより厚く検証ができる、多因子間網羅率が高くなる。どの水準を考慮しなかったかによって、怪我の功名になる場合もあり?

    • 組み合せ考慮漏れ

    • レベル低い。直交表で言うと1行なくなる。1行なくなる=網羅ケースが1つということではなく、複数の因子組において網羅率が低下する。ただし、4つの中で一番「レアケース」に近いか。



中途半端だけど、今日はこのくらいで。

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

単体テスト~結合テスト

単体テストをするとき、「スタブ」と「ドライバ」が必要になってくる。

Photo

スタブとは、テストのために用意されるテスト対象が呼び出す予定のメソッドや関数、サブルーチンのこと。ドライバは、テストのために用意されるテスト対象を読み出すメソッドや関数、サブルーチン。ひとつのテスト対象にはひとつずつスタブとドライバが必要になってくる。ただし、一般的には単体テストをトップダウンあるいはボトムアップで行うことが多いため、スタブとドライバの片方はすでにテスト実施済みのメソッドや関数、サブルーチンがあてられる。

そこでだ。世の中で結合テストといわれているのはどこを指すのか。

Photo_1

あくまで僕の認識だが、上図でいうと呼び出しa、呼び出しb、呼び出しcを「単体テストの通し」と考えている。この最上位の単体テストにたどり着くとそれはほとんどモジュールAの機能テスト=結合テストの一部とみなせるんじゃないか。

なんでこんなことを書いているかというと、結合テストって単体テストやシステムテスト、非機能テストに比べて定義があいまいな気がしたので。誰かこれっていう定義を知ってたら教えてください。

ちなみに、Softeware Testing のコラムでは、

結合テストは、モジュール間のインターフェースや組み合わせを対象としたテストです。C言語などではモジュールの呼び出しや戻り、Javaなどではメッセージのやり取りになります。モジュール間のインターフェースに食い違いがあるバグや、(単一のモジュールでバグが見つからないのに)複数のモジュールを組み合わせた時にだけ見つかるバグを検出します。

となってます。

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

ソフトウェアテストPRESS vol.1 - テスト駆動開発と単体テストのカンケイ

本棚にある雑誌を読み直してて見つけた。

テスト駆動開発と単体テストのカンケイ by ソフトウェアテストPRESS vol1 (p111)

さて、ここでTDDで作られるテストコードは、今までコーディング後に単体テストとして実施していたものを、先に書いただけと見ることも可能です。ということは、コーディングが終われば単体テストが終わったことになるのでしょうか?

これは、半分正しいですが半分間違っています。

(中略)

実際のところ、TDDのテストファーストなテストで4〜5の観点のテストコードが漏れなく書かれていることは通常ないでしょう。なぜなら、テストコードを書くための工数が増えすぎて作業のスピード感が一気に落ちてしまい、本来のTDDの良さがなくなってしまうためです。

引用中の4とは「境界値パターン」、5とは「ゼロ、NULLなどパターン」です。すなわち境界値分析とエラー推測的な観点でのテストケースといえます。そういったテストケースはTDDの場合、スピード感を損なうために通常はテストコードとして実装されず、単体テストとして別枠で工数をとって実施しましょう、という趣旨。

これについは僕は少し考えが違ってます。というか僕はこの4と5のパターンのテストコードも実装します。指摘されている通り、スピード感が落ちてしまってTDDの良さが消えてしまいそうですが、それでも回帰的/スモーク的なテストができるというメリットはやはり捨てがたい。目的はTDDをすることではなくて、一定の品質を保つ製品をなるべく短期間・低コストで作成することだと思うので、「TDDの良さがなくなってしまうため」に4や5を組み込まないということはしない。

ただ、前半部分のコーディング終了=単体テスト終了、っていうは間違ってない気がしてきた。何らかの指標があってそれを評価してはじめて単体テストが終了する、といったイメージかな。(テストカバレッジとか)

# あくまで私見です。そんなにTDDの専門家といえるほどの知識も経験もないので。
# ちゃんと勉強するためには、こんな本読まなきゃいけないのか。。。汗

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

タグチメソッドを勉強するにも本を持ってなかった

JQAのプロセスとテスト駆動型開発(TDDあるいはBDD)の手続きって似てると思った。どちらも理想の姿を思い描いて少しずつギャップを埋めていくところが。

==

タグチメソッドやSN比を勉強しようと本棚を漁ってみたが、よく考えてみるとそういった本は持っていなかった。持っていたのは「よくわかる実験計画法」という本だけで、タグチメソッドはいいや〜って買っていなかったらしい。インターネットではココが一番詳しいかな?

タグチメソッドを勉強する最初の第一歩は、どんな本がおすすめですかねぇ?

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

[セミナー]JaSST'07 Tokyo

今日は経営品質協議会主催のセミナーに参加。いろんな気づきがありました。「正しい決断をしたか」ではなく「正しく決断したか」が重要。

==

JaSST'07の参加申込みが始まっています。

http://www.jasst.jp/attribute/jasst07e.html

1月30日だけ出席しようかと思ったけど、プログラムを見たら、直交表についてのセッションが1月31日にあるみたい。

http://www.jasst.jp/attribute/session.html#b4-3



■B4-3 パソコンによる直交表の自動構成とソフトウェアテストへの応用

須田 健二(群馬工業高等専門学校)

 我々は、水準数と因子数、強さを入力するだけでテスト回数最小という意味で最適な直交表を自動構成できるソフト
 Galoisを開発した。 このGaloisはすでにある直交表を選択して使うのではなく、ソフトウェアテストで必要な多因子、
 多水準、強さ2・3・4のそれぞれに対して必要な直交表を全く新しく生成してくれるソフトである。 本発表では
 Galoisが、少ないテスト回数で高品質なソフトウェアテストに応用が可能であることを示す。

水準数、因子数だけでなく強さ(強度)まで指定できるとは。名前の由来は数学者のガロアのようですね。

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

テスト駆動型開発(TDD)とグレーボックステスト

最近、テスト駆動型開発(TDDあるいはBDD)についての雑誌を買ったり他のブログに感化されたりしたので軽い考察を。

==

実装とテストを繰り返しながら設計をすすめる、といった形でコーディングするとき、みなさんはどんな手順ですすめますか?僕はこんな感じでやってます。(僕はC言語をベースに開発することが多いので、C言語をサンプルに)

  1. 骨組みだけの関数を作成する


  2. /**
     * func1(); ○△×をする関数
     * 引数
     * 復帰値
     * 0 正常
     * -1 エラー
     */
    int
    func1(
      const char* str1,
      char* ptr2,
      int num3 )
    {
      return(-1);
    }

    モジュール設計に基づいた関数の骨組みだけを記述する。ただし、復帰値がvoid以外ならばエラー復帰をまず記述しておく。


  3. テストスイートを作成する


  4. - 引数チェック
    - 正常系ケース
    - 限界値ケース
    - エラーケース
    - 異常系ケース

    テストスイートは複数のテストケースの集まりをあらわし、「引数チェック」「正常系ケース」「限界値ケース」「エラーケース」「異常系ケース」といったテストケースを作成する。引数チェックは、関数の引数にNULL、0、負の数、ヌル文字のポインタ(””)などを指定した場合に正しく引数エラーを返すかどうかを確認する。正常系ケースでは、尤もらしい動作をするであろう条件を指定する。最低でもひとつ、そしてコーディング後に追加するのもあり。限界値ケースは、条件の境界値(最大値、最小値)において正常な動作をすることを確認する。これは正常系ケースと兼ねてもいい。エラーケースは、尤もらしいエラーが発生する条件を指定し、エラーが発生することを確認するテストケース。異常系ケースは、今までの4群以外で、例えば非常に大きなデータや、言語上の限界値などを指定する。

    これらのテストケースをまとめる際、仕様書の欠陥などを同時にレビューするのもよい。


  5. テストを実行する
  6. 骨組みだけの関数をコンパイルし、テストスイートにある条件&評価でテストする。僕の場合はMinUnitというマクロをベースにテストコードを自動生成して、「-fprofile-arcs -ftest-coverage」をオプションにしてコンパイル&実行する。

    ちなみに、ほとんどテストケースは失敗に終わり、いわゆる「レッド」の状態。



    /* 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;

    -fprofile-arcs -ftest-coverage」をオプションにするのはあとでgcovでカバレッジ測定をするため。


  7. テストケースをクリアするように実装をすすめる
  8. 対象となる関数を実装していき、テストケースが「グリーン」にしていく。このとき、実装とともに必要と思われるテストケースを追加していくのもあり。


  9. テストスイートがクリアすることと、カバレッジ率を80%以上に保つ
  10. テストケースをすべてクリアすることと同時に、ステートメントカバレッジにも着目すること。僕の場合は、目安は80%~95%を目標にする。


本当は「リファクタリング」も必要なのだが、とりあえずこんな感じで試しているところ。

==

さて、こういったテストファーストで実装していくこと得られるメリットは、というと、、、

  1. ユニットテストケースがグレーボックスっぽい
  2. 境界値や異常系を考慮するので、グレーボックス的なアプローチができる。

  3. 引数チェックでブラックボックスっぽい
  4. 引数チェックは境界値やエラー推測といったブラックボックス的なアプローチができる。

  5. 仕様書の見える化、掘り起こしができる
  6. テストケースを作成するプロセスは、仕様を浮き彫りにする作業となる。

ただし、いいことずくめではないと思っていて、引数が多くなったり、複雑な処理になるにしたがって、テストケースは膨れ上がる。テストをグリーンにするために実施カバレッジは少なくとも100%にする必要もある。だから、どこかで手を打たなくちゃならない。その基準は、まだよくわからない。


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

[雑誌]日経SYSTEMS 2006年12月号 「特集2 勝ちにいく!ソフトウエア・テスト」

ソフトウェア関連の特集があったので。

==

Nikkei_systems_200612

日経SYSTEMS 2006年12月号

ソフトウェアテストで「敗北」するときのポイントである「有効打の不足」 「時間切れ」についての記事が載っている。各工程でのすすめ方とか、各技法についての詳細な記事ではないが、どの工程でどんなテストをしたらいいか、どんなテストの記述方法があるのか、などの概論がまとめられている。

直交表についても少し載っていたが、「単体テストで実施済み」というのは「単機能テストで実施済み」と同義ってことかな。

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

タグチメソッド for ソフトウェアテスト ≠ HAYST法 と思ってます

久しぶりに直交表/HAYST法関連のブログ記事~。

==

以前ご紹介したブログで直交表やHAYST法についての考察が出された。

マイリストに「ソフトウェアテストにおける直交表(HAYST法、All-pair法)の利用」をアップ by つれづれなる技術屋日記



・ソフトウェアテスト開発技術者やソフトウェアテスト技術者にとって未知の世界
・タグチメソッド自体が賛否両論
・直交表自体の学習の難しさ
 ・実験計画法の記述のほとんどが、数式と表
 ・ベースとなる統計や代数・幾何

直交表とかタグチメソッドとかいう名前を会社の上司に話したとしても、知ってる程度で実際に直交表の書かれた紙や画面を見せると、苦笑い、といったことが多い。これは指摘の通り、未知の世界だということが大きいかも。今や大学在籍時の専攻が理学系だったとしても、なかなか数学って敬遠されがちな分野。行列とかベクトル空間とかあんまり記憶にないのが現実。だから、「直交(orthogonalかな?)」という概念もすぅ~っと頭に入りにくい。

僕はちなみに数学を主専攻にしていたので、大学時代ぶりの数式を見るとけっこう楽しい。ツボだね。それは同僚からすると意外に稀有な存在に映るらしい。



・タグチメソッド(品質工学)との間隙

(中略)

 ・SN比など重要な概念が、電気・機械・化学等の計測した数値の場合が多い
 ・体系が、電気・機械・化学等の事例をベースに確立されている

タグチメソッドについて浅学すぎて議論についていっていないかもしれないが、ここで僕の考えは少し違う。そもそもタグチメソッドを利用したソフトウェアテストという体系と、直交表を使ったソフトウェアテストという体系は別物だと考えてます。どういう理屈からかというと、、、

# 以下、浅学なため見当違いの意見を含むかもしれませんので、ご指摘を。。

  • タグチメソッドとはいかに分散を抑えるかが目的
  • タグチメソッドを説明するサイトで多く見られるのが、平均値が正確な技術と分散が小さい技術、どちらを優秀と評価するか、といった例が挙げられている。このメソッドによって、例えばどういった環境とどういったデータでソフトウェアは想定した動作をするかを評価はできる。あるいは、サーバのCPU性能、メモリ搭載量、ディスク性能といったパラメータがどのように処理性能に影響するかを評価するときに利用できる。

  • 直交表の性質から、効率的な組み合せパターンを作成できる
  • 直交表は任意の2列が直交という性質を持っていて、それをテスト条件の因子に当てはめると、効率的なテストケースのパターン作成に役立つ。例えば、ON/OFFの2種類の条件が7つあった場合、組み合せ数は2の7乗=128通りが想定できるが、任意の2条件についてすべて網羅できるという制約をつければたった8通りのテストケースで網羅できる。また、ソフトウェアによっては3条件以上の網羅を必要とする場合があるが、それも田口博士の工夫によって網羅率を高める方法が存在する。

    以上のように、ソフトウェアテストへの応用について言えば、タグチメソッドと直交表とは区別したほうがいいのではないか。と、私見ではあるが考える。



    少ない利用事例

    ・タグチメソッド自体、ソフトウェアでの利用事例発表が少ない
    ・HAYST法利用での発表も同様
    ・All-pair法利用での発表は皆無(特に日本。参考文献5は貴重)

    ほんっとに、少ない。ソフトウェアテスト全般に活用できるとは思っていないが、局所的にはすごく便利なツールなのでもっと文献や資料、事例がないと、なあ。タグチメソッド(というかSN比)の活用については、負荷分析に利用できる、といった示唆はあったが、それくらい。



    ・ソフトウェアテストのイメージ(困難な直交表経験者の流用)

    (中略)

     ・従来のタグチメソッド用ツールが使えない(HAYST法のツールはソフトウェア専用。たぶんAll-pairも)
     ・逆にソフトウェア直交表ツールを、ハードウェアのタグチメソッドに使えない

    お互いのツールがお互いを意識していないから、だろうか。



    ・ホワイトボックステストへの利用

    (中略)

    function funcA(a1, a2:integer)
     :
     :
    function funcA(b1, b2, b3:integer)
     :
     :
    function funcA(c1, c2:integer)
     :
     :

      funcA~funcCを因子へ
      a1~c2を水準へ

    なるほど。この考え方は僕にとっては新鮮でした。単体テストケースで直交表を利用するというのはやってみたいな。ただし、関数I/Fが変更された場合はおそらくゼロから単体テストケースを作り直す必要はありそうだ。


    ==

    いや~、PDF76ページの大作。読みごたえあり。すべてについて感想や意見を書く時間はなかったけれど、何かアクションしたかったので記事にしてみました。直交表って魔法に見えたり、難解なパズルに見えたり、いろんな顔を持ってるので、感じ方も千差万別かな。


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

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