功能测试主要做什么

功能测试只回答一个问题：给一个输入，系统给出的输出是否与需求写明的一致。它不打开代码看实现，所以又叫黑盒测试。衡量它做得好不好，不是看跑了多少条用例，而是看需求里的每一条规则，有没有至少一条用例真正覆盖到。

功能测试盯的是「输入到输出」，不是代码

这里的「输入」比一般人想的宽。点一次按钮是输入，填一段超长文本是输入，在弱网下重复提交也是输入，用没有权限的账号去调接口同样是输入。同一段业务逻辑，从页面点进去和直接调接口进去，走的是两条路径，两条都要覆盖。

它和单元测试的分界在责任人与颗粒度。单元测试由开发写，针对一个函数或一个类，验证分支；功能测试由测试人员按需求写，针对用户能看见的行为，验证结果。单元测试全绿不代表功能可用，因为集成处的参数拼装、权限校验、状态流转，单元测试通常碰不到。

判断一条结果算不算缺陷，依据是需求文档、原型和已经确认过的口径，不是测试人员的主观预期。需求没写清楚的地方要先问清楚再写用例，否则争到最后往往变成一句「这是需求问题」。

黑盒用例怎么设计，四种方法各补哪一块盲区？

等价类划分把输入域切成若干块，每一块取一个代表值，认为块内效果相同。有效等价类验证正常路径，无效等价类验证异常处理。这里有一条容易被忽略的规则：一条用例只覆盖一个无效等价类。因为程序碰到第一个非法输入就会报错返回，后面几个非法值根本没被执行到，把它们塞进同一条用例，等于自己骗自己。

边界值分析针对「等于、略大于、略小于」三个点取值。大量缺陷恰好落在边界上，因为循环的终止条件、数组的下标、字段的长度限制，错的往往就是那个「等于」。判定表用来处理多条规则交叉的情况，把条件桩与动作桩列全，逐列检查有没有漏掉的条件组合。场景法则按用户的真实操作链走，一条基本流加若干备选流，专门抓「单步都对、连起来就错」的问题。

四种方法不是选一个用，而是叠着用。先用场景法铺出主流程，再用等价类和边界值填数据，最后用判定表核对规则组合有没有缺口。只做其中一种，覆盖率的缺口一定存在，只是看不见。

一条合格的测试用例，要写满六项

六项分别是用例编号、前置条件、操作步骤、测试数据、预期结果、实际结果。编号保证可追溯，缺陷单里要能指回是哪条用例发现的；前置条件写清账号角色、数据状态、环境版本，否则别人复现不出来；操作步骤要细到「点哪个按钮、填哪个框」，写「进行删除操作」这种话等于没写。

测试数据和操作步骤要分开列。数据单独成列，改一个值就能生成一条新用例，也方便做数据驱动。预期结果必须具体到可见的文案、状态码或数据变化，写「删除成功」不算数，要写「列表页不再出现该条记录，总数减一，弹出提示『删除成功』」。

实际结果一栏在执行时填，通过与不通过都要留痕。这一栏空着的用例，在回归阶段等于废纸，因为没人知道它上次跑出的是什么。

「删除」一个按钮，能拆出多少种情况？

最基础的三条是：删除一条库里存在的数据，看是否真的删掉；删除一条不存在的数据，看是否给出提示而不是抛五百错误；删除一个格式非法的标识，看是否被拦截。这三条只覆盖了正常路径与两类异常，离「测全」还远。

真正容易出事的是后面几条。删除一条已被其他业务引用的数据，系统是级联删除、禁止删除，还是留下脏数据？两个人同时删同一条，第二次操作是提示「已被删除」还是直接报错？批量删除十条里有一条失败，是全部回滚还是部分成功？没有删除权限的账号直接调这个接口，前端藏了按钮但后端有没有校验？删除之后列表的分页、总数、缓存有没有同步刷新？

这几条的共同点是都涉及状态与并发，单看界面点一遍永远发现不了。功能测试的价值，很大程度上就体现在能不能想到这些「不在需求正文里、但一定会发生」的情况。

功能测试之外，还有五类测试在管别的事

性能测试看响应时间、吞吐量和资源占用，功能全对但三秒才返回，一样不能用。兼容性测试看不同浏览器、系统版本、屏幕尺寸、机型下的表现。安全测试看越权、注入、敏感信息泄露，它与功能测试里的权限校验有重叠，但深度不同。易用性测试看用户能不能顺畅完成任务。回归测试则在每次改动后确认老功能没被改坏。

这几类测试与功能测试的分工，可以按关注点划：功能问「对不对」，性能问「快不快」，兼容问「到处能不能用」，安全问「会不会被绕过」，易用问「好不好用」。同一条用例可能同时服务多个目的，但设计时的出发点必须清楚，否则测出来的结论会含糊。

常见问题

功能测试和黑盒测试是同一个东西吗？

不完全等同。功能测试是按测试对象划分的类别，黑盒测试是按是否查看代码划分的方法。功能测试绝大多数用黑盒方法做，但也可以用灰盒方式，比如查日志、查数据库来辅助判断。反过来说，性能测试、兼容性测试同样属于黑盒。

测试用例写得越细越好吗？

看项目阶段。需求稳定、回归频繁的项目，用例要写细，细到换个人也能执行；需求天天变的早期项目，写太细会大量返工，这时更适合写测试点加探索式测试。判断标准很简单：这条用例三个月后还有没有人照着跑。

自动化能替代功能测试吗？

能替代重复执行的部分，替代不了判断。脚本能比对返回值和页面元素，但「这个交互是否符合用户预期」「这句提示文案会不会引起误解」，仍然要人看。比较现实的做法是：稳定的主流程做自动化，新功能与边界情况靠人工探索。