Copyright © 2018-2022 All Rights Reserved.
了解最新技术文章
测试用例是您的团队应执行的一组记录的操作，以验证软件应用程序的特定特性、功能或要求是否按预期工作。
测试用例定义了在实际开始测试之前要测试的内容。
编写良好的测试用例对于彻底和优化的软件测试过程至关重要。测试团队使用测试用例来：
在开始测试之前计划需要测试什么以及如何测试
通过提供重要的详细信息（例如开始测试之前需要满足的先决条件以及测试期间要使用的示例数据）来提高测试效率
测量和跟踪测试覆盖率
将预期结果与实际测试结果进行比较，以确定软件是否按预期运行
记录您的团队过去如何测试您的产品以发现任何回归/缺陷或确认新软件更新没有引入任何意外问题。
以下是编写测试用例时需要考虑的四个常见要素：
确定要测试的功能
您的软件的哪些功能需要测试？例如，如果您想测试网站的搜索功能，则需要将其搜索功能标记为测试。
确定测试场景
可以测试哪些场景来验证功能的各个方面？用于测试网站登录功能的潜在测试场景示例包括：
使用有效或无效的凭据进行测试
使用锁定帐户进行测试
使用过期的凭据进行测试
确定正面和负面测试场景的预期结果非常重要。例如，对于具有有效凭据的登录测试场景，预期结果将是成功登录并重定向到用户的帐户页面。具有无效凭据的测试场景的预期结果将是一条错误消息并阻止访问帐户页面。
识别测试数据
您将使用哪些数据来执行和评估每个测试场景的测试？例如，在使用无效凭据进行测试的登录测试场景中，测试数据可能包括不正确的用户名和密码组合。
确定测试方法
一旦确定了测试用例的测试功能、场景和数据，您将更好地了解如何进行测试以获得最有效的结果。
以下是此步骤的一些重要注意事项：
如果您是第一次测试新功能并需要确认特定功能，您可能需要编写更详细的测试步骤。例如，假设您正在测试电子商务网站的新结账流程。在这种情况下，您可能会包含详细步骤，例如将商品添加到购物车、输入运输和账单信息以及确认订单。
如果您的测试用例设计是探索性的或以用户接受为重点，您可以简单地编写您希望在测试期间完成的测试章程或任务。例如，如果您正在对移动应用程序上的新功能进行用户验收测试，您的任务可能是确保该功能的登录过程易于使用并满足用户的需求。
在敏捷软件开发中，测试用例更像是大纲，而不是单个测试的分步说明列表。测试用例可以包括有关所需条件、依赖性、过程、工具和预期输出的详细信息。
测试用例的七个常见元素包括：
标题： 测试用例的标题指向正在测试的软件功能。
描述（包括测试场景）：描述总结了测试中正在验证的内容。
测试脚本（如果自动化）：在自动化测试中，测试脚本提供每个功能测试所需的数据和操作的详细描述。
测试ID：每个测试用例都应该有一个唯一的ID，作为测试用例的标识符。为了清楚起见，测试用例 ID 应遵循标准命名约定。
测试环境的详细信息：测试环境是测试软件或系统的受控设置或基础设施。
注意：此部分包括有关测试用例的任何相关注释或详细信息，这些注释或详细信息不适合测试用例模板的任何其他部分。
测试用例模板提供了一种结构化且有效的方法来记录、管理和执行测试用例，确保测试工作一致、记录良好并符合您的业务标准和要求。
在 TestRail 中，您可以在不同的项目和测试套件中重用测试用例模板，并自定义它们以符合特定的测试方法和项目要求。这些功能使其成为强大且适应性强的测试工具，可在测试过程中保持一致性、效率和组织。
在 TestRail 中编写测试用例时，您可以自定义四个默认模板：
测试用例（文本）：
图片：这个灵活的模板允许用户描述测试人员应该采取的步骤，以便更流畅地测试给定的案例。
测试用例（步骤）
图片：此模板允许您向测试的每个步骤添加单独的结果状态，以及每个步骤的缺陷、需求或其他外部实体的链接。这种区别为您提供了更好的可见性、结构和可追溯性。
探索性会议
图片： TestRail 的探索性会话模板使用文本字段，您可以在其中定义任务和目标，这将指导您完成探索性测试会话。
行为驱动开发
图片：此模板允许您直接在 TestRail 中设计和执行 BDD 场景。用户还可以将测试定义为场景。BDD 中的场景通常遵循Give-When-Then (GWT) 格式。
测试用例模板通过提供标准化格式来增强一致性，使创建、执行和分析测试用例变得更加容易，并通过捕获有关测试场景和过程的重要信息来确保文档记录。
开发有效的测试用例对于确保高质量的软件至关重要。以下是编写优化测试用例的一些最佳实践：
根据优先级编写测试用例
根据测试用例的重要性和对软件的潜在影响确定测试用例的优先级。您可以使用优先级系统来帮助确定应首先编写和执行哪些测试用例。
您可以使用这些测试用例优先级测试技术来确定优先级并识别更高优先级的测试用例：
基于风险的优先级
基于历史的优先级
基于覆盖范围的优先级
基于版本的优先级
基于成本的优先级
例如，假设您正在测试电子商务应用程序并使用基于风险的优先级来编写测试用例。在这种情况下，验证销售税正确计算的测试用例可能比验证按钮颜色的测试用例具有更高的优先级和风险级别。
让您的测试用例清晰易懂
您的测试用例应该清晰且易于理解，以便测试团队中的任何人都能准确地知道测试的目的。
附件、屏幕截图或录音有助于说明步骤。例如，假设您正在测试登录功能。在这种情况下，您的测试用例应清楚地说明登录步骤、要使用的登录凭据以及预期结果，例如成功显示用户仪表板。
确保测试用例名称易于理解和引用。标题应该表明测试用例属于哪个项目，以及它的用途。在处理数千个测试用例时，易于遵循的命名约定尤其重要。
在命名与可重用对象相关的测试用例时，请考虑在标题中包含该信息。有关先决条件、附件和测试环境数据的信息应记录在测试用例描述中。
指定预期结果
预期结果可以帮助您确保正确执行测试并且软件按预期运行。指定测试用例的预期结果可为您提供与实际结果进行比较的参考点。
例如，如果您正在测试购物车功能的工作情况，则此测试用例的预期结果将指定所选商品已成功添加到购物车并且购物车显示正确的价格。
为快乐和不快乐的路径编写测试用例
为了最大程度地覆盖软件需求，您必须编写覆盖尽可能多场景的测试用例。
快乐路径是指用户与软件交互时通常采用的常见路径。不愉快的路径表示用户行为异常的场景。覆盖这些不愉快的路径非常重要，以确保显示正确的错误消息，帮助用户导航，这样他们就不会意外地破坏您的软件。
例如，如果您正在电子商务网站上测试搜索功能，则快乐路径测试用例可能会搜索特定产品并成功找到它。不幸路径测试用例可能是搜索不存在的产品并验证是否显示适当的错误消息。
检查您的测试用例
与团队合作定期审查和完善测试用例。随着产品的发展，测试用例可能需要更新以反映需求或功能的变化。这种审查对于经历重大变化的产品尤其重要，例如添加新功能、增强功能或要求修改。
同行评审还有助于识别测试用例中的任何差距、不一致、歧义、误导性步骤或错误，并确保它们满足所需的标准。
例如，假设电子商务网站更改了其支付网关提供商。在这种情况下，有必要审查现有的测试用例，以确保它们仍然涵盖所有必要的测试场景和要求，即使支付网关提供商发生变化也是如此。
最重要的是，有效编写和管理测试用例是软件测试不可或缺的一部分，需要仔细规划、关注细节和清晰的沟通。通过实施测试用例编写最佳实践并使用 TestRail 等专用测试用例管理工具，您可以达到所需的组织和细节级别。
图片： TestRail 直观的界面使您可以轻松地编写和组织测试用例，只需输入测试用例的前提条件、测试说明、预期结果、优先级和工作量估计即可。
TestRail 的可定制和可重用的测试用例模板还提供了用于记录测试用例的预定义格式，使创建、执行和分析测试变得更加容易。
这种测试流程的灵活性和可见性使 TestRail 能够轻松融入任何组织的测试计划 —免费试用 TestRail，看看它如何帮助您制定测试计划。
测试用例提供了多种好处，符合敏捷方法的灵活性、协作和对变化的响应能力的原则。以下是主要优点：
共同理解：测试用例为用户故事或功能提供了一套清晰且记录在案的要求和验收标准。这确保了整个团队，包括开发人员、测试人员和产品所有者，对需要测试的内容有共同的理解。
效率：通过预定义的测试用例，测试变得更加高效。软件测试人员不必每次都决定测试什么或如何测试。他们可以遵循既定的测试用例，从而节省时间和精力。
回归测试：敏捷开发涉及频繁的代码更改。测试用例通过提供一组在每次更改后运行的结构化测试来帮助确保新的代码更改不会引入回归。
可重用性：测试用例可以在冲刺或项目中重用，特别是当它们涵盖常见场景时。这种可重用性可以提高一致性，并在测试类似功能时节省时间。
可追溯性：测试用例在用户故事、需求和测试执行之间创建可追溯性。这种可追溯性有助于确保所有要求都经过测试，并提供报告的透明度。
文档：测试用例作为测试工作的测试文档。它们捕获测试场景、步骤和预期结果，从而更轻松地跟踪进度并证明符合要求。
适应性和更快的反馈：敏捷强调早期和持续的测试，团队通常需要响应不断变化的需求和优先级。测试用例有助于在软件开发生命周期的早期阶段识别问题和缺陷，并且可以动态更新或创建，以便更快地反馈和采取纠正措施。
持续改进：敏捷鼓励持续改进的文化。测试用例和测试结果为回顾提供了宝贵的数据，帮助团队确定测试过程中需要改进的领域。
客户满意度：有效的测试可以带来更高的软件质量和更好的用户体验。详细记录的测试用例有助于交付满足或超出客户期望的产品。
如果编写和使用得当，测试用例可以促进协作、加快测试周期并提高软件产品的整体质量，最终使您的团队能够以迭代和面向客户的方式交付高质量的软件。
不同的软件测试方法可能需要不同类型的测试用例来解决特定的测试目标。以下是与不同软件测试方法相关的常见测试用例类型的细分：
测试方法 测试用例的类型 描述 功能测试 单元测试用例 单独测试各个函数或方法，以确保它们按预期工作。 集成测试用例 验证不同的组件或模块在集成时是否可以正常工作。 系统测试用例 测试整个系统或应用程序以验证其满足指定的功能要求。 用户验收测试（UAT）案例 让最终用户或利益相关者参与进来，以确保系统满足他们的需求和期望。 非功能测试 性能测试用例 衡量速度、响应能力、可扩展性和稳定性等方面。 负载测试用例 评估系统在特定负载条件（例如并发用户或数据负载）下的性能。 压力测试用例 将系统推向极限，以确定故障点和性能瓶颈。 安全测试用例 评估系统的安全措施和漏洞。 可用性测试用例 评估软件的用户友好性、直观性和整体用户体验。 辅助功能测试用例 确保该软件可供残障人士使用，并符合无障碍标准。 回归测试 回归测试用例 验证新的代码更改或更新不会对现有功能产生负面影响。 烟雾测试用例 执行基本测试用例的子集，以快速评估软件构建是否足够稳定以进行进一步测试。 探索性测试 探索性测试用例 测试人员无需预定义脚本即可探索软件，根据直觉和经验识别缺陷和问题。 兼容性测试 浏览器兼容性测试用例 测试软件与不同网络浏览器和版本的兼容性。 设备兼容性测试用例 评估软件在各种设备（台式机、移动设备、平板电脑）和屏幕尺寸上的性能。 集成测试 自上而下的测试用例 从应用程序层次结构的顶层开始测试，并逐渐集成较低级别的组件。 自下而上的测试用例 从较低级别的组件开始测试，并将其集成到较高级别的模块中。 验收测试 阿尔法测试用例 由组织内的内部开发团队或专业测试团队进行。 Beta测试用例 让外部用户或选定的一组客户在现实场景中测试软件。 负载和性能测试 负载测试用例 模拟指定数量的并发用户或事务，以评估软件在典型负载条件下的性能。 可用性测试用例 评估触摸手势、屏幕转换和整体用户体验。
编写有效的测试用例对于成功的软件测试至关重要。为了确保您的测试用例有用且高效，避免常见错误非常重要。以下是一些需要注意的最常见错误：
目标不明确：确保每个测试用例都有明确且具体的目标，概述您要测试和实现的目标。
测试覆盖率不完整：不要错过关键场景。确保您的测试用例涵盖广泛的输入、条件和边缘情况。
过于复杂的测试用例：保持测试用例简单，专注于测试某一特定方面或场景以保持清晰度。
缺乏独立性：避免测试用例之间的依赖关系，因为它们会使隔离和识别问题变得困难。
定义不明确的前提条件：明确指定执行测试用例之前必须满足的前提条件，以确保结果一致。
假设先有知识：以任何人都可以理解的方式编写测试用例，甚至是不熟悉系统的新团队成员。
忽略负面场景：不仅测试正面案例，还测试负面场景，包括无效输入和错误处理
售前咨询专员
