很多测试人员为了对功能点进行覆盖费劲了心思,可惜的是当他们将达到功能点覆盖100%的,系统,仍然不断出现问题,于是领导的责备,用户的冷眼,开发人员的讥讽就全来了,这个时候测试人员唯一的解释就是测试不是万能的,不可能发现所有的问题。

　　这个时候别人一问:你的功能点不是100%覆盖了吗?为什么还有错误没有发现,于是测试人员哑口无言了.

　　其实这个问题的关键问题在于如何功能点这个概念.

　　功能点的概念其实从开发中来的,在系统开发的时候一般会分层,最上边的的是系统,然后是子系统、模块、功能。一般来说功能是一个系统中最小的单位，这个概念被引入到了测试中来，于是出现了功能点覆盖的概念。

　　功能点覆盖一直一个没有明确的概念，这个概念很容易迷惑测试人员，如何算功能点覆盖了？

　　功能一般是系统完成一个具体的操作，比如在人力资源管理系统的中人员基本信息模块中有一个增加新人员信息的功能。

　　我们在对这个功能进行覆盖的时候，一般会考虑几个方面

　　1.合法数据是否可以加入到系统中

　　2.非法数据是否可以检验出来，并给出相关提示

　　3.其他操作约束是否可以满足，

　　如果这些方面都要测试到，那么用一个测试用例是不可能覆盖的，

　　这里有问题了。

　　我就写了一个测试用例是否就算覆盖这个这个功能？

　　我用100个不同的测试用例进行测试是否算覆盖了这个功能？

　　我用里10个测试用例发现了一个bug和用200个测试用例发现了一个bug ，对系统来说是否有什么不同？

　　所以个人认为在这个时候应该引入一个概念就是功能测试点的概念

　　我们在需求报告或者概要设计报告中很容易总结出系统所有的功能点，这些功能点是开发人员提供给测试人员的，那么测试人员要做什么？就是确定每一个功能（点）有多少个地方需要测试，而这些点就是功能测试点，

　　用来衡量测试人员工作效果的就是对功能测试点的覆盖

　　这样可以很好解释，测试用例的数量和产品质量之间的关系。

　　比如功能（点）覆盖达到了100%，但功能测试点的覆盖只有10%，说明测试强度不够，即使所有的功能都涉及到了，但测试强度还是很小的，产品的质量同样是没有保证的

　　同样的是，一个功能点我用了10测试用例发现一个bug，和用1000测试用例发现一个bug，虽然从bug数量上来说是一样，但后边一种对代码覆盖率要大（按照测试用例的方法来编写测试用例），所以，说明第二个系统可靠性比第一个系统要高。

　　将功能点和功能测试点区分开来还有一个好处，就是在统计测试人员工作效果的时候比较好，

　　对于测试人员的工作成绩不能单纯地以发现bug数量来说明，否则容易造成偏颇，通过功能点覆盖和功能测试点覆盖率来分解统计可以比较精确反映测试人员实际工作量