一直做功能测试，功能测试这个东西，也有他的一套理论，一套流程，以及测试过程中的一些方法，什么边界法，等价类。但实际工作中，因为真正把测试流程走的很好的公司毕竟很少。所以编写测试计划，写完整的测试用列，运用这些方法可能机会不多。而实际工作中，完全的功能测试重要的就是理解业务和需求。所以具体的什么流程就不说了，网上资料很多。
下面谈谈自己对功能测试的一点看法：
需求理解了，知道客户想要系统实现什么，理解了业务，就知道了系统是怎样一个流程来实现的。然后按照需求来进行测试的，不满足需求要求的都可以认为是BUG。但实际中，这样一个简化了过程都很难，毕竟想从开发那拿到一份完整详细的需求都是很不容易的（当然，可能也有比较规范的公司，但目前大多数应该是这个情况）。
当然功能测试也不是真的那么简单，要做好一个功能测试，前提是要对需求比较熟悉，各个业务细节都很了解。甚至做到比开发人员还要了解。这或许是测试人员唯一的优势了。个人做了快1年功能测试的一点看法。要做好功能测试，还需要对整个业务中数据库的操作比较清楚（针对信息管理相关的系统）。比如哪个业务需要用到那些表，做怎么样的操作。了解了这个就可以不单单从程序前台来看程序，看到数据库的过程，更有利于你找到隐藏的BUG。比如库表没有进行关联删除，日志表没有插如记录。这些是从前台看不出来的，但实际可能会导致程序出现问题。
除此之外，了解程序框架的一个结构也有助你更好的去测试程序以及定位程序错误。比如前台是如何和后台通信的，之间是什么协议，什么格式。后台是如何处理这些数据的。做完一个业务，发现错误，可以通过系统的日志记录来查看错误的原因。而前面数据库的也可以用上。可能日志中记录了执行那天SQL语句出错，执行哪个函数出错。这样就要助于你帮开发人员定位问题。当然，测试人员不可能去深入的了解程序代码（当然你如果足够有兴趣也有时间还是可以的，以后可以帮改BUG了）
在一个就是开发人员沟通。这个沟通其实也不是想象中那么重要，毕竟出现了BUG他就需要去改。但和开发人员搞好关系绝对很重要。因为BUG你可以问他原因，他会给你讲解，这也有助你在以后测试中多注意这样的问题，当然这是要靠自己总结的。在就是2个人沟通比较好的话，相互合作容易找到BUG的原因以及改正和验证。要知道，开发人员是很喜欢一个能帮他找到问题地方的测试人员，虽然这并不是我们工作的重点，但这也是对自己的一个提高。
最后一点就是个人的学习习惯了。确实，功能测试能学习到的东西并不多，如果你仅仅是了解业务，那你换个公司，换个系统，你永远都是个新人。所以做功能测试的如何去提高自己呢？功能测试是不能一辈子做的，当然如果你就喜欢用手点来点去，看看程序有没问题那也没办法。所以学习是很重要的。比如操作系统，数据库，网络。
自己做了这么久功能测试，也曾经很彷徨，觉得就这样点来点去，看看结果，觉得真的没有什么前途。现在想下觉得自己太浮躁。毕竟大多数的地方还是需要这样的功能测试人员。而且任何一个做测试的人也需要从这一步开始，熟悉测试的过程，有一定的测试理论基础才能走的更远。所以要多学习，多总结。做功能测试，经验也是很重要，当然也要熟悉整个
任何工作，都可以从中学到很多东西，都可以做的很深入，即便是功能测试。关键是自己时候有兴趣，是否适合自己。因为自己的兴趣并不是很大，虽然做的很认真，但并没有很深入的去学习。自己其实还很肤浅，或许只看到了功能测试的冰山一角，所以也只是谈谈自己对这一角的看法把。也欢迎大家谈谈自己的看法。（以上言论仅代表作者的个人观点，不代表51Testing观点）
