1. ホーム
  2. スクリプト・コラム
  3. その他

ソフトウェアテスト手法の概要

2022-01-09 22:56:42

ソフトウェアテスト手法の概要

ソフトウェアのテスト方法はたくさんありすぎて、覚えるのが混乱します。私はあなたにソフトウェアテスト業界の一般的なビューを与えるために、いくつかの本やオンラインソースを取って、一般的なソフトウェアテストの方法をリストアップしてみました。

テスト設計手法からの分類

<テーブル

テスト名

テスト内容

ブラックボックス化されたブラックボックステスト

ソフトウェアシステムを、システムの内部構造や知識を理解したり利用したりする方法がない、ブラックボックスと考える。内部構造ではなく、ソフトウェアの動作からテストを設計してください。

ホワイトボックスホワイトボックステスト

設計者はソフトウェアシステムの内部構造を見ることができ、ソフトウェアの内部知識を利用して、テストデータや手法の選択を導くことができます。

グレーのボックス。

黒枠と白枠の間

まとめますと。実際には、システムについて知っていることが多ければ多いほど良いのです。今日、ほとんどのテスターはブラックボックステストを行っており、ホワイトボックステストを行っているテスターは非常に少ない。これは、ホワイトボックステストがソフトウェアテスターにとって非常に厳しいものであり、多くのプログラミング経験を必要とするためです。.NETのプログラムのホワイトボックステストは、あなたが読んで理解することができる必要があります。JAVAプログラムのテスト、あなたはJAVAのコードを読むことができる必要があります。あなたはそれを読むことができれば、あなたはまだテストを行うことができます

テストが手動か自動かによる分類

<テーブル

テスト名

テスト内容

マニュアルテスト マニュアルテスト

テスターがマウスを使って手動でテストする(テストGUI)

自動化テスト

プログラムでプログラムをテストする(APIのテスト)

 プロジェクトにおいて、ソフトウェアの品質を確保する方法として、手動テストと自動テストは同じように重要です。今日、ほとんどのプロジェクトチームは、手動テストと自動テストを組み合わせています。多くのテストは自動化できず、また、多くの複雑なビジネスロジックは自動化が困難であるため、自動テストは手動テストに取って代わることができません。

ソフトウェアテスターの個人的な成長にとって、自動テストはテスターにとって挑戦であり、開発について多くのことを学ぶ必要がある(それは無限である)方向性である。長い目で見れば、自動化テストはますます望ましいものになるでしょう。

手動テストの最大の欠点は、ローテクで、面倒で、無駄が多いということです。

一般的に、手動テストはビジネスロジックをテストするのに適しており、自動テストは基本的なアーキテクチャをテストするのに適しています。

 テストするアプリケーションがテスト可能であれば、それを自動化することが重要です。自動化できる場合は、以下のようなケースです。

1. ストアドプロシージャをテストする。  例えば、C#を使用してストアドプロシージャをテストする場合

2. Webサービスのテスト。例:SoupUIツール、またはC#,Javaを使用してWebサービスをテストする。

3.MVC、MVPアーキテクチャ、WPFアプリケーションなど、インターフェースとビジネスロジックを分離したシステム。これらのプログラムのAPIをテストするために、テストスクリプトを使用することができます。

テストの目的による分類

 機能テスト

テストは、小規模から大規模、内部から外部まで、プログラム開発者(ユニットテスト)からテスター、一般ユーザーのアルファ/ベータテストまで幅広く対応しています

<テーブル

テスト名

テスト内容

ユニットテスト 单元测试

最低の関数/パラメータでプログラムの正確さを検証する、例えば関数の正しさをテストする(開発者が行う)。

機能テスト 機能テスト

モジュールの機能性を確認する(テスターが行う)

統合テスト

依存関係がある複数のモジュールの機能を検証する(テスターが行う)

シナリオテスト

複数のモジュールでユーザーシナリオを完結できることを確認する(テスターが行う)

システムテスト システムテスト

システム全体の機能テスト用(テスターが行う)。

αテスト

実際のユーザー環境でソフトウェアを徹底的にテストする(テスターが行う)

ベータテスト

実際のユーザーによる実際のユーザー環境でのテスト、パブリックテストとも呼ばれる(エンドユーザーが行う)。

 非機能テスト

ソフトウェアには、基本的な機能のほかに、サービス品質要件と呼ばれる非機能的な機能が数多く存在します。ソフトウェアの機能がなければ、これらの機能は表現できないので、ソフトウェア開発の適切な段階、つまり基本機能が完成した後に、これらのテストを実施します。

<テーブル

テスト名

テスト内容

ストレステスト ストレステスト

負荷設計を超えた場合でも、ソフトウェアがクラッシュすることなく正しい結果を返すことを確認する。

負荷テスト

負荷がかかった状態でソフトウェアが動作するかどうかを確認するためのテスト

パフォーマンステスト パフォーマンステスト

ソフトウェアの性能を確認し、満足のいくサービス品質を提供できるかどうかをテストします

アクセシビリティテスト

ソフトウェアアクセシビリティテスト - ソフトウェアが障害を持つユーザーに適切なアクセシビリティを提供するかどうかをテストします。

ローカライゼーション/グローバリゼーション

ローカライゼーション/グローバリゼーションのテスト

互換性テスト

互換性テスト

コンフィギュレーションテスト

構成テスト - さまざまな構成でソフトウェアが正しく動作することをテストします。

ユーザビリティテスト

ユーザビリティテスト - ソフトウェアが動作するかどうかをテストする

セキュリティテスト

ソフトウェアセキュリティテスト

 パフォーマンステスト

パフォーマンステストでは、テスターはQTP、LoadRunner、Jmeterなどのパフォーマンステストツールに習熟する必要があります。また、Visual Studioにもパフォーマンステスト用のツールが多数用意されています。テスターには、低レベルのプロトコルをよく理解し、スクリプトを書くことが要求されます。
パフォーマンステストは非常に技術的で将来性があり、ソフトウェアテスターのキャリアパスでもある。

セキュリティテスト

セキュリティテストは非常に幅広く、非常に難しいものです。私は、XSS(クロスサイトスクリプティング攻撃)とSQLインジェクション攻撃しか受けたことがありません。
セキュリティテストはとても技術的なもので、ソフトウェアテスターのキャリアパスだと思います。

テストのタイミングと役割による

ソフトウェア開発において、多くのテストは、ソフトウェア開発プロセスが円滑に進んでいるかどうかを教えてくれるビーコンのような役割を担っています。

<テーブル

テスト名

テスト内容

スモークテスト

Smoke" - テストに合格しないと、次のステップに進めません。

ビルドベリフィケーションテスト(BVT)

ビルドが基本テストに合格していることを確認します。

受入テスト

受入テスト、特徴/機能を完全に評価するために行われるテスト

BVTテストはスモークテストと呼ばれる、Build生成後に自動的に実行されるテストスクリプトで、Buildの基本機能を確認するためのものです。BVTテストが失敗した場合、開発者はすぐに修正し、Buildを再生成する必要がある

テスト測定戦略別に分類されています。

<テーブル

テスト名

テスト内容

リグレッションテスト リグレッションテスト

新しいバージョンでは、前のテストケースを再実行し、新しいバージョンが既知のバージョンと比較して劣化(リグレッション)しているかどうかを確認します。

アドホックテスト 探索的テスト

ランダムで探索的なテストです。

サニティテスト

一部のテストケースのみ実行する必要があるラフテスト

Regression Test 回帰テスト。 

ソフトウェアテスターにとっては、テストを繰り返すことがすべてです。ですから、回帰テストは理想的には自動化されるべきです。そうしないと、テスターは何度もテストを繰り返さなければならなくなります。 

1. 開発者が小さな変更を行い、テスターがリグレッションテストを行う必要がある。既存の機能が壊れていないことを確認する

2. バグフィックスには、新しいコードがフィックスを修正し、既存の機能が壊れていないことを確認するための回帰テストも必要です。

3. プロジェクトの後半では、すべての機能が良好であることを確認するために、完全な回帰テストが必要です

アドホックテスト 探索的なテスト。

私は普段、テストケースを残してランダムにテストをするのが好きです。自分ひとりで、自分の好きなようにできるんです。GUIをテストする場合、アドホックなら多くのバグを見つけることができます。

以上、ソフトウェアテストの整理方法をいくつか紹介しましたが、今後も関連情報を整理していきますので、よろしくお願いします!