ファームウェアをテストするためのツールを評価する方法

投稿の著者からの紹介

8年以上にわたって重要なシステムのソフトウェア開発の経験があり、重要なシステム（航空宇宙、医療、輸送、産業）のソフトウェアの開発と検証に関連する資料をコミュニティに紹介したいと思います。 外国の同僚からの多くの興味深い記事の翻訳と改作に同意したので、このリソースを使用することにしました。 記事が私たちのコミュニティに興味があるなら、私はうれしいです。 この記事では、Vector Software、Incの資料を使用しています。

コメントまたはPMで質問に答えます

どのテストツールを使用しますか？

過去数年にわたって、自動テストツールの市場は、同じ機能を実行すると主張する資金で満たされてきました-自動テスト。 ウィキペディアには、C / C ++プログラミング言語専用の38のテスト環境評価ツールがリストされています。 残念ながら、これらの製品の説明と簡単なデモバージョンを検討している潜在的なユーザーは、ほとんどのツールがほぼ同じであると結論付けることができます。



このドキュメントの目的は、特に自動化された動的なテストツールに関して、自動化されたソフトウェアテストツールを評価する際に考慮する必要がある情報をエンジニアに提供することです。

仕様を読んでテストツールを評価することはできません。

すべての仕様はかなり均一に見えます。 キーワードは同じです：「業界のリーダー」、「独自の技術」、「自動化されたテスト」、「高度な方法」。 スクリーンショットは互いに似ています：ヒストグラム、ブロック図、HTMLレポート、パーセンテージ。 これはすべてあなたを退屈させます。

ソフトウェアテストとは何ですか？

ソフトウェアテストを行ったことがある人なら誰でも、それが多くのコンポーネントで構成されていることを知っています。 簡単にするために、3つの用語を使用します。

• システムテスト-完全に統合されたソフトウェアアプリケーションのテスト
• 統合テスト-ソフトウェアモジュールの統合グループのテスト
• ユニットテスト-アプリケーションソースコードの個々のモジュールのテスト

ある程度、誰もがシステムテストを実施し、その間にエンドユーザーが実行するアクションの一部を実行します。 注意してください、私たちは「すべての可能性」についてではなく、いくつかの行動について話しているのです。 アプリケーションでエラーが発生する最も一般的な原因の1つは、予期しない入力データの出現です。



統合テストを実施する人は多くなく、ユニットテストを実施する人はほとんどいません。 統合または単体テストを実施した場合、アプリケーション内の他のすべてから単一のファイルまたはファイルのグループを分離するために作成する必要があるテストコードの数がわかります。 最も厳しいレベルのテストでは、テスト用に記述されたコードの量がテスト対象のコードの量を超える場合が一般的です。 その結果、このようなテストレベルは通常、航空、医療機器、鉄道産業などの分野の機能とセキュリティに不可欠なアプリケーションに適用されます。

自動テストとはどういう意味ですか？

手動で統合および単体テストを行うプロセスは、非常に高価で時間がかかることはよく知られています。 その結果、市場に登場する各機器は、自動テストを使用しているとみなされています。 しかし、「自動テスト」とはどういう意味ですか？ さまざまな人々が「自動化」という言葉を独自の方法で理解しています。 多くの開発者にとって、自動テストとは、ボタンを押して結果を取得する機能を意味します。つまり、コードが正しいことを意味する「グリーンチェック」またはエラーを意味する「赤いX」です。



残念ながら、そのようなツールは存在しません。 そして、あなたが存在した場合、それを使用したいですか？ 考えてみてください。 コードが「順序どおり」であることをツールが示した場合、どういう意味ですか？ これは、コードが完璧にフォーマットされていることを意味しますか？ おそらく。 これは、コードがコーディング標準を満たすことを意味しますか？ おそらく。 それはコードが正しいことを意味しますか？ 絶対に違います！



完全に自動化されたテストは達成不可能であり、原則として望ましくありません。 自動化では、テストプロセスのアルゴリズムと時間のかかる部分に焦点を当てる必要があります。 これにより、ソフトウェア開発者は常に高度で複雑なテストを作成する必要がなくなります。



テストツールを評価する場合、論理的な疑問が生じます。このテストツールはどの程度の自動化を提供しますか？ これは、組織がテストツールへの投資利益率を計算しようとする際の不確実性の主な領域です。

テストツール分析

通常、テストツールはさまざまな機能を提供します。 さまざまなツールキットがさまざまな企業によって提供されているため、別のツールを使用すると機能が異なる場合があります。 広範囲の基準システムに従って、評価済みのテストツールに存在する可能性のあるコンポーネントに次の名前を選択しました。

• Analyzer-このコンポーネントを使用すると、テストツールでコードを理解できます。 彼はコードを読み取り、コードの中間表現（通常は階層構造の形式）を作成します。 基本的に、コンパイラは同じことを行います。 その出力または「アナライザーデータ」は通常、中間言語のファイルに保存されます。
• コードジェネレーター -コードジェネレーターは、「アナライザーデータ」を使用して、テストプログラムのソースコードを構築します。
• テストプログラム -テストプログラムは厳密に言えばテストツールの不可欠な部分ではないという事実にもかかわらず、テストプログラムの構築中に下される決定はテストツールの他の特性に影響を与えます。 したがって、このようなプログラムのアーキテクチャは、テストツールの評価において非常に重要です。
• コンパイラ -テストツールがテストプログラムコンポーネントのコンパイルとリンクを開始できるようにします。
• ターゲットコンポーネント -エミュレータプログラム、シミュレータ、組み込みデバッグプログラム、商用リアルタイムオペレーティングシステムのサポートなど、さまざまな環境でテストスクリプトを実行できます。
• テストエディター -テストエディターを使用すると、スクリプト言語と洗練されたグラフィカルユーザーインターフェイスの両方を使用して、テストシナリオの前提条件と期待値（合格/不合格の基準）を設定できます。
• カバレッジ -ユーザーは、コードのどの部分がテストによってテストされているかレポートを取得できます。
• レポートコンポーネント -テストの通過中に収集されたデータを単一のプロジェクトドキュメントに結合できます。
• コマンドラインインタープリター -スクリプト、makeユーティリティなどを使用してツールをアクティブにすることにより、テストツールを使用する際の追加の自動化を提供します。
• 回帰コンポーネント -ソフトウェアの1つのバージョン用に作成されたテストを新しいバージョン用に再起動できます。
• 統合コンポーネント -サードパーティツールとの統合は、テストツールに投資するかどうかを決定する重要な要素となります。 原則として、構成管理システム、要件管理ツールおよび静的分析ツールとの統合が一般的です。

以下のセクションでは、上記のコンポーネントが問題のテストツールでどのように評価されるべきかをより詳細に説明します。

テストツールの種類/自動化レベル

テストツールには上記のテストコンポーネントのすべての機能が含まれていないという事実と、自動化の程度によるツール間の大きな違いのために、次の広範なテストツールの分類を作成しました。 評価された機器は、次のグループのいずれかに起因します。

• 手動 -「手動」ツールは、テストプログラムの空のフレームワークを作成し、テストスクリプトを実行するために、テストデータと論理部分のコードを手動で記述する必要があります。 原則として、これらは、テストの確認やテスト文書の表形式レポートの作成などの一般的なプロセスに使用できるスクリプト言語および/またはライブラリ関数のセットを提供します。
• 半自動化 -半自動化ツールには、グラフィカルインターフェイスと一部の自動化機能がありますが、より複雑な設計をテストするには、手動でのコード記述やスクリプト作成が必要です。 また、半自動化ツールには、自動化ツールの一部のコンポーネント、たとえばターゲットプラットフォームにソフトウェアを展開するための組み込みサポートが欠けている場合があります。
• 自動化 -自動化ツールは、前のセクションにリストされている各機能領域またはコンポーネントに関連付けられています。 このグループのツールは、手動のコーディングを必要とせず、すべての言語構成と異なるターゲットプラットフォームでのソフトウェア展開の両方をサポートします。

テストツールの暗黙的な違い

ツールの機能と自動化レベルを比較することに加えて、使用したテストアプローチを評価および比較することが重要です。 たとえば、テストプロジェクトを作成すると、ツールは統合開発環境にファイルをアップロードするだけですが、特定のアクションを実行するまでテストプログラムまたはテストスクリプトを作成しません。



その結果、テストツールに隠れた欠陥がある可能性があります。 したがって、テストツールにコードを読み込むだけでなく、テストするクラスの各メソッドの簡単なテストケースを構築することも重要です。 ツールは完全なテストプログラムを構築しますか？ スタブは自動的に作成されますか？ グラフィカルユーザーインターフェイスを使用して、テストシナリオのパラメーターと一般データを定義できますか、または手動でテストするかのようにコードを手動で記述する必要がありますか？



同様に、ターゲットプラットフォームのサポートは、使用するツールが異なります。 プロバイダーが「私たちはすべてのコンパイラとターゲットをサポートしています」と言っている場合は注意してください。 これは、「ツールを作業環境で機能させるには、すべての作業を行う必要がある」ということだけです。

テストツールを評価する方法

次のいくつかのセクションでは、ソフトウェアテストツールを評価するときに慎重に検討する必要のある情報について詳しく説明します。 理想的には、提案された各ツールをテストして、実際に受け取った情報を確認する必要があります。



このドキュメントの後続の資料は技術的な性質を持つため、いくつかの規則を紹介します。 各セクションには、対処する問題を説明する見出しがあり、この問題が重要である理由をさらに説明し、最後に、検討した資料の要約として「キーポイント」を示します。



また、慣例について言えば、用語に注意を払う必要があります。 「関数」という用語は、プログラミング言語Cの関数とプログラミング言語C ++のクラスのメソッドの両方を指し、「モジュール」という用語はプログラミング言語Cのファイルとプログラミング言語C ++のクラスを指します。 最後に、ほとんどすべてのテストツールが「キーポイント」に記載されている項目を何らかの形でサポートしていることを覚えておく必要があります。タスクは自動化のレベル、使いやすさ、サポートの程度を評価することです。

コードアナライザーとジェネレーター

Cプログラミング言語のアナライザーを作成するのは比較的簡単です。 C ++プログラミング言語用の本格的なアナライザーを構築することははるかに困難です。 評価プロセスで回答する必要がある質問の1つは、アナライザーテクノロジーの信頼性と熟考です。 一部のテストツールベンダーは、ライセンスされたアナライザーテクノロジーを購入して再販し、他のベンダーは独自のアナライザーを持っています。 アナライザーとコードジェネレーターの信頼性は、複雑なコード構成（プロジェクトで使用するコードの典型的なサンプル）を使用して確認できます。

テストドライバー

テストドライバーは、テストを制御するメインプログラムです。 Cプログラミング言語の標準ライブラリの正弦の数学関数をテストする簡単なドライバーの例を次に示します。

#include <math.h> #include <stdio.h> int main () { float local; local = sin (90.0); if (local == 1.0) printf ("My Test Passed!\n"); else printf ("My Test Failed!\n"); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはかなり単純な例ですが、「手動」テストツールでは、この小さなコードを手動で入力（およびデバッグ）する必要があります。半自動ツールは、特定の種類のスクリプト言語または正弦引数を入力するためのシンプルなGUIを生成します。 自動化ツールには、テストシナリオを構築するための本格的なGUI、コードカバレッジの統合分析、統合デバッガープログラム、およびターゲットプラットフォームにソフトウェアを展開する統合機能が含まれます。



このドライバにエラーがあることに気づいたのではないかと思います。 これは、サインを計算する関数が実際に度ではなくラジアンの角度を入力値として使用するという事実にあります。

依存関数にスタブを使用する

テスト中に依存関数によって返される値を制御する場合は、依存関数の置換を構築する必要があります。 スタブの使用は、アプリケーションの他の部分からテスト済みコードを分離でき、対象のサブシステムを簡単にテストできるため、統合と単体テストの重要な部分です。



多くのツールでは、静的スカラー値（return0;）を返すことを除いて、スタブでより複雑な処理を完了するために、テストコードを手動で作成する必要があります。

試験データ

テストシナリオの実装では、半自動ツールと自動ツールで使用される2つの主なアプローチがあります。 1つ目はデータ駆動型アーキテクチャで、2つ目は単一のテストアーキテクチャです。



データ駆動型アーキテクチャの場合、テストプログラムはすべてのテスト済みモジュールに対して作成され、これらのモジュールで定義されているすべての機能をサポートします。 テストが実行されると、ツールはデータをファイル記述子やUARTなどの物理インターフェイスなどの情報ストリームとともに提供します。



単一のテストのアーキテクチャの場合、テストを実行するたびに、ツールはテストドライバーを作成し、それを実行可能プログラムにコンパイルします。 いくつかの点に注意することが重要です。 まず、単一のテストに必要な追加コードの作成と、その後のコンパイルにはテストの実行に時間がかかります。 次に、結果として、テストシナリオごとに個別のテストプログラムを作成します。



つまり、評価対象のツールは特定の名目上のシナリオでは正常に機能し、より複雑なテストでは正しく機能しない可能性があります。

自動テストデータ生成

さまざまな自動化ツールは、テストケースを作成するためのある程度の自動化を提供します。 これにはさまざまなアプローチが使用されますが、そのいくつかを下の表に示します。

• （MMM）Min-environment-maxテストスクリプト -MMMは、入力データ型の境界値のテスト関数をテストします。 プログラミング言語CおよびC ++のコードは、許容範囲外の入力データから自身を保護しないことがよくあります。
• （EC）同等クラス -EUテストは次のとおりです。特定のクラスの各代表とプログラムが同じように動作するという原則に基づいて、データは同等クラスに分割されます。 したがって、すべての可能なデータがチェックされるわけではなく、クラスの個々の代表者がチェックされます。
• （RV）ランダム変数 -RVテストは、各関数パラメーターのランダム値の組み合わせを指定します。
• （BP）条件付きステートメントブランチでのテスト-BPテストは、条件付きステートメントブランチで高レベルのカバレッジを自動的に作成できます。

テストシナリオの自動作成について考えるとき、それらがどのような目的を果たすかを覚えておくことが重要です。 自動化されたテストは、アプリケーションコードの堅牢性（信頼性）の評価には適していますが、正確性（高レベルのコードカバレッジを提供する場合でも）の評価には適していません。 正確を期すために、アプリケーションが行うこと（コード）ではなく、アプリケーションが期待するもの（要件）に基づいてテストを作成する必要があります。

コンパイラー統合

コンパイラー統合には二重の意味があります。 一方では、統合により、コンパイラパラメータのユーザー入力を必要とせずに、テストプログラムコンポーネントを自動的に構築できます。 一方、統合により、テストツールは、処理に使用されるコンパイラに固有の言語拡張機能を受け入れることができます。 クロスコンパイラは、C / C ++プログラミング言語標準の一部ではない拡張機能をサポートするのが一般的です。 一部のツールでは、このような拡張子を空の文字列として定義しています。 これは非常に粗雑なアプローチであり、その主な欠点は、コンパイラによって生成されたオブジェクトコードが変更されることです。 たとえば、GCC属性を持つ次のグローバル外部変数を考えます。

 extern int MyGlobal __attribute__ ((aligned (16)));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題のツールがグローバルMyGlobalオブジェクトを定義する際に属性をサポートしていない場合、アライメントは同じではないため、テスト中および動作状態でコードの動作が異なります。

ターゲットプラットフォームのテストサポート

このセクションでは、クロスコンパイラ、デバッグインターフェイス（エミュレータ）、ターゲットプラットフォーム、リアルタイムオペレーティングシステム（RTOS）などの開発環境に適用される「ツールボックス」という用語を使用します。 問題のツールがツールボックスと良好に統合されているかどうかを確認し、別のツールボックスに移行するためにツールで何を変更する必要があるかを理解することが重要です。



また、自動化のレベルとターゲットプラットフォームとの統合の信頼性を確認することも重要です。 前述したように、ベンダーが「すべてのコンパイラとターゲットプラットフォームをサポートしている」と言う場合、これはたった1つのことを意味します。「作業環境でツールを動作させるには、すべての作業を行う必要があります」



理想的には、選択するツールは「ワンクリック」テストを実行する必要があり、ソフトウェアをターゲットプラットフォームにダウンロードして作業マシンでテスト結果を収集するすべての困難は、メッセージ「テストが実行中」の背後に隠されているため、ユーザーからの特別なアクションは不要です。



ターゲットプラットフォームでのテストにおける追加の課題は、ハードウェアの可用性の問題です。 多くの場合、ハードウェアはソフトウェアと並行して開発されているか、ハードウェアへのアクセスが制限されています。 重要なポイントは、独自の環境でテストを開始し、後で実際のターゲットプラットフォームに移行できることです。 テストツールのアーティファクトは、ハードウェアに依存しないことが理想的です。

テストスクリプトエディター

明らかに、テストツールを使用してほとんどの時間を費やすのはテストスクリプトエディターです。 ツールが上記の項目の自動化を本当にサポートしている場合、テスト環境のセットアップとターゲットプラットフォームとの通信に費やす時間は最小限になります。 最初に言ったことを思い出してください-私たちの目標は、エンジニアが時間を使ってより高度でより完全なテストを作成することです。



評価中に回答する必要がある重要な質問は、非自明な構造のテスト入力データと期待値を確立することがいかに難しいかです。 市場にある既存のツールは、スカラー値を設定するかなり簡単な方法を提供します。 たとえば、評価対象のツールには、クラスを構築するためのシンプルで直感的な方法が備わっていますか？ ベクトルやマップなどのSTLコンテナーのセットアップについてはどうですか。 このようなニュアンスは、テストスクリプトエディターで評価する必要があります。

コードカバレッジ

ほとんどの半自動およびすべての自動テストツールには、コードカバレッジツールが組み込まれており、テストスクリプトの実行時に実行されるソフトウェアコードの量を示すメトリックを表示できます。 一部のツールは、この情報を表形式で提供します。 他のものはフローグラフを生成し、一部はコメント付きソースコードリストを生成します。 表は要約の優れたプレゼンテーションですが、コードを100％網羅しようとする場合は、コメント付きのリストが最善の方法です。 このようなリストには、覆われた構造、部分的に覆われた構造、覆われていない構造のソースコードファイルが示されています。 これにより、100％のカバレッジに必要な追加のテストケースを簡単に確認できます。



ソフトウェアに追加のソースコードが追加されるため、ツールキットの影響を評価することも重要です。 考慮しなければならない2つのポイントがあります。1つはオブジェクトコードのサイズの増加、もう1つはプログラム実行中の追加コストです。 ソフトウェアにプログラムのメモリ制限または時間制限（またはその両方）があるかどうかを理解することが重要です。 これは、ソフトウェアにとってより重要なことに集中するのに役立ちます。

回帰テスト

テストツールを選択するとき、2つの主な目標を覚えておく必要があります。 最初の目標は、テスト時間を節約することです。 あなたがこれらの言葉を読んだ場合、あなたは私たちに同意します。 2番目の目標は、作成されたテストをソフトウェアライフサイクル全体で効果的に使用することです。 これは、テストの作成に費やされた時間とお金が、テストの複数の使用の可能性をもたらし（ソフトウェアが時間の経過とともに変化する場合）、これらのテストの構成管理を容易にすることを意味します。 主なことは、将来同じテストに合格するために保存する必要がある個々のエンティティと、再起動の制御方法に関心があるツールで評価することです。

報告

ほとんどのツールは、同様の方法でレポート機能を提供します。 少なくとも、入力、期待される出力、実際の出力、および期待値と実際の値の比較を示すわかりやすいレポートを作成する必要があります。

他のツールとの統合

単一のツールの品質や実用性に関係なく、すべてのツールは、異なるメーカーのシステムを組み合わせた環境で機能する必要があります。 大企業は、「すべての人のために」すべてを実行するツールを開発した中小企業を買収するために膨大な時間とお金を費やしました。 これらのメガツールキットの場合、「総量は部品の合計より少ない」という特徴があります。 多くの場合、企業は4〜5個の小さいが実用的なツールを使用して、それらを1つのかさばって使用できないツールに統合します。



既に検討したツールボックスとの統合に加えて、テストツールの最も便利な統合タイプは、静的分析、構成管理、および要件管理ツールとの統合です。 誰もがテストツールのアーティファクトを構成管理システムに保持し（再利用のため）、ほとんどの人はテストケースの要件をトレースしたいと考えています。

必要なテストツールの追加機能

「テストツールの分析」セクションのレビューを完了しました。 前のセクションでは、自動化されていると見なされるツールの機能コンテンツについて説明しました。 以下のセクションでは、これらの特性の重要性について議論しながら、望ましい（およびあまり一般的ではない）特性の一部をリストします。 これらの特性は、プロジェクトへの適用性のレベルが異なる場合があります。

真の統合テスト/マルチユニットテスト

統合テストは、単体テストの続きです。 モジュール間のインターフェイスをテストするために使用され、特定の機能プロセスを実行するモジュールを組み合わせる必要があります。 多くのツールは、テストプログラムを使用して実際のモジュールのオブジェクトコードをリンクすることにより、統合テストをサポートすると主張されています。 このメソッドは、実行可能なテストプログラム内に多くのファイルを作成しますが、これらの追加モジュール内の機能をアクティブにする機能は提供しません。 理想的には、単一のテストシナリオ内で、任意のモジュールの任意の機能を任意の順序でアクティブにできる必要があります。 モジュール間のインターフェース全体をテストすると、ソフトウェアの多くの隠れた仮定とエラーが明らかになります。 実際、統合テストは、単体テストの履歴がないプロジェクトの最初のステップになります。

動的スタブを使用する

動的スタブを作成すると、独自のスタブ関数を動的に有効または無効にできます。 これにより、他のすべての機能を（テスト対象の機能と同じモジュールに存在する場合でも）消して、単一の機能のテストを作成できます。 非常に複雑なコードの場合、これはテストを大幅に簡素化する重要な機能です。

ライブラリとアプリケーションのテスト

システムテストの複雑な問題の1つは、完全に統合されたソフトウェアを対象としたテストアクションでは、ユーザーがボタンやスイッチを押すか、コンソールに印刷する必要があることです。 アプリケーションが埋め込まれている場合、入力の制御がさらに難しくなります。 統合テストと同様の方法で、機能レベルで外部の影響を送信できるとします。 これにより、ソフトウェアAPIのみに依存する一連のテストスクリプトを構築できます。



最も高度なツールの中には、この方法でテストできるものがあります。 このテストモードのもう1つの利点は、アプリケーションをテストするためのソースコードが必要ないことです。 API定義（通常はヘッダーファイル）が必要です。 この方法論は、システムテストを実行するための自動化されたスクリプト化された方法をテスターに​​提供します。

テストによるアジャイルテストおよび開発（TDD）

テストによる開発は次のことを意味します。最初にアプリケーションコードを記述し、次にモジュールをテストする代わりに、アプリケーションコードを記述する前に最初にテストを作成します。 これは新しい人気のある開発アプローチです-最初にテストを開発します。 アジャイル開発方法論の使用を計画している場合、自動化ツールはこのテスト方法をサポートする必要があります。

要件管理ツールとの双方向統合

要件をテストケースにリンクすることに関心がある場合は、テストツールと要件管理ツールの統合が望ましいです。 この機能に興味がある場合は、双方向インターフェースに注意することが重要です。 テストケースで要件がマークされると、テスト名や合格/不合格ステータスなどのテストケース情報が要件データベースに転送されます。 これにより、完了テストの要件を把握できます。

ツールの資格

民間航空やクラスIII医療機器の製造などの規制された環境で作業する場合、アプリケーションの構築とテストに使用する開発ツールを認定する必要があります。



認定には、ツールの目的（運用要件）の文書化と、これらの要件に従ってツールが機能することを証明するテスト結果が含まれます。 理想的には、仕入先はこれらの材料を完成した形で、また業界で資格データを使用した顧客の履歴を持っている必要があります。

おわりに

ほとんどすべてのファームウェアテストツールは、何らかの形で重要なポイントで言及されているポイントをサポートしていることに注意してください。 どのように自動化されているか、使いやすいことを理解し、サポートの有用性を評価することが重要です。