如何做好功能测试

功能测试在所有的测试工作中，是比较基础的工作，没有很多技术含量。现在市场上很多公司会关注自动化测试，并且往这方面投注更多的资源，比如研发属于自己公司的一套自动化测试系统。会自动化测试技术的人员虽然越来越受欢迎，但功能测试在测试体系中依旧不可缺少，只是现在只会功能测试的人员会越来越少，需要的更多是复合型的人才。

言归正传，功能测试虽然不需要掌握很多技术，但是做好功能测试，也不是很容易的一件事。

需求分析

测试工作的第一步，是拿到产品的需求文档，做一个业务流程的分析，以及需求可能存在的盲区做一个排查。

需求文档的确定

需求文档确定的这个流程，每个公司都有属于自己公司独特风格。

在一些中小型公司，产品经理与业务讨论后确定了一个需求后，产品经理会编写一个需求文档的初稿，之后会开展需求分析的会议，这个会议可能会有开发，测试，产品，业务这几方都参与进来，业务和产品提出需求，开发发表意见以及简述开发流程，测试对功能点进行记录，且对可能存在矛盾，或者一些需求中的盲点进行讨论。

中小型公司各部门之间的联系比较紧凑，方便于交流，解决问题起来也比较轻松。现在很多中小型公司也推行 Devops 、敏捷开发和敏捷测试，这个也是一种发展的趋势。

我个人还是比较喜欢这种流程的，虽然这个可能会占用比较多的时间，但这种流程有一个好处，就是业务和产品会听取开发和测试人员的意见，这样更不会出现临时更改需求和返工的现象，可以更好的保障软件开发流程中的质量。

但是在一些大型公司，就不是这样了。经常可以看到的，就是产品、开发和测试人员间的“相爱相杀”。

在一些大型公司中，很多是属于软件的版本迭代，这些版本迭代的内容，通常是通过用户的反馈或者是业务的开展而产出的需求，所以，产品经理关注的，是这个需求能不能实现，要的是一个结果；开发人员关注的，是这个需求的功能能不能实现，更多关注的是完成任务；测试人员关注的，是功能完成的质量，最怕的事情就是线上发布后产生了bug。

一个版本的迭代，会有很多个需求，产品经理会将这些需求分配给项目组组内对应的项目经理和测试经理，而项目经理和测试经理又分配给自己部门对应的开发人员和测试人员。在这一步中，需求文档的质量尤其重要，这将决定开发人员与测试人员对拿到手的需求文档的理解，需求分析会议成了这个项目的关键点之一，有些公司会有测试分析师这一职位，在需求分析会议上对需求文档中的某些盲点、不合理的点提出，与项目经理、产品经理进行讨论，产品经理会根据会议内容完善需求文档。

理解需求，提取测试点

不管公司的流程如何，做功能测试的测试人员，最开始的一步，就是明确需求。若对需求文档中的某些内容存在疑惑，一定要问清楚，不能光靠自己的理解决定。

理解需求，需要分清楚以下几个概念：

• 业务需求:需求的大致逻辑
  了解业务背景（做这个需求的目的是什么）

• 功能需求:为了实现业务需求，软件应有的功能。
  有的是需求文档明确写出来的；有的是需求文档中未提及的，未提及到的则需要我们根据自身的软件测试经验来进行补充并与产品或测试分析师确认。
  为了更好地理解功能需求，可以编写思维导图。

• 测试需求:为了实现本期需求文档中提及的功能，所进行一系列测试活动。
  包含本期所有的功能需求、以及涉及到可能影响的功能模块（主要包括上下游模块和公用方法模块）、旧数据的兼容、非功能性测试（兼容、性能）
  为了测试所测功能是否达到要求，需要编写测试用例，依据编写的测试用例进行测试。

将业务需求转化为测试需求，关键在于对测试点的分析：

• 分析各个功能模块之间的业务顺序和各个功能呢模块之间传递的信息，理清存在功能交互的功能项，尤其关注数据的流向及数据的变化。
• 分析需求描述中的输入,输出,处理,限制,约束等,理清对应的验证内容
• 考虑需求的完整性,要充分覆盖需求的特种特征,包含隐性需求的验证。
  比如界面的验证,注册账号的唯一性验证

测试流程

测试导图和测试用例

提取测试点，是编写思维导图和测试用例的关键。而测试导图和测试用例的编写，则是整个测试流程的核心，尤其是测试用例的编写，一份好的测试用例，可以更好的保障测试的质量。

思维导图的编写是为了方便测试人员编写测试用例：

1. 思维导图的内容，要做到简洁明了，包含需求关键点，如：按扭、文本框、页面跳转和页面展示、数据的变化和数据的展示…
2. 思维导图的编写，需要按照需求去整理测试的流程，根据测试的流程来分点，可以使思维导图的内容做到简洁有序，这样编写测试用例，就更不会发生遗漏。

测试用例的编写，要做到覆盖所有测试点，测试用例无法保证做到完全覆盖，但覆盖率广的测试用例，可以更好的保障测试工作的质量。

1. 测试用例可根据测试导图中的关键点进行编写
2. 最常见的四种测试方法：等价类划分法，边界值分析法、错误推断法、场景模拟法等

比如文本框:

• 输入内容的限制，采用等价类划分法划分有效等价类和无效等价类。需考虑到字母，数字，汉字，特殊字符和空格的输入和组合输入，能否输入为空这些情况
• 输入长度的限制，采用边界值分析法。对输入的长度进行分析

在测试过程中，可能会发现某些遗漏的测试点，例如该测试点和其他功能有所关联，这时一定要将该测试点的测试用例补全，这样才能更好的测试到所有会发生的情况，没有遗漏。

测试总结

不同的公司，测试工作有不同的测试流程。从最开始的瀑布式测试，到现在一直在追求的敏捷测试，不管是怎样的测试流程，都是公司在不断的探索和完善的过程。

测试过程中不会一帆风顺，并不是简单的按照测试用例去执行，就能完成测试的工作，在测试过程中，会 遇到许多大大小小的麻烦。

例如，在大公司中，各部门的联系没有那么紧凑，且系统与系统之间的联系较为复杂，所以有些时候开展工作，会比较麻烦。比如涉及到系统之间联系比较多的时候，造数据就是一件很令人头疼的事情，可能其他系统的工作人员不配合，或者是流程复杂，要耗费较长的时间。

如果是其他系统的工作人员不配合，这个就考验自身的个人交际能力了，如果沟通好的，可以很快就能解决。
如果对方性格如此，就是不配合，可以向上级反映，或是找对方的领导。
如果是流程复杂，那就要分清轻重缓急，当然，这并不意味着可以把问题丢在一遍，不去解决，这样往往会造成更加严重的问题产生。

在测试过程中遇到的问题，测试工作结束后，要学会自我总结，只有不断地总结，才会有所提升，测试能力不是完全靠细心，靠天赋的，更多是在一个不断完善的过程中不断提升，学会总结，吸取教训，才能不断提升测试工作的质量，同样也是做好功能测试的关键所在。