✅ 一、什么是“测试用例”？（通俗理解）

测试用例就是用来验证某个功能有没有做好的一组检查项，它包含：

• 要测的功能（比如登录）
• 输入什么数据（比如用户名和密码）
• 预期输出（比如返回“登录成功”）
• 实际输出（测试时看到的结果）
• 判断测试是否通过

简单理解： 测试用例就像做饭前的食谱，你告诉厨师：“用鸡蛋+番茄，炒出来要是红黄相间的番茄炒蛋才算成功”，这就是一个测试用例。

---

✅ 二、为什么要写测试用例？

1. 防止出错：写完功能后，有没有漏写逻辑？写错逻辑？测试用例能帮你查出来。
2. 防止回归问题：以后改代码，别人能快速判断有没有影响原有功能。
3. 可以自动化测试：用脚本执行一堆测试用例，让测试更快、更准。
4. 团队协作：前端、后端、测试、产品都能明确功能预期。

---

✅ 三、举个例子：thinkjs 的测试用例（API 示例）

假设我们有一个用户登录接口 /api/user/login，POST 方法。

1. 目标代码（thinkjs 控制器）：

// src/controller/api/user.js
module.exports = class extends think.Controller {
  async loginAction() {
    const username = this.post('username');
    const password = this.post('password');

    if (username === 'admin' && password === '123456') {
      return this.success({ message: '登录成功' });
    } else {
      return this.fail(401, '用户名或密码错误');
    }
  }
};

---

2. 测试用例（写法是 Mocha + think-testing）

// test/controller/api/user.js
const test = require('think-testing');
const assert = require('assert');

describe('测试用户登录接口', () => {
  const instance = test();

  it('正确的用户名和密码应该登录成功', async () => {
    const res = await instance.post('/api/user/login').send({
      username: 'admin',
      password: '123456'
    });
    assert.equal(res.body.errno, 0); // 成功
    assert.equal(res.body.data.message, '登录成功');
  });

  it('错误的密码应该返回错误', async () => {
    const res = await instance.post('/api/user/login').send({
      username: 'admin',
      password: 'wrong'
    });
    assert.equal(res.body.errno, 401); // 错误码
    assert.equal(res.body.errmsg, '用户名或密码错误');
  });
});

---

✅ 四、拆解一下测试用例的组成：

用例编号	描述	输入	预期输出
TC001	登录成功	username=admin password=123456	errno=0, message="登录成功"
TC002	密码错误	username=admin password=wrong	errno=401, errmsg="用户名或密码错误"

---

✅ 总结

• 测试用例=说明书+验收标准。
• 有了测试用例，你就知道功能做完了没，有没有出错。
• 用 Mocha + think-testing 可以快速编写 thinkjs 的自动化测试用例。

✅ 简单回答：

人工测当然可以，但自动化测试更稳、更快、更能应对复杂变化。

就像你手动拧螺丝当然行，但你要组装 1 万台机器，用电动螺丝刀效率高得多。

---

对比：人工测试 vs 写测试用例

维度	人工测试（比如 Postman）	写测试用例（自动化）
初始成本	✅ 低，上手快	❌ 有点麻烦，前期要写脚本
测试速度	❌ 慢，一个个点	✅ 一键运行几十上百条用例
可重复性	❌ 每次都要重复手动点	✅ 脚本写一次，随时跑，随时验证
回归测试	❌ 难，每次改功能都得手动再测	✅ 自动化用例直接复用，一键跑完
错误记录	❌ 人工易忘、出错难重现	✅ 自动比对预期和实际，留下日志
适合场景	一次性测试，功能不复杂	功能多、逻辑复杂、需要长期维护的项目

---

场景举例说明

✅ 场景一：上线前一天改了个登录逻辑

• 你用 Postman 测：你得一个一个接口点过去。
• 你用测试用例：一条命令 npm test，几十个用例自动跑，10 秒内知道有没有被你改坏。

---

✅ 场景二：你和别人协作开发接口

• 没测试用例，你得靠人沟通“接口是不是正常”。
• 有测试用例，你说：“你改完跑下测试用例，绿灯就代表没出问题。”

---

✅ 场景三：有个 bug 难以复现

• 用 Postman 手动测时，漏掉了某种情况。
• 用测试脚本时，把所有输入组合都写进去，不容易漏掉。

---

最终建议

✔ 如果你是小项目、接口不多：

用 Postman 辅助测试也行，省事儿。

✔ 如果你是团队协作、大项目、多人维护、持续迭代：

自动化测试用例一定要有！ 哪怕只写核心接口，也能大大减轻你以后的维护压力。

---