« 差分表示をデバッガやエディタに | メイン | WMV のキーフレーム埋め込み »
2007年07月19日
思う事/思い付いた事:: テスト
Tweet @jin1016をフォロー単体・結合試験をしないとどうも不安な今日この頃。
単体試験、結合試験・・・と進めれば品質が高くなるのは間違いない。
コーディングすればミスをするし、考慮が漏れていることも多い。
試験はその実施のみではなく、試験仕様書の作成自体にも不具合発見の効果がある。
試験仕様書を作成する時、仕様書やソースコードなどを見直し取りうる入力、パスを通すための入力、様々な状態などを列挙していく。
この段階で、この状態でこの入力がきたらバグる、そもそもこの入力に対する考慮が漏れているなどが発見される。
考慮漏れと言うものは、ある程度系統立てて検証しないと発見しづらい。
これはソースコード上のバグのみでなく、様々な成果物に対して言える。
最終段階において元となる要件が漏れていれば、かなりの手戻りが発生することがあるのは周知の通りだ。
少し脱線した。その辺りのことは別の機会に書くとしてテストだ。
ある程度の規模を持ったソフトウェアでは、すべてをテストすることは現実的ではない。
よってそこには時間 ( コスト ) による制限が加わる。
当然、その制限内に終わるように計画を立てなければならない。
単体試験では、全パスを通さなければならない。
それは本当なのだろうか？
実際に結合された段階では通りえないパスが存在する。
使われないものをテストする必要はあるのか？
それはないだろう。
しかし、規模が大きくなればなるほど通らないパスを見つけることは困難になる。
また、今回は通らなかったが、将来加えた変更によって通るようになることもある。
そして発見させるのが潜在バグだ。
ゲーム開発において系統立ててテストが行われることは、経験上や見聞きした範囲ではない。
ゲーム開発でのテストは2種類。
動作確認とシステム全体に対するテスト。
単体や結合なんてすっ飛ばして、いきなりシステムテスト ( 総合テスト ) 。
しかも、そのシステムテストはランダムテストだったりする。
これはある意味合理的とも言える。
システムテストでは、通らないパスをテストすることはない。
しかし、システムテストで見付かった不具合を直したら通らなかったパスを通るようになり不具合が顕在化することはよくある。
潜在バグだ。
では、これをどうやって回避するのか？
回帰テストによって回避する。
不具合修正の影響範囲を調べて、その影響範囲を元に試験書を作成。実施するなどと言うまどろっこしいことはしない。
不具合修正したら、動作確認して次のシステムテストのテストサイクルで何とかする。
同じテストを何度も繰り返して不具合が収束するのを待つ。
それがいつ終わるのかはわからないが、その内収束する。
だから大丈夫。(？)
力業ではあるが、合理的とも言える。
システムテストで基本的なことがすべてカバーできているのであれば、最終製品のクオリティーもある程度保障される。
だが少し心もとない。
もう少し改善できないのだろうか？
つづく・・・
投稿者 Takenori : 2007年07月19日 15:36
comments powered by Disqus