【项目管理一点通】（40） 功能测试

测试的概念特别多，估计很多测试人员自己都懵了，上节我们说到单元测试，可以说是测试对象的最小单元了，在上一层，就是功能测试，功能测试上去一层，就是模块测试，模块测试上去一层，就是系统测试，还有上去一层吗？有的，几个系统集成起来进行测试，这实际上是系统级的集成测试，和模块级的集成测试没什么大的区别。
顺便说一下白盒测试和黑盒测试，它与今天我们所说的功能测试有一定的关系，我们不要被这个稀奇古怪的名字吓住了，所谓的白盒测试就表示可以直接看到被测试的对象的内部逻辑，可以直接针对被测对象的内部逻辑编写测试脚本，换句话说被测对象对测试人员是透明的，比如说测试人员可以直接修改某一个被测功能的代码或者脚本。所谓的黑盒测试是指测试人员仅仅知道被测对象的业务接口，但是并不知道内部的程序逻辑，这时候的测试纯粹是针对接口进行测试。显然，针对这两种类型的测试，其方法也是不一样的，白盒测试可以更清楚的了解问题的根源，并且可以根据内部的逻辑设计有针对性的用例，黑盒只能提供测试的结果。
下面接着说功能测试。从名称上就可以看出来，功能测试就是针对功能进行测试的，即验证接口是否符合设计要求。
一般情况下，测试人员第一道测试就是功能测试，而不是之前提到的单元测试和需求测试，甚至测试人员80%的工作量都集中在功能测试上面，所以功能测试非常重要。
下面针对功能测试提出一些建议，供大家参考。
1、熟悉需求和业务。测试人员如果要期望得到良好的测试结果，就必须准确把握需求和业务，如果对业务理解不准确，就必然会导致测试用例和需求之间的偏差，这种偏差甚至会导致错误的结果，从而直接导致测试返工，值得注意的是，这种现象比比皆是，问题的根源是测试人员由于缺少足够的时间理解业务而写了不准确的用例；
2、对功能的理解要透彻，功能用例要保证严密。一般的功能测试都是黑盒测试，对于测试人员而言，仅仅知道功能是做什么用的，输入什么数据，输出什么数据，其内在实现并不清楚，所以测试人员需要设计各种输入场景来验证功能。有很多人由于对业务场景理解不深入，会导致设计的用例覆盖不够，从而出现数据错误或者输出错误的情况。当然超出业务场景的也需要进行边界封闭，即开发人员需要判断业务的边界问题，否则测试人员会当做异常处理。
3、测试人员不仅是为了完成测试人员，在很多公司，测试人员还充当了设计师的角色，即设计师或者开发人员对功能考虑得不周到，测试人员根据自己的经验对功能进行了优化，从而更符合业务需要和用户体验，这是非常好的事情，但是，凡事不能过，测试人员主要工作还是做与需求设计相匹配的符合性测试，而后才是改进性测试，对用户的体验更多的是需要设计师来关注的。
4、功能测试用例需要不断优化，根据业务场景不断提高覆盖率，提高测试用例的效率，比如说有的功能只需要一个用例即可覆盖，而有的人却需要三个用例，这就体现了用例的效率。看来测试工程师的逻辑思维还真的非常人所比。
5、测试报告要与需求进行对比。测试报告不要符合不符合一句话了结，而应该和期望的结果做对比，所以最好是有个一览表，如果可能的话，可以备注一下针对开发的改进意见。
6、测试工具。基本上所有的测试软件都适合功能测试，因为功能测试是最基本的测试类型，我们日常用的比较多的有LoadRunner、Winrunner、Quicktest、Jemeter等。网上关于这些测试工具有详细的使用说明，大家如果感兴趣，可以了解一下，作为项目经理，没必要将精力投入进去研究。
实际上所有的测试所关注的点都很类似，所以有些建议可能重复了，希望大家不介意。谢谢大家的阅读。