mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

コンポーネントテスト、統合テストにも役立つSQuBOK

Advent Calender

18日目です。早いものですね。（書くの遅くてすみません。）

 

www.adventar.org

すみません、テストの話をします

予告ではコーディングと言っていたのですが、書いてみたらテストの話だったのでタイトル変えました。楽しみにしていた方すみません…

 

なお、この記事において想定しているのは一般的なVモデル、ウォーターフォールモデルでの開発です。あらかじめご了承ください。

 

ホワイトボックステスト、ちゃんとやれていますか？

ホワイトボックステストはテスト対象の内部構造に着目したテストで、コンポーネントテスト、統合テストレベルにおいて実施されることが多いのではと思います。ですが、これをしっかりやれているか？というと意外と難しいです。（自分はやれてませんでした…）

ホワイトボックステストについて、SQuBOK V2では以下の章で取り上げられています。（S-KA: コードに基づいた技法 というトピックにまとめられています）

ここでは、僕がやれていたテストとやれていなかったテストについてSQuBOKから簡単に紹介したいと思います。

 

制御フローテスト

制御フローテストは、プログラムの制御構造をフローグラフに表現して、そのグラフを網羅するようにテストを設計する技法です。命令網羅、分岐網羅といったカバレッジ基準について耳にしたことがある方も多いのではないでしょうか。カバレッジの計測ツールを使われている方もいることと思います。この制御フローテストの技法をシステムテストに応用したものが、トランザクションフローテストと呼ばれます。

 

データフローテスト

データフローテストは、プログラムの制御フローをもとに、プログラム中の変数のライフサイクルに着目してパスを選択し、テストを設計する技法です。変数のライフサイクルには定義、使用、消滅があります。

仕様追加などに伴いソースコードが巨大化していくにつれ、ソースコード中にデータ宣言文が増加していきます。 そうすると、データに関する障害が発生してしまう確率も高まっていきます。

 

意外とやってないこともあります（よね？）

コンポーネントテスト、統合テストにおいては「制御フローテストのカバレッジ基準を満たしているから、コンポーネントテストは大丈夫！」とはいえません。カバレッジ基準はあくまで目安であり、それを満たしているからといってテストが十分であるとは主張できないからです。特に、（僕もそうでしたが） 「制御フローテストはやっていたけど、データフローテストはきちんとやっていなかった」ということもあるのではないでしょうか。そういった方はぜひ一度、データフローをしっかり考えてテストしてみることをおすすめします。データフローテストをきちんとやっていれば防げただろうなというバグを自分も何度か経験しています…（初期化漏れ、型変換間違いとか）

 

これはもちろん、コードレビューにおいても重要な観点だと思います。しっかり意識することで、コードの品質も高めていきたいですね。