📜  静态测试的类型

📅  最后修改于: 2021-07-05 09:56:15             🧑  作者: Mango

测试过程分为两种类型:静态测试和动态测试。静态测试与动态测试的不同之处在于,静态测试不涉及程序或软件的执行。但是,动态测试是通过执行软件产品的代码来执行的。

根据定义,静态测试是一种不涉及执行或运行程序或软件产品的人工测试技术。相反,它涉及在软件开发生命周期(SDLC)的每个阶段,根据软件产品的软件需求规范(SRS)中提到的要求或标准检查或监视软件。

为什么需要进行静态测试?

  • 在早期阶段检测错误/缺陷–
    在制作软件时,不能仅仅依靠动态测试,因为它会在以后发现软件产品的错误或缺陷,这可能会花费开发人员大量的时间和精力进行调试。
  • 增加软件大小–
    随着软件产品尺寸的增加,由于代码覆盖率的降低而变得难以处理。这就是为什么需要静态测试的原因,因为它有助于消除软件中较早的错误或错误。
  • 动态测试非常耗时–
    尽管动态测试发现了错误并提供了有关该错误的一些详细信息,但是,修复该错误仍然很费时间和精力,因为它包括检测从测试用例到根本原因的故障,从而使该过程变得非常困难。
  • 动态测试很昂贵–
    如前所述,动态测试需要测试用例,而这样做本身就很昂贵,因为应该首先创建,然后执行和验证测试用例,还必须对其进行维护,这导致测试人员需要进行大量工作。

静态测试的好处:

  • SDLC成本降低–
    由于这些错误是在SDLC的早期阶段中发现的,因此需要较少的精力和时间来修改产品并解决它们,从而降低了SDLC的总体成本。
  • 提高产品质量–
    在软件中检测到缺陷后,将其修复并在那里修复,从而提高了产品的质量。
  • 跟踪错误的确切位置–
    在静态测试中,可以跟踪错误的确切位置,而在动态测试的情况下,很难找到相同的位置。
  • 立即评估和反馈–
    对产品的评估经常进行,使产品质量更高,因为在开发产品的每个阶段都会收到即时反馈。
  • 提高动态测试的效率–
    随着代码在静态测试后变得越来越清晰,它需要更少的精力和时间来创建和维护高质量的测试用例,从而使动态测试更加有效。

静态测试的类型:

1.软件检查:

检查过程在SLDC的早期阶段执行,并应用于产品的特定部分,例如SRS,代码,产品设计。等等。它涉及在早期阶段手动检查产品的各个组件。软件检查过程包括六个阶段,这些阶段如下:

  • 计划检查会议–
    • 此阶段的重点是确定要检查的产品和检查的目的。
    • 在此阶段分配了一位主持人,他负责管理整个检查过程。
    • 指定的主持人检查产品是否准备好进行检查。主持人还选择检查团队并分配他们的角色。
    • 主持人还会安排检查会议,并将所需的材料分发给检查团队。
  • 概述 –
    • 在此阶段,检查团队将获得检查会议的所有背景信息。
    • 作者-负责产品开发的编码人员或设计师介绍了产品的逻辑和理由,包括产品的功能,预期用途以及开发过程中使用的方法或概念。
    • 确保检查组的每个成员都了解并熟悉将要举行的检查会议的目的和宗旨。
  • 成员个人准备–
    • 在此阶段,检查团队的成员通过研究早期阶段提供的材料来单独准备检查会议。
    • 团队成员确定产品中潜在的错误或错误,并将它们记录在日志中。日志最终提交给主持人。然后,主持人会编译从成员那里收到的所有日志,并将其副本发送给作者。
    • 检查员是负责检查和识别文档或程序中的错误和不一致之处的人员,负责检查产品并记录发现的任何问题(包括常规问题和特定领域问题)。检查员将问题记录在准备工作上,并记录在日志中。
    • 主持人查看日志,以检查团队是否已为检查会议做好准备并做好准备。
    • 最后,主持人将所有已编译的日志提交给作者。
  • 视察会议–
    • 这个阶段涉及作者对团队成员在已编译日志中提出的问题的讨论。
    • 成员们可以决定所提出的问题是否是错误的。
    • 主持人结束会议并提供会议摘要–这是产品中发现的错误列表,由作者解决。
  • 重工 –
    • 作者根据上一阶段主持人提供的摘要列表进行返工。
    • 作者修复了所有错误,并向主持人报告
  • 跟进 –
    • 主持人检查所有错误是否都已解决。然后主持人准备一份报告。如果所有错误都已解决并得到解决,主持人将释放该文档。
    • 否则,未解决的问题将添加到报告中,并安排另一个检查会议。

2.结构化演练:
这种类型的静态测试不太正式,本质上也不那么严格。与检查过程相比,它具有更简单的过程。它涉及以下四个步骤:

  • 组织 –
    此步骤涉及为选择用于结构化演练的团队分配角色和职责。该团队可以由以下成员组成:
    • 协调员–组织和与所有成员协调与演练相关的活动。
    • 演示者–介绍要检查的项目。
    • 抄写员–记下成员提出的所有问题和建议。
    • 测试器–查找要检查的项目中的缺陷或错误。
    • 维护Oracle –专注于产品的未来维护。
    • Standards Bearer –评估是否符合标准和准则。
    • 用户代表–代表用户的需求和关注点。
  • 准备 –
    • 在此步骤中,重点在于为结构演练做准备,其中可能包括考虑测试产品所需的基本测试用例。
  • 演练–
    • 演练由参加会议的测试人员执行,并带有少量测试用例。
    • 测试用例由测试人员明智地执行,结果记录在纸或演示媒体上。
  • 返工和跟进–跟进–
    • 此步骤类似于检查过程的最后两个阶段。
    • 如果未检测到错误,则该产品将被批准发布。否则,错误将得到解决,然后再次进行结构化演练。

3.技术评论:

与检查或演练技术相比,它是更高级别的技术,因为它还涉及管理。通过检查产品是否符合开发标准,指南和规格,该技术可用于评估和评估产品。
它没有定义好的过程,大部分工作由主持人完成,如下所述:

  • 主持人收集材料和文档并将其分发给所有团队成员。
  • 主持人还准备了一套指标,以根据规格和已经建立的标准和准则来评估产品:
    • 一致性
    • 文件资料
    • 遵守标准
    • 完整性
    • 问题定义和要求
  • 结果记录在包含缺陷和建议的文档中。
  • 最后,解决缺陷并考虑改进产品的建议。