画期的なバグ票分析→だいたい探索型テスト支援システムをちゃちゃっと書いてみた。 - I like Ruby too.
私は最近のバグの傾向、キーワードを組み合わせて連想したネタでバグを見つけることが多いです。見つけないことも多いけど。 これを機械にやらせたらおもしろそう。 https://github.com/seki/Drip/blob/master/sample/tw_markov.rb オフレコなんだけど、githubのDripのsample/に、自分のツイートのログからマルコフ連鎖つかって自分っぽいツイートを生成するスクリプトがあるじゃん？この自分のツイート風文章作成の辞書をバグ票から作ればそのシステムに出てきそうなバグが作れるはず。 んで、やってみた。（あまりに短いのでスクリプトは載せません） うちのRWikiに入ってる数万のストーリーから直近の数千のバグっぽいチケットを集めてきて辞書を作って、バグ報告風文章を作成するシステムを書いてみたですよ。確かにそれらしいバグ報告が生成されます。次はそのバ
続・テストコードのリファクタリング - 千里霧中
「テストコードのリファクタリング - 千里霧中」の続きです。 十分に実施できる方法 テストコードを対象としたリファクタリングの回帰テストについてですが、現実性があり、十分に実施できる方法は主に次の２つとなると思います。 テストコードのインプットとなるテストケース仕様にもとづいて、ミューテーション分析を実施。ミューテーションテストと正常系のテストを実施することで、バグがなければパスし、バグがあれば失敗することを確認する。 テストコードに対する入出力・間接入力（テストフィクスチャからの入力など）・間接出力（Assertionメソッドへの出力等）を、Test Doubleやロギングで網羅的に記録。変更前と変更後で、入出力、間接入力・間接出力が変化しないことを確認する。 ただ現実性があるといっても問題もあります。ミューテーション分析については、テストケース仕様からミューテーションテストの仕様を作成
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
