ソフトウェアのメモリ、最大混乱の広い範囲をテストし、ソフトウェアのテスト方法が分類されている場合は、より明確になります。我々は、ソフトウェアテスト業界の一般的な見解を持っているように私は、いくつかの書籍やオンライン情報、記載されている一般的に使用されるソフトウェアのテスト方法を参照してください。
テスト設計方法から分類
| テスト名 |
テスト内容 |
| ブラックボックスブラックボックス |
「ブラックボックス」などのソフトウェアシステムは、または内部構造やシステムを利用するための知識を理解することはできません。ソフトウェアの動作からではなく、テストの内部構造を設計するために開始します。 |
| ホワイトボックスホワイトボックス |
設計者は、ソフトウェアシステムの内部構造を見ることができ、内部知識ソフトウェアの使用は、試験データとメソッドの選択を案内します。 |
| 灰色のボックス。グレーボックステスト |
ブラックボックスとホワイトボックスの間 |
概要：実用的な作業、システムをより良く理解します。ほとんどのテスターは、ブラックボックステストを行っている、ホワイトボックステストを行うことがほとんどありません。ソフトウェアテスターのためのホワイトボックステストの要件が非常に高いですので、我々は、プログラミング経験の多くを持っている必要があります。.NETプログラムあなたはホワイトボックステストしたいですが、.NETのコードを理解することができます。JAVAプログラムのテストを行うには、Javaコードを理解できるようにする必要があります。あなたが理解できれば、あなたは試験に何をしますか
テストから手動または自動分類であります
| テスト名 |
テスト内容 |
| 手動テスト手動テスト |
マウス（テスト用GUI）をテストするためのマニュアルのテスター |
| オートメーション自動テスト |
プログラムのテストプログラム（テストAPI） |
プロジェクトでは、手動および自動テストが等しく重要である、それはソフトウェアの品質アプローチの保護です。現時点では、プロジェクトチームのほとんどを一緒に手動および自動テストがあります。多くの、多くの複雑なビジネスロジックは、自動化が困難であるため、自動化されたテストを行うことができないので、自動テストの手動テストは交換することはできません。
ソフトウェアテスターの個人的な開発のために、自動化されないテストは挑戦ですが、また、テストは、開発知識の多くを学ぶ必要があるスタッフの開発の方向性のテスト、（知識の開発は本当に長い学習ああです）。長期的には、自動テストは間違いなく、より求められています。
ただ、すぐに働く人々のためのより適切な手動テストは、手動テストの最大の欠点は、ローテク、退屈な、簡単なバスケットです。
全体的に、手動テストは、テストのビジネスロジックで勝利し、テスト自動化テストは、基礎となるアーキテクチャで勝利します。
プログラムがテストされている場合は、テスト容易性が優れている、自動テストを行う必要があります。自動化を作ってみるん自動化され、次のシナリオでは、自動化を行うことが可能です
1.試験ストアドプロシージャ。例えば、C＃がテストするストアドプロシージャ
など2.テストのWeb servies：使用SoupUIツール、またはC＃、Java（登録商標）は、Web serviesをテストします。
3.例えばシステムのインタフェースとビジネスロジック、MVC、MVPアーキテクチャ、またはWPFアプリケーション。テストスクリプトは、これらのAPIプログラムをテストするために使用することができます。
分類テストの目的のために
機能テスト
（ユニットテスト）がテスタにプログラム開発者から、内側から、小から大までの範囲を試験し、一般ユーザアルファ/ベータテスト
| テスト名 |
テスト内容 |
| ユニットテスト ユニットテスト |
機能最低で/ （開発者が行う）、このような機能の正しさをテストするようプログラムパラメータの正確性を検証します |
| 機能テスト 機能テスト |
機能検証モジュール（テスター行います） |
| 統合テスト 統合テスト |
互いのいくつかの機能検証モジュールの依存関係 （テスター行います） |
| シナリオテスト シナリオテスト |
いくつかのモジュールは、ユーザのシナリオを検証するために完了することができます （テスター行います） |
| システムテスト システムテスト |
テストのためのシステム全体の機能 （テスター行います） |
| アルファテスト |
ソフトウェア人材をテストし、実際のユーザー環境でソフトウェアの包括的なテストを実施する （テスターが行います） |
| ベータテスト |
また、ベータ版として知られている実際のユーザー環境でのユーザーの実際のテスト、（エンドユーザーが行います） |
非機能テスト
ソフトウェアの基本的な機能に加えて、「と呼ばれる機能、外部のプロパティが多いサービス要件の品質で、」サービス品質要件は。いいえソフトウェア機能は、これらの機能は、それを表示することができないではないので、我々はソフトウェア開発の適切な段階でなければならない- 基本的な機能の完了後にこれらのテストを行います。
| テスト名 |
テスト内容 |
| ストレステストストレステスト |
検証ソフトウェアは、まだクラッシュし、設計荷重を超過した場合の正しい結果を返すことはできません |
| 負荷テスト負荷テスト |
ソフトウェアテストは負荷の下で働くことができます |
| パフォーマンステストパフォーマンステスト |
パフォーマンステストソフトウェア、満足のいくサービス品質を提供するかどうか |
| アクセシビリティテスト |
ソフトウェアアクセシビリティテスト- ソフトウェアは無効なユーザーへの適切なアクセスを提供するかどうかをテスト |
| ローカリゼーション/グローバリゼーション |
ローカリゼーション/ グローバリゼーションのテスト |
| 互換性テスト |
互換性テスト |
| 設定のテスト |
コンフィギュレーション・テスト- テストソフトウェアは、様々な構成で作業することができます |
| ユーザビリティテスト |
ユーザビリティテスト - テストソフトウェアを使用するのは簡単です |
| セキュリティテスト |
ソフトウェアのセキュリティテスト |
パフォーマンステスト
性能テストのテストは、QTP、LoadRunnerは、JMeterのように熟練した人材のパフォーマンステストツールが必要です。Visual Studioは、低レベルのプロトコルを必要とテスターのパフォーマンステストツールの多くを提供して非常に理解とスクリプトです
パフォーマンステストは非常に技術的な内容、有望である、キャリア開発のソフトウェアテスターです。
セキュリティテスト
コンテンツセキュリティテストは、非常に難しいああ非常に広いです。XSS（クロスサイトスクリプティング）とSQLインジェクション攻撃と私の唯一の接触。
セキュリティテストは非常に技術的な内容ですが、私はキャリア開発は、ソフトウェアテスターであることを考えます
タイミングと分類テストの役割により、
ソフトウェア開発プロセスでは、多くのテストが「ビーコン」役として働き、彼らはソフトウェア開発プロセスが滑らかであることを私たちに語りました。
| テスト名 |
テスト内容 |
| スモークテスト |
「煙」- テストに合格していない場合、それは次のステップすることはできません |
| ビルドの検証テスト（BVT） |
基本的なテストを構築するかどうかを確認します。 |
| 受け入れテスト |
受け入れテストは、完全に特定の機能を評価するために/ 特徴は、テストを行います |
BVTテストは、スモークテストです後は良いビルドの世代を指し、自動化されたテストスクリプトは、ビルドの基本機能をチェックするために、自動的に実行します。BVTテストが失敗した場合、それはすぐに変更する開発者を必要とし、ビルドを再構築
テスト戦略の分類により測定しました。
| テスト名 |
テスト内容 |
| 回帰テスト 回帰テスト |
新しいバージョンのために、分解の新しいバージョンとに比べ既知バージョンがあるかどうかを確認するために、以前のテストケースを再実行 （回帰） |
| アドホックテストの探索的テスト |
無作為化、探索的テスト。 |
| 正気テスト |
ラフテスト、テストケースの実装の一部のみ |
回帰テスト 回帰テスト：
ソフトウェアテスターそうテスターは、何度も何度もテストを繰り返します、テスト、その最高の自動化された回帰テストを繰り返すことです
1.開発者は、いくつかの小さな変更を行い、我々は、回帰テストを行うためにスタッフをテストする必要があります。確認し、既存の機能が破壊されていません
2.バグ修正の回帰テストはまた、既存の機能が破壊されていないことを確認し、新しいコードの修正は、修正することを確認する必要があり
3.プロジェクトの後半、我々はすべての機能が良好であることを保証するために、完全な回帰テストを行う必要があります
アドホックテスト探索的テスト：
私は通常、ランダムなテストをしたい、とテストケースを脇に置きます。自分のアイデアに基づき、ほんの少し。テストGUI場合は、アドホックは、バグの多くを見つけることができます。
テスト設計方法から分類
| テスト名 |
テスト内容 |
| ブラックボックスブラックボックス |
「ブラックボックス」などのソフトウェアシステムは、または内部構造やシステムを利用するための知識を理解することはできません。ソフトウェアの動作からではなく、テストの内部構造を設計するために開始します。 |
| ホワイトボックスホワイトボックス |
設計者は、ソフトウェアシステムの内部構造を見ることができ、内部知識ソフトウェアの使用は、試験データとメソッドの選択を案内します。 |
| 灰色のボックス。グレーボックステスト |
ブラックボックスとホワイトボックスの間 |
概要：実用的な作業、システムをより良く理解します。ほとんどのテスターは、ブラックボックステストを行っている、ホワイトボックステストを行うことがほとんどありません。ソフトウェアテスターのためのホワイトボックステストの要件が非常に高いですので、我々は、プログラミング経験の多くを持っている必要があります。.NETプログラムあなたはホワイトボックステストしたいですが、.NETのコードを理解することができます。JAVAプログラムのテストを行うには、Javaコードを理解できるようにする必要があります。あなたが理解できれば、あなたは試験に何をしますか
テストから手動または自動分類であります
| テスト名 |
テスト内容 |
| 手動テスト手動テスト |
マウス（テスト用GUI）をテストするためのマニュアルのテスター |
| オートメーション自動テスト |
プログラムのテストプログラム（テストAPI） |
プロジェクトでは、手動および自動テストが等しく重要である、それはソフトウェアの品質アプローチの保護です。現時点では、プロジェクトチームのほとんどを一緒に手動および自動テストがあります。多くの、多くの複雑なビジネスロジックは、自動化が困難であるため、自動化されたテストを行うことができないので、自動テストの手動テストは交換することはできません。
ソフトウェアテスターの個人的な開発のために、自動化されないテストは挑戦ですが、また、テストは、開発知識の多くを学ぶ必要があるスタッフの開発の方向性のテスト、（知識の開発は本当に長い学習ああです）。長期的には、自動テストは間違いなく、より求められています。
ただ、すぐに働く人々のためのより適切な手動テストは、手動テストの最大の欠点は、ローテク、退屈な、簡単なバスケットです。
全体的に、手動テストは、テストのビジネスロジックで勝利し、テスト自動化テストは、基礎となるアーキテクチャで勝利します。
プログラムがテストされている場合は、テスト容易性が優れている、自動テストを行う必要があります。自動化を作ってみるん自動化され、次のシナリオでは、自動化を行うことが可能です
1.試験ストアドプロシージャ。例えば、C＃がテストするストアドプロシージャ
など2.テストのWeb servies：使用SoupUIツール、またはC＃、Java（登録商標）は、Web serviesをテストします。
3. 界面和业务逻辑分离的系统，比如，MVC，MVP架构， 或者WPF 程序。 可以用测试脚本去测试这些程序的API。
从测试的目的分类
功能测试
测试的范围从小到大，从内到外， 从程序开发人员（单元测试）到测试人员，到一般用户Alpha/Beta测试
| 测试名称 |
测试内容 |
| Unit Test 单元测试 |
在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的) |
| Functional Test 功能测试 |
验证模块的功能 （测试人员做的） |
| Integration Test 集成测试 |
验证几个互相有依赖关系的模块的功能 （测试人员做的） |
| Scenario Test 场景测试 |
验证几个模块是否能完成一个用户场景 （测试人员做的） |
| System Test 系统测试 |
对于整个系统功能的测试 （测试人员做的） |
| Alpha 测试 |
软件测试人员在真实用户环境中对软件进行全面的测试 （测试人员做的） |
| Beta 测试 |
真实的用户在真实的用户环境中进行的测试, 也叫公测 （最终用户做的） |
非功能测试
一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“Quality of Service requirement”服务质量需求。没有软件的功能，这些特性都无从表现出来，因此，我们要在软件开发的适当阶段-基本功能完成后做这些测试。
| 测试名称 |
测试内容 |
| Stress test 压力测试 |
验证软件在超过负载设计的情况下仍能返回正确的结果，没有崩溃 |
| Load test 负载测试 |
测试软件在负载情况下能否正常工作 |
| Performance test性能测试 |
测试软件的效能，是否提供满意的服务质量 |
| Accessibility test |
软件辅助功能测试-测试软件是否向残疾用户提供足够的辅助功能 |
| Localization/Globalization |
本地化/全球化测试 |
| Compatibility Test |
兼容性测试 |
| Configuration Test |
配置测试-测试软件在各种配置下能否正常工作 |
| Usability Test |
可用性测试 –测试软件是否好用 |
| Security Test |
软件安全性测试 |
性能测试
性能测试要求测试人员熟练性能测试工具，比如QTP, LoadRunner, Jmeter。 Visual Studio也提供了很多性能测试的工具. 要求测试人员对低层协议非常理解和编写脚本
性能测试非常有技术含量， 很有发展前途， 是软件测试人员的一个职业发展方向。
安全性测试
安全性测试的内容很广， 非常有难度啊。 我只接触过XSS（跨站脚本攻击）和SQL注入攻击。
安全性测试非常有技术含量， 我认为也是软件测试人员的一个职业发展方向
按测试的时机和作用分类
在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否畅通。
| 测试名称 |
测试内容 |
| Smoke Test |
“冒烟”–如果测试不通过，则不能进行下一步工作 |
| Build Verification Test（BVT） |
验证构建是否通过基本测试。 |
| Acceptance Test |
验收测试，为了全面考核某功能/特性而做的测试 |
BVT测试是一种Smoke Test, 指Build生成好之后，自动运行的自动化测试脚本来检查这个Build的基本功能。 如果BVT测试失败了，需要开发人员马上修改，重新生成Build
按测试测策略分类。
| 测试名称 |
测试内容 |
| Regression Test 回归测试 |
对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化 (regression) |
| Ad hoc Test 探索性测试 |
随机进行的，探索性的测试。 |
| Sanity Test |
粗略的测试， 只需要执行部分的测试用例 |
Regression Test 回归测试：
对软件测试人员来说就是重复测试，所以回归测试最好是自动化的， 否则测试人员就要一遍又一遍地重复测试，
1. 开发人员做些小改动，就需要测试人员做回归测试。确保现有的功能没有被破坏
2. Bug Fix 也需要回归测试，确保新的代码修复了Fix, 也确保现有的功能没有被破坏
3. 项目后期，需要做一个完整回归测试， 确保所有的功能都是好的
Ad hoc Test 探索性测试：
平常我最喜欢做随机测试了， 抛开test case. 自己按照自己的思路，随便点点。 如果测试GUI，Ad hoc能发现大量的bug.