この記事は、インテル® デベロッパー・ゾーンに掲載されている「Testing Parallel Programs」(http://software.intel.com/en-us/articles/testing-parallel-programs) の日本語参考訳です。
情報科学分野では、より高速なパフォーマンスへの渇望が満たされることはありません。今日では、スピードだけでなく、より小さく強力なモバイルデバイスでのパフォーマンス要求が高まっています。この高まるユーザーの期待に応えるため、OEM デバイスでは高速なマルチコア・プロセッサーの採用が進むと IDC は予測しています [1]。今後、並列プログラムはマルチコア・テクノロジーを最大限に活用するためモバイルデバイスで幅広く使用されるでしょう。
開発テストは、ソフトウェア開発サイクルにおいて最もコストがかかるフェーズの 1 つです。大手ソフトウェア・ベンダーは、開発コストの 50% をテストに費やしています [2]。並列ソフトウェアではこのコストがさらに増えるため、ソフトウェア開発戦略において、効率良く最適なテスト方法を選択することが重要です。
これまでの記事で [3]、シリアル・アプリケーションを並列化するためのヒントと並列処理を最適化する方法を述べました。この記事では、並列ソフトウェアのさまざまなテスト手法を紹介します。
通常、並列プログラムは 次の 3 つの高レベルな手法でテストすることができます。
ブラックボックス: 並列アプリケーションのコードに関して特定の知識がなくてもアプリケーション機能をテストすることができます。ブラックボックス・テストの欠点は、コードのどれだけの部分がカバーされたか分からないことです。回避策として、テストデータの適用条件を熟考して何をテストすべきかを明確にすることです。一方、この手法の利点は、簡単に自動化でき、プログラム構造に関する情報が不要なためホワイトボックス手法より少ない労力で済むことです。
ホワイトボックス: ソフトウェア機能の実装に使用されている並列ソースコードとアルゴリズムをテストします。ホワイトボックス・テストでは、テストケースの設計と実施にシステム内部、データ構造、並列プログラミングの知識が必要です。テスト担当者は、各コードを実行するのにどの入力データを使うべきか、そして、機能が正しく動作し、適切な出力が得られたかどうかを判断できなければいけません。そのため、労力だけでなく、経験豊富な知識が必要になります。
ホワイトボックス・テストは、ソフトウェア・テスト・プロセスのさまざまなシステムレベルに適用できますが、通常はユニットレベルで行われます。ユニット内のパス、ユニット間のパス (統合時)、サブシステム間のパス (システムレベル・テストの場合) をテストすることができます。この手法は多くのエラーや問題を見つけられますが、仕様の未実装部分や要件不足を検出することはできません。
混合: ブラックボックス手法とホワイトボックス手法を組み合わせたものです。一般に、専用ライブラリーを使ったり、あるいはテスト目的で並列アルゴリズムの一部が実装されている場合に利用されます。
テスト戦略
並列プログラムのテスト戦略は大きく分けて 4 つあります。
耐久テスト: 通常の状況下における正しい動作ではなく、高負荷時の信頼性、可用性、エラー処理を重視したテストを指します。特に、並列プログラムのテストでは、まれに発生するインターリーブを検出し、計算リソース不足によりソフトウェアがクラッシュしないようにすることが目的です。
系統的テスト: テスト対象のユニットが仕様とテストの想定内容に完全に一致するかを徹底的に検証する、ソフトウェアの完全な適合性テストを指します [4]。このテストを実装する 1 つの方法として、モデル・チェッカー・メカニズムを使用することができます。このツールは、指定された入力データに対するさまざまなスレッドのインターリーブを系統的に把握するのに役立ちます。
ランダムテスト: インターリーブをランダムに選択して、動作をテストします。ここで重要なのはアクティブテストです [5]。アクティブテストは 2 つのフェーズから成ります。まず、一般的なスタティックまたはダイナミック・プログラム予測解析により、データ競合、デッドロック、アトミック性の違反などの並列性に関する問題の可能性を見つけます。次に、予測解析のレポートを使用して並列プログラムのスケジューラーを明示的に制御し、わずかなオーバーヘッドで実際の並列性問題を高い確率で正確かつ迅速に発見します。
ヒューリスティック・テスト: テスト担当者は問題があると思われるスケジュールを慎重に計画しテストします。主にプロファイルと解析からプログラムを理解する必要があります。
計画と測定
並列アプリケーション・テストの最初のステップは、許容範囲のパフォーマンスのしきい値を定義して、適切なパフォーマンスの期待値を設定することです。このしきい値は、プロジェクトの計画時に定義するべきであり、達成すべき製品の非機能要件となります。
しきい値を定義する際、テストのライフサイクルで収集およびテストするメトリックをアーキテクトが決めるべきでしょう。アプリケーションのパフォーマンスを評価するメトリックには、単一ジョブの時計時間 (ターンアラウンド時間とも呼ぶ)、MFLOPS (Million FLoating-point Operations Per Second) レート、メモリー使用量、I/O 使用率、MIPS (Million Instructions Per Second)、ネットワーク使用量など多数あります。そのため、アプリケーションの特性に応じて、どのメトリックを使用するかを決めることが重要です。
さらに、テスト計画で重要なことは、テストケースの実行で使用されるデータセットの定義です。アプリケーションの実行シーケンスを十分にカバーできるデータセットと実行環境を慎重に選択する必要があります。ベンチマークの測定は、同じデータセットと設定環境で行われるべきです。また、テストとテストの間の変更は 1 つにすることを推奨します (例えば、コンパイラー・オプションやシステム設定など)。そうすることで、変更とそのパフォーマンスへの影響が理解しやすくなります。異なるツールや手法により取得したデータは、できるだけ比較してください。
テストはソフトウェア開発サイクルにおいて最もコストがかかるフェーズの 1 つです。そのため、効率良く効果的な戦略を選択することが重要です。ここで紹介した手法は、特定のプロジェクトで最適なテスト・アプローチを定義するのに役立つでしょう。
並列プログラミングとアプリケーションの並列性を評価するツールに関する詳細は、「Performance」(http://software.intel.com/en-us/performance (英語)) ページを参照してください。
[1] World wide Mobile Phone 2011–2015 Forecast Update: September 2011.Ramon T.Llamas William Stofega
[2] Parallel Execution of Test Runs for Database Application Systems, Florian Haftmann Donald Kossmann, Eric Lo [3] 並列アプリケーション最適化のための計画 Diana Byrne, July 22 2011. https://www.isus.jp/article/idz/parallel/planning-for-parallel-optimization [4] A theory of regression testing for behaviourally compatible object types, Software Testing, Verification and Reliability J H Simons, UKTest 2005 Special Issue, September, eds.M Woodward, P McMinn, M Holcombe and R Hierons (Chichester: John Wiley, 2006), 133-156. [5] CalFuzzer: An Extensible Active Testing Framework for Concurrent Programs; Pallavi Joshi, Mayur Naik, Chang-Seo Park, and Koushik Senコンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。
