動的テストの自動化を考える#2

第2回目のテーマは、「Jenkinsによるテストポイントの自動挿入」です。DTシリーズでは、「時間計測」「カバレッジ計測」「CPU負荷やタスクの占有率」これら全てを「テストポイント」によって計測しています。DTシリーズと「テストポイント」は切っても切れない関係にあると言えます。言い換えれば、DTシリーズの機能を生かすも殺すも「テストポイント」の挿入の仕方次第ということになります。単純な例ではありますが、テストポイントの数が多ければ、欲しいデータが大量のデータに埋もれてしまって、何をテストした結果なのかわからなくなるケースもあります。逆に、テストポイントの数が少なければ、一部のテストの目的ははたせたとしてもそれで十分であったのか判断がつきません。DTシリーズ製品の特徴を十分に活かすためにも、テストの目的と内容と合った最適な「テストポイント挿入」が望まれています。

さて、このような「テストポイント」ですが、今回のテーマは「Jenkinsによるテストポイントの自動挿入」です。Jenkinsを使用することでテストポイント挿入のCI化は比較的容易に行えますが、「テストポイント挿入」をCI化するとき押さえておきたいポイントがあります。今回は、この押さえるべきポイントとあわせてどのような観点で「テストポイントの挿入」から「テスト結果のアウトプット」までをシナリオ設計すればよいか、ご紹介したいと思います。

動的テストのためのCI環境とは

動的テストツールをCI(Continuous Integration)環境に組み込んだときの流れを、DTシリーズ製品を例に考えてみましょう。図1は、動的テストに必要な一連のCIサイクルを、Jenkins上で回したときの各処理の手順を表したものです。これらの一連の手順をJenkinsのJobとして登録しておき、ソースコードを構成管理ツールにコミット時もしくはある決まった時間に、登録したJobを実行させるのが一般的です。Jobが実行されることで、Jenkinsは自身のワークスペース上で構成管理ツールからソースコードを取得し、必要に応じてコードインスペクション(コーディングチェックや静的解析の実施)を行い、対象ソースコードにテストポイントの挿入を行います。続けて、ビルドを行い実行ファイルを作成し、実行ファイルを対象環境にディプロイ後、テストスクリプトを実行しつつテストレポート(実行ログ)を取得します。最後、取得したデータを解析し、テスト結果を集計しアウトプットするまでが、登録したJobの処理内容となります。

図1: 動的テストのCIサイクル

テストポイント挿入のための4W2H

何か行動や振る舞いを考えるとき、「5W2H」の観点で考えるとうまくまとめられると言われていますが、テストポイントの挿入の自動化も然りです。ただし、テストポイントの挿入の自動化では人は介在しませんので、「5W2H」のうちWhoを除いた「4W2H」の観点で考えると必要があります。それでは、いつどのタイミング(When)で、どこの(Where)フォルダで、どの(What)ファイルに、何のために(Why)、どうやって(How)、どのくらい(How many)テストポイントを挿入すればよいか考えて行きましょう。

動的テスト自動化のためのシナリオ設計

静的テストの自動化と違い、動的テストの自動化では自動化のシナリオ設計が重要です。例えば、カバレッジ計測の自動化とパフォーマンスの測定の自動化では、挿入するテストポイントの位置や種類も異なりますし、テスト結果の集計の仕方も変わってきます。ですので、「テストポイントの挿入」から「テスト結果のアウトプット」までの首尾一貫した自動化シナリオ設計が必要になります。それでは、どのような観点でもってシナリオ設計すればよいか、「日々のソースコード変更に対するパフォーマンスの変化の監視」を例に考えてみましょう。

何を監視の対象とするか

エンハンス開発でベースコードを元に機能をインプリして行くとき、日々のソースコードの変更がどれだけパフォーマンスに影響を与えているかを早目に知りたいときがあります。パフォーマンスの変化は「時間」に表れますので、ある特定の個所の「処理時間」や「周期時間」を監視の対象とします。また、ツール側で負荷情報が算出可能な場合は、負荷に関する情報も監視の対象とします。以下は、監視対象の例です。

時間と負荷を計測するためのテストポイントの挿入

基本的に処理時間を計測するときには、少なくとも計測地点にテストポイントが挿入されている必要があります。また、負荷を計測するときは、負荷計測用のテストポイントもあわせて挿入しておきます。以下は、計測対象と計測に必要なテストポイントの組み合わせの例です。

負荷計測のためのテストケースの準備

負荷を変化を見て行きますので使用するテストケースとしては、以下の三種類のデータが用意できるのが望ましいです。また、定点観測が基本となりますので、計測開始日から計測終了日までの間は、同じテストケースを使い続けるのが望ましいです。

計測データ集計

データの集計では、監視対象となっている項目毎に「最大値」「最小値」「平均値」グラフにプロットして日々の変化を見て行きます。

エンハンス開発では処理を追加するごとに徐々に負荷や処理時間の「平均値」が上がって行く傾向にありますが、特に、「平均値」の変化量に比べて「最大値」の変化量が大きくなるときは注意が必要になります。このように、数値の変化から何らかの異常が発見されたとしても、その当時のソースコードの変更履歴と異常のあった個所を照らし合わせることで、パフォーマンス低下の要因となっている個所の早期発見と手当がすぐにできます。

今回は、「日々のソースコード変更に対するパフォーマンスの変化の監視」を例に挙げましたが、「テストポイントの挿入」から「テスト結果のアウトプット」まで考えるべきことは多岐に渡ります。日々のカバレッジの変化を監視する場合でも同様です。ですが、このシナリオ設計をしっかりやっておくことでその恩恵は必ず受けられます。是非トライしていただきたいと思います。

最後に

いかがでしたでしょうか？
概念的な話が続いてなかなかツールの使い方の具体的な話が出て来なくて、本ブログを読んでいただいている方の中で少々物足りなさを感じている方もいるかもしれません。次回はがらりと変わって技術的な話がメインになりますのでご期待ください。

どんなツールも「適材適所」な使い方が望まれてはおります。この「適材適所」という言葉は、言うは易し行うは難しの言葉の一つではないでしょうか。「適材適所」の領域に辿り着くまでには、何度も「トレードオフ」が発生するはずです。都度よりよいジャッジが求められますが、これが難しくしている理由の一つかもしれません。よくよく考えてみると、実は、この判断能力はエンジニアであれば誰でも持っているのではないでしょうか。万能なデバイスであったり、夢のようなライブラリははありませんので、エンジニアは日々ハードウェアやソフトウェアを設計する上で、何らかの「トレードオフ」を経験していてそれをうまく裁いているはずですので。もしかしたら、ツールの「適材適所」な使い方は、エンジニアがその気になれば、意外とすぐに見つけられるのかもしれません。