アプリケーション開発において、テスト自動化は必須の要件になってきています。ここで言うテスト自動化はUIテストやAPIテストを自動で実行するテストを指します。弊社取り扱いのRanorexやSOAtest、OSSではSeleniumなどテスト自動化ツールは多くあり、その効果から導入も進んでいます。
導入当初はテスト作成時に発生する課題に対応し、様々な工夫をしながら自動化したテストケースを作成してきたことでしょう。導入が進み運用が定着してくると、今度はメンテナンスや実行時間など、運用時に特有の課題に直面する場合があります。ここではその中の一つ、実行時間が増加する問題を取り上げます。
テストケースの増加による実行時間の増大
テスト自動化の導入当初はテストケースの数も少なく、実行してもそれほど時間もかからずに結果が得られるためあまり気になりません。しかし、テストケースが増えるにつれてテストの実行時間も増加してきます。UIテストやAPIテストはUI操作をシミュレートしたり、ネットワークを介してテストを行う場合もあるなど、そもそもテストの実行に時間がかかります。
そのため、テストケースが増えると実行時間も大きな問題になります。例えばソースを修正し、プッシュしたあとにCI環境で多くのテストが実行されると終了をしばらく待つ必要があり、開発のリズムも悪くなります。もちろん回帰テストのためすべてのテストケースを実行すべきだと思いますが、頻繁にコードの変更が発生する様なタイミングでは素早くレスポンスを受けて次のステップに進みたいと考えます。
その解決策として、JtestやdotTESTのアプリケーションカバレッジ機能のひとつ、テスト影響分析を使ってテスト実行時間を短縮する方法をご紹介します。
ソースコードの品質向上を実現します。
アプリケーションカバレッジとは？
アプリケーションカバレッジとはWebアプリケーションやデスクトップアプリケーションを実際に操作したカバレッジを取得する方法です。UIを操作した際のカバレッジが取得できるため、結合テストやシステムテストのカバレッジを確認できます。また、単体テストなど別のテストのカバレッジとマージし、開発プロセス全体のカバレッジも確認できます。過去の記事で詳しくご紹介していますので、興味がありましたらご覧ください。
ソースコード修正時の影響範囲分析
テストケースの絞り込みはアプリケーションカバレッジで取得したカバレッジを元にテスト影響分析の機能を使って実施します。テスト影響分析とは特定のタイミングでとったカバレッジをベースラインとして設定し、そのあとに変更があったソースコードに影響するテストケースを特定する機能です。
例を使ってテスト影響分析を説明します。
テスト対象は買い物を行うWebアプリケーションです。以下の3つのテストシナリオがあり、一度アプリケーションカバレッジを使ってカバレッジを計測している事とします。このカバレッジがベースラインになります。
この時、ログイン処理に仕様変更があり、AuthCheck.javaを修正しました。AuthCheck.javaは「ユーザー情報変更テスト」、「買い物決済完了テスト」のテストシナリオの中で呼び出されているため、最低でもこの2つのテストケースは実行する必要があります。
一般的にテストケースを絞り込む場合、設計書などから依存関係を確認して実行すべきテストケースを絞り込みます。今回の様な単純な例ではそれも可能でしょう。しかし、実際のアプリケーションはこのような単純な構造ではなく、複雑な呼び出し関係があります。さらに共有ライブラリの様に色々な場所から呼び出しがあるような場合、全体を把握するのは困難です。ヌケモレの可能性も出てきます。
そこで、Jtest/dotTESTのテスト影響分析の機能を使うと、前回計測したカバレッジをベースラインとして修正後のモジュールを解析し、自動で依存関係のあるテストケースのリストを作成します。ツールによっては作成されたリストを渡すことによって、依存関係のあるテストだけを実行することができます。
下図はテスト影響分析の実行手順のイメージです。
まとめ
Jtest/dotTESTのテスト影響分析の機能はカバレッジを使ってソースコード修正に影響のあるテストケースを特定する機能です。例えばソースコードが頻繁に変わるようなタイミングでは最小限のテストだけを実行し、マージリクエストなど特定のタイミングでその他のテストも実行する、といった使い分けをすることでテストの待ち時間を減らし、効率的に開発を行うことができます。もし、自動化されたテストの実行時間に課題をお持ちの場合は、Jtest/dotTESTのアプリケーションカバレッジを使ったテスト影響分析をお試しください。
