如何作好功能测试

      不论你是何时开始接触测试这个行业的，你首先据说的应该是功能测试。经过一些测试手段来验证开发作出的代码是否符合产品的需求？固然你也有本身对功能测试的理解，可是最近两年感受功能测试好像不太受欢迎，同时很多同窗真的是功能测试都没有作好，就去尝试自动化测试，测试开发什么的，结果是越学越迷茫，这是为何呢？究其缘由是，你功能测试尚未学好呢！

      咱们一般认为的功能测试是根据需求，采起以下测试流程：需求分析，用例编写，用例评审，提测验证，Bug回归验证，上线与线上回归等来进行测试。如此日复一日，年复一年，响应了不少需求，但是想换工做的时候却得不到承认,你们想一想是否是这种状况？下面我就以一个功能测试人员如何进行工做，来介绍一下功能测试应该用到的知识及相关的提高建议。

一，  需求分析，发挥主动性

      正常的需求在产出的时候，产品是要分析这个需求的价值，影响范围和实现代价的。但是如今不少状况是，需求来了就组织评审，而后开发测试与上线。产品主导型的开发模式很是常见，做为测试咱们没法主导需求和项目。在需求评审的时候，做为一个测试人员必须了解此次需求的内容，影响到哪些现有的功能，涉及到的操做系统或是类别等，而后准确的评估出工做量，防止因评估不足形成后期测试不充分。再者，关注开发和产品的讨论，若是开发说哪一部分比较难实现，最后如何实现？其中作出的变更和难点就是测试的时候必须重点关注的部分。不能由于这些暂时和你没有关系就不去关注，后期会带来麻烦。第三，需求评审结束后，要求产品更新这次评审过程当中的全部改动部分，同时给出方案确保产品的任何改动都及时更新。第四，根据产品需求，设计测试方案及时间安排，此时能够粗粒度考虑，时间上要合理；同时与在会人员进行探讨。

二，  用例设计与评审，作到不遗不漏

      测试用例是每一个测试人员工做过程当中必需要完成的工做，无论你是用Excel,仍是用FreeMind来写，在测试工做中一是用来指导测试工做，并且是相关业务的一个文档沉淀。可能你不太在乎测试用例的编写，但是在我以往面试的经验中，有超过一半的人写的测试用例是不达标的。不少人写用例是用书本上的方法，什么边界值法，条件覆盖法等等，其实咱们更应该关注用户，从用户的角度来写用例才对。

      测试用例必须具有的测试用例名，执行步骤，预期结果这三点是必需要写清楚的。再者就是测试方案选择必须全面，做为功能测试人员你可能不会编写自动化测试脚本，不会性能测试，安全测试，可是你必须能根据需求想到要实施哪方面的测试。如面试的时候给你一个场景：一个全新的App要发版，若是让你来测试，你能想到哪些测试方案？若是你只能想到如何去测试app的功能的话，那你做为功能测试人员就是考虑不全面。此时的App的功能，App的性能，数据传输的安全性，接口或服务的功能测试，接口或服务的自动化测试与监控，接口或服务的性能测试，底层数据的存储与容灾状况都必须考虑在内。

      设计用例的时候要设计两类， 一类是开发自测和验收提测试标准的冒烟测试用例，一类是针对需求的全面测试用例。写完用例要主动联系相关人员进行用例评审，强调开发自测，在评审过程是及时修改不合适的用例。

三，  测试流程，注重项目控制

      其实项目的流程控制在需求开始的时候就应该重视起来，只是不少时候咱们没有意识到这是测试的工做，有的是产品来控制，有的是专门的项目经理来控制。测试人员是一线的工做人员，无论你工做了多久，必须有关注总体项目的意识。若是你不关注项目进度，何时提测你何时开始测试，在测试过程当中你就会遇到测试的内容和最初的需求不一致，增长新的内容从而增长工做量，或是产品和开发一块儿来压缩测试时间的状况，到时你想不加班都难。

      需求一旦明确了由你来负责的时候，就要时刻按排期来关注项目的状况。中间变动需求的时候，要评估是否影响项目进度，若是影响了从新进行排期。若是开发提测试晚了，是否影响上线时间，若是可能会影响，立刻就要给相关的人员发预警邮件，通知你们详细的状况。同时在测试过程当中，发现了bug必须详细描述问题，无论是jira,禅道或是其余的bug管理方式，一个bug要写清楚如下几点：Bug问题描述，bug重现步骤，是否有前置条件，预期结果，实际结果，以方便开发去进行修改。同时给bug准确分级，实时跟踪进度，保证项目定期完成。 

四，  上线回归与项目总结

     一个需求上线完成后，要及时进行线上回归，若是有必须提醒相关的人员进行自动化线上回归或是监控工做。同时必须回归咱们在需求评审的时候考虑到的可能影响到的原有的功能，以确保新功能的彻底上线成功。而做为功能测试人员，在一个项目完成后，无论公司有没有要求，要对项目作相应的文字总结。总结整个项目过程当中遇到的问题，最后的解决办法或是当时讨论的处理办法，有哪些须要注意的问题？有什么能够借鉴的方案或是改进策略？项目中有没有通用性的问题等等。

       若是公司有相应的项目总结方案，那测试的时候就要多关注一些数据，如冒烟测试是否一次经过，Bug数及不一样级别的bug数，参与开发人员对应的Bug数，提测试次数，上线次数等等。然后借助于第三方工具进行图表化相应的数据，而后相关问题的总结，改进方案都须要进行详细的总结。

五，  能力的总结和沉淀

     在咱们找工做的时候，不少作功能测试多年的同窗通常很难经过面试，这里面的缘由到底是什么？其实最核心的缘由是，你不具有相应工做年限应该具有的能力。

     测试工具的使用：在你以往的工做经验中，有没有总结过什么样的需求或是项目应该使用什么样的测试工具，而不是仅仅使用公司提供或是指定的工具？有没有分析过同类的工具的优缺点？若是一个相似的全新的产品，你可否围绕着工做需求，准备相应的测试工具来辅助测试？什么样的测试工具在测试项目的时候可能存在问题，问题的解决办法是什么？

     问题的总结：在测试工做中总结部署环境出现502或是404产生的缘由及解决办法？产品的哪儿块功能容易出现问题，或是开发怎么实现相应的功能可能出现问题？产品的功能模块之间是如何工做的，修改部分功能后可能会对其余模块产生影响？哪一个版本的编译器打包的产品容易在哪些方面出现问题？等等相应的问题总结有没有作，若是作了，在接到相应的需求后就能快速的评估测试范围，选择测试方案，规划测试时间等。

    技术的沉淀：技术不只仅指的是编码能力，像平时咱们部署环境出现问题后，最后的解决方案的总结；测试过程当中日志出现空指针的排查；项目测试过程当中遇到的问题及解决方案；一些常见问题的排查及解决方案等等。要在工做中善于积累，从而指导本身的工做或是为同事提供解决问题的思路与办法。

      时常问本身一句话：离开现有的平台，我还有什么？这个才是你的资本，对公司业务的熟悉，公司如今工具的使用等等，对你来讲是没有任何优点可言的。而对同类业务流程的掌握，项目的总体把控，快速了解业务并能根据需求选择测试方案，引进现有的测试工具提升测试效率，测试过程当中遇到问题的预判和解决办法等才是功能测试人员必须具有的能力。这些方面你作到了吗？业务专家也是不想作编码的测试人员一个很好的选择，不要成天抱怨功能测试如何如何，要充分认清行业现状和本身的优缺点，作好职业规划。