慧乐课堂：不要小看了功能测试

Posted 2021-03-05 huile11

 

大家看到功能测试，是不是想到的都是：功能测试有什么可测的啊，不就是点点点的去测试嘛，没啥技术含量……

你如果这么想，你就错了！

千万别小看功能测试！

千万别小看功能测试！

千万别小看功能测试！

不论你是什么时候开始接触测试这个行业的，你首先听说的应该是功能测试。通过一些测试手段来验证开发实现的功能是否符合产品的需求（需求文档）？当然你也有自己对功能测试的理解，但是最近两年感觉功能测试好像不太受欢迎，为什么呢？主要是不少同学真的是功能测试都没有做好，就去尝试自动化测试、测试开发什么的，结果是越学越迷茫。究其原因就是：你功能测试还没有学好！（没学会走路呢，就想跑，那能跑得稳吗？）

我们通常认为的功能测试是根据需求，采取测试流程一般是：需求分析—>用例编写—>用例评审—>提测验证—>Bug回归验证—>上线—>线上回归等来进行测试。如此日复一日，年复一年，响应了很多需求，可是想换工作的时候却得不到认可，大家想想是不是这种情况？

下面我就以一个功能测试人员如何进行工作，来介绍一下功能测试应该用到的知识及相关的提升建议。

 

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

正常的需求在产出的时候，产品是要分析这个需求的价值，影响范围和实现代价的。可是现在很多情况是，需求来了就组织评审，然后开发测试与上线。产品主导型的开发模式非常常见，作为测试我们无法主导需求和项目。

1. 在需求评审的时候，作为一个测试人员必须了解这次需求的内容，影响到哪些现有的功能，涉及到的操作系统、类别等方面，然后准确的评估出工作量，防止因评估不足造成后期测试不充分。

2. 关注开发和产品的讨论，如果开发说哪一部分比较难实现，最后如何实现？其中做出的变动和难点就是测试的时候必须重点关注的部分。不能因为这些暂时和你没有关系就不去关注，否则后期会带来很多麻烦。

3. 需求评审结束后，要求产品更新此次评审过程中的所有改动部分，同时给出方案确保产品的任何改动都及时更新。

4. 根据产品需求，设计测试方案及时间安排，此时也可以粗粒度考虑，另外时间上要合理。同时与在会人员进行探讨。

 

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

测试用例是每个测试人员工作过程中必须要完成的工作。不管你是用Excel，还是用FreeMind来写，在测试工作中不仅用来指导测试工作，而且是相关业务的一个文档沉淀。

可能你不太在意测试用例的编写，可是在我以往面试的经验中，有超过一半的人写的测试用例是不达标的。很多人写用例是用书本上的方法，什么边界值法，条件覆盖法等等，其实我们更应该关注用户，从用户的角度来写用例才对。

测试用例的几要素：

1. 必须具备：测试用例名，执行步骤，预期结果这三点是必须要写清楚的。

2. 再者就是测试方案选择必须全面。

a) 作为功能测试人员你可能不会编写自动化测试脚本，不会性能测试，安全测试，但是你必须能根据需求想到要实施哪方面的测试。

b) 如面试的时候给你一个场景：一个全新的App要发版，如果让你来测试，你能想到哪些测试方案？

i. 如果你只能想到如何去测试app的功能的话，那你作为功能测试人员就是考虑不全面。

ii. 此时的App的功能，App的性能，数据传输的安全性，接口或服务的功能测试，接口或服务的自动化测试与监控，接口或服务的性能测试，底层数据的存储与容灾情况都必须考虑在内。

设计用例的时候要设计两类：

a) 一类是针对需求的全面测试用例。

b) 一类是开发自测和验收提测试标准的冒烟测试用例。

注意：写完用例要主动联系相关人员进行用例评审，强调开发自测。用例评审是为了及时修改不合适的用例。

 

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

其实项目的流程控制在需求开始的时候就应该重视起来，只是很多时候我们没有意识到这是测试的工作；这个流程控制有的是产品来控制，有的是专门的项目经理来控制。

关注项目的进展

测试人员是一线的工作人员，不管你工作了多久，必须有关注整体项目的进展的意识。如果你不关注项目进度，什么时候提测、什么时候开始测试都不知道；在测试过程中你就会遇到测试的内容和最初的需求不一致，增加新的内容从而增加工作量，或是产品和开发一起来压缩测试时间的情况，到时你想不加班都难。

关注需求的变更

需求一旦明确了由你来负责的时候，就要时刻按照排期来关注项目的情况。中间变更需求的时候，要评估是否影响项目进度，如果影响了重新进行排期。如果开发提测试晚了，是否影响上线时间，如果可能会影响，马上就要给相关的人员发预警邮件，通知大家详细的情况。

详细描述bug

在测试过程中，发现了bug必须详细描述问题，不管是jira，禅道或是其他的bug管理系统，一个bug要写清楚以下几点：

a) Bug问题描述

b) Bug重现步骤

c) 是否有前置条件

d) 预期结果

e) 实际结果

f) 机型（品牌、系统、系统版本）

g) Bug级别

写清楚上面几点，以方便开发去进行复现以及修改。

同时也要实时跟踪进度，保证项目按期完成。

 

四. 上线回归与项目总结

一个需求上线完成后，要及时进行线上回归，如果有必须提醒相关的人员进行自动化线上回归或是监控工作。同时必须回归我们在需求评审的时候考虑到的可能影响到的原有的功能，以确保新功能的完全上线成功。

而作为功能测试人员，在一个项目完成后，不管公司有没有要求，你都要对项目做相应的文字总结。总结整个项目过程中遇到的问题，最后的解决办法或是当时讨论的处理办法，有哪些需要注意的问题？有什么可以借鉴的方案或是改进策略？项目中有没有通用性的问题等等。

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

 

五. 能力的总结和沉淀

在我们找工作的时候，很多做过功能测试多年的同学也很难通过面试，这里面的原因究竟是什么？其实最核心的原因就是，你不具备相应工作年限应该具备的能力。

具体需要有哪些能力呢，我们一起来分析下：

 

01、测试工具的总结

在你以往的工作经验中，有没有总结过什么样的需求或是项目应该使用什么样的测试工具，而不是仅仅使用公司提供或是指定的工具？有没有分析过同类的工具的优缺点？

如果一个类似的全新的产品，你能否围绕着工作需求，准备相应的测试工具来辅助测试？什么样的测试工具在测试的时候可能存在问题，问题的解决办法是什么？

这些都需要你自己去有意识的总结。总结的过程，也是你对工具深入学习的过程，这样就能促进你更好的去学习工具。

 

02、问题的总结

在测试工作中总结部署环境出现502或是404产生的原因及解决办法？产品的哪儿块功能容易出现问题？或是开发怎么实现相应的功能可能出现问题？产品的功能模块之间是如何工作的，修改部分功能后可能会对其他模块产生影响？哪个版本的编译器打包的产品容易在哪些方面出现问题？等等。

相应的问题总结有没有做？如果做了，在接到相应的需求后就能快速的评估测试范围，选择测试方案，规划测试时间等。

 

03、技术的沉淀

技术不仅仅指的是编码能力，像平时我们部署测试环境出现问题后，最后的解决方案的总结；测试过程中日志出现空指针的排查；项目测试过程中遇到的问题及解决方案；一些常见问题的排查及解决方案等等。

要在工作中善于积累，从而更好的指导自己的工作，或者为同事提供解决问题的思路与办法。

 

04、时常问自己一句话

“离开现有的平台，我还有什么？”

这个才是你的资本！

对公司业务的熟悉，公司现在工具的使用等等，对你来说是没有任何优势可言的。而对同类业务流程的掌握，项目的整体把控，快速了解业务并能根据需求选择测试方案，引进现有的测试工具提高测试效率，测试过程中遇到问题的预判和解决办法等才是功能测试人员必须具备的能力。

这些方面你做到了吗？不要整天抱怨功能测试如何如何。所谓做一行爱一行，既然做了功能测试，那么就要做好；功能测试是测试行业的基础，只有将这个基础打好，打牢，将来你才能把其他的做好。即使你将来不做功能测试了，这也是你的一个技能。

最后，建议大家，要充分认清行业现状和自己的优缺点，做好职业规划。