« 電子雑誌を開発者が書くと言うアイデア | メイン | TJS2をVC2012でビルドしてみる »

2013年01月25日

Misc.:: 影響範囲とテスト

    

B. 直った。これでコミットしてしまう。
A. 待って、影響範囲のテストしないで該当個所の確認だけなのは、デグレとか心配。
B. レアケースなのでとりあえず様子見?
A. 普通に影響範囲のテストすればいいだけでは。
B. 影響的には、○○と言う処理がなくなるだけなので悪影響はないです。たぶん。
A. そのパスを通る処理をテストして、悪影響が出ていないことを確認するのがテスト。
B. 一応そのパスを通る処理で、いままでが異常だったのが直ったのが現状。

と言うように、全く話が通じないと感じる状況があったので書く。
コミットはリリースされるリポジトリに入れると言う話。
リリース済みのソフトウェアの不具合修正の話で、回帰テストの話なわけだけど、それが何か理解されていないのかな。

普通は影響範囲を調査して、その範囲のテストのやり直しと、必要であれば追加テストケースを書いてテストするはずで、修正されたことを確認だけで終了というのはしないと思っていたけど、そうではないようだ。
ゲームでリリース前の開発途中の場合は、単なる動作確認でどんどん進めてしまって、最後にランダムテストでできるだけつぶす形で開発を進めるのはあるけど、リリース後もそれと同じのりでやってしまうのは気になる。

どこか修正した場合、その影響はどこに及ぶかわからないから全部テストし直すべきだという意見もあるが、工数的な理由から影響範囲を調査して、その範囲をテストし直すと言うことがよくとられる(テストが自動化されている場合、全部テストしても工数はほとんどかからないので積極的に自動化すべきと言う意見も)。
では、影響範囲とはどの範囲か?
・修正対象関数を呼び出している関数を調べて、それらの関数が外部から操作可能な操作。
・クラスメンバ変数等の状態を変更している場合は、その変数にアクセスしている関数とその関数を呼び出している関数を調べて、それらの関数が外部から操作可能な操作。
基本的には、これが影響範囲だと考えられる。
言うまでもなく、テストは入力変数を考慮してテストケースを作る必要がある。
関数の呼び出し範囲は、関数呼び出しグラフを生成してくれるドキュメント自動生成ツールなどがあるので、それを使うと少し楽。
該当個所に及ぶ効果が重複する場合などで、テストケースを削ることもある。
もちろん手作業ではなく、テストプログラムを書いて自動テストすることもある。
該当不具合を検出できるテストケース等も当然追加する。
また、類似バグと言うのは良くあるので、似たような構造を持った箇所や動作のテストケースも追加してテストすると芋づる式に不具合が見つかることが良くあるため、そのようなテストも行うと効果的。

最初のやりとりを見るとテスト仕様書を作ることもうまく通じていない気もするけど、影響範囲のテストはこんな感じだろうか。

知識ゼロから学ぶ ソフトウェアテスト この辺り分かりやすいので、読んでおいた方がいいと思う。



投稿者 Takenori : 2013年01月25日 15:22




comments powered by Disqus
Total : Today : Yesterday : なかのひと