一.演化
♦1960年代的趋势:
♦1990年代的趋势：
♦2000年代的趋势：
测试的趋势和能力正在发生变化。现在要求测试人员更加注重技术和流程。现在的测试不仅仅局限于发现错误，而且范围更广，从项目一开始就需要甚至没有最终确定。 由于测试也是标准化的。就像软件开发有生命周期一样，测试也有生命周期。在随后的章节中，我将讨论生命周期是什么以及它与软件测试有何关系，并将尝试详细说明。
开始吧！
二. 什么是生命周期？
简单术语中的生命周期是指从一种形式到另一种形式的变化顺序。
这些变化可能发生在任何有形或无形的事物上。
每个实体从开始到退休/消亡都有一个生命周期。
以类似的方式，软件也是一个实体。
就像开发软件涉及一系列步骤一样，测试也有一些应该以一定顺序执行的步骤。
这种以系统和有计划的方式执行测试活动的现象称为测试生命周期。
三. 什么是软件测试生命周期（STLC）
软件测试生命周期是指一个测试过程，其具有以确定顺序执行的特定步骤，以确保满足质量目标。
在STLC过程中，每个活动都以有计划和系统的方式进行。
每个阶段都有不同的目标和可交付成果。
不同的组织在STLC中有不同的阶段;但基础保持不变。
以下是STLC的各个阶段：
- 需求阶段
- 计划阶段
- 分析阶段
- 设计阶段
- 实施阶段
- 执行阶段
- 结论阶段
- 关闭阶段
#1. 需求阶段:
在STLC的这个阶段，分析和研究要求。与其他团队进行头脑风暴会议，并尝试确定这些要求是否可测试。此阶段有助于确定测试范围。如果任何功能不可测试，请在此阶段进行通信，以便可以规划缓解策略。
#2. 计划阶段:
在实际情况中，测试计划是测试过程的第一步。在此阶段，我们确定有助于实现测试目标的活动和资源。在规划期间，我们还尝试确定指标，收集和跟踪这些指标的方法。
在什么基础上进行规划？只有要求？
答案是不。要求确实构成了基础之一，但是还有另外两个影响测试计划的非常重要的因素。这些是:
–-组织测试策略。
–-风险分析/风险管理和预防。
#3. 分析阶段:
STLC阶段定义了要测试的“WHAT”。我们基本通过需求文档，产品风险和其他测试依据来确定测试条件。测试条件应该可追溯到要求。影响测试条件识别的因素有很多：
– 测试的级别和深度
– 产品的复杂性
– 产品和项目风险
– 涉及软件开发生命周期。
– 测试管理
– 团队的技能和知识。
– 利益相关者的可用性。
我们应该尝试以详细的方式写下测试条件。例如，对于电子商务Web应用程序，您可以将测试条件设置为“用户应该能够进行付款”。或者您可以通过说“用户应该能够通过NEFT，借记卡和信用卡付款”来详细说明。编写详细测试条件的最重要的优点是它增加了测试覆盖率，因为测试用例将根据测试条件编写，这些细节将触发编写更详细的测试用例，最终会增加覆盖范围。还要确定测试的退出标准，即确定停止测试的一些条件。
#4. 设计阶段:
这个阶段定义了“HOW”进行测试。此阶段涉及以下任务：
– 详细说明测试条件。将测试条件分解为多个子条件以增加覆盖率。
– 识别并获取测试数据
– 识别并设置测试环境。
– 创建需求可跟踪性度量标准
– 创建测试覆盖率指标。
#5. 实施阶段:
STLC阶段的主要任务是创建详细的测试用例。确定测试用例的优先级，还可以确定哪个测试用例将成为回归套件的一部分。在最终确定测试用例之前，重要的是进行审查以确保测试用例的正确性。另外，在实际执行开始之前，不要忘记取消测试用例的签名。如果您的项目涉及自动化，请确定自动化的候选测试用例并继续编写测试用例的脚本。别忘了查看它们！
#6. 执行阶段:
顾名思义，这是实际执行的软件测试生命周期阶段。但在开始执行之前，请确保满足您的输入条件。执行测试用例，记录任何差异时的缺陷。同时填写可追溯性指标以跟踪您的进度。
#7. 结论阶段:
该STLC阶段集中于退出标准和报告。根据您的项目和利益相关者的选择，您可以决定报告是否要发送每周报告/每日报告等。您可以发送不同类型的报告（DSR - 每日状态报告，WSR - 每周状态报告）但重要的是，报告的内容会发生变化，具体取决于您发送报告的对象。如果项目经理属于测试背景，那么他们对项目的技术方面更感兴趣，因此请在报告中包含技术内容（通过的测试用例数，失败，引发的缺陷，严重性1缺陷等）。但是，如果您向上层利益相关方报告，他们可能对技术问题不感兴趣，因此请报告他们通过测试减轻的风险。
#8. 关闭阶段:
关闭活动的任务包括以下内容：
–检查测试是否完成。是否所有测试用例都执行或缺少的。检查是否没有打开严重性1的缺陷。
–取经验教训会议并创建经验总结文件。（包括哪些方面进展顺利，哪些方面有改进，哪些方面可以改进）
四. 总结:
让我们试着总结软件测试生命周期（STLC）吧！
| S.No | 阶段名称 | 入境标准 | 活动执行 | 交付 |
|---|---|---|---|---|
| 1 | 需求 | 要求规范文件 应用设计文件 用户验收标准文件 |
集思广益的需求。创建需求列表并澄清您的疑虑。. 了解需求是否可测试的可行性 如果您的项目需要自动化，请进行自动化可行性研究 |
RUD ( 需求理解文档. 测试可行性报告 自动化可行性报告 |
| 2 | 计划 | 更新的需求文档. 测试可行性报告 “ 自动化可行性报告 |
定义项目的范围 进行风险分析并制定风险缓解计划。 执行测试评估 确定整体测试策略和流程。 确定工具和资源，并检查是否有任何培训需求. 识别环境 |
测试计划文档. 风险预防文件 测试评估文件 |
| 3 | 分析 | 更新的需求文档 测试计划文档 风险文档 测试评估文档 |
确定详细的测试条件 | 测试概要文件。 |
| 4 | 设计 | 更新的需求文档 测试概要文件 |
详细说明测试条件。 识别测试数据 创建可跟踪性指标 |
详细的测试条件文件 需求可追溯性指标 测试覆盖指标 |
| 5 | 实施 | 详细的测试条件文件 | 创建并查看测试用例。 创建并查看自动化脚本。 确定回归和自动化的候选测试用例. 识别/创建测试数据 签下测试用例和脚本。. |
测试用例 测试数据 测试脚本 |
| 6 | 执行 | 测试用例 测试脚本 |
执行测试用例 记录 bugs / 出现差异的缺陷 报告状态 |
测试执行报告 缺陷报告 测试日志，缺陷日志 更新需求可跟踪性指标 |
| 7 | 结论 | 更新了包含结果的测试用例 测试关闭条件 |
提供准确的数字和测试结果 确定减轻的风险 |
更新了可追溯性指标 测试总结报告 更新风险管理报告 |
| 8 | 关闭 | 测试闭合条件 测试总结报告 |
进行回顾性研究并了解所学到的经验教训 | 经验教训文件 测试矩阵 测试结束报告. |
HAPPY TESTING!!