但是做起来就是：写不完的用例，跑不完的case，天天都要加班。
我以功能测试的工作流程，结合实际的工作内容，来具体细说一下做好功能测试的建议：
一、需求分析
首先一般大家接触到的都是产品主导型的开发模式，其中需求和项目，作为测试是没办法去主导的。这个时候就需要开展需求会议，来让团队中的各个成员来充分理解需求。
注意，需求会上没有澄清的一个小点，都会成为日后你工作中一个巨大的坑。
在需求评审中，你需要做的是提前阅读需求文档，把问题点都记录下来，然后在会上对描述不清晰、不便于设计用例、测试点不明确的地方都要抛出了，让产品经理给出具体的说明。
明白了什么是需求之后，进行需求澄清的时候，测试人员要深刻理解需求，在需求评审会议中，针对描述不清、不便于设计测试用例、找不准测试点、业务相关知识串联不起来的地方提出来，抛出疑惑，让产品经理给出说明。
为什么一定要开这个需求评审会呢？
以下面的这个快捷登录的页面为例：
比如，身份复选框是否合理？一个人是否能够拥有多重身份？验证码的有效时间及位数？产生异常情况页面会给出什么提示信息......这些细节点明确后，后面的工作才方便展开。
前面提到了需求评审之前要看需求文档。可以说如果你不知道怎么测，那你一定没有看过需求文档。
但是实际会遇到各种各样的情况：
第一种情况：没有需求文档或者需求就是一句话
第二种情况：有需求文档，但是非常的粗糙
遇到这种情况，有3个建议
· 要求需求分析人员或者开发完善需求文档；
· 如果团队不配合，就自己把待明确的点问清楚，同时做好记录；
· 切忌含糊不清，不要给自己挖坑。
第三种情况：有清晰详细的需求文档
有了清晰的文档，想要做好，还有一些建议
· 提高主观能动性，关注开发和产品的讨论内容，变动和难点要重点听，不要因为暂时没关系就不关注；
· 评估要全面，比如需求的内容涉及到的操作系统、改动会影响到哪些功能，然后给出准确的工作量，防止因为时间不足造成的测试不充分；
· 需求评审后，要求产品更新此次评审过程中的所有改动部分；
· 根据需求，制定好测试方案和需求，注意时间安排要富裕，防止出现意外情况。
二、用例编写
天下测试，唯用例设计不破，唯缺陷报告不破！
当说到用例编写就是等价类、边界值等，那么说明你写用例是照着书本上去写，而不是从用户的角度去写用例。
测试用例的设计能力是一个测试工程师的核心竞争力，这种能力能够让你面对各种类型的测试，都能设计出高效而全面的发现缺陷的测试用例。
想要达到这种水平，就要求你：
· 深入理解业务需求，熟悉产品的运行环境，比如技术架构、缓存机制、第三方服务集成等；
· 融会贯通，把具体的业务和系统性的测试设计方法结合起来，保证自己稳定出色的输出；
· 平时多积累，对常见的缺陷模式、类型等做好归纳总结，形成体系化用例设计思维；
· 经常阅读好的用例设计实例，开拓思路，举一反三。
三、提测验证
先说好，提测的时候不敢怼开发的，后面的锅可都是自己背哦！
在设计测试用例的时候，冒烟用例是一个子集。如果这些用例通不过，我们就可以将提测的模块打回。
发出一封可爱的主题为“xxx功能冒烟不通过，打回”并抄送老板的邮件，开发那边就要认真的执行冒烟用例了。
在此之前必须保证我们测试人员所提供的冒烟用例必须有质量，能够准确的覆盖重要的功能点。
在开发提测前，一定要确保开发做好以下准备，如果没有，宁可按下不动，也不可给自己挖坑：
· 完成端对端的联调
· 执行冒烟用例
· 列出改动点
· 准备好上回归环境的清单
· 必要时也可以让产品经理提前验收
对于测试人员来说，测试阶段要注意几个点：
必须有关注整体项目的意识，防止出现测试的内容和最初的需求不一致，增加新的内容从而增加工作量；
需求有变更，就要评估项目进度，如果有影响就要重新排期；
对于发现的bug一定要描述清楚，问题描述、重现步骤、前置条件、预期结果、实际结果等。
bug分级要准确，保证项目按期完成。
四、上线回归
当项目需要频繁的交付和上线的时候，面对无法自动化的测试用例，如何有效的进行手工的回归测试呢？
和项目中的开发以及项目负责人沟通确认；
关键点的测试，比如测试的重点：bug修改，关联功能，新增加功能，修改功能呢个，上一轮测试bug多的功能。
对开发人员能力的评估
项目初期对测试用例的维护
对项目做好完整的总结，比如提测次数、上线次数等
最后，对于刚入行的测试人员，小有所成之后，一定要经常的问自己：
我现在能力水平，究竟是我个人的能力，还是平台或者公司的高度？离开了这个公司，或者离开了这个熟悉的业务，我还能剩下什么？在测试行业我的优势和核心竞争力是什么？
只有把功能测试做好，研究明白，才能更好的去做性能和自动化测试。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
