1

これでいいのかな??

  1. ブラックボックス

    1.1 機能

        1.1.1 Equivalence
    1.1.2 BVA
    1.1.3 Use case
    1.1.4 Regression
    1.1.5 UAT

    1.2 機能しない

        1.2.1 Testing the System Design

  2. 白い箱

    2.1. 機能的

           2.1.1 Unit
       2.1.2 Integration
       2.1.3 System

上記は適切なカテゴリに該当しますか?

私がこの質問をした理由は、レポートの一部として、テスト テクニックを適切に分類した適切な参考文献を見つけようとしていたからです。これは、さまざまな情報源からの私の分析と調査によって得られたものです。そして、これが同じ調査を行っている可能性のある他の誰かに役立つことを願っていますが、間違っている場合は更新する必要があります.

4

3 に答える 3

1

また、相互に依存する複数のプログラムが同時に開発される場合も考えられます。次に、これらすべてのアプリケーションをいくつかの機能ドメインにグループ化するアプリケーション アーキテクチャを考慮に入れる必要があります。

したがって、たとえば、大量のデータを処理する必要がある金融アプリケーションは1 つの機能ドメインになり、その中で次のものを開発する必要があります。

  • 複数のコンピューターでこれらのデータを処理するためのディスパッチャー モジュール
  • 何が起こっているかを確認するための GUI
  • 正しい接続を開始するためのランチャー 正しいデータを取得してフォーマットする
  • 等々

しかし、それは1 つの機能ドメインにすぎません。プログラムの結果を利用するには、他のドメインを開発する必要があるためです (たとえば、「参照ドメイン」は、それらの結果をさまざまなデータベースに格納し、通信バスを提供するために存在します)。他のプログラムがそれらにアクセスできるようにします。これは 2 番目の機能ドメインになります)。

したがって、次のカテゴリをテストに追加します。

  • アセンブリ テスト: 独自の機能ドメイン内でテストする場合 (アセンブリ サーバー上で、一連のテスト データを使用して、ドメインのさまざまなアプリケーションを展開する場合)
  • 統合テスト:すべての機能ドメインからすべてのアプリケーションをテストする場合。これはフロント ツー エンド テストとも呼ばれます。

注：「統合テスト」は「継続的統合テスト」とは異なります。これは、基本的に、 1つのプログラムについて、非常に定期的に、説明した白黒テストを処理できます。

私が言及しているテストは、以下によって週に数回実行されます。

  • アセンブリ テストのためのドメインの" Project Operational Architecture " チーム: 通常、アセンブリ サーバーをセットアップするチームの一部の開発者は、データが最新であるかどうかを確認し、開発を担当するさまざまなプログラムを展開します。
  • " Production Operational Architectural " チームは、"プロダクションのような" 環境の設定を担当し、フォントからバックまでのアプリケーションのすべてのチェーンを実際にテストできる唯一のチームです。

注: 「運用アーキテクチャ」チームには、「実行環境を運用可能にする」という役割があります。これは、次のことを意味します。

  • 適切なサーバーとネットワークを用意するために、適切な物流チームが連絡を取り、
  • 適切なアプリケーション チームは、システムのすべてのアプリケーションのさまざまな開始/停止アプリケーション プロセスと展開手順について知るために連絡を取ります。

要するに、あなたのカテゴリは1 つのプログラムに対するものですが、IS (情報システム) を開発している場合、「1つのチームによって開発された 1つのexe が1 つの実稼働マシンにデプロイされている」という話ではないという事実を認めざるを得ません。 . そして、まったく新しいテストの世界へようこそ ;)

于 2008-10-11T09:12:46.293 に答える
0

あなたの分類は良い第一歩だと思います。

ブラックボックスとホワイトボックス（ガラスボックスを好む人もいます）のテストの分離は、仕様（設計、ソースコード）のみにアクセスできるかどうかに焦点を当てています。

機能テストと構造テストの間に2つ目の分離を追加します。これは、ソフトウェアが何を実行するか（機能）またはどのように実行するか（構造）に焦点を当てます。

3番目の分離では、決定論的または統計的に（ランダムではなく、意図的な分布を使用して）テスト入力を生成する方法を扱います。いずれにせよ、あなたの焦点はあなたがターゲットとするカバレッジにあります。

最後に、よく知られている分離は、ソフトウェアサイクルのさまざまなレベル間です：単体テスト、統合、システム、受け入れ、...

于 2008-12-11T09:04:09.417 に答える
0

以下は、ソフトウェア テストで広く定義されているテスト方法論です。

1. ブラック ボックス テスト は、テスト対象の項目の内部構造/設計/実装がテスターに​​知られていないソフトウェア テスト方法です。これらのテストは、通常は機能しますが、機能する場合と機能しない場合があります。テスト設計手法には、等価分割、境界値分析、原因効果グラフが含まれます。

2. ホワイト ボックス テスト は、テスト対象の項目の内部構造/設計/実装がテスターに​​知られているソフトウェア テスト方法です。テスト設計手法には、制御フロー テスト、データ フロー テスト、分岐テスト、およびパス テストが含まれます。

3. グレー ボックス テスト は、ブラック ボックス テスト法とホワイト ボックス テスト法を組み合わせたソフトウェア テスト方法です。

于 2015-08-04T11:49:09.277 に答える