编写有效的测试用例是任何测试人员在软件测试生命周期（STLC）中完成的重要行动之一。测试用例是你对任何软件产品研究的基础。 然而，编写有效的测试用例是一种技术，可以通过对应用程序的深入研究来学习，其中包括开发测试用例，最重要的是，经验。识别、定义和分析需求将是编写有效测试案例的方法。
在这篇文章中，我已经概述了一些关于编写有效测试案例的技巧。然而，在我们深入了解编写一流的测试用例的经验之前，让我们从测试用例的重要性开始。
什么是测试用例？
测试用例是一组用于评估软件产品的条件，确定它是否符合业务要求。一个拙劣的测试用例可能会导致严重的缺陷泄漏。这可能会耗费时间和金钱。因此，编写有效的测试用例对于任何软件项目的成功都是至关重要的。
编写测试用例时使用的基本术语
以下是用于定义测试用例的基本术语。
| 测试用例ID | 案例_01, TC_ |
| 测试用例描述 | 测试用例的描述 |
| 类型(阳性/阴性) | 阳性测试案例/阴性测试案例 |
| 场景 | 本案例的测试对象是哪个场景 |
| 测试数据 | 本测试用例的输入数据是什么？ |
| 前期条件 | 运行此测试用例前的条件。 |
| 该测试用例的执行行动/步骤 | 执行此测试用例的步骤 |
| 预期结果 | 基于上面提到的几点，预期结果可以在这里提到。 |
| 实际结果 | 这将在测试用例的实际执行中填写。 |
| 评论 | 任何类型的意见都将在此提及。 |
编写有效测试用例的最佳实践
简单执行的测试用例被认为是有效的测试用例。他们通过减少时间和精力来加速测试过程。遵循这17个最佳实践将帮助我们达到我们的目标。
1.坚持范围和规范
确定测试的范围和目的。早些时候，我曾经假设一个测试案例的预期功能应该是怎样的。通过一次惨痛的教训，我意识到对SRS（软件需求规范）文件进行透彻的理解总是更好。我目睹了人们变得更加直观，而不是遵循逻辑的方法，有时这种直觉会导致假设。
在制定测试用例时，对特性和功能的假设往往会使你偏离客户最初要求的实际需求。这将影响被测试的产品和客户与组织的关系。
2.注意产品的更新
遵循软件需求规范（SRS）是至关重要的。如果软件的版本已经过期，则不一定要坚持SRS。 没有人愿意测试一个被淘汰的功能。
我们生活在一个由敏捷方法论主导的世界，产品开发在快车道上行驶。有时，软件需求规范（SRS）文件被搁置，以应对短的时间窗口或部署一个即时的错误修复后。最好的办法是为主要和次要的变化更新SRS。
3.编写，直击要害的描述
测试用例描述对于转述错误的根本原因至关重要，它必须始终包含重现的步骤。当我开始我的测试生涯时，我没有意识到写具体细节和写得华丽之间的细微差别。我曾经在现场为测试用例描述写过故事。我认为尽可能多地填充描述会令人印象深刻。
然而，我错了!这不仅浪费了我的时间，也浪费了开发人员的时间!我意识到保持描述的干脆、简单和信息量是多么重要。没有人喜欢读长篇大论。只要做到这一点就可以了。
在编写有效的测试用例时，只应包括必要和有效的步骤。如果一个测试用例有太多的测试步骤需要完成，那么测试用例的重点和目标可能就会丢失。因此，每个测试用例应该只涵盖一个预期结果，而不是试图涵盖几个预期结果。如果执行测试用例需要相同的操作，在先决条件步骤中包括测试用例的ID。
4.设身处地为客户着想
从终端用户的角度创建测试用例。通常情况下，一个愤怒的客户会在客户支持部敲门，解释说软件没有提供预期的功能，达不到他的期望。
作为一个软件测试人员，你应该能够将自己与客户联系起来，以便从客户的角度向你的开发团队解释这个问题。我的经理曾经一直引用 "客户总是正确的"。
在编写测试方案时，要牢记客户或最终用户的要求，因为最终，所设计的软件或产品是为客户服务的。记下可用性测试和可及性测试。
5.用户角色
用户角色是终端用户的虚构代表，有助于描述来自不同工作角色的人如何在你的软件上操作。如果你不熟悉用户角色，你一定想知道为什么需要一个虚构的角色来帮助你编写有效的测试案例。
我曾经认为，除非我了解到确定用户的范围可能是多么关键。为了更具体地理解这一点，让我们以杰克为例。杰克是一个网络开发人员，他登录LambdaTest，一个跨浏览器的测试工具。因此，他可以测试他的网站或网络应用的网络元素在多个浏览器上的呈现情况。
在这种情况下，Jack不会关心后端功能，如API通信，渗透测试将不属于他的范围。因此，为了编写有效的测试案例，创建不同的用户角色，每一个都代表你的目标受众的社区和他们的职业，并专注于涵盖各自方面的案例。
6.在写下执行的步骤时要细化
编写有效的测试用例的步骤应该是详细的，直截了当的，这样一个新的测试人员可以简单地执行它们。测试用例的目的和范围应在测试用例中明确说明。测试用例本身应该是不言自明的。所有先决的测试数据应该在测试用例本身和具体步骤中描述。同行成员应审查测试用例。
当提到执行测试用例的步骤时，避免复合句子始终是一个最佳做法。相反，写一个小而具体的步骤指南作为测试用例的演练。
例如 - 让我们写一个测试用例，对他的网站进行跨浏览器测试。选择像LambdaTest这样的基于云的基础设施平台，可以让你访问一个由3000多个运行在真实操作系统上的真实设备组成的在线设备场，以执行自动化测试。此外，这个跨浏览器测试平台允许用户在各种浏览器、操作系统和设备上测试公共或本地托管的网络应用。
让我们来看看以下步骤：-（这项工作可能需要自信的写作）。
第1步→登录www.lambdatest.com。
第2步→进入实时测试部分。
第3步→选择测试的配置。(浏览器、浏览器版本、操作系统和屏幕分辨率）。
第4步→点击START按钮运行测试，在相应的配置上对你的网站进行测试。
第5步→终止测试会话。
你观察到综合步骤了吗？是第4步。"点击START按钮，运行测试，在各自的配置上对你的网站进行测试。"
记住，一个有效的测试案例应该总是不言自明的。重要的是要把步骤写得尽可能的细化。
因此，上面的案例写成下面的样子会更有效
第1步→登录www.lambdatest.com。
第2步→从左侧面板选择实时测试。
第3步→选择测试的配置（浏览器、浏览器版本、操作系统和屏幕分辨率）。
第4步→点击START按钮，运行测试。
第6步→检查所有的图标和填充物是否支持。
第7步→改变分辨率显示（检查不同屏幕尺寸的设备）。
第8步→终止会话。
这只是一个简单的例子，帮助你了解如何将步骤分解到最细微的程度。
LambdaTest还允许你在真实的设备云上用真实的浏览器和操作系统进行测试。下面是你如何使用LambdaTest平台在真实设备上进行实时测试。
7.掌握你的测试案例的所有权
我观察到，在一个大型项目上工作的软件测试人员中，测试用例是如何在没有适当所有权的情况下被杂耍的。在这种情况下，测试用例应该被适当地分配。每个软件测试人员应该只对分配给他的测试用例负责。
我对 "产品所有权 "的定义包括了产品的整个生命周期。对于软件测试人员来说，在一个测试用例被执行后，我们应该监测它在用户手中的运行情况，每次更新。审查性能统计，并向你的团队提供关于如何改善用户体验的积极想法。
8.积极使用测试用例管理工具
测试用例管理工具被认为是管理稳定发布周期的必要工具。它们有助于发展一个透明的水平，每个人都知道谁在做什么工作。它们还可以用于跟踪与错误修复有关的最后期限，以及更多。
然而，员工往往不能积极有效地利用这些工具。为了编写有效的测试用例，你必须学习各自测试用例管理工具的实际使用方法。
电子表格可以用来处理一个小团队的测试用例。随着你的团队的扩大和你的应用程序的迭代，他们很快就会成为一个主要的负担。其他工具，如JIRA，可以被设置为管理测试用例，但它们缺乏测试的具体功能。
编写有效测试用例的另一点是跟踪、维护和自动处理你的测试用例。你最终会需要猎取一个专门的测试用例管理应用程序。
9.监控所有的测试用例
在测试执行中，测试监控是评估测试活动和努力的过程，以跟踪当前的测试进展，找到并跟踪测试指标。同时，根据测试指标来估计未来的行动，并向有关团队和利益相关者提供关于当前测试过程的反馈。
当远程软件测试人员工作时，或有太多的软件测试人员在一个类似的项目上工作时，两个软件测试人员碰上类似的测试案例是很常见的。因此，监控所有的测试用例对于编写有效的测试用例是很重要的。另外，记得删除不相关的和重复的测试用例。
10.以100%的测试覆盖率为目标
美好的时刻终于到来，你已经创建了测试，屏幕上显示 "100%覆盖"。你很满意；所有的测试都通过了，你的代码将不再有缺陷。然而，这就是100%测试覆盖率的实际含义吗？
100%的测试覆盖率意味着你已经创建了足够的测试来覆盖你程序中的每一行代码。没有更多或更少。如果你的测试结构良好，你应该能够预测一些输入将产生一些输出。
测试覆盖率是保证任何软件健壮性的一个重要方面。在编写有效的测试用例时，以100%的测试覆盖率为目标是至关重要的。花点时间，计划你的测试用例，以覆盖SRS文件中规定的每个组件和功能。
可追溯性矩阵可以用来验证没有任何功能或条件未被测试，从而实现100%的覆盖。需求追踪矩阵是测试用例和需求之间的映射，将追踪任何未测试的功能或条件。
11.小心依赖性测试用例
当一个测试用例的行为或结果依赖于另一个测试用例的执行或结果时，这被称为测试用例依赖性。
曾经有几次，我在一个随机的场景中发现了一个错误，当我试图复制它时，事情并没有按照我的计划发生。这时我意识到，即使是测试用例也可以依赖其他测试用例。
例如，你可能有一个测试用例X，只有在依次执行了测试用例Y和测试用例Z之后才会被执行。这种情况通常在两个模块非互斥的情况下被观察到。因此，除非你在弄清了依赖性测试用例后起草一个方案，否则一个错误可能不会重现。
12.成为批评者
有时你需要采取与别人不同的方法来发现软件的未知数。未知数是指产品团队看不到的场景，直到它们被终端用户报告。
在我们看完一个场景的所有测试用例后，我们应该作为测试人员再看一遍，而不是作为测试用例的写手。为了写出有效的测试用例，你必须以不同的方式做事，并进行特殊的思考，特别是如果你的目标是探索性测试。
13.意图要具体
意图是很重要的。作为人类，我们很少在没有计划的情况下行动，我们希望事情的结果是怎样的!实现验收标准对于编写有效的测试用例是必不可少的。验收标准是验证软件在最终用户方面是否按预期工作的条件。
记住，验收标准的存在是为了帮助你判断最终用户的意图，而不是步骤。例如，"管理员应该能够邀请或踢出在一个组织下从事同一项目的团队"，而不是 "管理员应该访问组织设置下的团队页面，并点击邀请将人加入团队，或点击删除将人踢出团队"。
14.倚重自动化
作为一个软件测试员，我的经验告诉我，软件测试是一个严格的、永不停息的过程。渐进式增强的兴起和敏捷方法论的采用，使回归测试成为我们中许多人的紧急情况和头痛问题。
通过纳入一个有效的测试自动化策略，你可以确保一个没有错误的应用程序。据统计，42%的公司认为自动化测试是其质量保证过程的一个重要部分。因此，如果你正在手动测试应用程序，你可以考虑从手动测试切换到自动化测试。
然而，自动化测试的引入已经改变了回归测试的游戏规则。自动化导致软件测试人员的生产力和带宽增加，使他们能够思考更好的方法来编写有效的测试案例，而不是每天都被困在相同的测试案例中。
在3000多个浏览器和浏览器版本上运行自动化测试。现在就试试LambdaTest吧!
15.测试用例的最佳文档
作为一个软件测试人员，你无疑会同意我的观点，即创建一个完美无瑕的测试文档是一项艰难的工作。不要一时兴起就投入到编写测试文档中。在你开始写文档的过程之前，你必须了解编写有效的测试案例的目的。
测试应该始终是简单明了的。他们应该以这样的方式来写，即测试人员可以很容易地按照每个测试中列出的指示来完成测试。
这里有一些提示，可以帮助你在测试文档方面从人群中脱颖而出。
- 你的测试文件的结构是否令人满意？
- 不要忘记解决负面的测试案例
- 要有原子化的测试程序
- 测试应该有优先次序。
- 顺序很重要
- 在文件中保留两张独立的纸："错误 "和 "摘要"。
这是很常见的现象，我相信你也会遇到这样的情况，一旦一个测试用例文件得到客户的认可，那么所有的团队都会固定在这个文件上。没有人试图跳出框框来写有效的测试用例，因为我们觉得文件就是我们所需要的一切因此，在你的测试文档中涵盖所有内容是很重要的。
16.对你的测试用例进行优先排序
测试用例的优先级是将测试用例按重要性排序的过程。对测试用例进行优先排序有助于满足软件测试中的两个主要限制，即时间和预算，以便在可行的情况下尽快提高故障检测率。
当我开始我的软件测试员生涯时，我很笨拙，压力很大，商业专家的概念对我来说是陌生的。我习惯于以一种无组织的方式跳入测试场景，而没有意识到测试案例中优先级的作用。
有一个发布周期，我的带宽不足，当发布日期来敲门时，我匆匆忙忙地做了许多高优先级的测试案例。发布后，当客户报告失败时，我们承诺回滚。这是一个惨痛的教训。我意识到，在你写一个有效的测试用例时，同时确定测试用例的优先级是多么关键。
17.跨浏览器测试可以帮助尽量减少故障
对于编写有效的测试用例，记下浏览器的差异是很重要的。有一次，我们的办公室出现了故障，我们的支付页面以一种非常慌乱的方式出现在终端用户面前。我们的开发人员做了从清除缓存到重启服务器的所有工作。
然而，这个问题仍然存在，造成了恐慌的局面。后来我们意识到，面临不便的用户有一个共同点。他们要么使用过时的IE浏览器，要么使用特定移动供应商的安卓系统。就在那时，我们意识到我们的网站与不同的浏览器和设备不兼容的问题。从那以后，我们在每一个发布周期中都会进行跨浏览器测试，再也没有出现过这种尴尬的情况。
在这种情况下，LambdaTest是一个神奇的测试和信任平台。在我的个人项目中，LambdaTest显示出了惊人的可靠性和丰富的功能。LambdaTest带有一个由3000多个浏览器和操作系统组合组成的在线浏览器场，因此没有任何范围。而最重要的是，这一切都通过云端完成。你只需登录并开始在任何地方、任何时间、通过任何系统进行实时测试。
编写有效的测试案例的奖励点
1.定义测试的范围和目的。编写有效测试案例的第一步是确定可测试的需求。你必须理解测试目标以及特点。
2.领域专业知识。在开发测试用例之前，你需要有领域知识，这是任何软件程序的基础，因为业务规则因领域而异，对业务功能有很大影响。它可能会导致业务的损失。所以，要避免领域标准之间的冲突；作为一个测试人员，在开发测试用例之前，必须掌握这些知识。
3.应避免假设。当创建一个测试用例时，不要对你的软件应用程序的功能和特点进行假设。这可能会导致客户的规格和产品之间的脱节，影响业务。当创建一个测试案例时，不要对你的软件应用程序的功能和特点进行假设。遵循文件中的规范。
4.寻找非功能需求。非功能需求与功能需求一样重要。实际上要确定额外的非功能测试需求，如要解决的硬件要求、操作系统和安全特性，以及测试数据准备，如确定额外的测试需求，如测试数据准备。
5.建立一个测试案例框架。测试用例框架可以根据系统的需要进行调整。性能、兼容性、UI界面、容错性和各类性能都应包括在测试案例中。
6.附上相关工件。有时，很难掌握测试步骤。在这种情况下，将工件或设计附在特定的测试阶段，将有助于理解流程。它将有助于跟踪我们的应用程序在发布或部署期间的大规模变化。
7.正面和负面的测试案例。当组成测试用例时，等价类划分，边界值分析，正常和异常情况是一些应该应用的测试用例设计方法。你还应该考虑消极测试、失败情况和错误处理，因为这些可能会帮助你找到代码中最有可能出现的错误。不要对功能做任何假设；相反，根据需求说明文件来编写测试用例。
总结
编写有效的测试方案，包括所有必要的细节，是一项出色的工作。只要你记得考虑最终用户的观点，应用程序了解端到端的过程，并遵循我在这篇文章中描述的编写测试用例的最佳实践，你就会很顺利。
这就是我的全部观点。我希望我写有效的测试用例的经验对你们中的许多人来说是有关系的或有知识的。
祝你测试愉快!
常见问题(FAQ)
编写有效测试用例的最佳实践是什么？
- 保持简单明了和基本的东西。
- 创建可重复使用的测试方案。
- 将测试用例的ID分开。
- 同行评审是至关重要的。
- 编写有效的测试用例时，应考虑最终用户或既定的要求。
- 描述预期的结果和假设。
一个好的测试用例应该包括什么？
- 测试名称
- 测试ID
- 参考资料
- 测试设置
- 测试目的
- 前提条件
- 测试步骤
- 测试结果
什么是编写测试用例？
测试用例是一连串的行动，以确保你的应用程序的一个特定的功能或能力是正常工作的。一个测试用例是一组测试步骤，测试数据，前提条件和后置条件，为一个给定的测试场景创建，以验证任何需求。
