A.進化
♦1960年のトレンド：
♦1990年のトレンド：
♦2000年のトレンド：
動向とテスト機能が変化しています。今の技術やプロセスにもっと注意を払うようにテスターが必要です。今テストがエラーに限定されるものではなく発見され、より広い範囲、プロジェクトの最初からさえ確定していない必要があります。テストが標準化されているので。ソフトウェア開発ライフサイクルのように、テストとしてもライフサイクルを持っています。以降の章では、私はライフサイクルがあるとそれがソフトウェアテストに関連していて、細部にしようと議論します。
先に行きます！
II。ライフサイクルとは何ですか？
簡単に言えばライフサイクルは別の形式への一つの形から順に変化します。
これらの変更は、任意の有形または無形のものに発生する可能性があります。
スタートからの引退/絶滅の各エンティティは、ライフサイクルを持っています。
同様にし、また、ソフトウェアエンティティで。
ソフトウェア開発、テストなどの一連の段階を含むと同じように、あなたが特定の順序で取るべきいくつかのステップがあります。
このテストでは、ライフサイクル試験として知られている体系的かつ計画的現象で活動を行っています。
III。ソフトウェアテストのライフサイクル（STLC）は何ですか
ライフサイクルをテストする品質目標ことを確実にするために、実行順序を決定するために、特定のステップを、持っているテスト手順を意味します。
STLCプロセスでは、各アクティビティは、計画と体系的な方法で行われます。
各ステージには、異なる目的と成果を持っています。
異なる組織は、中STLCにおける様々な段階があります。しかし、基本は同じまま。
次はSTLCの様々な段階です。
- 要件フェーズ
- 計画段階
- 分析フェーズ
- 設計フェーズ
- 実施段階
- 実施段階
- 結論相
- クロージャ相
＃1要件フェーズ：
このステージSTLC、分析および研究の要件で。他のチームとのミーティングをブレインストーミングし、これらの要件をテストすることができるかどうかを判断してみてください。この段階では、テストの範囲を決定するのに役立ちます。機能は、すべてのテストで使用できない場合は、緩和戦略を計画することができるように、この段階でご連絡ください。
＃2計画段階：
実際には、試験計画は、試験プロセスの最初のステップです。この段階では、我々はテスト活動と資源の目標達成に貢献することを決定しました。計画時には、我々はまた、これらの指標の指標、収集および追跡を確認してみてください。
どのような基準で計画？唯一の要件？
答えはノーです。実際、基本的な要件の1を構成しているが、テスト計画に影響を与える他の二つの非常に重要な要素があります。これらは次のとおりであります：
-テスト戦略を整理します。
-リスク分析/リスク管理と予防。
＃3分析フェーズ：
STLCステージは「WHAT」テストするために定義されています。私たちの基本的な条件は、テスト要件文書、製品のリスクや他のテストベースで決定されます。試験条件は、要件にさかのぼる必要があります。同定された試験条件に影響を与える要因は数多くあります：
-テストのレベルと深さ
-製品の複雑さ
-製品とプロジェクトのリスク
-ソフトウェア開発ライフサイクルに関わります。
-テスト管理
スキルとチームの知識-
-可用性の利害関係者。
私たちは、詳細な方法で試験条件を記述してみてください。例えば、e-コマースWebアプリケーションのために、あなたは「ユーザーが支払いを行うことができるはずです。」試験条件を設定することができます それとも、詳細に説明されている「ユーザーはNEFT、デビットカードやクレジットカードでの支払いにできるはずです」と言うことができます。テストケースは、テスト条件に基づいて作成されるため、詳細な試験条件を記述するための最も重要な利点は、それがテストカバレッジを増加させることで、これらの詳細は、より詳細な筆記試験をトリガーする、最終的に範囲を拡大します。また、試験した条件の一部を停止するように決定された標準的な試験を、終了することを確認してください。
＃4の設計段階：
このフェーズでは、「どのように」テストのために定義されています。このフェーズでは、次のタスクが含まれます。
-試験条件の詳細な記述。試験条件は、カバレッジを増加させる複数の条件にサブ分割されます。
-テスト・データを識別し、獲得
-識別およびテスト環境をセットアップします。
-要件のトレーサビリティメトリックを作成
-テストカバレッジ指標を作成します。
＃5実装フェーズ：
STLC段階の主なタスクは、詳細なテストケースを作成することです。テストケースの優先順位を決定するために、テストケースはまた、回帰スイートの一部となるかを決定することができます。テストケースを最終決定する前に、テストケースの精度を確保するために見直されることが重要です。実際の実行が始まる前に加えて、テスト署名をキャンセルすることを忘れないでください。プロジェクトは、自動化を必要とする場合は、テストケースとテストケースの自動化のための候補者は、スクリプトを書き続けていることを確認します。それらを表示することを忘れないでください！
＃6実施段階：
名前が示すように、これは実用的な実装のソフトウェアテストのライフサイクル段階です。しかし、あなたが開始する前に、必ずご入力条件ということにします。テストケースの実施、矛盾の記録欠陥。あなたの進捗状況を追跡するための指標のも、完全なトレーサビリティ。
＃7結論段階：
STLCフェーズは終了基準および報告に焦点を当てました。あなたのプロジェクトや利害関係者を選択することにより、あなたは週次レポートレポート/毎日レポートを送信するかどうかを決定することができます。あなたは、レポートの異なる種類（ - 毎日のステータスレポート、WSR - DSR毎週のステータスレポート）を送ることができますが、レポートの内容は、あなたがレポートを送信するかに応じて、変化することが重要です。プロジェクトマネージャは、バックグラウンドをテストするために属しているので、彼らはプロジェクトの技術的な側面で、より興味を持っている場合は、そのレポートに（欠陥、欠陥の重症度などによって引き起こされるテストケース、失敗の数によって）技術的な内容を記入してください。あなたがいる場合は、彼らがそうのリスクを軽減するための試験に合格するためにそれらを報告してください、上部の利害関係者に報告技術的な問題に興味がないかもしれません。
＃8閉鎖段階：
アクティブなタスクには次のものが含ま閉じます。
-テストが完了しているか確認してください。すべてのテストケースを実行したり欠落しています。チェックなしのオープン欠陥の重大度1という。
-学んだ教訓は、会議の教訓を取ると、ファイルを作成します。（何が改善されているとどのような側面を向上させることができ、うまくいくものを含みます）
四の概要：
のは、ソフトウェアテストのライフサイクル（STLC）、それを要約してみましょう！
| S.No | 芸名 | エントリの標準 | 活動の実施 | 届けます |
|---|---|---|---|---|
| 1 | 需要 | 要件仕様書 アプリケーション設計文書 ユーザー受け入れ基準ファイル |
ブレーンストーミングの需要。要件のリストを作成し、あなたの疑問を明らかにする。。 需要がテストすることができるかどうかの可能性を理解し 、プロジェクトが自動化を必要とする場合、フィージビリティ・スタディを自動化してください、 |
RUDは（文書を理解する必要があります。 フィージビリティーレポートテスト 自動化の実現可能性報告書のを |
| 2 | 計画 | 要件ドキュメントを更新しました。 実現可能性報告書」のテスト 自動化の実現可能性報告書を |
定义项目的范围 进行风险分析并制定风险缓解计划。 执行测试评估 确定整体测试策略和流程。 确定工具和资源，并检查是否有任何培训需求. 识别环境 |
测试计划文档. 风险预防文件 测试评估文件 |
| 3 | 分析 | 更新的需求文档 测试计划文档 风险文档 测试评估文档 |
确定详细的测试条件 | 测试概要文件。 |
| 4 | 设计 | 更新的需求文档 测试概要文件 |
详细说明测试条件。 识别测试数据 创建可跟踪性指标 |
详细的测试条件文件 需求可追溯性指标 测试覆盖指标 |
| 5 | 实施 | 详细的测试条件文件 | 创建并查看测试用例。 创建并查看自动化脚本。 确定回归和自动化的候选测试用例. 识别/创建测试数据 签下测试用例和脚本。. |
测试用例 测试数据 测试脚本 |
| 6 | 执行 | 测试用例 测试脚本 |
执行测试用例 记录 bugs / 出现差异的缺陷 报告状态 |
测试执行报告 缺陷报告 测试日志，缺陷日志 更新需求可跟踪性指标 |
| 7 | 结论 | 更新了包含结果的测试用例 测试关闭条件 |
提供准确的数字和测试结果 确定减轻的风险 |
更新了可追溯性指标 测试总结报告 更新风险管理报告 |
| 8 | 关闭 | 测试闭合条件 测试总结报告 |
进行回顾性研究并了解所学到的经验教训 | 经验教训文件 测试矩阵 测试结束报告. |
HAPPY TESTING!!