STLC - 测试执行
测试执行是执行代码并比较预期结果和实际结果的过程。测试执行过程需要考虑以下因素 −
- 根据风险，选择要在此周期执行的测试套件子集。
- 将每个测试套件中的测试用例分配给测试人员执行。
- 执行测试、报告错误并持续捕获测试状态。
- 解决出现的阻塞问题。
- 报告状态、调整任务分配并每天重新考虑计划和优先级。
- 报告测试周期的发现和状态。
测试执行需要考虑以下几点。
在此阶段，QA 团队根据准备好的测试用例对 AUT 进行实际验证，并将分步结果与预期结果进行比较。
此阶段的进入标准是完成测试计划和测试案例开发阶段，测试数据也应该准备好。
在正式进入测试执行之前，始终建议通过冒烟测试验证测试环境设置。
退出标准要求成功验证所有测试案例；缺陷应关闭或推迟；测试案例执行和缺陷摘要报告应准备好。
测试执行活动
此阶段的目标是在进入生产/发布之前实时验证 AUT。为了从此阶段签字，QA 团队执行不同类型的测试以确保产品质量。除此之外，缺陷报告和重新测试也是此阶段的关键活动。以下是此阶段的重要活动 −
系统集成测试
产品/AUT 的真正验证从这里开始。系统集成测试 (SIT) 是一种黑盒测试技术，用于评估系统是否符合指定的要求/准备的测试用例。
系统集成测试通常在系统子集上执行。SIT 可以在最少使用测试工具的情况下执行，验证交换的交互，并调查各个层内每个数据字段的行为。集成后，数据流主要有三种状态 −
- 集成层内的数据状态
- 数据库层内的数据状态
- 应用程序层内的数据状态
注意 − 在 SIT 测试中，QA 团队会尝试找到尽可能多的缺陷以确保质量。这里的主要目标是找到尽可能多的错误。
缺陷报告
当预期结果与实际结果不匹配时，就会出现软件错误。它可能是计算机程序中的错误、缺陷、故障或故障。大多数错误都是由开发人员或架构师的错误引起的。
在执行 SIT 测试时，QA 团队会发现这些类型的缺陷，需要向相关团队成员报告。成员采取进一步行动并修复缺陷。报告的另一个优点是它简化了对缺陷状态的跟踪。有许多流行的工具支持缺陷报告和跟踪，如 ALM、QC、JIRA、Version One、Bugzilla。
缺陷报告是通过测试或记录客户反馈来查找测试应用程序或产品中的缺陷并根据客户的反馈制作修复缺陷的新版本产品的过程。
缺陷跟踪也是软件工程中的一个重要过程，因为复杂且业务关键的系统有数百个缺陷。最具挑战性的因素之一是管理、评估和优先考虑这些缺陷。缺陷的数量在一段时间内成倍增加，为了有效地管理它们，缺陷跟踪系统可用于使工作更容易。
缺陷映射
一旦报告并记录了缺陷，就应该将其与需求可追溯性矩阵中相关的失败/阻止测试用例和相应的需求进行映射。此映射由缺陷报告者完成。它有助于制作正确的缺陷报告并分析产品中的缺陷。一旦测试用例和需求与缺陷映射，利益相关者就可以分析并根据优先级和严重性决定是否修复/推迟缺陷。
重新测试
重新测试是针对 AUT 执行先前失败的测试，以检查问题是否已解决。修复缺陷后，将执行重新测试以在相同的环境条件下检查场景。
在重新测试期间，测试人员会在功能发生变化的区域寻找细节，而回归测试则涵盖所有主要功能，以确保不会因这种变化而破坏任何功能。
回归测试
一旦所有缺陷都处于关闭、推迟或拒绝状态，并且没有任何测试用例处于进行/失败/未运行状态，就可以说系统集成测试完全基于测试用例和需求。但是，需要进行一轮快速测试，以确保不会因代码更改/缺陷修复而破坏任何功能。
回归测试是一种黑盒测试技术，包括重新执行那些因代码更改而产生影响的测试。这些测试应在整个软件开发生命周期中尽可能多地执行。
回归测试的类型
最终回归测试 − 执行"最终回归测试"是为了验证一段时间内未发生更改的版本。此版本已部署或发送给客户。
回归测试 −执行常规回归测试是为了验证构建是否没有因最近为修复缺陷或增强功能而进行的代码更改而破坏应用程序的任何其他部分。
活动框图
以下框图显示了此阶段执行的重要活动；它还显示了与前几个阶段的依赖关系 −
