また、注意をそらして体系的に検討する場合、テスターの役割は実際にはすべての人にあります。 プロジェクトを人として見ると、役割
- プロジェクトマネージャーは脊椎および自律神経系です
- プログラマーはスケルトンと運動性です
- アナリストは感覚器官です
- テスターは良心です
品質保証はテストと同義と見なされることがよくありますが、実際には、エラーを見つけて修正するのではなく、エラーを防ぐ方法です。 この意味での品質は、作られた製品の特徴です。
正式に言えば、テスターは、プログラムのコードやインターフェイスだけでなく、 技術的なタスク、プロジェクト計画、分析でも一貫性と明確さを確認する必要があります。 ソフトウェア開発の一般的な流れにおける独立した分野としてのテストは、聴衆（クライアント）、品質、および開発時間がより重要になった90年代初頭に登場しました。
ソフトウェアテストの重要性は、重要なシステムでは特に重要です。 たとえば、 Therac放射線治療装置（1985）は、コードと検証でユニットの状態を検証できないため、6人に致命的な放射線を照射しました。 あるいは、1999年のローバーは、開発チーム間の統一された測定システムの思考不足により、1億2500万ドルの損失をもたらしました。 そしてエストニアでさえ、不十分な負荷テストによる電子選挙に問題があった。
テストの基本原則は、小さなISTQB文書および「ソフトウェアテストの基礎」に具体化されています。
テスターの専門分野全体の「魅力」は、原則として、プログラミングに大きな知識を必要とせず、Web構築から遠く離れた人がこの役割に挑戦できることです。
組織プロセス
プロジェクトに関する会社の作業の一部としてのテストは、プロジェクトの最後にのみテスターの下で行われるウォーターフォールアプローチ、または各反復で完成バージョンが展開されるアジャイル手法に従って実行できます。
テストの反復は、次の項目で構成されます
- 計画中。 目標、ツール、時間、順序が決定されます。 最も技術的に難しい部分は、特に技術的なタスク、ドキュメント、および責任のあるプロジェクトマネージャーがいない場合に、システムがどのように機能するかを理解して覚えることです（以下の探索的テストを参照）
したがって、テスターには少なくとも内部がありますが、分析は...
- 条件
- インタラクションストーリー（ケース）
- 仕様、アーキテクチャ、およびその他のドキュメント（存在する場合）へのリンクを含むドキュメント（基本）の形式の実施形態
- チェック。 アクセス不能および理解不能の場合-いつ、誰と連絡を取り、タスクが忘れられないこと。
- テストケースの優先順位付け（通常、1ケース= 1要件= 1 Webページ）。 最も重要なシナリオは何ですか？ 開発で最も危険なのはどれですか？
- 共通モジュールごとにテストをキット（スイート）にグループ化する
- 検証と要件との比較（実際にエラーを検索）
- レポートの作成（バグと全体像の両方-カバレッジ率）
- 変更部分の再確認（確認、再テスト）または未変更部分への影響（ 回帰テスト ）
- 完了。 テストのアーカイブ、学習した教訓の保存。
テストレベル
テストには、独自のレベル、階層、およびクラスがあります（hello RPGプレイヤー！）。 アプリケーションのさまざまな部分（つまり、エリアごと、ページごと）と、このセクションのさまざまなプロパティ（つまり、深さ、品質の程度）の両方を確認できます。 ここでは、サイトの規模に応じて、テストをカテゴリに分類できます...
- モジュラー（ 単体テスト ）。 プログラマーが単体テストでチェックするクラスコードと非常に密接にテストを記述する必要があるという意味での半自動テスト。 TDDに従う必要はありません。少なくとも最も重要な部分（金融取引など）について書くことができます。
- 統合（ 統合テスト ）は、異なるモジュール間の接続を確認します。 システムの一般的な統合の前（モジュールごと）と後（書き込み、書き込み、追加-最終受け入れテストの前にテストします）の両方で行うことができます。 ここでも、コードとプログラマとの緊密な仕事。
- システム-システム全体を調べて、一般的な標準および仕様との不一致を見つけます。 原則として、最終的には、システムの基本的な準備が整った時点です。
- 受け入れテストは通常、プロジェクトの転送中にクライアントと行われ、クライアントと協力する意欲を示します。 この段階で、 アルファバージョン（すべてがまだマシンの開発者にあり、サードパーティのテスターが関与している）とベータバージョン（すべてが既にクライアントにあり、潜在的なクライアントが関与している）が表示されます
テストの種類
今、実際には、本質的にテスト..
- 機能的には、アプリケーションが行うべき質問「 何 」に答えます
- 非機能要件/テストは、質問「 どのように 」に答えます。 非機能には、インターフェースの利便性、信頼性、データセキュリティ、スケーラビリティ、クロスプラットフォーム、さらには経済的実現可能性の特性が含まれます（ISO / IEC 9126を参照）
- 外部（ブラックボックス）/内部（構造、ホワイトボックス）。 構造テストでは、実装時にアプリケーションの内部構造をチェックしますが、コードを理解する必要があります。 「ブラックボックス」アプローチは、ソフトウェアがまだ実装されていないか、正確な操作がわからないという事実に基づいていますが、すべてがどのように機能するかについての仕様があります。 構造（ ホワイトボックス ）アプローチは、アプリケーションをボトムアップでテストし、コードの最大カバレッジ（インターフェイスの入力/出力の組み合わせではなく）に集中します。 通常、ブラックボックスに加えてホワイトボックスアプローチが使用されます（動作方法）。
- 回帰テスト-しかし、この変更により何かが壊れていますか？ 原則として、これは、より大きな自動化のために単体テストに関連付けられるべきものです。
- テストサポート（ メンテナンステスト ）-システムは既に動作しており、更新（展開と移行）するだけです。 最近では、移行も通常自動化されています。
- 動的/静的テスト。 動的とは、対話式で、既製のシステムまたはコードで動作することを意味します。 これは常に必要であり、可能であるとは限りません。 理論的には、ドキュメントをテストしたり、分析の一貫性を確認したり、ログからエラーを見つけたりすることができます。
テスターと自己監視用の「テクニカルタスクライター」は、略語SMARTを常に覚えておく必要があります。これにより、より実践的な人々がそれらを正しく理解できるようになります。
- 特定-要件の正確な説明。クライアント、チャット、データダンプ、単音節文との通信のコピーペーストなし
- 測定可能-数値、時間、確率、ユーザー、場所の測定値。
- 達成可能 - 技術的に達成可能な要件。 技術的にすべてが可能なわけではありません。進歩を先取りすることはできません
- 実現可能 -時間、品質、知識、価格に関する人間が達成可能な要件
- 追跡可能-最初のアイデアと目的への対応 、いくつかの要件の論理的一貫性。
ブラックボックス技術者
アドホック （猿）-特定の戦略なしのランダムテスト
探索的テスト （探索的テスト）-ドキュメントの大部分が欠落している場合の製品の調査
エラーを同等のクラスごとにグループ化します （ 同等のパーティション分割 ）。 最も人気のある手法。 各入力の要件（文字の長さ、可能な値による）がチェックされます。 テストの数を最小化するために、さまざまな入力のクラスを組み合わせて、エラーを最大限にカバーします。
主に整数値用の別の手法があります。 通常、エラーは境界値で発生するため、この手法が呼び出されます（ 境界値分析 ）。 境界付近で2つまたは3つの値が選択されます。 たとえば、ヘッダーの最大長が250文字の場合、249、250、および251の値でどのようにエラーが生成されますか？
動的システムにより近い状態遷移テスト手法があります。 状態は入力と以前の状態に依存します。 状態と遷移はグラフ（ 有限状態マシン ）で記述されます。
アプリケーションのビジネスルールが非常に複雑で、大規模な数学的計算を必要とする場合、意思決定表のテストはそれ自体で思い浮かびます。 テーブルを使用して、一意の組み合わせの数を最小限に抑えます。
シナリオ （ユースケースベース）のテストは 、分析で作成されたシナリオに従って、さまざまな役割、代替フローを考慮して実行されます。
直観的に経験されたテスト （経験ベース）は、すでに理解されているように、時間の経過とともに人に付属し、コードの変更を考慮して、設計、プログラマ、データフローの体系的なエラーを見つけることができます。
ホワイトボックス（構造）テクニック
構造的手法の目的は、可能な限りコードカバレッジをカバーすることです。また、白いボックスはシナリオテクニックへの追加として使用されるため、シナリオまたはより正確には分岐（ステートメント＆決定カバレッジ）の最大カバレッジがあることが論理的です。
数学的にカバー率= 100％* カバーされたユニットの数/すべてのユニットの数。 これは、すべてがテストされることを意味するのではなく、選択されたテストユニット（ カバレッジアイテム ）のみがテストされます。 各ロールのテストユニットは異なって見えます-開発者にとっては、データベーステーブル、コード内の関数、外部コンポーネントへのリクエスト、テスターやアナリストにとってはスクリプト内のアクション、同等クラスです。
テストユニットの上に上がると、 文を見ることができ、それに応じてそれらをカバーできます（ ステートメントカバレッジ ）。 ブラックボックステクニックを使用した適切なテストは、最大60〜75％のオファーをカバーできます。 コードに関しては、これは特定の行です
意思決定カバレッジはすでにより高いレベルであり、すべてのタイプの階層（if-else、switch、メソッド呼び出しなど）が含まれています。 ブラックボックスメソッドは40〜60％をカバーできます。 周期的な複雑さ -二次、指数、および対数の複雑さについてすべてのコンピューター科学者に知られているテストアルゴリズム。
次の範囲のカバレッジには、分岐をたどることができる可能なパスが含まれます。 理論的には、すべてのサイクルを考慮すると、これらのパスは無限に多くなります。
ツール
プログラマーが最もよく知っているツールは、もちろん、バグ/問題追跡システム（ Mantis 、 Bugzilla 、 Trac）です。 いくつかのIDEはそれらと統合できるため、バージョンシステムリポジトリ（SVN / CVS / Git / Mercurial）のコミットアクションは、ブラウザで動作せずにバグを更新できます。
要件の準備、シナリオのグループ化など、より一般的な工業製品があります-HP（Mercury）Quality CenterおよびIBM Rational Quality Manager
自動インターフェイステストは、 Selenium 、 SilkTest 、 HP QuickTest Pro 、QF-Test、 Rational Robot 、 TestComplete 、 Watir 、TestPartnerで最も人気があります。 soapUIのようなもっとエキゾチックなテストがあります。
追加のマシンが必要になるため（たとえば、1台のマシンで300人のユーザー接続をシミュレートする）、負荷テストはもう少し複雑になります。通常、1台のマシンで3000接続を実行することはできません。 ツール：
- 小-Apache ab、 httpperf 、 openload 、 Neoload 、 hammerora
- 大-Apache JMeter 、 IBM Rational Performance Tester 、 HP LoadRunner （Mercury）、 Oracle Application Quality Management （Empirix e-Load）
オリジナル記事