netail.net

_ [hyCalendar] 今後の改造プラン ▲

メールで質問を受けて気づいたのですが，今まで「隔週予定」はあっても「５日ごとの予定」とかは書けなかったんですね．30日ごとにチャージしなおす必要があるプリペイドSIMを買ってみたところなので，ちょっと対応してみようかと思います．

ただし，現在は単体テストの導入に向けてかなり大規模な改修を加えている真っ最中です．本業の都合も強く影響しているので，次のリリースはまだ少し（かなり？）先になる予定です．

_ [論文] 良いテスト集合の選択基準の提案 ▲

Benoit Baudry and Franck Fleurey, Yves Le Traon: Improving Test Suites for Efficient Fault Localization.

Proceedings of ICSE 2006, pp.82-91, Shanghai, China, May 2006.

各ステートメントに対して「成功／失敗したテストケースの数」をカウント・比較することで「疑わしさ」を計算し，調査すべき対象のステートメントを推薦することができる．しかし，下手にテストを用意すると，ほとんどの文が同じ「疑わしさ」を持ってしまって役に立たないため，疑わしい文とそうでない文をうまく区別できるような良いテスト集合を作ろう，という論文．

論文では，テストケースの最適化の基準の提案と，それを用いることで「バグを発見するまでに調べなければならなかったステートメントの数」がどのくらい小さくなったかを実験している．

この論文では，テストケースの良さの基準を「Dynamic Basic Block（DBB）」と名づけている．DBBは，あるテスト集合に対して，まったく同じテストケースによってカバーされるような文の集合のことを指す．

たとえば，文 p, q, r, s に対してテスト３つのカバレッジが t1 = (p, q, r, s)，t2 = (p, q, r) ，t3 = (r, s) だったとすると，(t1, t2) によってカバーされる (p, q)，(t1, t2, t3) によってカバーされる(r), (t1, t3) によってカバーされる(s) という３つの Dynamic Basic Block が得られる．(p, q) の片方だけを実行するようなテストケースが作れなければ，これらは区分できないので，同じブロックに属し，「疑わしさ」度合いが常に同じ値になる．

Dynamic Basic Block の数が大きい（１つの集合が少数の文しか含まない）テスト集合というのは，テストごとに違う文の集合を実行することになるので，各文ごとのテストの成功・失敗数をカウントする方法による調査が容易なテスト集合であると考えられる．

この論文では，テストケースを遺伝的アルゴリズムで選ぶ・生成する方法によってテスト集合を洗練する実験を行っている．その評価基準として Dynamic Basic Block を使っており，従来手法より，調べるべきステートメント数を減らせるような少数のテストケースを選択することに成功している．

「良いテスト集合」を得るまでは，カバレッジ計算のためにひたすらテスト実行する必要はあるのが個人的には気になるけれど……，そこは人間の仕事ではないからOKという立場でもいいのかもしれない．