弊社の動的テストツールの採用を検討するお客様、また製品を導入されたお客様において、最も関心の高いテーマのひとつが、カバレッジです。「ゆくゆくはカバレッジを取得するプロセスにしたい」という声をいただく一方で、カバレッジを取得するプロセスを適切な方法で、継続して運用できているお客様は多くありません。ソフトウェア開発の品質の確保・向上のためには現状を変えなくてはいけないという認識はあっても、そのためのリソースや時間を確保できない、といった板挟みに遭う開発者・テスターの方がほとんどではないでしょうか。

そこで今回は限られた工数で品質を確保するためのカバレッジ取得の考え方、そして実際にカバレッジを取得するまでのフローを紹介したいと思います。

コード変更による影響範囲を把握して、テストを絞り込む

すべての機能やモジュールに対して、テストの実施やカバレッジを取得することが理想ですが、工数が限られている中では現実的な解ではありません。コード変更箇所に対して、テストするべき箇所をどう見極めるのかが重要です。そのひとつの解として「コード変更箇所とその影響範囲」を把握して、絞り込むというアプローチがあります。影響範囲とは、制御フローの中で変更した関数を呼び出している箇所が該当します。

1.「変更箇所」を取得する

多くの開発者はGitやSVNといった構成管理ツールを使用していると思います。構成管理ツールでは任意の2点間のコミットの変更箇所をテキストで抽出できます。例えばSVNの場合、変更箇所を取得するには「diff」というコマンドを使用します。

#「diff」コマンドのヘルプ
# 2点間のコミットと言えど、何をもって取得するかで引数が異なる。
svn diff -h
1. diff
2. diff [-c M | -r N[:M]] [TARGET[@REV]...]
3. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] [PATH...]
4. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]
5. diff OLD-URL[@OLDREV] NEW-PATH[@NEWREV]
6. diff OLD-PATH[@OLDREV] NEW-URL[@NEWREV]

このコマンドにより、指定したコミット間の変更箇所をユニファイド形式で取得できます。例えば、前回のリリース時からの変更箇所を取得する場合は、3番目のフォーマットで対象のリビジョンを指定します。

C:\Demo\SampleApp>svn diff -r 27:37 // 27-前回リリース時の最終コミット、37-比較したいコミット(今回のリリース相当のコミット)

また、以下のように比較対象を“”yyyy-MM-dd’T’HH:mm:ss.SSSZ””のように日時で指定して、その間の変更箇所を抽出することも可能です。

C:\Demo\SampleApp>svn diff -r "{2020-06-04 15:00:00}":"{2020-06-05 15:00:00}
ユニファイド形式とは?

以下のようなフォーマットのファイルをユニファイド形式と呼びます。冒頭の「—」が比較元、「+++」が比較対象のファイルを示します。コード部分の左端に存在する「-」がついている行が比較元に存在していて、比較対象では削除された箇所となります。逆に「+」が追加された箇所を表します。

C:\Jenkins_Demo\FFFTP>svn diff -r 27:37
Index: registry.c
===================================================================
--- taskwin.c   (revision 27)
+++ taskwin.c   (revision 37)
@@ -109,8 +109,6 @@
                DispLogSemaphore2 = CreateSemaphore(NULL, 1, 1, NULL);

        }
-       else{
-       }
        return(Sts);
 }
2.「影響範囲」を自動で取得する

上の節で「変更した関数を呼び出している箇所」を影響範囲として説明しましたが、変更箇所を手掛かりに、Grepで検索する方法を思い浮かべた方も多いのではないでしょうか。
手動で行うこの方法は手間と時間が掛かり、作業ミスによる抜け漏れの発生が懸念されますが、弊社が提供する影響範囲特定ツールKentaurosではこの作業の自動化ができます。

Kentaurosは上記で取得したユニファイド形式のテキストファイル(=変更箇所)を入力することで、変更した関数と影響範囲に該当する関数をセットにして、自動でファイル出力するツールです。影響範囲の導出には、構造解析ツールの情報も併用しています。

Kentaurosによって生成される情報(コード変更した関数とその影響範囲に該当する関数のリスト)をもとにすると、機能や操作といった外部の仕様の中で変更に関連する部分が判別できますので、関連する機能のテストケースから必要なものを抽出できます。Kentaurosを使うことで影響範囲も正しく解析できますので、外部の仕様の観点のみでは一見関連がないように思われるようなテストケースを見逃す、といったことも防げます。

3.DT10でカバレッジを確認する

Kentaurosから出力された影響範囲の情報をDT10に入力することで、コード変更した関数とその影響範囲となる関数にのみテストポイント(=printfデバッグで使用するprint文)を自動で挿入できます。これにより、的を絞ったカバレッジの取得環境が容易に構築できます。ターゲット機器を実機でテストしながら、DT10で実行経路を取得することで、関数・メソッドごとにC0・C1カバレッジを取得できます。

一般的なカバレッジ測定ツールでは、スタブやドライバなどテストコードを用意することが手間となりますが、実機を動作させながら、動的なカバレッジが取得できることが、DT10の大きな特長です。またDT10では、単にカバレッジを取得するだけでなく、効率的なカバレッジの運用をサポートする機能も備えています。そのひとつとして、複数人で別々のテストケースを実施した際にも、各人がテストして取得したカバレッジ結果を合算し、トータルのカバレッジ値の集計ができます。

DT10では、通過したテストポイントは青、通過していないテストポイントは赤と色分けされますので、テストされていないコードが一目で分かります(下図の左側)。また、関数ごとに未通過のテストポイントをリストアップする機能(下図の右側)もあり、リストをクリックすることで該当のコードにジャンプして、未通過コードを確認できます。前後の処理と照らし合わせて確認することで、「テストケースを追加するべきか」「フェールセーフなので通過しなくても問題ない」といった判断を迅速に行えます。カバレッジ結果のレビューにおいても活用できます。

まとめ

テスト範囲を絞り込むことで、優先してテストするべき箇所を明確にできますので、工数を抑えつつも効果的なテストが実施できます。またKentaurosを使用することでテストが必要な部分を見逃すことなく、かつ手間をかけることなく抽出できます。同時にカバレッジを取得することで、そういった部分に対してテストの抜け漏れが発生していないかを把握できます。

昨今の限られたリソースの中でいかに効率的にテストを行うか。テスト手法を見直すための考え方として取り入れてみてはいかがでしょうか。

ホワイトペーパーのご案内

影響範囲の特定手法について、ホワイトペーパーで詳細に解説しています。こちらも要チェック!
ダウンロードはこちらから

Kentauros/DTシリーズを無料でお試しいただけます!

今回ご紹介したKentauros、動的テストツールDTシリーズは無料トライアルも可能ですので、ご興味がある方はお気軽にお問い合わせください。
「動的テストツールDT+」の詳細はこちらから
「Kentauros」の詳細はこちらから