软件是否真的能按预期工作？答案是靠一组精心设计的测试用例来验证。本篇是 Trailhead「Test Case Development」模块的中文导读，讲解测试用例（test case）的完整生命周期：先结合业务需求规划"测试什么、在哪里测、如何测"，再动手编写测试用例，最后用模块化、参数化和定期维护让它们长期有效。
全文分为两个单元：第一单元建立规划框架，从"什么 / 哪里 / 如何"三个维度把测试目标想清楚；第二单元讲解测试用例的编写结构（前置条件、步骤、预期结果），以及如何通过模块化复用、参数化变量和系统化维护，让测试用例随应用演进持续发挥作用。每个小节对应一页 PPT 幻灯片并附讲解视频。
01 规划你的测试用例（Plan Your Test Case）
本单元建立测试用例的规划框架。学完本单元，你将能够：定义测试用例、解释测试用例的目的，并识别规划测试用例时的关键考量。
什么是测试用例（What Is a Test Case?）
测试用例（test case）是一组指令，概述了验证应用程序的功能是否按预期工作的步骤。测试用例旨在与特定的应用程序需求对齐，确保达到预期的结果。
你所执行的测试类型决定了你写什么样的测试用例。例如，在回归测试（regression testing）中，你可能会写一个测试用例来验证"创建新联系人"是否按预期工作。即使你之前已经测试过这个功能，你仍需要确认这个关键功能依然正常。
通过精心规划测试用例，你的团队可以建立一套有组织、系统化的测试方法，确保最大的覆盖率和质量。
测试什么（What to Test）
"测试什么"这个决定不应该孤立地做出。你的测试应该与业务目标对齐，所以要与业务团队协作，了解他们对最终用户的需求。否则，你可能会把精力浪费在测试那些对用户体验几乎没有影响的、不切实际的场景上。一旦与业务需求对齐，用下面几个关键问题来指导你的规划：
- 我在测试哪个应用程序？——专注于那些直接影响用户的应用程序。
- 我是在测试"正常路径（happy path）"还是"异常路径（negative path）"？——两者都要测：既测预期的工作流（正常路径），也测边界情况（异常路径），以获得更全面的覆盖。
- 我是在 UI 里测试，还是通过 API 测试？——API 测试适合快速的数据校验与操作，但在评估最终用户体验时，UI 测试必不可少。
例如，如果你和业务团队把"创建新联系人"确定为高优先级需求，你的测试用例可能会专注于在 Sales Cloud 中通过 UI 走一条正常路径来测试。这种做法能确保功能满足最终用户的预期。
但如果你想校验 Contact 字段的所有信息，你仍然在 Sales Cloud 里测试，不过这次通过 API 进行。因为你在校验数据，用 API 是更快、更合适的方式。
限制测试用例的范围至关重要。你不可能用一个测试用例做完所有事。聚焦一个功能或特性，明确定义它的预期行为，并坚持这一点。缩小范围不仅有助于编写测试用例，也有助于执行它、解读它的结果——当 bug 出现时，你需要筛选的变量越少，就越容易定位原因。
在哪里测试（Where to Test）
一旦你知道了需要测试什么，接下来决定你需要在哪里测试。这又引出几个需要考虑的问题：
- 我在哪个环境中测试？——在把变更部署到生产环境之前，先在沙盒（sandbox）环境中测试。如果发现 bug，可以在它们触达最终用户之前解决。
- 我在哪个浏览器中测试？——在最终用户常用的浏览器里测试。
- 我在哪个操作系统中测试？——在最终用户拥有的操作系统里测试。
让测试环境与真实使用条件保持一致，测试结果才有意义。
如何测试（How to Test）
最后一项考量是：如何围绕最终用户来开展测试。不同的用户有不同的权限集（permission sets），所以务必让你的测试用例覆盖所有相关角色。把每个受影响的用户画像（persona）都纳入进来，能提升你对所验证功能的信心。
带着这些画像去测试，你能更有把握地确认：这个功能对真正会使用它的人来说是有效的。用一套深思熟虑、结构化的方法来规划测试用例，你就能实现高效、有影响力的测试。在下一个单元，你将学习如何编写、扩展和维护测试用例。
02 构建你的测试用例（Build Your Test Case）
本单元动手编写测试用例。学完本单元，你将能够：概述测试用例的常见要素、解释如何扩展测试用例，并解释如何维护测试用例。
编写测试用例（Write a Test Case）
规划好之后，就该写测试用例了。一个写得好的测试用例，会概述测试某个特定功能所需的步骤序列。团队可能采用各种结构（比如来自 Testing Methodologies 的 Gherkin 语法），但大多数都共享一些常见要素，以提供清晰度和一致性：
- 前置条件（Preconditions）：说明在执行测试之前必须为真的事项。例如，如果你在测试"创建新联系人"的功能，前置条件可能包括"用户已登录"，这就暗示了登录功能不在本次测试范围内。
- 步骤（Steps）：写清晰、简单的步骤，并拆解成一个个独立的动作。避免复合步骤，因为它们会混淆执行和结果。目标是让团队里的任何人都能毫不含糊地轻松执行这个测试用例。
- 预期结果（Results）：在测试之前先确定预期结果。明确你测的是正常路径还是异常路径，并清楚地说明你预期会与不会发生什么。
除了这些核心要素，还有几个有用的小项：写一个能反映测试用例目标的简洁标题（title），便于识别和组织；再加一个状态（status），标明它处于设计或评审阶段，还是已获批准、可以执行。
扩展测试用例（Adding to a Test Case）
在扩展测试用例之前，先想想如何把模块化（modularity）融入其中。模块化的测试用例开发方式，意味着把你的测试用例拆解成更小的单元，称为模块（modules）。
一旦写好，这些模块就能在其他测试用例中复用，从而减少编写和维护测试用例的时间。随着你的测试用例不断增长，可复用性会成为测试用例管理效率的关键。
扩展测试用例时另一个重要实践是参数化（parameterization）。正如你在 Testing Methodologies 里看到的：与其硬编码特定的值，参数化使用动态变量。否则，你的测试用例就会依赖固定值才能通过。
维护测试用例（Maintaining a Test Case）
应用程序在持续演进，所以测试用例需要定期评审和更新。采取主动的方式，为此建立一个系统。最好是在你花时间执行和调试之前，就发现你的测试用例已经过时了。
先为你的团队建立一套文档系统：标准化的文件夹结构和测试用例命名规范，能简化协作、提升透明度。还要决定把测试用例放在哪里——本地化保存，还是用第三方工具。最后，建立一套系统来记录和分享你在系统性评审中所做的变更。
在落实计划的同时，务必维护好你的数据。凡是没有参数化的地方，如果这些值不按需更新，测试期间就可能出现误报（false positives）或漏报（false negatives）。
总结（Sum It Up）
测试用例是测试的基础。要结合业务需求精心规划它们；在构建时融入关键要素和推荐实践，让执行和维护更轻松、更高效；用模块化和参数化来提升效率；并主动地维护它们。
经过深思熟虑的开发，测试用例能驱动一套稳健的测试方法，提升你的软件质量，并满足最终用户的期望。接下来，可以继续学习 Testing Methodologies 模块来深化你的技能。