ソフトウェアテストの基本

ホワイトボックステスト

論理構造の正しさのみをテストする。
ソフトウェアの仕様が間違っていることから起こるバグは発見できない。

・ステートメントカバレッジ
コード内の命令文(ステートメント)を少なくとも1回は実行。

・ブランチカバレッジ
分岐コードに対して、それぞれの判定条件がTRUE、FALSEの結果を少なくとも1回ずつ持つようにテストケースを書く。

カバレッジテストで全てのバグを見つけるのは理論的に不可能である。不可能な例としては、

・ ほとんど起こり得ないようエラー処理でのバグ
・ 使われていないコードがもたらすバグ
・ プログラムのループに関するバグ
・ 要求仕様自体が間違っていたり、機能が備わっていないバグ(仕様バグ)
・ データに関するバグ(mutexなどを用い、データが適切に使われるよう処理しているか、データの扱い方が適切か、データが汚れていないか)

ブラックボックステスト

プログラムを一種のブラックボックスと見立て、様々な入力を行うことによって、ソースコードを見ずにテストを行う技法。

・ 同値分割法
・ 境界値分析法
・ ディシジョンテーブル
・ 状態遷移テスト
・ ランダムテスト(アドホックテスト、アドリブテスト、モンキーテスト)

探索的テスト

非機能要求のテストにはあまり向かない。ユーザビリティテスト以外はあまり良い結果が出ない。

・クライテリア(criteria:判定基準)を決める。
・ターゲットソフトウェア、テスト対象の機能・処理を決める。
・機能をリストアップする。
・弱いエリアを見つける。
→ データ変換が発生する
→ 何か共有するデータがある
→ 複雑に組み合わさったデータ入力をもとに判断する
→ ファイルをネットワーク越しにオープンさせる
→ エラーや例外処理時のハンドリング、リカバリ処理
→ リソースに影響を与える(メモリが少ない状態、サイズの大きいファイル)
・各機能のテスト及びバグの記録
→ 一つ一つのテストケースは書かない。テストの実行に当てる。
・継続的なテストの実行
→ 環境を変えての試験
→ バグ改修により、他の機能に影響が出ていないかの確認

強化試験と称し、探索的手法をやるケースが見られる。

非機能テスト

・パフォーマンステスト
パフォーマンステストで発見されるバグは最悪のバグ

・セキュリティテスト
悪意ある攻撃が引き起こす問題を見つけることは、ソフトウェアテストの範疇外

・静的解析ツール
→ HP Fortify
→ Coverity Prevent
無駄なエラーが出ることが多いため、取り除く作業が必要。砂金採りのようなもの。一粒の金を採るために数百粒の砂粒を取り除く必要がある。

これからの試験

テストすることとコードを書くことの区別がつきにくくなる。TDD(Test Driven Development)という手法。単体テストをやりながらコードを書く。

#システム #システム開発 #テスト #試験 #ホワイトボックステスト #ブラックボックステスト #探索的テスト #非機能テスト #TDD #ソフトウェア #ソフトウェアテスト