测试用例编写的一般步 骤，以使编写的测试用例最大程度上满足 完备的要求，而又不产生重复而冗余的负 担。 测试用例的来源是产品需求，如果足 够幸运，我们应当有一份不错的可依赖的 Use Case文档，但大部分情况下，Use Case恐怕是不存在，能有一份不错的 PRD文档和原型设计图已经是不错的待遇 了，如果可能的话，最好还能够有HLD文 档，这些已经足够我们开始写详细的测试 用例文档（我相信在这之前无法产出详细 的测试用例文档①）。也许LLD文档产生 之后或者产品的第一个版本发布之后，我 们会不断的更新已有的测试用例，但那将 是不断的迭代过程，暂不做讨论。 首先让我们先从理论上了解测试用例 编写的一般步骤②： 1、确定测试套件（Test Suite）：测 试套件是功能上的划分，是相似测试场景 的组合，而非技术划分。如果技术设计中 各模块耦合度较高（强烈推荐解耦，哪怕 复制粘贴代码），可能功能上不相干的模 块由于代码重用的原因会在bug fix时互相 引致错误，实际上回归测试即是为了避免 这种情况。但是我们在做功能测试划分模 块时，还是要从用户的角度出发，按照用 户场景划分测试的“模块”。值得庆幸的 是，相似或相关的功能总是倾向于在同一 组页面出现，按钮和输入框、选择菜单等 内容并不是随机组合的一堆零件。 2、针对每一个测试套件，确定一个 或多个基本流程（basic flow）和可选流 程（alternative flow），即测试场景 （Test Scenario）：可以借助scenario matrix来清晰地对可能出现的场景进行排 列组合。值得注意的是，一方面Use Case或PRD文档中的描述很有可能并没 有完整的写尽所有的场景，测试人员尽可 能地挖掘测试场景，既有可能是出于测试 本身的需要，也可能是基于开发团队的工 作；另一方面，在复杂系统中，测试场景 不可能覆盖所有可能的场景，这便需要测 试人员采用一定的测试策略③，对 SUT（System under Testing）进行“足够 （adequate）”的测试，而不是完全的测 试。 3、针对每一个测试场景，确定一到 多个测试用例（Test Case）：仍然可以 借助matrix来清晰地规划测试用例，每一 个测试用例都有其对应的预置条件④、输 入和期望结果。测试用例分为Positive Test Case和Negative Test Case两种，分 别用来测试产品是否完成应当完成的工作 和不执行不应当完成的操作。更详尽地 说，测试用例一般包括以下列column： 用例编号/测试场景/用例描述/需求对应/用例分类（Positive/Negative）/用例类 型/用例级别/是否自动化/预置条件/测试 步骤/测试数据/预期结果/实际结果/备注/4、增加测试数据（Test Data）完成 测试用例：测试数据是测试用例中很重要 的内容，一个用例可能对应多套测试数 据，测试工程师根据某种测试技术⑤，将 尽可能的设计较少的测试数据完成“足 够”的测试。 任何规范、流程都是为了让工作更加 可靠，对于项目工程，天外飞仙灵机一动 应当放在合适的位置，而不应当成为规范 和流程的反例存在⑥。 现在让我们开始从登陆（PC端网 页，如果是PC客户端比如QQ或手机客户 端则又不同）开始说起。 不打开任何网站的登陆框，想象一下 登陆框的样子。