功能测试是什么？如何做好功能测试？从入门到实战10年经验分享
“功能测试是什么？如何做好？”这个问题，我刚入行时也懵懵懂懂，觉得不就是点点点嘛。但十年摸爬滚打下来，才明白这二字背后是软件质量的生死线。
一、功能测试到底在测什么？
简单说，功能测试就是验证软件的各项功能是否按照需求规格说明书的要求正确实现。它不关心代码怎么写、用了什么架构，只看输入什么、输出什么、业务流程能不能走通。
跟性能测试、安全测试比起来，功能测试的“技术含量”看起来没那么高。但说句实在话，功能测试做不好，后面所有测试都是白搭，功能都不对，性能再快、安全再强，有什么意义？
我见过的项目，绝大多数上线后出的问题，80%以上都是功能逻辑层面的问题，不是性能问题，也不是安全问题。功能测试虽然基础，但它是最容易出问题、最容易被低估的环节。
二、做好功能测试，核心是这四件事
第一，把需求吃透。
这是所有功能测试的起点。测试用例是根据需求写的，需求理解错了，用例设计得再好也是白费。
需求规格说明书是测试的“宪法”。功能点是否完整实现、业务流程是否走通、边界条件是否正确处理，全凭它说了算。但很多项目的需求文档写得稀烂，甚至压根没有。这时候你不能停下来等，得去找产品经理、找业务方、找客户，把需求一点点抠出来。
需求不明确就开测，结果就是测了一堆自以为对的东西，最后用户验收的时候告诉你“这不是我要的”。那时候再改，成本翻了几倍都不止。测试人员能做的事，就是尽早介入需求讨论。需求评审会的时候就在那里，把模糊的地方问清楚，把含糊的表述明确化。别等代码写完了才跑来问“这个功能到底是啥意思”。
第二，用例设计得有章法。
很多人写用例就是“想到哪写到哪”，今天测登录、明天测支付，最后用例东一块西一块，覆盖得乱七八糟。
好的用例设计需要用到一些经典方法：
1.等价类划分，把输入数据分成有效和无效两类，从每类里挑几个代表来测。比如年龄输入框要求1-100岁，那就测一个有效值（比如25岁），再测两个无效值（0岁和101岁）。这样能用最少的用例覆盖最多的场景。
2.边界值分析，大量的bug出现在边界上。密码长度要求6到16位，那就测5位、6位、7位、15位、16位、17位。6位是边界，5位和17位是越界——这几个值能测出大部分边界问题。
3.场景法，业务场景测试。用户不会只点一个按钮，他们会在系统里走完一条完整的路径。设计用例的时候，把用户的核心操作路径串起来：浏览商品→加入购物车→登录→填写地址→支付→确认订单。这条路径上的任何一个环节出问题，都会导致业务走不通。
第三，执行测试不能“应付差事”。
最怕的是“测了，但没认真测”。用例写好了，执行的时候走马观花，点一下没问题就过了。这种测试，发现不了真正的问题。
执行测试的时候，除了走通正向流程，还要注意异常输入，比如登录的时候输入特殊字符、超长字符串，看看系统会不会崩溃；边界情况，比如购物车为空的时候去结算、支付的时候余额刚好不够；权限控制，普通用户能不能访问管理员页面、能不能看到别人的订单。
还有一个容易被忽略的点：测试数据要真实。用几条假数据跑出来的结果，跟真实业务场景里的结果完全是两码事。数据量不一样，很多逻辑走不到，测出来的结果也就没意义。
第四，缺陷管理要闭环。
发现bug不是终点，修完了还得验证、还得关闭。
缺陷管理有几个基本要求：缺陷描述要能让开发人员精准复现;操作步骤、预期结果、实际结果、日志截图，一样不能少。缺陷要分级：致命、严重、一般、轻微，不同级别对应不同的修复优先级。最关键的是回归测试,修完bug之后，重新执行相关用例，确认修复没有引入新问题。改了一个bug结果把另一个功能搞坏了，这种连锁反应在项目里太常见了。
三、十余年测试经验总结的几个“坑”
坑一：只测正向流程，不测异常。
正向流程全通了，用户一上来随便输了个特殊字符，系统直接崩了。验收的时候压根没测异常输入，等出了事才反应过来。
坑二：用例跟需求脱节。
需求已经改了，用例还在用旧版本的。项目过程中需求变了但测试不知道，按旧需求跑用例，开发按新需求改了代码，最后对不上的时候全是坑。
坑三：自己测自己，看不见盲点。
开发人员太熟悉自己的代码了，测试的时候顺着自己的思路走，那些真正要命的边界条件和异常场景，恰恰是自己最容易忽略的。
坑四：不重视回归测试。
修了一个bug，结果引发了三个新bug。每次改完代码，都得把之前已经测过的功能重新跑一遍。这事儿虽然烦，但必须做。
功能测试这件事，本质上是在做一件事：用你的专业判断力，发现开发人员没想到的问题。 想的越多、越细，测试质量就越高。
标签：功能测试、软件测试报告