软件功能测试的依据从哪里来？如何确定测试的准绳？

软件功能测试

功能测试的依据到底从哪来？说白了就一句话：你说要做什么，我就测你有没有做到。但“你说”这两个字，在真实项目里可能来自好几个不同的地方。下面把这几个来源拆开讲讲。

测试依据的来源一：需求规格说明书

这是最核心的依据。需求规格说明书里写清楚了系统应该做什么、不应该做什么。测试用例就是从这里长出来的，每个功能点至少对应一条测试用例。如果需求文档里写了“用户注册需校验手机号格式”，那测试用例里就必须有一条“输入非法手机号格式，验证是否被拦截”。

但问题在于：很多项目的需求文档写得稀烂，甚至压根没有。

这种时候你不能停下来等，得去找产品经理、找业务方、找客户，把需求一点点抠出来。需求不明确就开测，结果就是测了一堆自以为对的东西，最后用户验收的时候告诉你“这不是我要的”。那时候再改，成本翻了几倍都不止。

测试依据的来源二：合同和技术协议

这比需求文档更硬。合同里写的技术条款，是具有法律约束力的验收标准。需求文档可以含糊，但合同里写的“系统响应时间≤2秒”“支持1000并发用户”，这些是白纸黑字签过字的，没有商量的余地。验收测试的时候，合同条款是第一优先级，需求文档排第二。合同里写了但需求文档里没写的，以合同为准。

第三个来源：行业标准和国标

有些事需求文档里可能没说清楚，但行业有通用的规范。比如软件质量要求，可以参照GB/T 25000.51-2016；信息安全方面的要求，等保2.0的标准在那里摆着。这些标准的好处是：你不必从头定义什么是“好的软件”，行业已经替你定义好了。

第四个来源：用户场景和原型

这是个容易被忽视的来源。需求文档写的是一回事，用户怎么用是另一回事。如果项目有原型图或者用户操作流程图，那这些也是测试依据的一部分，因为它们反映了用户真实的使用习惯和路径。

举个例子：需求文档写了“登录后跳转到首页”，但原型图上首页顶部有个醒目的“待办事项”模块，那测试的时候你除了验证跳转功能本身，还得验证这个模块在登录后是否正确显示了。需求文档没提这个模块怎么测，但原型图暗示了这个模块的重要性，这就是用户场景驱动的测试思维。

怎么确定测试的准绳？

准绳这个东西，核心就三个字：可量化。“系统反应快”“界面美观”“用户体验好”，这些都是废话，没法当准绳。你得把它们翻译成可验证的具体条件：

“反应快”可以变成“核心接口在1000并发下，95%的请求响应时间≤2秒”；

“界面美观”可以变成“所有页面在1920×1080和1366×768分辨率下无错位”；

“用户体验好”可以变成“新用户注册全流程在5分钟内可独立完成”。

准绳的判定标准大概分这么几类：

功能完整性：需求文档里的所有功能点都实现了，且测试全部通过。

性能达标：响应时间、吞吐量、并发数等指标达到合同或需求里约定的值。

兼容性范围：在约定的操作系统、浏览器、设备上都能正常运行。

安全性要求：通过安全测试，无高危漏洞。

用户体验标准：界面符合设计稿，操作路径符合用户习惯。

测试依据和测试准绳的关系是这样的：依据告诉你“要测什么”，准绳告诉你“测到什么程度算过”。一个是方向，一个是标尺。没有依据，你不知道测哪；没有准绳，你不知道测到什么程度算完。

说点实在的，实际项目里，需求文档和真实系统之间永远有差距。有人把这个差距叫“需求理解的偏差”，但我觉得更准确的说法是：“需求从一开始就没说清楚，而所有人都在假装自己听懂了。”测试人员能做的最靠谱的事，就是尽早参与需求讨论。

需求评审会的时候就在那里，把模糊的地方问清楚，把含糊的表述明确化。别等开发写完了代码、测试用例都设计好了，才跑来问“这个功能到底是啥意思”。那时候再问，什么代价都晚了。

还有一个容易被忽略的点：测试依据不是一成不变的。需求变更了，测试依据就得跟着更新。项目过程中需求变了但测试不知道，这种情况最要命，你还在按旧需求跑用例，开发已经按新需求改了代码，最后对不上的时候谁背锅？所以需求变更管理流程得跟上，每次变更都得同步到测试团队。

标签：测试依据、功能测试报告