企业官网建设流程全解析

原文用“功能、界面、性能、兼容性”等维度提醒自己不要遗漏测试方向，这个用途还在。但“测试正常登录”不是一条可以执行的用例，“万能模型”也不会自动告诉我什么结果才正确。

我想把这篇补成一个完整的小过程：先固定需求，再选输入，写出预期，执行后检查。否则表格再长，也可能只是在重复“应该正常”。

1. 先问需求，别先列上百条输入

以下是自建的本地输入校验模型，不连接网站，不验证账号密码是否匹配，不签发 Token，也不模拟真实登录服务。只讨论这几条明确规则：

R3、R4 不通过返回 INVALID_FORMAT，全部通过返回 FORMAT_OK。FORMAT_OK 只表示格式通过，不表示认证成功。6～12 位也是为了延续原文的练习示例，不是给真实系统推荐的密码策略；真实策略要另审长度上限、字符支持与安全需求。

如果需求没有说服务不可用与账号停用谁先提示，测试不能自己拍脑袋判定正确输出。先记录疑问，确认优先级，再写预期。

2. 等价类和边界不是一串随意挑的数字

在服务可用、账号启用的前提下，长度分成小于6、6～12、大于12三类。选8位是合法类的一个代表，但它不能代替端点测试。

这里是离散的整数长度，所以可以使用相邻的三个点检查每个边界。不能把“永远测 n±1”搬到时间、浮点金额、Unicode 字符等任意输入域。

长度测试全部使用 ASCII 字母，以免同时引入字符规则导致归因混乱。再另外测空格、标点、非ASCII字符和非字符串。无效输入是否属于同一类，取决于处理规则，不是都给它贴一个“错误数据”标签就结束。

3. 判定表把多条件与优先级写出来

先使用合法输入 abc123，隔离格式因素。

最后一行正是优先级测试。如果把两个判断互换，只测“账号停用”与“服务不可用”各自单独出现，是发现不了这个变化的。

判定表用于列条件组合与动作；因果图可以辅助整理条件关系，但不是判定表的另一个名字。组合很多时，还要标记不可能状态、约束和风险，不能无条件要求所有场景都暴力穷举。

4. 把表中的预期变成可以运行的断言

保存为 input-check.cjs，使用 Node.js 执行。所有预期都写在数据表里，不让校验函数自己给自己生成正确答案。

const assert = require('node:assert/strict'); function assessInput(password, enabled, online) { if (!online) return 'SERVICE_UNAVAILABLE'; if (!enabled) return 'ACCOUNT_DISABLED'; if (typeof password !== 'string' || password.length < 6 || password.length > 12 || /[^A-Za-z0-9]/.test(password)) { return 'INVALID_FORMAT'; } return 'FORMAT_OK'; } const decisionCases = [ ['abc123', true, true, 'FORMAT_OK'], ['abc123', false, true, 'ACCOUNT_DISABLED'], ['abc123', true, false, 'SERVICE_UNAVAILABLE'], ['abc123', false, false, 'SERVICE_UNAVAILABLE'] ]; const lengthCases = [ [5, 'INVALID_FORMAT'], [6, 'FORMAT_OK'], [7, 'FORMAT_OK'], [11, 'FORMAT_OK'], [12, 'FORMAT_OK'], [13, 'INVALID_FORMAT'] ].map(([n, expected]) => ['a'.repeat(n), true, true, expected]); const formatCases = [ [null, true, true, 'INVALID_FORMAT'], ['abc 12', true, true, 'INVALID_FORMAT'], ['中文1234', true, true, 'INVALID_FORMAT'], ['abc12!', true, true, 'INVALID_FORMAT'], ['abc123\n', true, true, 'INVALID_FORMAT'], ['abc123', true, true, 'FORMAT_OK'] ]; const cases = [...decisionCases, ...lengthCases, ...formatCases]; for (const [password, enabled, online, expected] of cases) { assert.equal(assessInput(password, enabled, online), expected, JSON.stringify({password, enabled, online})); } console.log(`PASS: ${cases.length} decision/boundary/format cases`);

node input-check.cjs

Node.js 22.14 本次实际输出：

PASS: 16 decision/boundary/format cases

字符检查使用 ASCII 范围，是为了与 R4 一致，不是因为 JavaScript 字符串长度普遍等于用户看到的字符数。这里检查“是否存在非法字符”，另行检查长度，尾部换行也不能混过去。若改写为带^、$的整串校验正则，不应随手加多行标志m，否则锚点也会匹配行边界，而不只整串边界，参见 MDN 输入边界断言。若真实需求接受 Unicode，要先决定按码元、码点还是用户感知字符计数，再设计用例。也不要在生产日志中输出密码；这里的断言信息只包含固定的合成样例。

为了检查验证器自身，本次另外把下界改成7、把两个状态检查交换、让标点绕过字符检查。三种错误版本都被这16条用例拒绝。变异被拒绝，只说明这些指定错误能被发现，不等于测试集已经完整。

5. 覆盖率要能追溯，也要敢写“还没测”

这就是一个很小的需求跟踪表。需求有用例、用例有结果，是可追溯性的起点；“每条需求都有至少一个用例”不是“每条需求都充分验证”。不要把这两个比例都叫百分之百覆盖率。

真正的业务场景还需要请求、错误提示、后端认证、会话以及重试等层面。性能、弱网、兼容性可以用来补检查方向，但应说明目标环境与预期指标，不能用本地函数16条通过来代替这些验证。

错误猜测可以提出“实现是不是误用 trim”“前后端是否字符计数不同”等候选风险；最终仍要写出可执行前提和判定标准。没有需求依据的猜测，应先作为待确认问题，而非直接宣布产品有Bug。

6. 回到面试回答，也回到日常工作

我现在更愿意这样回答：先确认输入域、依赖状态和失败优先级；按等价类找代表，按边界找临界点，多条件用判定表；把预期写死成可执行断言，再用需求跟踪表注明已验证和仍缺的层面。

与测试分类与覆盖率反例一起看：分类帮助我找方向，用例帮助我检验具体行为。这里不追求“万能”，追求的是每条用例都有依据、失败能解释、结果能复现。