自動化ツール適用時の試験
コーディングの自動化ツールを適用した開発では、「設計通りのソースコード」が自動生成されるため、「設計通り動くか」をテストする必要はありません。しかし、設計情報自体に誤りが存在する場合があるため、「設計自体の正しさを動かして確認する」ことが自動化ツール適用時のテストの役割となります。これは裏を返せば、レビューで設計自体の正しさを動作の観点も含めて充分に確認できれば、テストをしなくても機能的な問題は無くせることを意味しています。NTTデータではこの観点に着目し、レビュー時に漏れのない確認ができるツールの開発に着手しています。
図1:自動化の場合のテスト(結合試験)
レビューの分析、問題、解決方法
一般的な開発における設計レビューでは以下の作業を実施しています。
- (1)レビュアーの頭の中で必要なデータバリエーションを用意する。
- (2)データが入力された時にどのように動作するかを頭の中でシミュレーションする。
- (3)シミュレーション結果が頭の中の期待する結果と同じかを確認する。
この時、処理の複雑さがレビュアーの頭の許容限界を超えた場合、(1)で十分なデータバリエーションを用意できなかったり、(2)で動作結果をシミュレーションしきれず、レビュー漏れによる設計誤りが発生すると考えられます。そのため、上記(1)や(2)を人の代わりに自動的に実施するシミュレーションツールがあればこの許容限界を超えてしまう問題は解決できると考えます。具体的には、設計情報からデータバリエーションを自動生成し、それらがどのようなアウトプットを出力するかを(設計情報から自動生成した)ソースコードを実行して明らかにし、入力データとそれに対するアウトプットをレポートとして出力すれば、ユーザーは(1)、(2)の問題から解放されると考えます。
なお、このレポートは期待値などを持ちません。現在設計されている内容だとどのようなアウトプットを出力するかを表しているだけなので、レポートを見てレビュアーが自分の頭の中の期待する結果と同じかを確認する必要があります(すなわち(3)を実行する必要があります)。
図2:シミュレーターで実施しようとしていること
シミュレーター技術の現状と課題
現状はNTTデータの自動生成ツールである「TERASOLUNA ViSC」の設計情報を入力として研究開発しており、代表的な課題は以下のような課題が挙げられます。
- 1.レビュアーが確認しやすいように無駄のないバリエーションである必要がある
- 2.設計内容を確認するためには境界値などのバリエーションを出力する必要がある
- 3.非線形な数式や項目属性変換、DB、ループなどを考慮できる必要がある
- 4.品質を確保するためにどの程度のバリエーションを生成するべきか明らかでない
- 5.現実的な時間でレポートを生成する必要がある
最終的に人の判断が入るためそこも考慮に入れると、レビュアーがいかに確認しやすいかなどの面でも研究開発すべきであり、やるべきことが尽きない状況です。
参考文献
- ソフトウエア・レビュー技術~基礎から実践までのノウハウ~
織田 巌,ソフト・リサーチ・センター
- DART:directed automated random testing
P Godefroid, N Klarlund, K Sen - ACM Sigplan Notices, 2005
- 設計モデルを利用したテスト用データベース自動生成手法
丹野 治門, 張 暁晶, 星野 - 情報処理学会論文誌, 2012