什么是软件测试中的测试用例?
测试用例是一个广义的术语，用于描述检查过去结果的项目或事件。测试用例是一组文档化的操作——操作步骤——在软件测试的实践和专业中管理对特定需求的观察和分析。
下面的讨论将只涵盖上面描述的上下文中的测试用例。要了解与测试用例和软件测试原则和实践相关的概念的完整范围的更多信息，包括软件测试的特定级别(单元、烟雾、回归、集成、系统、验收等等)、不同的测试方法(黑盒、白盒和非功能测试)，以及手动测试和软件测试自动化的动态，请阅读本文关于自动化软件测试的文章。
测试用例是软件开发生命周期(SDLC)中不可或缺的组成部分。软件测试人员通常将编写、执行和记录SDLC作为质量保证(QA)过程的一部分。通过执行指定的操作，测试人员可以发现软件的问题并识别缺陷(或bug)。
测试用例文档向其他人描述测试人员如何达到每次试验的结果。该文档验证了测试活动，并列出了有助于得出结论的组件。测试用例中的一组条件定义了测试的结果。通过执行测试用例指定的操作，团队可以确定软件代码单元、被测应用程序(AUT)的特性，或者被测系统(SUT)背后的整体软件是否满足预期的行为。
标准测试用例格式
无论您是使用文字处理文档、电子表格，还是测试管理工具，都要格式化测试用例，以处理单个需求的单个可执行测试的步骤。测试用例文档没有被设计成过去结果的数据库日志，因此它没有被格式化以显示以前的结果。
测试用例说明要测试的内容、预期的结果，以及确定独立的通过/失败结果所涉及的步骤。通常，测试用例包括以下测试标准字段:
测试用例声明:该声明，或测试描述，提供了关于测试寻求确认的信息(即，被测试的需求)，用于执行测试的工具，测试的条件(环境)，以及关于可选测试技术的信息，如果适用的话。(可选测试技术的例子包括等价划分、错误猜测和过渡状态测试。)在编写测试用例语句时，始终牢记最终用户。
测试设置:这些是测试的先决条件。它们包括测试评审、测试批准、测试执行计划、测试证明、测试报告过程、适当的用例，以及与测试需求相关的风险。测试用例依赖包括AUT的版本信息、相关的数据文件、操作系统和硬件的类型、浏览器详细信息、安全许可、日期和时间。
测试用例ID:测试用例必须是可识别的，并且可以追溯到作为测试结果记录的错误或缺陷。此方法有助于正确地识别和记录每个测试用例和已知错误，并有助于避免冗余测试。
测试场景:这包括以特定的、详细的目标的形式提供的关于测试的信息，这些目标可以帮助测试人员执行更准确的分析。然而，它不包括特定的步骤或顺序。测试场景处理可能与多个测试用例重叠的过程。
测试步骤:测试步骤是透明的;它们以简单明了的方式告诉测试人员如何执行测试。它们还让测试人员知道执行这些步骤的正确顺序。使用主动语态来描述具体的动作，这样人们可以很快地理解目的。这些步骤是原子性的——换句话说，当测试失败时，由于这些步骤没有与多个测试需求或子功能重叠，因此对于需要修复的内容有一个清晰的概念。
测试数据:此部分包括执行特定测试步骤所必需的变量，如帐户信息、电子邮件地址或输入值。边界分析测试是一种确定测试数据范围参数的方法。例如，测试人员将使用最小和最大数量的字符值来测试密码工具。
预期结果:这包括测试人员期望从测试中看到和收集的任何详细和精确的信息或数据。
实际结果:记录您从测试中收到的所有正面和负面结果，以帮助确认或拒绝预期结果，并检测任何问题或错误。
通过/失败的确认:这是过程的一部分，在此过程中，测试人员讨论并审查结果，以确定测试是成功还是失败。
额外的评论:这个部分处理测试人员和测试生成的所有其他注释，包括时间和名称戳记。
避免常见问题的有用测试用例技巧
为了避免与测试用例相关的常见问题，请记住软件测试受制于持续的更改和修订。例如，需求的变化会影响测试的内容。当测试元素发生变化时，测试人员需要相应地更新测试用例。同样，不同级别的测试需要不同的测试用例条件;测试人员通过进行必要的修订或创建新的测试用例来处理这些不断变化的需求。下面是一些避免常见测试用例问题的技巧:
简单性:测试用例分布在开发团队和业务涉众之间。一些软件开发方法需要测试用例来驱动开发，因此测试用例不应该是复杂的，或者依赖于从一个文档移动到另一个文档到测试场景。应该使用易于理解和清晰的语言编写测试用例，同时避免使用技术术语。详细描述手动测试步骤和顺序流程。避免离题和复杂。如果测试失败，它反映一个失败条件，而不是一系列步骤中的多个失败。
是至关重要的:编写测试用例的目的是尽早并经常地揭示信息。在确定预期结果时，对AUT持批判态度，不要依赖于应用程序的先前版本来确定测试行为。当编写测试用例时，检查它以确认其他人可以在没有指令的情况下执行它。用最终用户体验来评价测试用例场景，以暴露设计或可用性缺陷。为所有测试用例寻求同行评审和公开反馈。
组织:如果您使用电子表格系统来管理测试用例，请使用标准化模板。在单独的工作表上创建每个测试用例，因此每个工作表反映单个步骤流。当多个用户管理大量的测试用例时，测试用例管理软件可以自动地组织用例的创建。这种类型的软件被设计用来帮助管理几种测试条件——例如，当你面对集群测试用例或者一系列相互依赖的测试用例时。为创建和管理测试用例建立培训过程和支持文档，这样新员工就有了一致的资源和技术文档。欧宝体育app官方888
测试用例、测试脚本和测试场景
在软件测试领域，测试用例、测试脚本和测试场景是串联工作的，但是它们指的是规程的不同组成部分。
测试用例vs测试场景
一个测试用例是阐明测试软件所需的特定条件、测试场景所需的构建块或操作方法的文档。测试场景解决整体测试需求;例如，场景可以预测用户如何与软件交互。
使用详细的文档，测试用例提供了关于前提条件、要采取的步骤和预期结果的信息。测试场景可能涵盖许多测试用例，并给出每个独立测试用例的总体条件。
测试用例和测试场景代表了以下领域中测试的两个非常不同的方面:新代码的功能，AUT特性的更新，或者SUT的新功能。
测试用例与测试脚本
一个测试脚本是测试用例的一个组件。它以手动或自动化的方式提供了操作步骤，使用软件代码来测试需求。测试脚本不断变化，因为它们被设计为匹配新的特性需求。它们还旨在重复测试相同的步骤，不鼓励灵活的、探索性的测试或创造性的策略来寻找bug。条款测试用例和测试脚本现在可以互换使用。以前，这两个术语区分了手动测试步骤(测试用例)和自动测试步骤(测试脚本)。
测试用例与测试计划
测试用例是整体的单个组件测试计划。(多个测试用例被称为一个测试套件)。测试计划是一个测试工件，即项目文档(或可交付成果)。测试计划定义了项目的测试范围、风险、可交付成果和测试环境。使用测试进度表，测试计划概述了项目的QA活动，并为测试团队分配角色、职责和测试目标。
测试用例计划和执行模板
测试用例管理工具和测试自动化
测试人员可以编写他们自己的测试脚本(或代码)，或者使用测试管理工具来处理和自动化测试。这些软件解决方案自动化测试脚本，并提供跨不同需求和不同版本的AUT的报告功能。
专用测试管理解决方案的市场包括像HP质量中心、Jira、TestLodge、TestComplete和Selenium这样的供应商。这些解决方案的一些最常见的优点包括测试用例模板、测试版本控制、通过电子邮件通知分配给开发人员的自动错误跟踪、受控的协作访问、按需求跟踪的测试覆盖，以及云备份存储。
自动化测试测试用例模板
SQL Server集成服务测试测试用例模板
软件需求规范(SRS)文档和测试工件
使用来自测试工件文档的测试需求，测试人员为不同的场景编写测试用例并创建测试脚本。测试工件是软件开发和计划过程的副产品，描述了软件的功ob欧宝娱乐app手机下载能和设计。测试工件可能涉及用例、需求或设计文档，比如用户界面(UI)线框图。开发团队在合作客户和业务涉众的帮助下生成该文档。
一个软件需求规范(SRS)文档为来自业务和项目需求的测试场景提供了信息。测试人员根据SRS文档创建测试用例，因此QA活动与开发和业务工作流同步。根据组织和测试过程，测试用例需求可能来源于其他测试工件文档，包括以下内容:
UI线框图或屏幕原型
业务或用户需求文档
用例文档
功能需求文档
ob欧宝娱乐app手机下载产品要求文档
软件项目计划
QA /测试计划
帮助文件或发行说明
测试用例vs.用例
用例不同于测试用例。一个用例提供一个或多个软件解决方案的开发路径。测试用例验证解决方案是否满足特定的需求。用例提供关于期望的输入——由SRS文档中的业务和用户需求捕获——测试用例使用该输入来验证期望。测试场景依赖于来自用例功能的详细需求。测试用例可以循环使用，而测试场景根据用例频繁更改。
根据来自用例的输入，不同的测试用例反映不同的功能需求。例如，UI测试需要一个测试用例来验证静态用户名和密码按钮显示适当的文本。为了尝试一个功能，团队创建了一个测试用例来探索当用户单击时发生了什么登录按钮。为了检查数据输入，团队创建了一个数据库测试用例来检查系统是否调用了正确的数据库并授予了权限。如果用户忘记了密码，则过程测试检查是否单击忘记了密码按钮将生成一封电子邮件以重置用户的密码。
用户验收测试测试用例模板
什么是好的测试用例?
有用的测试用例具有支持科学方法的属性。他们帮助管理软件测试和SDLC的复杂性。科学的方法需要通过使用已知的条件和变量来定义测试状态，在问题中执行特定的行为来测试针对特定需求的假设，观察系统行为，并记录结果。
测试用例使测试人员能够创造性地思考，并考虑不同的角度和方法来验证和确认软件需求。通过让所有涉众都可以访问您的测试用例来促进反馈、学习和优化。
正确格式化的测试用例是准确的，可以追溯到单个需求，维护安全，可重复使用，可重用，并且独立于其他测试用例。与发表的科学方法研究一样，同行评审的测试用例促进了SDLC中每个人的可访问的、开放的贡献，并确保了适当的测试覆盖率(即，正确的代码量和正确的测试率)。构造不良的测试用例具有以下特征:
广泛的步骤:无效的测试用例使用模糊或过于宽泛的步骤，或者它们完全遗漏了步骤。这些差距会影响正确测试场景的能力，或者让未来的用户感到困惑，并测试不相关的功能。是特定的;否则，测试人员将只覆盖SUT整体功能的一小部分，或者只重复最常见的用例场景。
非正式的测试:如果您的测试用例不是系统化的、可追踪的，并且所有涉众都无法访问，那么它就是无用的。一些软件开发和测试方法跳过了编写测试用例的步骤，而另一些则需要编写以驱动开发。不管测试方法是什么，如果您创建了一个测试用例，那么它就是一个正式的文档，它需要特定的输入和先决条件、定义的测试过程和预期的结果。构造不良的、非正式的测试用例文档阻止了测试人员在软件的未来版本上运行一系列可重复的测试。(回归测试是关键的可重复测试的一个例子。)非正式的测试用例文档缺乏对每个需求和后续需求的正面和负面测试用例。
用户环境:构造不良的测试用例无法解释开发环境中的数据依赖性或变更。(例如，一个不充分的测试用例没有考虑到已经登录的用户。)过于简单的测试用例步骤可能会歪曲用户的旅程。如果您创建测试用例而不考虑特殊的测试执行步骤、需求的变更、AUT的新版本，或者业务用例的更新，那么它们将不能反映最终用户的体验。良好定义的测试环境，当与准确的数据配对时，会产生更多的创造性和彻底的测试用例场景。这意味着要确保包含任何用户数据依赖关系(例如，用户应该登录，用户应该从特定页面开始旅程，等等)。
失踪的先决条件:如果，对于一个特定的测试用例，测试人员缺乏访问用例需求或SRS文档的权限，那么该测试用例将缺乏目标和简洁性。对测试数据的混淆或缺少先决条件会导致定义不清的测试用例。测试人员需要访问内部客户倡导者和用户数据，以确定如何测试和验证什么。创建测试用例类似于使用科学的探究方法。清晰概述的测试假设依赖于在创建测试用例之前可用的先决条件数据。缺乏明确性和惯例会导致构造不良的测试用例文档和难以识别的测试范围。
可怜的文档:用关于技能水平或背景知识的假设编写的测试用例忽略了细节，因此测试人员可能会错过计划的一部分，或者创建与预期不同的结果。糟糕的文档会导致缺乏有效分析的无效测试用例。如果您没有清楚地定义通过结果的标准，或者如果您走捷径，那么将来的测试人员将缺乏基准测试的细节来确定特定的测试是通过还是失败。此外，当您的测试用例文档缺乏清晰的范围(例如，可重用的测试关键字或测试脚本功能)时，您就损害了自动化未来测试和与其他测试用例区分的能力。
高效的测试用例文档
有效的测试用例文档在创建测试用例之前就开始了。它从测试需求的收集开始。
首先，对测试工件文档执行逐行检查。收集清晰的需求(例如，那些您了解所描述的特性或功能的期望的需求)和可测试的需求(例如，那些您可以测试和预测预期结果的需求)。专注于识别准确描述这些需求的关键字和短语，并在不清楚的元素上做笔记。通过关注需求收集阶段和预测试条件，您的测试覆盖可能会更加完整。为了创建测试用例，您必须拥有正面和负面测试用例的数据。一定要从测试工件中收集这两种元素。
接下来，检查标准化的测试用例文档。检查适用于您所收集的需求的测试用例的现有测试项目文件。当创建新的测试用例时，关注可重用的、易于维护的标准，并创建通用步骤，以确保在将来需要类似的测试用例时，可以替换新的数据变量。
大量的测试用例管理涉及特性增强和对基于web的应用程序的现有功能的更改，这些应用程序容易发生需求更改。有效的文档支持标准化的方法来处理涉及网站特性的通用测试场景和概念的测试用例。浏览器兼容性测试是一种常见的测试场景。
什么是手工测试中的测试用例?
手工测试是软件测试，但是这个术语被用来区分使用测试脚本(软件代码)的自动化测试实践和使用带有自动化特性的测试管理工具的实践。测试用例是您手动创建的文档，以支持自动化的软件测试实践。
通过手动收集一组测试数据(前提条件)，确定预期的结果(后置条件)，并开发一个测试用例来验证特定的需求，测试人员就有了一个自动化测试执行的起点。
例如，测试用例的手动测试步骤的功能流可能遵循基本、备用或异常流方法来测试web应用程序的登录页面:
基本测试:使用多个浏览器(Internet Explorer、Safari、Chrome)输入web应用程序的登录凭据。
替代测试:使用具有不同屏幕分辨率的移动设备输入web应用程序的登录凭据。
异常测试:输入错误的登录凭据，以测试用户是否在不同的操作系统(Windows、MacOS、Linux)上收到错误消息。
手动测试测试用例模板
如何在Microsoft Excel中编写测试用例
本节是使用Microsoft Excel 2016 (Office 365版)创建测试用例的分步指南。对于测试用例管理，没有正确或错误的工具，但是电子表格是传统的选择。
无论您如何选择记录和管理您的测试用例，通过测试管理解决方案或项目管理协作工具，使用标准化模板来提高效率和一致性都是一个好主意。本教程基于手动测试测试用例模板。
测试识别和可追溯性:打开Excel电子表格模板，单击测试题目细胞。根据您正在测试的功能、特性或组件来命名测试用例。保持标题简短而具体;一个简短、精确的标题对于可追溯性和沟通是很重要的。接下来，单击测试用例ID单元格，并使用以下格式:TC_Test Title_Test Number。例如，如果您正在测试一个web应用程序登录屏幕，那么第一个测试可能包含以下内容测试用例ID: TC_Login_01。
注意:每个Excel表反映一个完整的、独立的测试用例，因此您可以复制测试题目为工作簿的每个单独工作表命名。测试重点:选项中选择测试优先级优先级下拉菜单单元格(低/中/高）.这种分类在测试执行和测试覆盖期间是有用的。您根据在测试工件文档中找到的业务需求以及您使用的测试活动的类型和级别来确定分类。例如，如果您为非功能性需求创建了一个测试用例，那么它的优先级可能较低高优先级。
测试设置和数据:考虑到最终用户，在文档中输入有关测试要确认的内容或功能测试数据(描述测试需求)的信息测试描述细胞。然后，将非功能数据(如AUT版本、相关数据文件、操作系统类型、设备硬件和浏览器类型)添加到测试依赖关系细胞。然后，在测试条件单元，输入其他软件模块或受测试影响的特定领域的测试用例的信息。或者，如果适用的话，输入您使用的替代测试技术(例如，等效划分、错误猜测或过渡状态测试)。最后，在测试执行人单元格中输入日期执行日期细胞。
执行步骤和观察:详细说明测试活动的连续步骤，方法是首先在列表中输入步骤号一步ID细胞。接下来，使用步骤描述单元格，输入测试操作的具体细节。(当按顺序组合时，这些细节构成了测试脚本)。例如，您可以写“输入用户名”或“输入密码”。是透明的。使用主动语态，用简单明了的词写出每一步。按适当的顺序写出这些步骤。请记住，这些步骤都是原子性的——它们按顺序独立存在，没有与其他需求或子功能重叠的步骤。
然后使用Test Data单元格包含该特定步骤的任何相关数据，例如活动电子邮件地址或输入值。进入预期的结果。接下来，输入实际结果在相应的单元格中执行测试步骤。最后，输入通过/失败属性中该步骤的任何附加注释额外的笔记细胞。
手动测试用例示例
下面的例子是基于前面的教程和手工测试用例模板。该场景旨在展示本文中讨论的使用Microsoft Excel创建测试用例电子表格文档的概念。测试需求用于验证用户是否会收到一封发送到其注册帐户的电子邮件，其中包含一个用于重置其帐户密码的临时链接。
测试题目:帐户登录密码重置
测试用例ID: TC_Reset Password_01
优先级:高
测试描述:验证是否向注册邮箱发送了带有临时重置密码链接的邮件。
测试依赖关系:有效的电子邮件帐户
测试条件:功能需求
- 测试步骤1:
- 额外的笔记: Google Chrome浏览器
- 通过/失败状态: N /
- 实际结果: N /
- 预期的结果: N /
- 步数据:登录页面URL
- 步骤描述:进入登录页面
- 测试步骤2:
- 额外的笔记: Google Chrome浏览器
- 通过/失败状态:通过
- 实际结果:收到的邮件
- 预期的结果:将带有密码重置链接的邮件发送到有效的邮箱
- 步数据:有效的电子邮件地址
- 步骤描述:提交注册账号邮箱地址
- 测试步骤3:
- 额外的笔记: Google Chrome浏览器
- 通过/失败状态:通过
- 实际结果:请输入新密码和确认密码
- 预期的结果:单击，进入重置密码链接
- 步数据: N /
- 步骤描述:验证用户是否导航到重置密码web portal
- 测试步骤4:
- 额外的笔记: Google Chrome浏览器
- 通过/失败状态:失败
- 实际结果:返回帐户登录页面
- 预期的结果:密码重置确认
- 步数据:密码必须大于等于8个字符
- 步骤描述:验证已注册帐户是否提交新密码
- 测试步骤1:
这个测试用例只使用正面结果的示例。测试用例应该总是说明积极和消极的结果。有关阴性测试用例的更多信息，请参见本文讨论的是负面测试用例。
用Smartsheet改进软件开发的测试用例
通过设计一个灵活的平台来满足你的团队的需求，并随着需求的变化而适应，从而使你的员工能够超越自己。
Smartsheet平台可以轻松地从任何地方计划、捕获、管理和报告工作，帮助您的团队更有效地完成更多工作。报告关键指标，并通过汇总报告、仪表板和自动工作流实时了解工作情况，以保持团队的联系和信息。
当团队对要完成的工作有了清晰的认识时，就不知道他们在同样的时间内能完成多少工作。今天就免费试用Smartsheet吧。