A question in test management---Function point overlay or functional test point overlay

Function point coverage is a frequently mentioned thing in the test work,

Many testers in order to cover the function point of the effort, unfortunately, when they will reach a functional point covering 100%, the system, still constantly appearing problems, so the leader of the blame, the user's cold, the developer's sarcasm is all come, this time the only explanation for testers is that the test is not omnipotent, It's impossible to find all the problems,

This time someone asked: "Your function point is not 100% covered?" Why did the error not be found, so the testers were speechless.

In fact, the key problem of this problem is how to function point of the concept.

The concept of functional points in fact from the development, in the system when the development of the general will be layered, the top of the system, and then subsystems, modules, functions. In general, the function is the smallest unit in a system, the concept is introduced into the test, and the concept of functional point coverage is presented.

Feature point coverage has always been a no-no-no concept, and this concept is easy to confuse testers, how to calculate the function point coverage.

function is generally a system to complete a specific operation, such as in the human resources management system in the personnel basic information module has a function of adding new personnel information.

When we cover this function, we generally consider a few aspects

1 whether legitimate data can be added to the system

2 whether illegal data can be checked out, and give the relevant hints

3 Whether other operational constraints can be met,

If these aspects are to be tested, then it is impossible to overwrite with a test case,

There's a problem here,

I've written a test case that even overwrites this feature.

I tested it with 100 different test cases to see if it covered the feature.

I found a bug with 10 test cases and found a bug with 200 test cases, which is different for the system.

So personally think that at this point a concept that should be introduced is the concept of functional test points

We can easily summarize all of the system's functional points in the requirements report or the summary design report, which the developers provide to the testers, and what the testers do. is to determine how many places each function (point) needs to be tested, and these points are functional test points,

To measure the effectiveness of a tester's work is to cover the functional test points.

This is a good explanation for the relationship between the number of test cases and the quality of the product.

For example, the function (point) coverage reached 100%, but the function test point coverage only 10%, indicating that the test strength is not enough, even if all the functions are involved, but the test strength is very small, the quality of the product is also not guaranteed

Similarly, a function point I used 10 test cases to find a bug, and 1000 test cases to find a bug, although the number of bugs is the same, but the next one on the code coverage is large (according to the test case method to write test cases), so, Indicates that the second system is more reliable than the first one.

Distinguishing functional points from functional test points There is also the advantage that it is better to count the results of a tester's work,

For testers of the performance can not be simply to find the number of bugs to explain, otherwise prone to bias, through the function point coverage and functional test point coverage to decompose the statistics can be more accurately reflect the actual workload of testers