功能测试仅仅是负责界面显示内容测试吗？

个人理解什么是功能测试：
功能测试的依据是需求，一切软件的功能都来源于需求，因此功能测试主要是对需求的实现情况的验证，不需要关系软件代码本身。嘻嘻，这就是传说的黑盒测试
~~嗯，写到这里要说一下，不管代码实现，那么数据库是否管呀？
我觉得只要你在程序中找得到对应的显示，你可以从程序表象去验证。但是如果在程序表面你看不到的信息，那么你需要直接进入数据库中查看

我们要把功能测试进行到底，那么必须具有技术含量，仅仅界面中的点来点去，实在是没有什么意思。最主要的是这样的测试会遗漏很多测试检查点。

个人理解功能测试需要做得工作：
1、需求理解（明确测试目的）
2、业务理解（明确测试流程）
3、界面测试（计划，执行测试内容）
4、相关界面测试（通过对数据结构的分析，找到被测模块的相关模块）

功能测试测试点：
常规的测试点我就不说了，基本大家都知道。
个人认为经常出问题的就是“经过修改或者删除操作后，信息的同步，信息的一致性问题”。
举个例子，资产信息中资产数量为10，资产金额为900。当该资产登记了出库申请后，出库单上表明资产数量为10，资产金额为900。但是此时，如果对这个资产基础信息进行了修改，将数量变成了8，金额变成了100。那么此时，之前的出库单上面记录的是那个数量呢？这种出库单的情况就属于历史数据情况。
如果类似的历史数据情况不有一个良好的验证，很可能会将原有产生的数据搞混乱。影响后续的统计，汇总，报表等工作。

功能测试用例：
经常看到两个极端的用例，要么超级细节，写得详细的很，可读性很差，写后自己都看不动为什么这么写。
还有一种用例就是写得相当简单扼要，其实跟需求差不多，并没有表明具体测试点。

最终总结，不能用语言描述，只能说需要两种情况的结合，掌握“度”。通过跟需求和开发人员的不短磨合，才能做出适合你所在的工作环境的功能测试用例。

个人认为，一切事务无好坏之分，只有适合与否。从老师那里听来的理论固然正确，但是运行到实际工作中，可能就是不好的（用不了，不适合）的。