软件测试 – 快速指南

软件测试 – 快速指南

软件测试 – 概述

什么是测试？

测试是评估系统或其组件的过程，目的是确定它是否满足规定的要求。简而言之，测试正在执行一个系统，以识别与实际需求相反的任何差距、错误或缺失的需求。

根据 ANSI/IEEE 1059 标准，测试可以定义为 – 分析软件项目以检测现有条件和所需条件（即缺陷/错误/缺陷）之间的差异并评估软件项目功能的过程。

谁做测试？

这取决于项目的过程和相关的利益相关者。在 IT 行业，大公司有一个团队负责根据给定的需求评估开发的软件。此外，开发人员还进行测试，称为单元测试。在大多数情况下，以下专业人员在各自的能力范围内参与测试系统 –

  • 软件测试员
  • 软件开发师
  • 项目负责人/经理
  • 最终用户

不同的公司根据他们的经验和知识对软件测试人员有不同的称呼，例如软件测试员、软件质量保证工程师、QA 分析师等。

在其周期内的任何时间都无法测试软件。接下来的两个部分说明了何时应该开始测试以及何时在 SDLC 期间结束它。

什么时候开始测试？

尽早开始测试可以减少返工和生产交付给客户的无错误软件的成本和时间。然而，在软件开发生命周期 (SDLC) 中，测试可以从需求收集阶段开始，一直持续到软件部署。

它还取决于正在使用的开发模型。例如，在瀑布模型中，在测试阶段进行正式测试；但在增量模型中，在每次增量/迭代结束时执行测试，并在结束时测试整个应用程序。

在 SDLC 的每个阶段以不同的形式进行测试 –

  • 在需求收集阶段，需求的分析和验证也被视为测试。

  • 在设计阶段审查设计以改进设计也被视为测试。

  • 开发人员在完成代码时执行的测试也被归类为测试。

什么时候停止测试？

很难确定何时停止测试，因为测试是一个永无止境的过程，没有人可以声称软件经过 100% 测试。停止测试过程需要考虑以下方面 –

  • 测试截止日期

  • 完成测试用例执行

  • 完成功能和代码覆盖到某一点

  • Bug 率下降到一定水平以下，并且没有识别出高优先级的 Bug

  • 管理决策

验证和确认

这两个术语对于大多数人来说非常混乱，他们可以互换使用它们。下表突出显示了验证和确认之间的差异。

Sr.No. 确认 验证
1 验证解决了这个问题：“你做对了吗？” 验证解决了这个问题：“你在构建正确的东西吗？”
2 确保软件系统满足所有功能。 确保功能满足预期行为。
3 验证首先进行，包括检查文档、代码等。 验证发生在验证之后，主要涉及对整个产品的检查。
4 由开发人员完成。 由测试人员完成。
5 它具有静态活动，因为它包括收集评论、演练和检查以验证软件。 它具有动态活动，因为它包括根据需求执行软件。
6 这是一个客观的过程，不需要主观的决定来验证软件。 这是一个主观的过程，涉及对软件运行情况的主观决定。

软件测试 – 神话

下面给出了一些关于软件测试的最常见的误解。

误区一：测试成本太高

现实– 有一种说法，在软件开发期间花更少的钱进行测试，或者在以后为维护或修正支付更多的费用。早期测试可以在许多方面节省时间和成本，但是不进行测试就降低成本可能会导致软件应用程序设计不当，从而导致产品无用。

误解 2：测试很耗时

现实– 在 SDLC 阶段，测试从来都不是一个耗时的过程。然而，诊断和修复在正确测试期间发现的错误是一项耗时但富有成效的活动。

误解 3：只测试完全开发的产品

现实– 毫无疑问，测试取决于源代码，但审查需求和开发测试用例独立于开发的代码。然而，作为开发生命周期模型的迭代或增量方法可以减少测试对完全开发的软件的依赖性。

误解 4：完全测试是可能的

现实– 当客户或测试人员认为完整的测试是可能的时，这就会成为一个问题。团队可能已经测试了所有路径，但永远不可能进行完整的测试。可能有一些场景在软件开发生命周期中从未被测试团队或客户执行过，而在项目部署后可能会执行。

误解 5：经过测试的软件没有错误

现实– 这是客户、项目经理和管理团队所相信的一个非常普遍的神话。即使具有高超测试技能的测试人员测试了软件应用程序，也没有人可以绝对肯定地声称软件应用程序是 100% 无错误的。应用。

误区 6：遗漏的缺陷是由测试人员造成的

现实– 即使在执行测试后，将应用程序中仍然存在的错误归咎于测试人员并不是一种正确的方法。这个神话与时间、成本和需求变化约束有关。然而，测试策略也可能导致测试团队遗漏错误。

误解 7：测试人员对产品质量负责

现实– 这是一个非常普遍的误解，认为只有测试人员或测试团队应该对产品质量负责。测试人员的职责包括向利益相关者识别错误，然后由他们决定是修复错误还是发布软件。当时发布软件会给测试人员带来更大的压力，因为他们会因任何错误而受到指责。

误区 8：应尽可能使用测试自动化以减少时间

现实– 是的，测试自动化确实减少了测试时间，但在软件开发过程中的任何时候都无法启动测试自动化。当软件经过人工测试并稳定到一定程度时，应启动测试自动机。此外，如果需求不断变化，则永远无法使用测试自动化。

误解 9：任何人都可以测试软件应用程序

现实– IT 行业以外的人认为甚至相信任何人都可以测试软件，而测试并不是一项创造性的工作。然而，测试人员非常清楚这是一个神话。考虑替代方案，尝试使软件崩溃以探索潜在错误对于开发它的人来说是不可能的。

误区 10：测试人员的唯一任务是查找错误

现实– 发现软件中的错误是测试人员的任务，但与此同时，他们是特定软件的领域专家。开发人员只负责分配给他们的特定组件或区域，但测试人员了解软件的整体工作原理、依赖项是什么以及一个模块对另一个模块的影响。

软件测试 – 质量保证、质量控制和测试

测试、质量保证和质量控制

大多数人在确定质量保证、质量控制和测试之间的差异时会感到困惑。虽然它们是相互关联的，并且在某种程度上可以被视为相同的活动，但它们之间存在区别点。下表列出了区分 QA、QC 和测试的要点。

Quality Assurance 质量控制 测试
QA includes activities that ensure the implementation of processes, procedures and standards in context to verification of developed software and intended requirements. 它包括确保根据文档化（或在某些情况下不是）需求验证已开发软件的活动。 它包括确保识别软件中的错误/错误/缺陷的活动。
Focuses on processes and procedures rather than conducting actual testing on the system. 通过执行软件专注于实际测试，目的是通过实施程序和过程来识别错误/缺陷。 专注于实际测试。
Process-oriented activities. 以产品为导向的活动。 以产品为导向的活动。
Preventive activities. 这是一个纠正过程。 这是一个预防过程。
It is a subset of Software Test Life Cycle (STLC). QC 可以被视为质量保证的子集。 测试是质量控制的子集。

审计和检查

审计– 这是一个系统的过程，以确定如何在组织或团队内进行实际的测试过程。通常，它是对软件测试过程中涉及的过程的独立检查。根据 IEEE，它是对组织实施和遵循的文件化流程的审查。审计类型包括法律合规审计、内部审计和系统审计。

检查– 这是一种正式的技术，通过识别任何错误或差距，对任何工件进行正式或非正式的技术审查。根据 IEEE94，检查是一种正式的评估技术，其中软件需求、设计或代码由作者以外的个人或团体详细检查，以检测错误、违反开发标准和其他问题。

正式的检查会议可能包括以下过程：计划、概述准备、检查会议、返工和跟进。

测试和调试

测试– 它涉及识别软件中的错误/错误/缺陷而不纠正它。通常具有质量保证背景的专业人员参与错误识别。测试在测试阶段进行。

调试– 它涉及识别、隔离和修复问题/错误。编写软件的开发人员在遇到代码错误时进行调试。调试是白盒测试或单元测试的一部分。调试可以在开发阶段进行，同时进行单元测试，也可以在修复报告的错误时分阶段进行。

软件测试 – ISO 标准

全球许多组织制定和实施不同的标准，以提高其软件的质量需求。本章简要介绍了一些广泛使用的与质量保证和测试相关的标准。

ISO/IEC 9126

该标准涉及以下方面以确定软件应用程序的质量 –

  • 质量模型
  • 外部指标
  • 内部指标
  • 使用质量指标

该标准为任何软件提供了一些质量属性，例如 –

  • 功能
  • 可靠性
  • 可用性
  • 效率
  • 可维护性
  • 可移植性

上面提到的质量属性又细分为子因素，在详细研究标准的时候可以研究。

ISO/IEC 9241-11

本标准的第 11 部分涉及特定用户使用产品以在特定使用环境中实现具有有效性、效率和满意度的特定目标的程度。

该标准提出了一个框架，描述了可用性组件以及它们之间的关系。在本标准中，可用性是从用户性能和满意度方面考虑的。根据 ISO 9241-11，可用性取决于使用上下文，可用性级别将随着上下文的变化而变化。

ISO/IEC 25000:2005

ISO/IEC 25000:2005 通常被称为提供软件质量要求和评估 (SQuaRE) 指南的标准。该标准有助于组织和增强与软件质量需求及其评估相关的过程。实际上，ISO-25000 取代了两个旧的 ISO 标准，即 ISO-9126 和 ISO-14598。

SQuaRE分为子部分，例如 –

  • ISO 2500n – 质量管理部
  • ISO 2501n – 质量模型部
  • ISO 2502n – 质量测量部
  • ISO 2503n – 质量要求部
  • ISO 2504n – 质量评估部

SQuaRE 的主要内容是 –

  • 术语和定义
  • 参考模型
  • 一般指南
  • 个别部门指南
  • 与需求工程相关的标准（即规范、计划、测量和评估过程）

ISO/IEC 12119

该标准涉及交付给客户的软件包。它不关注或处理客户的生产过程。主要内容与以下项目有关 –

  • 软件包的一组要求。
  • 根据指定要求测试已交付软件包的说明。

各种各样的

下面提到了与 QA 和测试过程相关的其他一些标准 –

Sr.No 标准和描述
1

IEEE 829

在软件测试的不同阶段使用的文档格式的标准。
2

IEEE 1061

一种用于建立质量需求、识别、实施、分析和验证过程和软件质量度量产品的方法。
3

IEEE 1059

软件验证和确认计划指南。
4

IEEE 1008

单元测试的标准。
5

IEEE 1012

软件验证和确认标准。
6

IEEE 1028

软件检查的标准。
7

IEEE 1044

软件异常分类标准。
8

IEEE 1044-1

软件异常分类指南。
9

IEEE 830

制定系统需求规范的指南。
10

IEEE 730

软件质量保证计划的标准。
11

IEEE 1061

软件质量度量和方法的标准。
12

IEEE 12207

软件生命周期过程和生命周期数据的标准。
13

BS 7925-1

软件测试中使用的术语词汇表。
14

BS 7925-2

软件组件测试的标准。

软件测试 – 测试类型

本节描述了可用于在 SDLC 期间测试软件的不同类型的测试。

手动测试

手动测试包括手动测试软件，即不使用任何自动化工具或任何脚本。在这种类型中，测试人员接管最终用户的角色并测试软件以识别任何意外行为或错误。手动测试有不同的阶段，例如单元测试、集成测试、系统测试和用户验收测试。

测试人员使用测试计划、测试用例或测试场景来测试软件，以确保测试的完整性。手动测试还包括探索性测试，因为测试人员探索软件以识别其中的错误。

自动化测试

自动化测试，也称为测试自动化，是测试人员编写脚本并使用其他软件来测试产品。该过程涉及手动过程的自动化。自动化测试用于重新运行手动、快速和重复执行的测试场景。

自动化测试

除了回归测试，自动化测试还用于从负载、性能和压力的角度测试应用程序。与手动测试相比，它增加了测试覆盖率，提高了准确性，并节省了时间和金钱。

什么要自动化？

不可能将软件中的所有内容都自动化。用户可以进行交易的区域，例如登录表单或注册表单，以及大量用户可以同时访问软件的任何区域都应该自动化。

此外，所有 GUI 项目、与数据库的连接、现场验证等都可以通过自动化手动过程进行有效测试。

什么时候自动化？

应通过考虑软件的以下方面来使用测试自动化 –

  • 大型和关键项目
  • 需要频繁测试相同区域的项目
  • 要求不经常变化
  • 使用许多虚拟用户访问应用程序以获得负载和性能
  • 相对于手动测试的稳定软件
  • 时间可用性

如何自动化？

自动化是通过使用支持的计算机语言（如 VB 脚本）和自动化软件应用程序来完成的。有许多工具可用于编写自动化脚本。在提到工具之前，让我们确定可用于自动化测试过程的过程 –

  • 识别软件中的自动化领域
  • 选择合适的测试自动化工具
  • 编写测试脚本
  • 开发测试服
  • 脚本的执行
  • 创建结果报告
  • 识别任何潜在的错误或性能问题

软件测试工具

以下工具可用于自动化测试 –

  • 惠普快速测试专业版
  • 硒
  • IBM Rational 功能测试员
  • 丝试
  • 测试完成
  • 随处测试
  • WinRunner
  • 加载程序
  • Visual Studio 测试专家
  • 卫兵

软件测试 – 方法

有不同的方法可用于软件测试。本章简要介绍了可用的方法。

黑盒测试

在不了解应用程序内部工作原理的情况下进行测试的技术称为黑盒测试。测试人员对系统架构一无所知，也无法访问源代码。通常，在执行黑盒测试时，测试人员将通过提供输入和检查输出与系统的用户界面进行交互，而无需知道输入的工作方式和位置。

下表列出了黑盒测试的优缺点。

Advantages 缺点
Well suited and efficient for large code segments. 覆盖范围有限，因为实际上只执行了选定数量的测试场景。
Code access is not required. 测试效率低下，因为测试人员对应用程序的了解有限。
Clearly separates user’s perspective from the developer’s perspective through visibly defined roles. 盲目覆盖，因为测试人员无法针对特定的代码段或容易出错的区域。
Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language, or operating systems. 测试用例很难设计。

白盒测试

白盒测试是对代码内部逻辑和结构的详细调查。白盒测试也称为玻璃测试或开盒测试。为了进行白盒上的应用程序的测试，测试人员需要知道的代码的内部工作。

测试人员需要查看源代码内部并找出代码的哪个单元/块表现不正常。

下表列出了白盒测试的优缺点。

Advantages 缺点
As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively. 由于需要熟练的测试人员进行白盒测试，因此增加了成本。
It helps in optimizing the code. 有时不可能查看每个角落以找出可能造成问题的隐藏错误，因为许多路径未经测试。
Extra lines of code can be removed which can bring in hidden defects. 维护白盒测试很困难，因为它需要专门的工具，如代码分析器和调试工具。
Due to the tester’s knowledge about the code, maximum coverage is attained during test scenario writing.

灰盒测试

灰盒测试是一种在对应用程序的内部工作了解有限的情况下测试应用程序的技术。在软件测试中，这句话知道得越多，在测试应用程序时就越好。

掌握系统的领域总是让测试人员比领域知识有限的人更有优势。与黑盒测试不同，测试人员只测试应用程序的用户界面；在灰盒测试中，测试人员可以访问设计文档和数据库。有了这些知识，测试人员可以在制定测试计划的同时准备更好的测试数据和测试场景。

Advantages 缺点
Offers combined benefits of black-box and white-box testing wherever possible. 由于无法访问源代码，因此检查代码和测试覆盖率的能力受到限制。
Grey box testers don’t rely on the source code; instead they rely on interface definition and functional specifications. 如果软件设计者已经运行了一个测试用例，那么这些测试可能是多余的。
Based on the limited information available, a grey-box tester can design excellent test scenarios especially around communication protocols and data type handling. 测试每个可能的输入流是不切实际的，因为它会花费不合理的时间；因此，许多程序路径将未经测试。
The test is done from the point of view of the user and not the designer.

测试方法的比较

下表列出了区分黑盒测试、灰盒测试和白盒测试的要点。

Black-Box Testing 灰盒测试 白盒测试
The internal workings of an application need not be known. 测试人员对应用程序的内部工作原理了解有限。 测试人员完全了解应用程序的内部工作原理。
Also known as closed-box testing, data-driven testing, or functional testing. 也称为半透明测试，因为测试人员对应用程序内部的了解有限。 也称为明盒测试、结构测试或基于代码的测试。
Performed by end-users and also by testers and developers. 由最终用户以及测试人员和开发人员执行。 通常由测试人员和开发人员完成。
Testing is based on external expectations – Internal behavior of the application is unknown. 测试是在高级数据库图和数据流图的基础上完成的。 内部工作原理是完全已知的，测试人员可以相应地设计测试数据。
It is exhaustive and the least time-consuming. 部分耗时且详尽。 最详尽和最耗时的测试类型。
Not suited for algorithm testing. 不适合算法测试。 适合算法测试。
This can only be done by trial-and-error method. 如果知道，可以测试数据域和内部边界。 可以更好地测试数据域和内部边界。

软件测试 – 级别

在测试过程中有不同的级别。在本章中，对这些级别进行了简要说明。

测试级别包括在进行软件测试时可以使用的不同方法。软件测试的主要级别是 –

  • 功能测试

  • 非功能测试

功能测试

这是一种基于要测试的软件的规范的黑盒测试。通过提供输入来测试应用程序，然后检查需要符合其预期功能的结果。软件的功能测试是在一个完整的、集成的系统上进行的，以评估系统是否符合其指定的要求。

测试应用程序的功能时涉及五个步骤。

Steps 描述
I 确定预期应用程序要执行的功能。
II 根据应用程序的规范创建测试数据。
III 基于测试数据和应用程序规范的输出。
IV 测试场景的编写和测试用例的执行。
V 基于执行的测试用例的实际和预期结果的比较。

有效的测试实践会将上述步骤应用于每个组织的测试策略，从而确保组织在软件质量方面保持最严格的标准。

单元测试

这种类型的测试由开发人员在将设置移交给测试团队以正式执行测试用例之前执行。单元测试由各自的开发人员在源代码分配区域的各个单元上执行。开发人员使用的测试数据不同于质量保证团队的测试数据。

单元测试的目标是隔离程序的每个部分，并表明各个部分在需求和功能方面是正确的。

单元测试的局限性

测试无法捕获应用程序中的每一个错误。不可能评估每个软件应用程序中的每个执行路径。单元测试也是如此。

开发人员可用于验证源代码的场景和测试数据的数量是有限的。在用尽所有选项后，别无选择，只能停止单元测试并将代码段与其他单元合并。

集成测试

集成测试被定义​​为测试应用程序的组合部分以确定它们是否正常运行。集成测试可以通过两种方式完成：自底向上集成测试和自顶向下集成测试。

Sr.No. 集成测试方法
1

Bottom-up integration

这种测试从单元测试开始，然后是对称为模块或构建的单元的更高级别组合的测试。
2

Top-down integration

在此测试中，首先测试最高级别的模块，然后逐步测试较低级别的模块。

在综合软件开发环境中，通常先进行自下而上的测试，然后进行自上而下的测试。该过程以对完整应用程序的多次测试结束，最好是在旨在模拟实际情况的场景中。

系统测试

系统测试对整个系统进行测试。集成所有组件后，将对整个应用程序进行严格测试，以确保其符合指定的质量标准。此类测试由专门的测试团队执行。

由于以下原因，系统测试很重要 –

  • 系统测试是软件开发生命周期的第一步，应用程序作为一个整体进行测试。

  • 该应用程序经过彻底测试，以验证其是否符合功能和技术规范。

  • 应用程序在非常接近应用程序部署的生产环境的环境中进行测试。

  • 系统测试使我们能够测试、验证和验证业务需求以及应用程序架构。

回归测试

每当对软件应用程序进行更改时，应用程序中的其他区域很可能会受到此更改的影响。执行回归测试以验证已修复的错误未导致其他功能或业务规则违规。回归测试的目的是确保更改（例如错误修复）不应导致应用程序中发现另一个错误。

由于以下原因，回归测试很重要 –

  • 当必须测试进行了更改的应用程序时，尽量减少测试中的差距。

  • 测试新的更改以验证所做的更改不会影响应用程序的任何其他区域。

  • 在对应用程序执行回归测试时降低风险。

  • 在不影响时间表的情况下增加了测试覆盖率。

  • 加快产品上市速度。

验收测试

这可以说是最重要的测试类型，因为它由质量保证团队进行，他们将衡量应用程序是否符合预期规格并满足客户的要求。QA 团队将拥有一组预先编写的场景和测试用例，用于测试应用程序。

将分享有关该应用程序的更多想法，并可以对其进行更多测试，以衡量其准确性以及启动该项目的原因。验收测试不仅旨在指出简单的拼写错误、外观错误或界面差距，而且还旨在指出应用程序中会导致系统崩溃或应用程序重大错误的任何错误。

通过对应用程序执行验收测试，测试团队将减少应用程序在生产中的执行情况。接受该系统也有法律和合同要求。

阿尔法测试

此测试是测试的第一阶段，将在团队（开发人员和 QA 团队）之间执行。单元测试、集成测试和系统测试结合在一起称为 alpha 测试。在此阶段，将在应用程序中测试以下方面 –

  • 拼写错误

  • 断开的链接

  • 多云方向

  • 应用程序将在最低规格的机器上进行测试，以测试加载时间和任何延迟问题。

测试版

此测试在成功执行 alpha 测试后执行。在 beta 测试中，目标受众的样本测试应用程序。Beta 测试也称为预发布测试。理想情况下，软件的 Beta 测试版本分发给 Web 上的广泛受众，部分是为了让程序进行“真实世界”的测试，部分是为了提供下一个版本的预览。在这个阶段，观众将测试以下内容 –

  • 用户将安装、运行应用程序并将他们的反馈发送给项目团队。

  • 排版错误、混乱的应用程序流程，甚至崩溃。

  • 获得反馈后，项目团队可以在将软件发布给实际用户之前解决问题。

  • 解决实际用户问题的问题越多，应用程序的质量就越高。

  • 当您向公众发布更高质量的应用程序时，将提高客户满意度。

非功能测试

本节基于从非功能属性测试应用程序。非功能性测试涉及从本质上是非功能性但重要的需求（例如性能、安全性、用户界面等）来测试软件。

下面讨论了一些重要且常用的非功能测试类型。

性能测试

它主要用于识别任何瓶颈或性能问题，而不是查找软件中的错误。降低软件性能的原因有多种 –

  • 网络延迟

  • 客户端处理

  • 数据库事务处理

  • 服务器之间的负载均衡

  • 数据渲染

就以下方面而言，性能测试被认为是重要且强制性的测试类型之一 –

  • 速度（即响应时间、数据渲染和访问）

  • 容量

  • 稳定

  • 可扩展性

性能测试可以是定性的也可以是定量的，并且可以分为不同的子类型，例如负载测试和压力测试。

负载测试

它是通过在软件访问和操作大量输入数据方面施加最大负载来测试软件行为的过程。它可以在正常和峰值负载条件下完成。这种类型的测试确定软件的最大容量及其在高峰时间的行为。

大多数情况下，负载测试是在 Load Runner、AppLoader、IBM Rational Performance Tester、Apache JMeter、Silk Performer、Visual Studio Load Test 等自动化工具的帮助下执行的。

虚拟用户（VUsers）在自动化测试工具中定义，并执行脚本来验证软件的负载测试。用户数量可以根据需要同时或增量增加或减少。

压力测试

压力测试包括测试软件在异常情况下的行为。例如，它可能包括带走一些资源或应用超出实际负载限制的负载。

压力测试的目的是通过对系统施加负载并接管软件使用的资源来测试软件，以确定断点。可以通过测试不同的场景来执行此测试，例如 –

  • 随机关闭或重启网口

  • 打开或关闭数据库

  • 运行消耗CPU、内存、服务器等资源的不同进程。

可用性测试

可用性测试是一种黑盒技术，用于通过观察用户的使用和操作来识别软件中的任何错误和改进。

根据尼尔森的说法，可用性可以用五个因素来定义，即使用效率、学习能力、记忆能力、错误/安全性和满意度。在他看来，一个产品的可用性是好的，如果系统具备上述因素，那么这个系统就是可用的。

Nigel Bevan 和 Macleod 认为可用性是质量要求，可以作为与计算机系统交互的结果来衡量。如果通过使用适当的资源有效地实现预期目标，则可以满足此要求并且最终用户将得到满足。

Molich 在 2000 年指出，一个用户友好的系统应该实现以下五个目标，即易学、易记、高效、易用、易懂。

除了可用性的不同定义外，还有一些标准和质量模型和方法以属性和子属性的形式定义可用性，例如 ISO-9126、ISO-9241-11、ISO-13407 和 IEEE std。 610.12 等

UI 与可用性测试

UI 测试涉及测试软件的图形用户界面。UI 测试确保 GUI 根据要求运行，并在颜色、对齐、大小和其他属性方面进行测试。

另一方面，可用性测试可确保良好且用户友好的 GUI，可以轻松处理。UI 测试可以被视为可用性测试的一个子部分。

安全测试

安全测试涉及测试软件，以便从安全和漏洞的角度识别任何缺陷和差距。下面列出的是安全测试应确保的主要方面 –

  • 保密

  • 正直

  • 验证

  • 可用性

  • 授权

  • 不可否认性

  • 软件针对已知和未知漏洞是安全的

  • 软件数据安全

  • 软件符合所有安全法规

  • 输入检查和验证

  • SQL 插入攻击

  • 注射缺陷

  • 会话管理问题

  • 跨站脚本攻击

  • 缓冲区溢出漏洞

  • 目录遍历攻击

便携性测试

可移植性测试包括测试软件以确保其可重用性以及它也可以从另一个软件中移动。以下是可用于可移植性测试的策略 –

  • 将已安装的软件从一台计算机传输到另一台计算机。

  • 构建可执行文件 (.exe) 以在不同平台上运行软件。

可移植性测试可以被视为系统测试的子部分之一，因为这种测试类型包括软件在不同环境中的使用情况的整体测试。计算机硬件、操作系统和浏览器是可移植性测试的主要焦点。可移植性测试的一些先决条件如下 –

  • 应该设计和编码软件，牢记可移植性要求。

  • 已对相关组件执行单元测试。

  • 已执行集成测试。

  • 测试环境已经搭建完成。

软件测试 – 文档

测试文档涉及应该在软件测试之前或期间开发的工件文档。

软件测试文档有助于估计所需的测试工作量、测试覆盖率、需求跟踪/跟踪等。本节描述了一些与软件测试相关的常用文档工件，例如 –

  • 测试计划
  • 测试场景
  • 测试用例
  • 追溯矩阵

测试计划

测试计划概述了将用于测试应用程序的策略、将使用的资源、执行测试的测试环境以及测试的限制和测试活动的时间表。通常，质量保证团队负责人将负责编写测试计划。

测试计划包括以下内容 –

  • 测试计划文档简介
  • 测试应用程序时的假设
  • 测试应用程序中包含的测试用例列表
  • 要测试的功能列表
  • 在测试软件时使用什么样的方法
  • 需要测试的可交付成果清单
  • 为测试应用程序分配的资源
  • 测试过程中涉及的任何风险
  • 要实现的任务和里程碑的时间表

测试场景

这是一条单行语句，用于通知将测试应用程序中的哪个区域。测试场景用于确保所有流程流都经过端到端测试。根据应用程序的规模和复杂性，应用程序的特定区域可以有少至一个测试场景到数百个场景。

术语“测试场景”和“测试用例”可以互换使用，但是测试场景有几个步骤，而测试用例只有一个步骤。从这个角度来看，测试场景是测试用例，但它们包括几个测试用例和它们应该执行的顺序。除此之外，每个测试都依赖于前一个测试的输出。

测试场景

测试用例

测试用例涉及执行测试任务时可以使用的一组步骤、条件和输入。此活动的主要目的是确保软件在其功能和其他方面是通过还是失败。测试用例的类型很多，例如功能测试用例、否定测试用例、错误测试用例、逻辑测试用例、物理测试用例、UI 测试用例等。

此外，编写测试用例是为了跟踪软件的测试覆盖率。通常，在编写测试用例时没有可以使用的正式模板。但是，以下组件始终可用并包含在每个测试用例中 –

  • 测试用例 ID
  • 产品模块
  • 产品版本
  • 修订记录
  • 目的
  • 假设
  • 先决条件
  • 脚步
  • 预期结果
  • 实际结果
  • 后置条件

许多测试用例可以从单个测试场景中派生出来。此外，有时为单个软件编写多个测试用例，统称为测试套件。

追溯矩阵

可追溯性矩阵（也称为需求可追溯性矩阵 – RTM）是用于在软件开发生命周期中跟踪需求的表格。它可用于前向跟踪（即从需求到设计或编码）或向后跟踪（即从编码到需求）。RTM 有许多用户定义的模板。

RTM 文档中的每个需求都与其关联的测试用例相关联，以便可以根据提到的需求进行测试。此外，Bug ID 也包括在内并与其相关的需求和测试用例相关联。该矩阵的主要目标是 –

  • 确保按照上述要求开发软件。
  • 有助于找到任何错误的根本原因。
  • 帮助在 SDLC 的不同阶段跟踪开发的文档。

软件测试 – 估计技术

估算测试所需的工作量是 SDLC 中主要且重要的任务之一。正确的估计有助于以最大的覆盖率测试软件。本节描述了一些可用于估算测试所需工作量的技术。

功能点分析

该方法基于对软件功能用户需求的分析，具有以下类别 –

  • 输出
  • 查询
  • 输入
  • 内部文件
  • 外部文件

测试点分析

此估计过程用于黑盒或验收测试的功能点分析。这种方法的主要元素是：规模、生产力、战略、接口、复杂性和统一性。

Mark-II 方法

它是一种用于基于最终用户功能视图分析和测量估计的估计方法。Mark-II 方法的程序如下 –

  • 确定观点
  • 计数的目的和类型
  • 定义计数的边界
  • 识别逻辑事务
  • 识别和分类数据实体类型
  • 计算输入数据元素类型
  • 计算功能大小

各种各样的

您可以使用其他流行的估算技术，例如 –

  • 德尔福技术
  • 基于类比​​的估计
  • 基于测试用例枚举的估计
  • 基于任务（活动）的估计
  • IFPUG方法

觉得文章有用？

点个广告表达一下你的爱意吧 ！😁