基本的な概念に移りましょう。
ソフトウェアテストは、特定の方法で選択された有限のテストセットで実行される、プログラムの動作の実際の結果と期待される結果の適合性の検証です。
テストの目的は、ソフトウェアが要件を満たしていることを確認し、ソフトウェアの品質の信頼性を確保し、ソフトウェアの明らかなエラーを検索することです。エラーは、プログラムのユーザーが見つける前に特定する必要があります。
ソフトウェアテストが必要なのはなぜですか？
- テストプロセスは、ソフトウェアが必要に応じて実行されることを確認します。
- これにより、開発フェーズの早い段階で問題を特定することにより、コーディングサイクルが短縮されます。開発フェーズの早い段階で問題を検出することで、リソースの正しい使用が保証され、コストの増加が防止されます。
- , .
- , , , .
- 1 — (Testing shows presence of defects). , , , . , , .
- 2 — (Exhaustive testing is impossible). , . , .
- 3 — (Early testing). , , .
- 4 — (Defects clustering). – . . , .
- 5 — (Pesticide paradox). , . « », , , , , .
- 6 — (Testing is concept depending). - . , , , , .
- 原則7-エラーがないことについての誤解（エラーがないことの誤謬を終わらせる）。テスト中に欠陥が見つからなかったからといって、製品がリリースの準備ができているとは限りません。システムはユーザーフレンドリーであり、ユーザーの期待とニーズを満たす必要があります。
品質保証（QA）と 品質管理（QC） -これらの用語は交換可能な用語に似ていますが、実際にはプロセスにいくつかの類似点がありますが、品質保証と品質管理には依然として違いがあります。
QC（品質管理）-製品の品質管理-テスト結果の分析とリリースされた製品の新しいバージョンの品質。
品質管理タスクには次のものが含まれます。
- ソフトウェアのリリース準備をチェックする。
- このプロジェクトの要件と品質への準拠の検証。
QA（品質保証）-製品の品質保証-開発プロセスを変更および改善する機会を模索し、チーム内のコミュニケーションを改善します。テストは品質保証の1つの側面にすぎません。
品質保証の目的は次のとおりです。
- 技術的特性とソフトウェア要件の検証。
- リスクアセスメント;
- 製品の品質を向上させるためのタスクのスケジューリング。
- ドキュメント、テスト環境、およびデータの準備。
- テスト;
- テスト結果の分析、およびレポートやその他のドキュメントの作成。
検証と妥当性確認は、テストと品質保証のプロセスに密接に関連する2つの概念です。残念ながら、それらの間の違いは非常に重要ですが、それらはしばしば混乱します。
検証とは、システムを評価して、現在の開発フェーズの結果が最初に策定された条件を満たしているかどうかを確認するプロセスです。
検証とは、開発されたソフトウェアがユーザーの期待とニーズ、システムに対するユーザーの要件に準拠しているかどうかを判断することです。
: 310, , «», . , , «». , . , , , . «» — , «» — . , .
ソフトウェア開発プロジェクトで使用されるドキュメントは、大きく2つのグループに分けることができます。
- プロジェクトのドキュメント-プロジェクト全体に関連するすべてのものが含まれます。
- 製品ドキュメントは設計ドキュメントの一部であり、個別に割り当てられ、開発されたアプリケーションまたはシステムに直接関連しています。
テスト段階：
- 製品分析
- 要件の処理
- テスト戦略の開発と品質管理手順の計画
- テストドキュメントの作成
- プロトタイプテスト
- 基本的なテスト
- 安定
- 搾取
ソフトウェア開発段階-プログラムが幅広いユーザーに利用可能になる前にソフトウェア開発チームが通過する段階。
ソフトウェア製品は、次の段階を経ます。
- プロジェクト要件の分析。
- 設計;
- 実装;
- 製品テスト;
- 実装とサポート。
要件
要件は、実装する必要があるものの仕様（説明）です。
要件は、ソリューションの技術的な側面を詳しく説明せずに、何を実装する必要があるかを説明します。
要件の要件：
- 正確性-各要件は、必要な機能を正確に記述している必要があります。
- 検証可能性-要件は、それが満たされているかどうかを明確にチェックする方法があるように策定する必要があります。
- 完全性-各要件には、開発者が機能を実装するために必要なすべての情報が含まれている必要があります。
- 明確な-要件は、非自明な略語や漠然とした文言せずに説明して書かれているものの唯一の明確な解釈を可能にしています。
- — .
- — ( ). .
- — .
- — .
- — , .
欠陥（バグ） -実際の結果が予想される結果から逸脱している。
バグレポートは、欠陥の発見につながった状況を説明し、理由と期待される結果を示すドキュメントです。
欠陥レポートの属性：
- 一意の識別子（ID）-システムによって自動的に割り当てられます。
- トピック（簡単な説明、要約）-「何？どこ？いつ？"
- 説明-欠陥の本質のより広範な説明（オプションで指定）。
- 再現する手順-欠陥の特定につながったアクションの順次説明。特定の入力値を示して、できるだけ詳細に説明する必要があります。
- (Actual result) — , , .
- (Expected result) — , , .
- (Attachments) — , -.
- (, Severity) — .
- (, Priority) — .
- (Status) — . - .
- (environment) – , .
Severity vs Priority
重大度は、欠陥の存在によってプロジェクトに生じた損傷の程度を示します。重大度はテスターによって公開されます。
欠陥の重大度の等級付け：
-
機能の重要な部分のブロッキング（S1-ブロッカー）テストはまったく利用できません。アプリケーションを動作不能にするブロッキングエラー。その結果、テスト対象のシステムまたはその主要な機能をさらに操作できなくなります。 - (S2 – Critical)
, -, , , , - , workaround ( / ), . - (S3 – Major)
- /-, , workaround, - . visibility – , , , . - (S4 – Minor)
GUI, , . , . - 些細な（S5-些細な）
ほとんどの場合、GUIの欠陥-テキストのタイプミス、フォントと色合いの不一致など、またはビジネスロジックに関係のない再現性の低いエラー、サードパーティのライブラリまたはサービスの問題、製品の全体的な品質に影響を与えない問題。
優先度は、欠陥を修正する速度を示します。優先度は、マネージャー、チームリーダー、または顧客によって設定されます。欠陥の優先度のグラデーション
（優先度）：
- P1高
エラーはできるだけ早く修正する必要があります。その存在はプロジェクトにとって重要です。 - P2中
エラーを修正する必要があります。エラーの存在は重要ではありませんが、解決する必要があります。 - P3 (Low)
, .
:
- (epic) — , .
- (story) — (), 1 .
- (task) — , .
- - (sub-task) — / , .
- (bug) — , .
- (Development Env) – , , , Unit-. .
- (Test Env) – . . , , . .
- (Integration Env) – , . end-to-end , , . , . – , .
- (Preview, Preprod Env) – , : , - , . , «». end-to-end , / (User Acceptance Testing (UAT)), L3 L2 DryRun ( ). L3 .
- (Production Env) – , . L2 , , . L3.
- Pre-Alpha: . . . .
- Alpha: . — . - . . .
- Beta: . , .
- リリース候補（RC）：ベータテストのフィードバックに基づいて、ソフトウェアを変更し、バグ修正をテストしたいと考えています。この時点では、機能に大幅な変更を加えるのではなく、バグをチェックするだけです。RCも一般に公開される可能性があります。
- リリース：すべてが機能し、ソフトウェアが一般にリリースされます。
ソフトウェアテストの主な種類
テストのタイプは、特定の目標に基づいて、システムまたはそのパーツの指定された特性をテストすることを目的とした一連のアクティビティです。
- 実行するコードを実行することによる分類：
- — . , . «». — .
- — . , / . — , . , , .
- :
- — , , // .
- — , White Box Black Box . , .
- — , – , .
- :
- — - ( , subprograms, subroutines, ) . , .
- — , ( , ).
- — , , .
- — , - .
- :
- .
- .
-
- — , .
- — , .
- :
- (smoke test) — , , .
- (critical path) — , .
- (extended) — .
- :
- - — . - .
- - — . , .
- :
- (functional testing) — ( ).
- (non-functional testing) — , , , « ».
- (performance testing) — , , .
- (load testing) — , , .
- (scalability testing) — .
- (volume testing) — , .
- (stress testing) — , .
- (installation testing) — , , .
- (GUI/UI testing) — .
- (usability testing) — , .
- (localization testing) — (, ).
- (security testing) — , .
- (reliability testing) — .
- 回帰テスト-アプリケーションコードに変更を加えた後、以前にテストした機能をテストして、これらの変更によって、変更されていない領域にエラーが発生しないことを確認します。
- 再テスト/確認テスト-最後の実行中にエラーを検出したテストスクリプトを実行して、これらのエラーの修正が成功したことを確認するテスト。
テスト設計は、ソフトウェアテストの段階であり、テストケース（テストケース）が設計および作成されます。
テスト設計手法：
- (equivalence partitioning) — , , ( ) .
- (boundary value testing) — () .
- (pairwise testing) — , -.
- (State-Transition Testing) — .
- (Decision Table Testing) — , , .
- (Exploratory Testing) — , -: .
- (Domain Analysis Testing) — , .
- (Use Case Testing) — Use Case ( — ).
ホワイトボックステストは、システムの内部構造/デバイス/実装がテスターに知られていることを前提としたソフトウェアテスト方法です。
ISTQBによると、ホワイトボックステストは次のとおりです。-
コンポーネントまたはシステムの内部構造の分析に基づくテスト。
-ホワイトボックス手法に基づくテスト設計-システムまたはコンポーネントの内部構造の分析に基づいてテストケースを作成または選択するための手順。
なぜホワイトボックス？テスターのためにテスト中のプログラムは透明な箱であり、その中身は完全に見えます。
グレーボックステスト-ホワイトボックスとブラックボックスのアプローチの組み合わせを想定したソフトウェアテスト方法。つまり、プログラムの内部構造を部分的にしか知りません。
ブラックボックステスト（仕様ベースのテストまたは動作テストとも呼ばれます）は、テスト対象のシステムの外部インターフェイスのみに依存するテスト手法です。
ISTQBによると、ブラックボックステストは次のとおりです。-
機能的および非機能的の両方のテスト。コンポーネントまたはシステムの内部構造の知識は含まれません。
-ブラックボックス手法に基づくテスト設計-内部構造を知らなくても、コンポーネントまたはシステムの機能仕様または非機能仕様の分析に基づいてテストケースを作成または選択する手順。
テストドキュメント
テスト計画は、施設の説明、戦略、スケジュール、テストの開始と終了の基準から、運用プロセスに必要な機器、特別な知識、リスク評価まで、テストの全範囲を説明するドキュメントです。それらの解決のためのオプションで....
テスト計画は、次の質問に答える必要があります。
- 何をテストする必要がありますか？
- 何をテストしますか？
- どのようにテストしますか？
- いつテストしますか？
- テスト開始基準。
- テスト終了基準。
テスト計画の主なポイント：
IEEE 829標準には、テスト計画が構成する必要のあるポイントがリストされています。a
）テスト計画識別子。
b）はじめに;
c）テスト項目;
d）テストされる機能;
e）テストされない機能;
f）アプローチ;
g）アイテムの合格/不合格基準。
h）一時停止基準と再開要件。
i）成果物をテストします。
j）タスクのテスト。
k）環境ニーズ;
l）責任;
m）人員配置とトレーニングのニーズ。
n）スケジュール;
o）リスクと不測の事態。
p）承認。
チェックリストは、何をテストする必要があるかを説明するドキュメントです。チェックリストは、完全に異なる詳細レベルにすることができます。
ほとんどの場合、チェックリストにはアクションのみが含まれ、期待される結果は含まれていません。チェックリストはあまり形式化されていません。
テストケースは、テスト対象の関数またはその一部の実装をテストするために必要な一連の手順、特定の条件、およびパラメーターを説明するアーティファクトです。
テストケースの属性：
- 前提条件-システムを基本的なチェックの実行に適した状態にするアクションのリスト。または、条件のリスト。その充足は、システムがメインテストの実行に適した状態にあることを示します。
- 手順-結果を取得するために、システムをある状態から別の状態に転送するアクションのリスト。これに基づいて、実装が要件を満たしていると結論付けることができます。
- 期待される結果-彼らが実際に何を得る必要があるか。
概要
定義を覚えるのではなく、理解するようにしてください。また、ご不明な点がございましたら、@ qa_chilloutテレグラムチャネルでいつでもお問い合わせください 。