功能测试(Functional testing )，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。
今天boss问我们对于公司当前功能测试是否有完善意见，突然觉得这个话题离我们很近，却总来没深入总结过。还好要求明天上交报告，先在此做些总结，到时候拼装下给boss.
接触测试三年了，从测试工程师到测试组长兼sepg，然后跳槽继续测试工程师。一路下来都在跟需求跟业务打交道。做好测试首先要做好需求、理解业务，这个不用多说了，相信很多人都总结过。当然也听到过一些言论“换单位了，那业务不是没用了”，换单位后，业务没用这是必然的，我也是从易制毒换到当前的税务，但有一点都是跟政府行业，其实我们要做的是摸索和总结如何快速获取和掌握新业务，内容不同，但方法是可以通用的。
对于需求处理，就我接触的有以下三种情况。
A、有需求说明，无设计文档。
B、有需求分析文档，快完成时临时补充设计文档。
C、有需求分析文档和设计文档。
A这种情况一般分工不是很明确的小团队都会出现，需求来源为客户或者区域客服（特点是太简单了没经过提取，或者太自我了，很难实现），这时候在不规范的过程也会弄一次需求讨论。
这个时候测试务必要做到这点——争取参加需求讨论会议，不用发言，只要听就可以。因为这里没有写文档的习惯，很多测试标准、需求处理细点都会在口头上体现，你得眼疾手快，参加会议很好的一点就是测试过程中，碰到不一致的地方，可以有足够的重语气让开发修改，因为你有证据，而不用去问开发这点是不是要改，如何实现。
B这种情况其实是最头痛的，在时间紧和维护项目中经常出现。软件需求功能在界面上都实现了，但开发只是考虑实现需求，却没有把需求与当前业务（其他模块的逻辑），后台数据处理（例如某个字段更新）这些弄好。因为功能测试时，测试人员大都会跑流程或者数据库测试，这时候模糊无标准的问题就来了，头痛。
另外一些开发人员就会以功能实现，进入测试、或者边设计边改，测试就大工作量了。这个时候测试有这些可以扭转一些局面——版本验收流程、开发人员给测试人员培训。版本验收：像前面提出的，设计不全面等，很容易导致只完成需求，破坏了原有功能或流程功能，在拿到版本后，进行初步的重要流程验收，可以减少很多测试工作量。
开发人员讲解培训：这个很好的解决了由于没设计文档导致的测试不了解内部，被动，另外也是给开发压力，逼他们做单元和集成自测，从中测试也可以提问，不要觉得这是浪费时间，好处你试了才知道。我很坏，呵呵。
C这种情况一般实行Cmmi3之后的企业都很规范。这里我讲下自己的几个方法，更好的理解需求：模块间逻辑图、数据流向图、需求用例矩阵。模块间逻辑图：其实就usecase图、流程图，只要能让自己摸清楚模块间的业务联系即可，为自己的业务测试用例做准备。数据流向图：目的是搞清楚，该某块功能涉及哪些表、存储过程，数据表见关系如何，其实有点像数据库模型的小型版，很多问题在界面上实现了，但后台sql处理却有错误。例矩阵这个主要是对覆盖率进行校验，其实就是一个execl，针对某个需求点有哪些用例。
这些文档我稍后上转。另外在阅读需求时，多写一些为什么（例如：文档上写着某输入框有默认值，那你注明下：默认值可以修改吗？）
或许你们觉得让测试参加会议，让开发讲解这些有点难，但记住一点：做测试的一定要“主动”。
在做功能测试过程中，经常会碰到其他的问题。例如：对于web，所用控件的ie兼容性，标签值显示格式、长度，提示信息风格、内容，按钮大小，名称等这些，当前项目和开发人员都习惯最后处理。更多时候测试跟开发还不能达成一致，维护时还有“这是以前开发人员弄的，当前不予修改这些。”
一些通用的界面要求可以定个标准并维护，这个初步难的话，在项目测试计划里能注明下，并达成统一。这样避免项目后期，开发人员改动，测试人员由于对工作负责又得全部测试一遍，减少工作量。
功能测试，先抓主干，在测分支这是恒定的原则。但如何完善功能测试这个值得讨论，测试前如何分析需求，编写用例，测试通过准则。测试中确定测试版本，选择用例，测试优先级。项目后期的测试分析，用例优化等等。
【编辑推荐】
