Code Coverage(from wikipedia)

This article defines "Code Coverage" and gives the main forms of coverage criteria. You can go to http://en.wikipedia.org/wiki/Code_coverage to visit the origianl. IP address of china can access this site. You have to find a valid oversea proxy for your IE.

Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that looks at the code directly and as such comes under the heading of white box testing.

Code coverage techniques were amongst the first techniques invented for systematic software testing. The first published reference was by Miller and Maloney in Communications of the ACM in 1963.

To measure how well the program is exercised by a test suite, one or more coverage criteria are used. There are a number of coverage criteria, the main ones being:

  Function coverage - Has each function in the program been executed?

  Statement coverage - Has each line of the source code been executed?

  Condition coverage - Has each evaluation point (such as a true/false decision) been executed?

  Path coverage - Has every possible route through a given part of the code been executed?

  Entry/exit coverage - Has every possible call and return of the function been executed?

Safety-critical applications are often required to demonstrate that testing achieves 100% of some form of code coverage.

Some of the coverage criteria above are connected. For instance, path coverage implies condition, statement and entry/exit coverage. Statement coverage does not imply condition coverage, as the code (in the C programming language) below shows:

void foo(int bar)

{

    printf("This is "); 

    if (bar <= 0)

    {

        printf("not ");

    }

    printf("a positive integer.\n");

    return;

}

If the function foo were called with variable bar set to −1, statement coverage would be achieved. Condition coverage, however, would not.

Full path coverage, of the type described above, is usually impractical or impossible. Any module with a succession of n decisions in it can have up to 2ⁿ paths within it; loop constructs can result in an infinite number of paths. Many paths may also be infeasible, in that there is no input to the program under test that can cause that particular path to be executed. However, a general-purpose algorithm for identifying infeasible paths has been proven to be impossible (such an algorithm could be used to solve the halting problem). Techniques for practical path coverage testing instead attempt to identify classes of code paths that differ only in the number of loop executions, and to achieve "basis path" coverage the tester must cover all the path classes.

Usually the source code is instrumented and run through a series of tests. The resulting output is then analysed to see what areas of code have not been exercised, and the tests are updated to include these areas as necessary. Combined with other code coverage methods the aim is to develop a rigorous yet manageable set of regression tests.

Code coverage is ultimately expressed as a percentage, as in "We have tested 67% of the code." The meaning of this depends on what form(s) of code coverage have been used, as 67% path coverage is more comprehensive than 67% statement coverage.

The value of code coverage as a measure of test quality is debated (see external links).

从Bugzilla网站上找到的一个有关bug生命周期的图片

http://www.bugzilla.org/

                   等价类划分

                                                                 ---读《软件测试艺术》

等价类划分是一种典型的黑盒测试方法。

测试方法大致可以分为白盒测试和黑盒测试两类。常用的白盒测试方法有：语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，多重条件覆盖。多重条件覆盖最为严格。常用的黑盒测试方法有：等价类划分，边界值分析，因果图分析和错误猜测。

我们都知道，对程序的穷举输入测试是无发实现的。所以，当我们测试某个程序时，我们就被限制在从所有可能的输入中找出某个正确的最小的子集。等价类的划分就是基于这样一种思想。

使用等价划分方法设计测试用例时有两个步骤：1. 确定等价类；2. 生成测试用例。

1.         确定等价类

确定等价类是选取每一个输入条件（通常表现为规格说明中的一个句子或短语）将其划分为若干个组。这里确定了两类等价类：有效等价类和无效等价类。有效等价类代表对程序的有效输入，而无效等价类则代表着其它的任何可能的输入（所有不正确的输入都可以）。

2.         生成测试用列

l         为每个等价类（有效、无效的）设置一个不同的编号

l         编写新的测试用例，尽可能多的覆盖那些尚未被覆盖的有效等价类，直到所有的有效测试类都被测试用例覆盖。这个步骤是个创造性的工作。

l         编写新的测试用例，覆盖一个且仅一个尚未被覆盖的非有效测试用例，直到所有的非有效测试用例都被覆盖。

注意第二点和第三点的区别，前者要求一个用例尽量多覆盖有效等价类，而后者要求一个用例只能覆盖一个非有效等价类。原因在于，某些特定的输入错误检查可能会屏蔽掉或者取代其他的错误输入。