(001-005/100)プログラムのテスト
|
■(001) プログラムのテストはやっかいな問題です。 規模が小さかったときでさえ手に負えないくらい大変だったみたいなのに、 最近では、規模が大きくなっただけでなく、 開発期間がえらく短縮されている…。 これは何とか考えないといかんよね。 ■(002)フレームワークとして考えないと難しい テストは、それ自体が独立して実行できるものではないです。 テストを実行する目的は、仕様通りに動作することを確認すること。 だから、仕様を知らないとテストは実行できません。 もっと突き詰めて考えていくと、結局プロジェクトとして、 どんなソフトウェアデザインにするのかとかまで行ってしまいそうです。 テストの実行を改良するには、開発のフレームワークから考える必要があるようです。 それだから、テスト計画者だけじゃどうにもならないことも多いのかも。 そもそも、テストって開発当初はあまり考えられていないし…。 うまい方法ってないものかね。 ■(003)ビルドは自動化できてますか? テストを自動化するためには、ビルドが自動化されている必要があります。 でも実行環境が複数ある場合も多い。 単体テスト環境と、結合環境、本番環境とか…。 超えるべき壁は多そうです。 ■(004)単体テスト、結合テスト、システムテスト 一般的に行われているテストの種類には、 単体テスト、結合テスト、システム(総合)テストがあります。 結合とシステムはテスト方法としてはあまり変わりませんが、 単体テストは大きく異なります。 単体テストでは、基本的には関数単位の試験を行います。 結合とシステムテストでは、仕様にもとづく機能単位の試験を行います。 ■(005)単体テストですべての不具合が発見できる?
テストの実行を自動化するときは、 おそらく単体テストが対象になるのだと思います。 ある本には、結合以降で発生する不具合は、 単体テストで抜けてしまったために発生しているとありました。 単体テストですべての不具合が発見できるかどうかは、 僕にはわかりません。 理論的にはできそうな気もするし、無理そうな気もします。 |
