当你第一次开始接触测试这个行业的时候，首先听说的应该都是功能测试。
功能测试是通过一些测试手段来验证开发做出的代码是否符合产品需求。这些年功能测试好像不太受欢迎了，不少同学开始尝试自动化测试，测试开发等等，结果是功能测试、自动化测试、测试开发一样都没做好。
我们通常认为的功能测试是根据需求，采取以下测试流程：需求分析，用例编写，用例评审，提测验证，Bug回归验证，上线与线上回归等测试。如此日复一日，年复一年，可是等准备换工作的时候却得不到认可，你也遇到这种情况吗？
那么如何做好功能测试？功能测试用到哪些知识？有哪些相关的建议呢？
业务方在提出需求的时候，产品是要分析这个需求的价值，影响范围和实现代价的。在需求评审的时候，作为一个测试人员必须了解这次需求的内容，影响到哪些现有的功能，涉及到的操作系统或是类别等，然后准确的评估出工作量，防止因评估不足造成后期测试不充分。
再者，关注开发和产品的讨论，关注需求最后如何实现？其中做出的变动和难点就是测试的时候必须重点关注的部分，不能因为这些暂时和你没有关系就不去关注，防止欠债越来越多，不能做好充分的的测试。
第三，需求评审结束后，要求产品更新此次评审过程中的所有改动部分，同时确保之后的任何需求变化都及时更新。
第四，根据产品需求，同时与在会人员进行探讨，设计测试方案及时间安排，此时可以粗粒度考虑，时间上要合理。
测试用例是每个测试人员工作过程中必须要完成的工作，它对测试工作起到指导作用，也是相关业务的一个文档沉淀。在以往面试的经验中，有许多人的测试用例写的没有章法，他们是凭着感觉去写测试用例，也没有从用户的角度来思考如何编写测试用例，对于测试用例设计较为常见的方法论也不清楚。
假如面试的时候给你一个场景：一个全新的App要发布，如果让你来测试，你能想到哪些测试方案？如果你只能想到如何去测试app的功能的话，作为功能测试人员就考虑不够全面。此时除了App的功能以外，还应关注App的兼容性，易用性，接口的功能测试和性能测试，数据的存储以及容灾情况等等都应考虑在内。
测试用例可设计为两类： 一类是开发自测和验收提测试标准的冒烟测试用例；一类是针对需求的全面测试用例。
编写完测试用例后主动联系相关人员进行用例评审，在评审过程中及时修改不合适的用例。
项目的流程控制在需求开始的时候就应该重视起来，只是很多时候我们没有意识到这是测试的工作，有的是产品来控制，有的是专门的项目经理来控制。
测试人员需要有关注整体项目的意识。如果你不关注项目进度，什么时候提测什么时候开始测试，那么在测试过程中会遇到测试的内容和最初的需求不一致时候就会额外需要时间来解决，导致项目延期。另外主动关注项目，长此以往，你的这份主动性也会是你有效的竞争力。
需求一旦明确了由你来负责的时候，就要时刻来关注项目的情况。中间变更需求的时候，要评估是否影响项目进度，如果影响了重新进行排期。如果开发提测试晚了，是否影响上线时间，如果影响需要及时跟相关的人员沟通，发风险邮件，通知大家详细的情况。
同时在测试过程中，发现了bug需要详细描述问题，以方便开发去进行重现和修改。同时给bug准确分级，实时跟踪进度，保证项目高质量的按期完成。
一个需求上线完成后，要及时进行线上回归，同时必须回归我们在需求评审的时候考虑到的可能影响到的原有的功能，以确保新功能完全上线成功。
在一个项目完成后，最好有一份个人总结报告，总结整个项目过程中遇到的问题及最后的解决办法，有哪些需要注意的问题？有什么可以借鉴的方案或是改进策略？项目中有没有通用性的问题等等。
在找工作的时候，很多做功能测试多年的同学都遭遇过面试失败，究其原因，我觉得最核心的原因是：不具备相应工作年限应该具备的能力。
我们应该时常问自己一句话：离开现有的平台，我还有什么？如果仅仅是对现在公司业务和工具的熟悉，那是没有任何优势可言的。
对同类业务流程的掌握，项目的整体把控，快速了解业务并能根据需求选择测试方案，引入提高测试效率测试方案和工具，测试过程中遇到问题的预判和解决办法等才是功能测试人员必须具备的能力。
这些方面你做到了吗？不要抱怨功能测试如何如何，认清行业现状和自己的优缺点，做好自己的职业规划。
如果你不善于编码，那么做务专家也是功能测试人员一个很好的选择。
