不管某个软件的设计有多好，在发布之前都需要经过多层测试。因此，每个测试人员或QA都必须在他们参与的每个项目中编写多个测试用例。
自然，写好测试用例是最重要的。本文的目的正是为了帮助读者解决这个问题。
让我们先来研究一下好的测试用例的特点。
- 站在客户的立场上
客户打电话给支持人员抱怨某个应用功能的实现低于预期的情况并不少见。任何测试人员都必须能够与客户建立联系，预测他们的需求并据此创建测试用例。测试用例应该能够测试符合客户使用方式的功能。在编写好的测试用例时，要把客户的需求放在首位。尤其是在运行可用性测试和可访问性测试时，更是如此。 - 了解用户角色
了解用户需求的一个好方法是创建用户角色。用户角色基本上是某个网站或应用的终端用户的虚构形象。考虑以下的用户角色。Mike 是一个经常在电子商务网站购物的人。他最可能会在意能很好地展示产品的出色展示，这些功能使他可以轻松地将产品添加到购物袋中并查看价格。他不会关心API通信等后端功能。
因此，测试用例的构建必须与这个角色保持一致。将测试用例的重点放在检查用户界面上，使其易于浏览，并在视觉上具有吸引力。由于电子商务涉及在线金融交易，所以安全性也会受到关注。
用户角色帮助测试人员了解用户的范围。因此，他们可以设计测试用例，确保应用程序的功能能够提供用户所需。通过创建多个用户角色，开发人员、测试人员和所有利益相关者可以努力塑造他们的软件，以获得最大的用户满意度。
- 争取100％的测试覆盖率
编写好的测试用例的重点是提供尽可能广泛的测试覆盖率。每个测试用例都必须以覆盖尽可能多的功能、用户场景和尽可能多的工作流程为目标。规划测试用例，以覆盖SRS（软件需求规格）文件中概述的每个组件、功能和特性。 - 使用良好的测试用例管理工具
测试用例管理工具对于管理稳定的发布周期是必要的。它们有助于提供透明度，使每个人都知道谁在做什么。它们可以跟踪截止日期，以及更多。创建好的测试用例包括积极有效地使用这些工具。在测试周期开始时，确保一个团队中的所有QA都能熟练使用管理工具，或者至少，能自如地使用该工具。 - 注意依赖的测试用例
测试人员有可能发现一个错误，但可能无法复制。如果一个测试用例依赖于其他测试用例，就会发生这种情况。例如，测试用例X可能只有在测试用例Y和Z被依次执行之后才会被执行。最好尽量避免这种情况，因为错误复制甚至是测试用例的审查往往需要更多的时间和精力。 - 使用有利于您的自动化
软件测试是一个严格的、永无止境的过程。功能的不断变化和更新意味着必须反复运行回归测试，以确保代码的任何变化都不会破坏原始的、功能的代码库。这时，手动做这些工作是很累人的，也是多余的。
使用像Selenium这样的自动化测试框架是执行此类涉及重复性动作的测试的最佳方式。自动化测试的结果是提高了软件测试人员的生产力和带宽，他们可以专注于编写有效的测试用例，而不是每天都在做同样的动作。
现在我们清楚了一个好的测试用例的特点，我们来看看一些构造不良的测试用例的共同点，让测试人员知道应该避免什么。
- 只运行一种特定的测试条件
每个测试用例的建立必须同时考虑到网站或应用程序预计要处理的多个用户场景。这意味着用所有可能的主要条件组合来测试软件模块。现在，对这些组合进行全面测试需要以一种其他质量检查人员也可以对其进行审查方式呈现。 - 只覆盖一小部分功能
构建专注于特定功能的测试用例是无效的。相反，他们需要验证使用模式和工作流程。每一个测试用例都应该精心设计，以测试尽可能多的工作流程，并在操作时跨越被测软件的技术边界。 - 只测试特定用户角色
为测试特定用户角色而创建的测试用例范围有限，效果较差。最有效的测试用例验证了用户在应用程序中的旅程。例如，任何业务类应用程序最好能通过测试用例在整个业务流程上进行测试检查。理想的情况是，这些测试用例应该覆盖一定数量的用户角色和覆盖用于启动和完成业务流程的系统。 - 只简单的重复了需求文档
通常情况下，测试人员只会在测试用例中重复需求文档。测试用例需要做的是测试 “corner-cases”。编写“corner-cases”的测试用例是具有挑战性的，但最有价值的是它们能发现最可能破坏用户体验的缺陷。 - 没有系统标记和编目
可以相当轻松地写出一百个测试用例，并将它们堆放到共享文件夹系统中。但是，如果没有系统的标记和编目，以后要识别某个测试用例的时候，就会变成一场噩梦。测试用例的归档方式应该能够让测试管理系统在任何时候都能访问到正确的测试用例。
在编写测试用例之前，先把本文中讨论的要点看一遍。省去自己犯常见错误的麻烦，这样可以更快地测试相关软件。更快地发现BUG，以便尽早地重现和解决这些问题。如果要成功地为改善软件质量和用户体验，了解一个好的测试用例的特点，对于任何一个QA或QA团队来说都是至关重要的。
文档出处（https://www.browserstack.com/guide/writing-good-test-cases）
