软件测试

软件测试是通过验证和验证检查工件和正在测试的软件的行为的行为。软件测试还可以提供对软件的客观,独立的视图,以使企业能够欣赏和了解软件实施的风险。测试技术包括但不一定仅限于:

  • 在各种情况下分析产品要求,例如行业视角,业务观点,可行性和可行性,实施,可用性,绩效,安全性,基础架构注意事项等。
  • 审查产品架构和产品的整体设计
  • 与产品开发人员合作,以改进编码技术,设计模式,可以根据各种技术(例如边界条件等)编写代码的测试。
  • 执行以检查行为的目的执行程序或应用程序
  • 查看部署基础架构以及相关脚本和自动化
  • 通过使用监视和可观察性技术参加生产活动

软件测试可以提供有关软件质量及其对用户或赞助商的风险的客观,独立的信息。

软件测试可以在某些特定假设的假设下确定软件的正确性(请参阅下面的测试难度的层次结构),但是测试无法识别软件中的所有故障。取而代之的是,它提供了一种批评比较,将产品的状态和行为与测试牙齿的状态和行为进行了比较 - 某人可能会认识到问题的原理或机制。这些口腔可能包括(但不限于)规格,合同,可比产品,相同产品的过去版本,有关预期或期望目的的推论,用户或客户期望,相关标准,适用法律或其他标准。

测试的主要目的是检测软件故障,以便可以发现和纠正缺陷。测试无法确定在所有条件下产品都能正常运行,但仅仅是在特定条件下它不能正常运行。软件测试的范围可能包括对代码的检查以及在各种环境和条件下执行该代码的执行以及检查代码方面:它是否按照应有的操作并执行需要做的事情。在当前的软件开发文化中,测试组织可能与开发团队分开。测试团队成员有各种角色。可以使用软件测试得出的信息来纠正开发软件的过程。

每个软件产品都有目标受众。例如,视频游戏软件的受众对银行软件的观众完全不同。因此,当组织开发或以其他方式投资软件产品时,它可以评估软件产品是否可以被其最终用户,目标受众,购买者和其他利益相关者接受。软件测试有助于进行此评估。

故障和失败

软件故障通过以下过程发生:程序员会出现错误(错误),这会导致软件源代码中的故障(缺陷,错误)。如果执行此故障,在某些情况下,系统将产生错误的结果,从而导致故障

并非所有故障都一定会导致故障。例如,死亡代码中的故障将永远不会导致故障。没有发现故障的故障可能会导致环境更改时故障。环境中这些变化的示例包括在新的计算机硬件平台上运行的软件,源数据的更改或与其他软件进行交互。单个故障可能导致多种失败症状。

并非所有软件故障都是由编码错误引起的。昂贵缺陷的一个常见来源是需求差距,即无法识别的要求,导致程序设计师的遗漏错误。需求差距通常是非功能性要求,例如可检验性可伸缩性可维护性性能安全性

输入组合和前提条件

软件测试的一个基本问题是,即使使用简单的产品,在输入和先决条件的所有组合(初始状态)下(初始状态)也不可行。这意味着软件产品中的故障数量可能非常大,并且在测试和调试中很难发现出现的缺陷。更重要的是,质量的非功能性维度(应该是如何应做的事情相比) -可用性可伸缩性性能兼容性可靠性- 可能是高度主观的;一个人构成足够价值的东西可能是另一个人无法忍受的。

软件开发人员不能测试所有内容,但是他们可以使用组合测试设计来确定获得所需覆盖范围所需的最少测试数量。组合测试设计使用户可以通过更少的测试获得更大的测试覆盖范围。无论他们是寻找速度还是测试深度,他们都可以使用组合测试设计方法在其测试用例中构建结构化变化。

经济学

NIST在2002年进行的一项研究报告说,软件错误每年耗资595亿美元。如果执行更好的软件测试,则可以避免三分之一以上的成本。

由于成本,外包软件测试非常普遍,中国,菲律宾和印度是首选目的地。

角色

软件测试可以由专用的软件测试人员完成;直到1980年代,通常使用“软件测试人员”一词,但后来也被视为一个单独的职业。关于软件测试的周期和不同目标,已经建立了不同的角色,例如测试经理测试铅测试分析师测试设计师测试人员自动化开发人员和测试管理员。软件测试也可以通过非专用软件测试仪进行。

历史

格伦福德·迈尔斯(Glenford J.社区将基本发展活动(例如调试)与验证分开。

测试方法

静态,动态和被动测试

软件测试中有许多方法。评论演练检查称为静态测试,而用给定的一组测试用例执行编程的代码称为动态测试

静态测试通常是隐式的,例如校对,加上编程工具/文本编辑器检查源代码结构或编译器(预编译器)时,将语法和数据流视为静态程序分析。当程序本身运行时,进行动态测试。动态测试可以在程序完成100%完成之前开始,以测试代码的特定部分并应用于离散功能或模块。这些的典型技术是使用存根/驱动程序或从调试器环境中执行。

静态测试涉及验证,而动态测试也涉及验证

被动测试意味着验证系统行为,而无需与软件产品进行任何互动。与主动测试相反,测试人员不提供任何测试数据,而是查看系统日志和迹线。他们挖掘出模式和特定行为,以做出某种决定。这与离线运行时验证日志分析有关。

探索方法

探索性测试是一种用于软件测试的方法,被简洁地描述为同时学习,测试设计和测试执行。 Cem Kaner在1984年创建了该术语,将探索性测试定义为“一种软件测试风格,强调个人测试人员的个人自由和责任,以通过处理与测试相关的学习,测试设计不断优化其工作的质量,测试执行和测试结果解释是在整个项目中并行运行的相互支持活动。”

“盒子”方法

传统上,软件测试方法分为白色和黑色盒子测试。这两种方法用于描述测试人员在设计测试用例时采取的观点。一种称为灰色盒子测试的混合方法也可以应用于软件测试方法。随着灰色盒子测试的概念(从特定的设计元素中开发了测试)引起了突出,这种黑色和白盒测试之间的“任意区别”已经逐渐消失。

白盒测试

White Box Testing Diagram
白盒测试图

白盒测试(也称为清晰的盒子测试,玻璃盒测试,透明的盒子测试和结构测试)验证了程序的内部结构或工作,而不是暴露于最终用户的功能。在白盒测试中,系统的内部视角(源代码)以及编程技能用于设计测试用例。测试仪选择输入以通过代码锻炼路径并确定适当的输出。这类似于在电路中测试节点,例如,电路测试(ICT)。

虽然可以在单元集成和软件测试过程的系统级别上应用白色框测试,但通常在单位级别进行。它可以测试一个单元内的路径,集成过程中单元之间的路径以及系统级测试期间的子系统之间的路径。尽管这种测试设计方法可能会发现许多错误或问题,但它可能无法检测到规范或缺失要求的未完成部分。

白盒测试中使用的技术包括:

  • API测试- 使用公共和私有API (应用程序编程接口)对应用程序进行测试
  • 代码覆盖范围- 创建测试以满足代码覆盖的某些标准(例如,测试设计师可以创建测试以导致程序中至少执行一次的所有语句)
  • 故障注入方法 - 故意引入故障以评估测试策略的功效
  • 突变测试方法
  • 静态测试方法

代码覆盖工具可以评估使用任何方法(包括黑框测试)创建的测试套件的完整性。这使软件团队可以检查很少经过测试的系统的一部分,并确保已测试了最重要的功能点。代码覆盖范围作为软件指标可以报告为:

  • 功能覆盖范围,报告执行功能
  • 语句覆盖范围,报告有关完成测试的行执行的行数
  • 决策覆盖范围,报告是否已执行给定测试的真实分支和错误分支

100%的语句覆盖范围可确保至少执行所有代码路径或分支(在控制流程方面)。这有助于确保正确的功能,但不足,因为相同的代码可能正确或错误地处理不同的输入。

黑盒测试

黑匣子图

黑框测试(也称为功能测试)将软件视为“黑匣子”,在没有任何内部实现的情况下检查功能,而无需看到源代码。测试人员只知道该软件应该做什么,而不是如何做。黑框测试方法包括:等效分区边界值分析全对测试状态过渡表决策表测试,模糊测试基于模型的测试用例测试,探索性测试和基于规范的测试。

基于规范的测试旨在根据适用要求测试软件的功能。这种测试水平通常需要向测试仪提供彻底的测试用例,然后他们可以简单地验证给定输入,输出值(或行为),“ IS”或“不是”与期望值不一样在测试案例中指定。测试用例围绕规格和要求构建,即该应用程序应该做什么。它使用软件的外部描述,包括规格,需求和设计来得出测试用例。这些测试可以是功能性的或非功能性的,尽管通常是功能性的。

基于规范的测试可能需要确保正确的功能,但是防止复杂或高风险情况不足。

黑匣子技术的一个优点是不需要编程知识。无论程序员可能拥有什么偏见,测试人员都可能具有不同的集合,并且可能会强调不同的功能领域。另一方面,据说黑盒测试“就像在没有手电筒的黑暗迷宫中散步”。由于他们没有检查源代码,因此在某些情况下,测试人员写许多测试用例来检查可能仅通过一个测试案例测试的东西,或者没有测试程序的某些部分。

这种测试方法可以应用于所有级别的软件测试:单元集成系统接受。它通常包括更高级别的大多数(即使不是全部)测试,但也可以主导单位测试。

组件接口测试

组件接口测试是黑盒测试的变体,关注数据值不仅仅是子系统组件的相关操作。组件接口测试的实践可用于检查除这些单元之间的完全集成测试之外的各个单元或子系统组件之间传递的数据的处理。传递的数据可以视为“消息数据包”,可以检查范围或数据类型,以获取从一个单元生成的数据,并在传递到另一个单元之前对有效性进行了测试。接口测试的一种选项是保留传递数据项的单独日志文件,通常使用时间戳记录,以分析数千个单位之间传递的数据案例,几天或几周。测试可以包括检查某些极端数据值的处理,而其他接口变量作为正常值传递。接口中的异常数据值可以帮助解释下一个单元中的意外性能。

视觉测试

视觉测试的目的是通过呈现数据以使开发人员可以轻松地找到他或她所需的信息来检查开发人员检查软件故障时发生的事情,并且清楚地表达了信息。 。

视觉测试的核心是向某人出现问题(或测试失败)的想法,而不是仅仅描述它,而是大大提高了清晰度和理解。因此,视觉测试需要记录整个测试过程 - 以视频格式捕获测试系统上发生的所有内容。输出视频由实时测试人员输入通过图片中的网络摄像头和麦克风的音频评论来补充。

视觉测试提供了许多优势。沟通质量大大提高,因为测试人员可以向开发人员展示该问题(以及导致该问题的事件),而不是仅描述它,并且在许多情况下复制测试失败的需求将不再存在。开发人员将拥有他或她需要测试失败的所有证据,而可以专注于故障的原因以及应如何固定。

临时测试探索性测试是检查软件完整性的重要方法,因为它们需要更少的准备时间来实施,而可以快速找到重要的错误。在临时测试中,在以即兴,即兴的方式进行测试的情况下,测试仪的基础测试的能力以及这些测试的即兴变化可能会导致对缺陷修复程序进行更严格的检查。但是,除非维持严格的程序文档,否则临时测试的限制之一是缺乏可重复性。

灰色盒子测试

Grey-Box测试(American Spelling:Gray-Box测试)涉及了解内部数据结构和算法,以设计测试,同时在用户或Black-Box级别执行这些测试时。测试仪通常可以访问“源代码和可执行二进制”。 Grey-Box测试还可以包括反向工程(使用动态代码分析)来确定边界值或错误消息。操纵输入数据和格式输出不符合灰色框的资格,因为输入和输出显然在我们正在调用的系统测试的“黑匣子”之外。在两个不同开发人员编写的两个代码模块之间进行集成测试时,这种区别尤其重要,其中仅接口进行测试。

通过了解软件如何工作的基本概念,测试仪在外部测试软件时做出了更明智的测试选择。通常,将允许灰色盒子测试仪建立一个隔离的测试环境,其中包括播种数据库等活动。测试仪可以在执行某些操作(例如针对数据库执行SQL语句,然后执行查询)之后观察正在测试的产品状态,以确保反映了预期的更改。灰色盒子测试基于有限的信息实现智能测试方案。这特别适用于数据类型处理,异常处理等。

测试水平

从广义上讲,至少有三个级别的测试:单元测试,集成测试和系统测试。但是,开发人员可能会包括第四级,即接受测试。这可能以操作接受测试的形式或简单的最终用户(beta)测试,测试以确保软件满足功能性期望。基于ISTQB认证的测试基础级课程提纲,测试级别包括这四个级别,第四级被命名为接受测试。测试经常通过在软件开发过程中或测试的特异性级别中添加的位置将测试分组为其中一个级别。

单位测试

单位测试是指通常在功能级别上验证代码特定部分的功能的测试。在面向对象的环境中,这通常是在班级级别,最小的单元测试包括构造函数和驱动器。

这些类型的测试通常由开发人员在代码(白色框样式)上工作时编写,以确保特定功能按预期工作。一个函数可能具有多个测试,以捕获代码中的角案例或其他分支。单独的单元测试无法验证软件的功能,而是用来确保软件的构件彼此独立地工作。

单元测试是一个软件开发过程,涉及多种缺陷预防和检测策略的同步应用,以减少软件开发风险,时间和成本。它是由软件开发人员或工程师在软件开发生命周期的构建阶段执行的。单位测试旨在在将代码提升为其他测试之前消除施工错误;该策略旨在提高所得软件的质量以及整体开发过程的效率。

根据组织对软件开发的期望,单位测试可能包括静态代码分析数据流分析,指标分析,PEER代码审查,代码覆盖范围分析和其他软件测试实践。

集成测试

集成测试是任何类型的软件测试,旨在通过软件设计验证组件之间的接口。软件组件可以以迭代方式或全部集成在一起(“大爆炸”)。通常,前者被认为是更好的做法,因为它允许界面问题更快,固定。

集成测试有助于揭示界面中的缺陷以及集成组件(模块)之间的相互作用。逐渐将与建筑设计元素相对应的较大的测试软件组件进行集成和测试,直到软件作为系统工作为止。

系统测试

系统测试测试一个完全集成的系统,以验证系统是否满足其要求。例如,系统测试可能涉及测试登录接口,然后创建和编辑条目,以及发送或打印结果,然后进行摘要处理或删除(或归档)条目,然后进行注销。

验收测试

接受测试通常包括以下四种类型:

  • 用户接受测试(UAT)
  • 操作接受测试(OAT)
  • 合同和法规接受测试
  • Alpha和Beta测试

在下一个测试类型部分中描述了UAT以及Alpha和Beta测试。

作为质量管理系统的一部分,使用运营接受度来进行产品,服务或系统的操作准备就绪(预发行)。 OAT是一种非功能软件测试的常见类型,主要用于软件开发软件维护项目。这种类型的测试重点是要支持的系统的操作准备,或者成为生产环境的一部分。因此,它也称为操作准备测试(ORT)或操作准备和保证(OR&A)测试。燕麦中的功能测试仅限于验证系统非功能方面所需的测试。

此外,软件测试应确保系统的可移植性以及预期的工作,也不会损坏或部分破坏其操作环境,或在该环境中引起其他流程,以使其无法工作。

合同接受测试是根据合同协议期间定义的合同接受标准进行的,而监管验收测试是根据软件产品的相关法规进行的。这两个测试都可以由用户或独立的测试人员执行。调节接受测试有时涉及审核测试结果的监管机构。

测试类型,技术和策略

不同的标签和分组方式可能是测试类型,软件测试策略或技术。

TestingCup- 2016年5月Katowice的软件测试冠军

安装测试

大多数软件系统都有在将其用于主要目的之前需要的安装过程。测试这些过程以实现可能使用的已安装软件系统,称为安装测试。这些过程可能涉及完整或部分升级,并安装/卸载过程。

  • 用户必须选择各种选项。
  • 依赖的文件和库必须分配,加载或定位。
  • 必须存在有效​​的硬件配置。
  • 软件系统可能需要连接才能连接到其他软件系统。

兼容性测试

软件故障的常见原因(真实或感知)是缺乏与其他应用程序软件操作系统(或操作系统版本,旧或新的)或与原始差异很大的目标环境(例如终端或终端或目标环境)的兼容性GUI应用程序旨在在桌面上运行,现在需要在Web浏览器中呈现Web应用程序。例如,在缺乏向后兼容性的情况下,可能会发生这种情况,因为程序员仅在目标环境的最新版本上开发和测试软件,这并非所有用户都可以运行。这导致了意想不到的后果,即最新作品可能无法在目标环境的早期版本上或目标环境的早期版本能够使用的旧硬件上起作用。有时,可以通过主动将操作系统功能抽象到单独的程序模块中来解决此类问题。

烟与理智测试

理智测试决定了进行进一步测试是否合理。

烟雾测试包括操作软件的最少尝试,旨在确定是否有任何基本问题可以阻止其工作。此类测试可以用作构建验证测试

回归测试

回归测试重点是在发生重大代码更改后找到缺陷。具体来说,它试图发现软件回归,因为降级或丢失的功能,包括返回的旧错误。每当先前正常工作的软件功能停止按预期工作时,就会发生这种回归。通常,当软件的新开发一部分与先前现有的代码相撞时,回归是程序更改的意外结果。回归测试通常是商业软件开发中最大的测试工作,因为在先前的软件功能中检查了许多详细信息,甚至可以在使用一些旧测试用例测试新设计的一部分以确保仍然支持先前功能的同时开发新软件。

回归测试的常见方法包括重新运行以前的测试用例集,并检查先前固定的故障是否已重新出现。测试的深度取决于释放过程中的阶段和附加功能的风险。它们要幺可以完成,要幺在发行版中添加的更改,也可以被认为是风险的,或者非常浅,包括对每个功能的积极测试,如果更改在发行版本的早期或认为具有低风险。

验收测试

接受测试可能意味着两件事之一:

  1. 在进行回归之前,将烟雾测试用作进一步测试之前的建筑接受测试。
  2. 客户通常在自己的硬件上在实验室环境中进行的接受测试称为用户接受测试(UAT)。接受测试可以作为开发的任意两个阶段之间的交接过程的一部分。

α测试

潜在用户/客户或开发人员网站的独立测试团队模拟Alpha测试或实际操作测试。在该软件进行Beta测试之前,通常将Alpha测试用于现成软件作为内部接受测试的一种形式。

Beta测试

Beta测试是在Alpha测试之后进行的,可以被视为一种外部用户接受测试的形式。该软件的版本(称为Beta版本)将发布给有限的受众群体,该组织被称为Beta Testers。该软件已发布给一组人,以便进一步的测试可以确保产品几乎没有故障或错误。可以向公开公开场所提供Beta版本,以将反馈字段增加到最大数量的未来用户,并提早提供价值,以延长甚至不确定的时间(永久性beta )。

功能与非功能测试

功能测试是指验证代码的特定操作或功能的活动。这些通常在代码要求文档中可以找到,尽管某些开发方法从用例或用户故事起作用。功能测试倾向于回答“用户可以执行此操作”或“此特定功能有效的问题”的问题。

非功能性测试是指软件的各个方面可能与特定功能或用户操作无关,例如可扩展性或其他性能,某些约束安全性下的行为。测试将确定断裂点,可伸缩性或性能的极端导致执行不稳定的点。非功能性要求往往是反映产品质量的要求,尤其是在其使用者的适用性观点的背景下。

连续测试

连续测试是作为软件交付管道的一部分执行自动测试的过程,以获得与软件发布候选者相关的业务风险的立即反馈。连续测试包括验证功能需求非功能性要求;测试范围从验证自下而上的要求或用户故事到评估与总体业务目标相关的系统要求。

破坏性测试

破坏性测试试图导致软件或子系统失败。它可以验证该软件即使收到无效或意外输入的软件也可以正常运行,从而确立了输入验证和错误管理例程的鲁棒性软件故障注入模糊的形式是故障测试的一个例子。从软件故障注入页面链接了各种商业非功能测试工具;还有许多可以执行破坏性测试的开源和免费软件工具。

软件性能测试

通常执行性能测试以确定系统或子系统在特定工作负载下的响应性和稳定性方面的性能。它还可以用于调查,测量,验证或验证系统的其他质量属性,例如可扩展性,可靠性和资源使用情况。

负载测试主要涉及测试系统可以在特定的负载下继续运行,无论是大量数据还是大量用户。这通常称为软件可伸缩性。当作为非功能活动进行的相关负载测试活动通常称为耐力测试卷测试是测试软件功能功能的一种方法,即使某些组件(例如文件或数据库)的大小会增加。压力测试是在意外或稀有工作量下测试可靠性的一种方法。稳定性测试(通常称为负载或耐力测试)检查该软件在可接受的时期内是否可以连续运行良好。

关于绩效测试的具体目标几乎没有共识。术语负载测试,性能测试,可伸缩性测试和音量测试通常可以互换使用。

实时软件系统具有严格的正时限制。为了测试是否达到了定时限制,使用实时测试

可用性测试

可用性测试是检查用户界面是否易于使用和理解。它主要与应用程序的使用有关。这不是可以自动化的测试;需要实际的人类用户,由熟练的UI设计师监视。

可访问性测试

进行可访问性测试是为了确保残疾人可以访问该软件。一些常见的Web可访问性测试是

  • 确保字体和背景颜色之间的颜色对比是合适的
  • 字体大小
  • 多媒体内容的替代文本
  • 除鼠标外,还可以使用计算机键盘使用系统。

合规性标准

安全测试

安全测试对于处理机密数据以防止黑客入侵的软件至关重要。

国际标准化组织(ISO)将其定义为“进行的一种测试类型,以评估测试项目以及相关的数据和信息受到保护,以便未经授权的人员或系统无法使用,读取或修改它们,并且授权人员或系统没有被拒绝访问它们。”

国际化和本地化

国际化和本地化的测试证实了该软件可以与不同的语言和地理区域一起使用。伪定位的过程用于测试将应用程序翻译成另一种语言的能力,并使其更容易识别本地化过程何时将新的错误引入产品。

全球化测试验证该软件是否适用于新文化(例如不同的货币或时区)。

也必须测试对人类语言的实际翻译。可能的本地化和全球化故障包括:

  • 软件通常是通过从上下文中翻译字符串列表来定位的,翻译人员可以为模棱两可的源字符串选择错误的翻译。
  • 如果该项目是由几个没有适当协调的人翻译的,或者翻译人员不明智的话,技术术语可能会变得不一致。
  • 字面上的单词翻译听起来可能是不适当的,人为的或太技术的目标语言。
  • 原始语言的未翻译消息可以在源代码中进行硬编码
  • 某些消息可以在运行时自动创建,并且所得的字符串可能是语法上的,功能不正确,误导或混乱。
  • 软件可以使用键盘快捷键,该快捷键在源语言的键盘布局上没有功能,但用于在目标语言的布局中键入字符。
  • 软件可能缺乏对目标语言的字符编码的支持。
  • 在源语言中适当的字体和字体大小在目标语言中可能不合适;例如,如果字体太小, CJK字符可能会变得不可读。
  • 目标语言中的字符串可能比软件所能处理的要长。这可能会使字符串部分看不见用户或导致软件崩溃或故障。
  • 软件可能缺乏对阅读或编写双向文本的适当支持。
  • 软件可以显示带有未本地化的文本的图像。
  • 本地化操作系统可能具有不同命名的系统配置文件环境变量以及日期货币的不同格式。

开发测试

开发测试是一个软件开发过程,涉及多种缺陷预防和检测策略的同步应用,以减少软件开发风险,时间和成本。它是由软件开发人员或工程师在软件开发生命周期的构建阶段执行的。开发测试旨在在将代码推广到其他测试之前消除施工错误。该策略旨在提高所得软件的质量以及整体开发过程的效率。

根据组织对软件开发的期望,开发测试可能包括静态代码分析,数据流分析,指标分析,PEER代码审查,单位测试,代码覆盖范围分析,可追溯性和其他软件测试实践。

A/B测试

A/B测试是运行受控实验的一种方法,以确定所提出的更改是否比当前方法更有效。将客户路由到功能的当前版本(控件),或者是修改后的版本(处理),并收集数据以确定哪个版本更好地实现了所需的结果。

并发测试

并发或并发测试评估通常在正常使用条件下使用并发计算的软件和系统的行为和性能。典型的问题这种类型的测试将暴露在内,种族条件以及共享内存/资源处理的问题。

一致性测试或类型测试

在软件测试中,一致性测试验证了产品根据其指定标准执行的。例如,对编译器进行了广泛的测试,以确定它们是否符合该语言的公认标准。

输出比较测试

创建显示预期输出的显示,无论是作为数据比较的文本比较还是UI的屏幕截图,有时称为快照测试或与许多其他形式的测试不同,这都无法自动检测到失败,而是要求人类评估输出的不一致之处。

属性测试

属性测试是一种测试技术,在这种技术中,从业者随机生成许多输入,而不是断言特定的输入产生特定的预期输出,而是在所有输入中运行程序,并主张某些“属性”的真实性,这些真相应为每一对正确输入和输出。例如,序列化函数的每个输出都应被相应的避免函数接受,并且排序函数的每个输出都应单调增加列表,其中包含与其输入完全相同的元素。

属性测试库允许用户控制构建随机输入的策略,以确保覆盖堕落案例或具有特定模式的输入,以充分遵守测试的实施方案。

属性测试有时也称为“生成测试”或“ QuickCheck Testing”,因为它是由Haskell Library QuickCheck引入和普及的。

变质测试

变质测试(MT)是一种基于属性的软件测试技术,这可能是解决测试甲骨文问题和测试案例生成问题的有效方法。测试甲骨文问题是确定所选测试用例的预期结果或确定实际输出是否与预期结果一致的困难。

VCR测试

VCR测试,也称为“播放测试”或“记录/重播”测试,是一种测试技术,用于提高回归测试的可靠性和速度,该测试涉及一个慢慢或不可靠的组件,通常是第三方API在测试人员的控制之外。它涉及制作系统与外部组件的交互的录制(“盒式”),然后重播记录的交互作用,作为在后续测试中与外部系统通信的替代品。

该技术由Ruby Library VCR在Web开发中普及。

测试过程

传统瀑布发展模型

瀑布发展中的一种常见做法是,测试是由独立的一组测试人员进行的。这可能发生:

  • 开发功能后,但在将其运送给客户之前。这种做法通常会导致测试阶段用作项目缓冲区,以补偿项目延迟,从而损害了用于测试的时间。
  • 与此同时,开发项目是一个连续过程,直到项目完成为止。

但是,即使在瀑布开发模型中,即使由单独的团队进行进一步的测试,也经常由软件开发团队进行单元测试。

敏捷或XP开发模型

相比之下,一些新兴的软件学科,例如Extreme编程敏捷软件开发运动,遵循“测试驱动的软件开发”模型。在此过程中,首先是由软件工程师编写的(通常在极端编程方法中具有配对编程)。测试最初有望失败。每个失败的测试之后都是编写足够的代码以使其通过。这意味着,随着发现新的故障条件和角病例,测试套件会不断更新,并将其与开发的任何回归测试集成在一起。将单元测试与软件源代码的其余部分一起维护,并通常集成到构建过程中(固有的交互式测试将降级为部分手动构建接受过程)。

该测试过程的最终目标是支持持续整合并降低缺陷率。

在到达任何正式的测试团队之前,该方法增加了通过开发完成的测试工作。在其他一些开发模型中,大多数测试执行发生在定义要求并完成编码过程之后。

样品测试周期

尽管组织之间存在差异,但仍有一个典型的测试周期。下面的样本在采用瀑布发展模型的组织中很常见。在其他开发模型中通常可以找到相同的实践,但可能并不清楚或明确。

  • 需求分析:测试应从软件开发生命周期的需求阶段开始。在设计阶段,测试人员致力于确定设计的哪些方面是可测试的,以及这些测试有效的参数。
  • 测试计划:测试策略测试计划测试床创建。由于在测试过程中将进行许多活动,因此需要计划。
  • 测试开发:测试程序,测试场景测试案例,测试数据集,用于测试软件中使用的测试脚本。
  • 测试执行:测试人员根据计划和测试文档执行软件,然后向开发团队报告任何错误。由于缺乏编程知识,运行测试时,这部分可能很复杂。
  • 测试报告:一旦测试完成,测试人员就会生成指标,并就其测试工作以及测试软件是否准备发布的最终报告。
  • 测试结果分析:或缺陷分析是由开发团队通常与客户一起完成的,以确定应分配,固定,拒绝的缺陷(即发现软件正常工作)或推迟以后进行处理。
  • 重新测试缺陷:一旦开发团队处理了一个缺陷,它将被测试团队重新测试。
  • 回归测试:对于新的,修改或固定的软件的每次集成,以确保最新的交付没有破坏任何东西,并且该软件产品作为一个,通常将小型测试程序构建为测试子集,以确保最新的交付整体仍在正常工作。
  • 测试关闭:一旦测试符合退出标准,就将捕获关键输出,经验教训,结果,日志,与项目相关的文档进行归档并将其用作未来项目的参考。

自动测试

许多编程小组越来越依赖自动化测试,尤其是使用测试驱动开发的组。有许多框架可以在其中编写测试,并且连续集成软件将每次将代码选中到版本控制系统时自动运行测试。

尽管自动化无法复制人类可以做的一切(以及他们认为这样做的所有方式),但对于回归测试来说可能非常有用。但是,它确实需要一套完善的测试脚本测试套件,才能真正有用。

测试工具

通过测试工具和辩论者可以在很大程度上帮助程序测试和故障检测。测试/调试工具包括以下功能:

这些功能中的一些可以将其纳入单个复合工具或集成开发环境(IDE)中。

捕获和重播

捕获和重播测试包括在与应用程序进行交互并将这些方案变成测试用例时收集端到端用法方案。捕获和重播的可能应用包括回归测试的生成。 Scarpe工具在执行时选择性地捕获了正在研究的应用程序的子集。 JRAPTURE捕获执行Java程序与主机系统(例如文件)或图形用户界面上的事件之间的相互作用的顺序。然后可以重播这些序列以进行基于观察的测试。 Saieva等。建议生成临时测试,以重新录制的用户执行跟踪,以便为关键安全错误测试候选补丁。

软件测试的测量

质量措施包括正确性,完整性,安全性ISO/IEC 9126要求,例如功能,可靠性效率可移植性可维护性,兼容性和可用性

有许多常用的软件指标或措施,用于帮助确定软件状态或测试的是否足够。

测试难度的层次结构

基于在每个上下文中构建完整测试套件所需的测试用例数(即测试套件,因此,如果将其应用于正在测试的实施中,则我们收集足够的信息以精确确定系统是正确还是不正确根据一些规范),已经提出了测试难度的层次结构。它包括以下可检验性类:

  • I类:存在有限的完整测试套件。
  • II类:可以使用有限的测试套件来达到任何部分区分速率(即,将正确系统与不正确系统区分开的任何不完整能力)。
  • III级:存在一个可数的完整测试套件。
  • IV类:存在完整的测试套件。
  • V类:所有情况。

已经证明,每个班级都严格包括在下一个。例如,测试当我们假设正在测试的实施的行为可以用确定性的有限状态机器来表示某些已知有限的输入和输出集,并且具有某些已知数量的状态属于I类(以及所有后续类) )。但是,如果未知状态的数量,则仅属于II类中的所有类。如果正在测试的实现必须是确定性的有限状态机,而单个跟踪(及其连续性)的规范失败,并且其状态数量未知,那么它仅属于III类中的类。如果在某些实际结合的间隔内产生输入仅属于IV类中的类,则测试触发过渡的时间机,而测试许多非确定性系统仅属于V类(但不属于所有类别,甚至属于I类) 。将I类包含在I类中不需要假定的计算模型的简单性,因为一些涉及以任何编程语言编写的实现的测试案例,并且根据连续幅度定义为机器的测试实现,已被证明是在I类中。诸如Matthew Hennessy在必须语义下的测试框架以及具有理性超时的颞机器的情况属于II类。

测试工件

软件测试过程可以产生多个工件。实际生产的工件是使用软件开发模型,利益相关者和组织需求的因素。

测试计划

测试计划是一份文档,详细介绍了预期测试活动的方法。该计划可能包括目标,范围,过程和程序,人员要求和应急计划等方面。测试计划可以以单个计划的形式出现,其中包括所有测试类型(例如接受或系统测试计划)和计划注意事项,也可以将其作为总测试计划发布,该计划提供了多个详细测试的概述计划(计划的计划)。在某些情况下,测试计划可以是广泛的“测试策略”的一部分,该策略记录了整体测试方法,这本身可能是总测试计划,甚至是单独的工件。

可追溯性矩阵

软件开发中,可追溯性矩阵(TM)是一个文档,通常是以表格的形式,用于通过使用多一关系的关系比较来帮助确定关系的完整性。它通常用于高级要求(通常包含营销要求)以及产品的详细要求,可与高级设计,详细的设计,测试计划测试用例的匹配部分一起使用。

测试用例

测试案例通常由唯一的标识符,设计规范中的要求参考,事件,事件,一系列步骤(也称为操作),以遵循,输入,输出,预期,预期结果和实际结果。临床定义,测试案例是输入和预期结果。这可以像“适用于条件x”的衍生结果是y'一样简短,尽管通常测试案例更详细地描述了输入方案以及可能预期的结果。它有时可能是一系列步骤(但通常将步骤包含在一个单独的测试程序中,该程序可以针对多个测试案例进行,但要与经济有关),但有一个预期的结果或预期的结果。可选字段是测试用例ID,测试步骤或执行号,相关要求,深度,测试类别,作者和复选框,用于测试是否可自动化并且已自动化。较大的测试用例也可能包含先决条件或步骤以及描述。测试用例还应包含用于实际结果的位置。这些步骤可以存储在文字处理器文档,电子表格,数据库或其他常见存储库中。在数据库系统中,您还可以看到过去的测试结果,谁生成结果以及使用了哪种系统配置来生成这些结果。这些过去的结果通常会存储在单独的表中。

测试脚本

测试脚本是复制用户操作的过程或编程代码。最初,该术语源自由自动回归测试工具创建的工作的产物。测试用例将是使用工具或程序创建测试脚本的基线。

测试套件

软件开发中,测试套件,鲜为人知的验证套件是一组测试用例,旨在用于测试软件程序以表明其具有一些指定的行为集。测试套件通常包含每个测试用例集合的详细说明或目标,以及有关在测试过程中要使用的系统配置的信息。一组测试用例还可能包含先决条件或步骤,以及以下测试的描述。

测试夹具或测试数据

在大多数情况下,多组值或数据用于测试特定功能的相同功能。所有测试值和可更改的环境组件都收集在单独的文件中,并作为测试数据存储。将这些数据提供给客户以及产品或项目也很有用。有生成测试数据的技术。

测试安全带

软件,工具,数据输入和输出样本以及配置均集体称为测试安全带

测试运行

测试运行是用户正在执行并将预期与实际结果进行比较的测试案例或测试套件的集合。完成后,可以生成报告或所有执行测试。

认证

已经存在几种认证计划,以支持软件测试人员和质量保证专家的专业愿望。一些从业者认为,如争议部分所述,测试领域还没有准备好认证。

争议

一些主要的软件测试争议包括:

敏捷与传统
测试人员应该学会在不确定性和不断变化的条件下工作,还是应该旨在“成熟”过程?自2006年以来,敏捷测试运动主要是在商业界的越来越受欢迎的,而政府和军事软件提供商则使用这种方法,但也使用传统的测试模型(例如,在瀑布模型中)。
手动与自动测试
一些作家认为,相对于其价值而言,测试自动化是如此昂贵,以至于应谨慎使用。然后,可以将测试自动化视为捕获和实施要求的一种方式。通常,系统越大,复杂性越大,测试自动化中的ROI就越大。此外,可以在组织内部具有适当知识共享水平的多个项目上摊销对工具和专业知识的投资。
ISO 29119软件测试标准是否存在合理的存在?
关于ISO 29119标准的上下文驱动的软件测试学院的重大反对派。专业测试协会(例如国际软件测试协会)试图撤回标准。
一些从业者宣布测试领域还没有准备好进行认证
现在没有提供认证实际上要求申请人显示其测试软件的能力。没有认证基于广泛接受的知识体系。认证本身无法衡量个人的生产力,他们的技能或实践知识,并且不能保证其作为测试人员的能力或专业精神。
用于显示固定缺陷的相对费用的研究
关于用于表明固定缺陷的相对费用的研究的适用性,根据其引入和检测,存在相反的看法。例如:

人们普遍认为,发现较早的缺陷,修复它的便宜。下表显示了根据发现的阶段固定缺陷的成本。例如,如果仅在释放后发现要求中存在问题,那么修复的费用要比需求审查已经发现的问题要高10-100倍。随着现代连续部署实践和基于云的服务的出现,随着时间的推移,重新部署和维护的成本可能会降低。

解决缺陷的成本检测到时间
要求建筑学建造系统测试释放后
引入时间要求5–10×10×10–100×
建筑学10×15×25–100×
建造10×10–25×

该表被推断的数据很少。劳伦特·博斯维特(Laurent Bossavit)在他的分析中说:

事实证明,“较小的项目”曲线仅来自两名一年级学生的团队,一个样本量很小,以至于将“一般而言”的“较小项目”推送到完全是无法辩护的。 GTE研究没有解释其数据,除了说它来自两个项目,一个大小。为贝尔实验室“保障”项目引用的论文专门拒绝了Boehm的数据点所暗示的细粒度数据。 IBM研究(Fagan的论文)包含似乎与Boehm的图形相矛盾的说法,并且没有明显与他的数据点相对应的数值结果。

Boehm甚至没有引用TRW数据的论文,除非在2010年为“制作软件”写作时,他引用了1976年的原始文章。 Boehm在正确的时间在TRW进行了一项大型研究,但该论文不包含支持Boehm主张的数据。

相关过程

软件验证和验证

软件测试与验证和验证有关:

  • 验证:我们构建了该软件吗? (即,它是否实现了要求)。
  • 验证:我们是否构建了正确的软件? (即,使可交付成果满足客户的满意)。

术语验证和验证在行业中通常可以互换;通常,看到这两个术语与矛盾的定义定义。根据IEEE软件工程术语的标准词汇表

验证是评估系统或组件的过程,以确定给定开发阶段的产物是否满足该阶段开始时施加的条件。
验证是在开发过程结束期间或在开发过程结束时评估系统或组件以确定其是否满足指定要求的过程。

并且,根据ISO 9000标准:

验证是通过检查确认,并通过提供已经满足特定要求的客观证据。
验证是通过检查确认,并通过提供客观证据,表明已经满足了特定预期使用或应用的要求。

矛盾是由使用要求和指定要求的概念而引起的,但含义不同。

对于IEEE标准,验证定义中提到的指定要求是该软件必须解决和满足的利益相关者的问题,需求和需求。此类要求记录在软件需求规范(SRS)中。并且,验证定义中提到的产品是软件开发过程每个阶段的输出工件。实际上,这些产品是诸如体系结构设计规范,详细的设计规范等规范。SRS也是一个规范,但无法验证(至少在此处使用的意义上没有,在下面使用此主题)。

但是,对于ISO 9000,指定的要求是必须验证的一组规格。如前所述,规范是软件开发过程阶段的产物,该阶段接收另一种规范作为输入。当规范正确实施其输入规范时,将成功验证规范。除SRS之外,所有规格都可以验证,因为它是第一个规格(不过,它可以验证)。示例:设计规范必须实现SRS;而且,施工阶段工件必须实施设计规范。

因此,当这些单词以通用术语定义时,明显的矛盾就会消失。

SRS和软件都必须验证。可以通过与利益相关者进行咨询来静态验证SRS。然而,运行该软件的某些部分实现或任何形式的原型(动态测试)并从中获得正面反馈,可以进一步提高SRS正确配制的SRS的确定性。另一方面,该软件作为最终产品和运行的产品(不是其工件和文档,包括源代码),必须通过执行软件并让他们尝试使用该软件来动态验证利益相关者。

有人可能会争辩说,对于SRS,输入是利益相关者的词语,因此SRS验证与SRS验证相同。这种方式不建议这样做,因为它只会引起更多的混乱。最好将验证视为涉及正式和技术输入文档的过程。

软件质量保证

软件测试可以被视为软件质量保证(SQA)过程的一部分。在SQA中,软件流程专家和审核员关注的是软件开发过程,而不仅仅是文档,代码和系统等工件。他们检查和更改软件工程过程本身,以减少最终在已交付的软件中出现的故障数量:所谓的缺陷率。什么构成可接受的缺陷率取决于软件的性质;与实际飞机的软件相比,飞行模拟器视频游戏的缺陷公差要高得多。尽管与SQA有密切的链接,但是测试部门通常独立存在,并且某些公司可能没有SQA功能。

软件测试是一项研究正在测试的软件,以便向利益相关者提供与质量相关的信息。相比之下,质量保证(质量保证)是旨在防止缺陷接触客户的政策和程序的实施。

也可以看看