ソフトウェアテストの手法またはカテゴリ[非公開]


16

どのようなソフトウェアテストを知っていますか?テスト駆動開発、単体テストなどについて聞いたことがありますが、それらの重要性と違いを理解できません。たとえば、なぜ回帰テストや受け入れテストを使用するのでしょうか。彼らが提供する利点は何ですか?


8
これのどの部分が混乱または不完全でしたか? en.wikipedia.org/wiki/Software_testing
S.Lott

2
あなたはそうしないなら回帰テストをスキップできます;既存の機能を壊しても大丈夫です、そして実際にソフトウェアを使っている人やそれを払っている人が期待通りのことをしていると思うかどうか気にしないなら受け入れテストをスキップできます。プロのプログラマーは、これらの両方を気にします。
HLGEM

さまざまな種類のテストカテゴリに関する概要を説明できる唯一の質問なので、この質問を再開することに投票しています。たぶん、誰かが質問をこのサイトに合うように言い換える方法を知っているのでしょうか?
ドックブラウン

回答:


38

私の考えでは、大まかなカテゴリは次のとおりです。

ブラックボックステスト。コードを見ることができず、アプリケーションまたはシステムの内容が隠されているので、ある程度盲目的にテストしています。したがって、この場合、すべてのエラーケースを知っているわけではなく、すべてのケースを見つけるために明らかな場合とそうでない場合があるさまざまな境界条件を推測する必要があります。

ホワイトボックステスト。コードを確認し、どのコードパスウェイが使用されているかを確認して、コードカバレッジをメトリックとして使用して、すべてのロジックがシステムで使用されていることを確認できます。ここでのアイデアは、コードがどのように見えるかを知って、テストをガイドし、ブラックボックステストほど不思議ではないようにすることです。

グレーボックステストは、前の2つのハイブリッドです。

境界ケースは、ヒットするテストを記述するコードにさまざまな条件があるため、ホワイトボックステストで見ることができるものになりがちです。コードのどこかにあるはずです。

テストの一般的な分類は次のとおりです。

単体テスト。これらは通常、かなり具体的なものをテストする最小のテストです。たとえば、このメソッドはこの境界ケースを処理しますか?ここでは、テストの依存関係を減らすために、モックオブジェクトが関係する場合に依存性注入を使用できることに注意してください。

統合テスト。これらは、いくつかのコンポーネントを接続し、コンポーネントが正常に機能することを確認するためにテストを実行するテストです。単体テストは独立して機能する場合がありますが、これは、さまざまな落とし穴をキャッチする際にこれらのテストが役立つ原因となるレイヤー間の通信不良がある可能性があるため、物事がどれだけうまく機能するかをテストする場所です。エンドツーエンドテストという用語は、コンポーネントの完全なチェーンが「アプリケーションのあるエンドポイントから別のエンドポイントへ」(それが何を意味するにせよ)テストされる統合テストに使用されます。

回帰テスト。これらは過去に行われたテストであり、修正されたものが修正されたままであり、バグがコードに再導入されていないことを確認するために再度行われます。

ユーザビリティテスト。これらは、エンドユーザーがソフトウェアを使用してさまざまなタスクを実行できる程度を確認するために行われるテストです。何かをより速くするために何かを自動化したり、何かを使いやすくするためにUIを調整したりできる場所。

ユーザー受け入れテスト。これらはエンドユーザーが行うテストであり、何かがどのように機能するかを直接確認し、ソフトウェアがそもそもそれを要求したビジネスニーズを満たしていることに同意することができます。

機能テストは、テスト対象のソフトウェアの機能仕様に基づいたあらゆる種類のテストです。これらは常にブラックボックステストです。

性能試験。これらは、システムが遅すぎることなく一定量の負荷を処理できることを確認するために行われるテストです。たとえば、サーバーの新しいWebファームをテストすることで、サイトに同時にアクセスする100人のユーザーを同時に処理でき、パフォーマンステストの例になります。これらは「負荷テスト」または「ストレステスト」とも呼ばれます。一般に、ここでの考え方は、システムを限界までプッシュするか、システムが別の部門からの予測を処理できることを確認することです。これらのテストの理論的根拠は、多くの場合、最適化するための多数の構成設定があり、ボトルネックを発見してこれに関する問題に対処するために少しの作業以上を要することがあるということです。ここでのボトルネックは、メモリ、I / O、CPU、またはネットワーク帯域幅であり、システムの応答性が期待どおりにならない可能性があります。

テスト駆動開発は方法論であり、特定の種類のテストを指すのではなく、テストがコードの前に記述されているため、テストは、動作ドメイン、または機能が他の例であるというよりも開発を推進するものです処理する。

継続的インテグレーションは、単体テスト、統合テスト、回帰テストなどの一部のテストを定期的に実行することで、変更がテストに違反した場合にできるだけ早くキャッ​​チされるようにします。


5
+1 ...残念ながら、それでも手動テストが残っています。
スティーブンエバーズ

2
およびStresテスト-同じマスクを同時にすべてのセッションでテストし、連続してテストシナリオをテストします。どこかにUATの一部として含まれています
。btw

1
カバレッジ/ブランチカバレッジテストを見逃していませんか?また、 "Electric Fence" mallocやValgrindのような、ある種のメモリ監視システムの下で実行していますか?
ブルースエディガー

1
@Bruce Ediger:カバレッジはホワイトボックステストの統計であり、テスト自体の方法ではなく、説明するツールはパフォーマンステスト用です。
スティーブンエバーズ

私は「ツール...はパフォーマンステスト用です」で異なる必要があります。一部の言語(CまたはC ++)では、valgrindで多数の単体テストを実行すると、上記の他の種類のテストでは検出できないバグが見つかります。Valgrindは確かにデバッグツールですが、valgrindedプログラムでテストを実行することは非常に必要です。
ブルースエディガー

4

回帰テストは、システムへの新しい変更が、変更の影響を受けるはずのない既存の機能を壊さないことを確認するために実行されます。

受け入れテストは通常​​、顧客/クライアント/ビジネスユーザーによって行われます。多くの場合、他の形式のテストよりも高レベルであり、変更を要求したユーザーが満足するように実行されます。生産システム。


1
そして、彼らが彼らが得たいと思っていたものを手に入れて、今あなたに支払うことができるようにするために、最も重要なことは何ですか。
-Mchl
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.