一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。在这种情况下，软件的质量、性能和功能不可能得到保障。此外，什么时候测试结束？或是否要对该程序作进一步的测试？对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。
项目测试管理
1.帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。
2.提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。
3. 结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一手信息。
测试计划
软件系统不仅变得越来越庞大，但是也变得越来越复杂。复杂的代码是很难阅读、理解和修改的；必须化更多的精力去测试、维护和再测试。测试复杂性分析能帮助软件工程师容易并精确地去计划他们的测试活动。 提供系统级复杂性分析和过程级复杂性分析去精确地测量复杂性，帮助工程师更好地计划他们的测试活动。帮助工程师更好估计和使用测试复杂性度量，为满足不同层次的测试覆盖的要求，必需提供：块测试复杂性、分支测试复杂性、段测试复杂性、条件-判定测试复杂性、条件-段测试复杂性。测试复杂性的值取决于用于记录对应的测试覆盖数据的插装点的点数
软件测试是对创造力和智力非常有挑战性的任务。测试一个大型软件需要的智能要超过设计这个程序的智能。软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。
一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。在这种情况下，软件的质量、性能和功能不可能得到保障。此外，什么时候测试结束？或是否要对该程序作进一步的测试？对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。
项目测试管理
1.帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。
2.提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。
3. 结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一手信息。
测试计划
软件系统不仅变得越来越庞大，但是也变得越来越复杂。复杂的代码是很难阅读、理解和修改的；必须化更多的精力去测试、维护和再测试。测试复杂性分析能帮助软件工程师容易并精确地去计划他们的测试活动。 提供系统级复杂性分析和过程级复杂性分析去精确地测量复杂性，帮助工程师更好地计划他们的测试活动。帮助工程师更好估计和使用测试复杂性度量，为满足不同层次的测试覆盖的要求，必需提供：块测试复杂性、分支测试复杂性、段测试复杂性、条件-判定测试复杂性、条件-段测试复杂性。测试复杂性的值取决于用于记录对应的测试覆盖数据的插装点的点数。
测试用例管理
1. OO-Test提供了在国内外市场上最全面的测试覆盖分析能力，去满足不同的测试覆盖需求：
●类的测试覆盖
●函数的测试覆盖
●块的覆盖
●循环边界的覆盖
●分支的覆盖
●段的覆盖
●条件（判定）的覆盖
●段--条件的覆盖
2．TCA能确定每一个测试用例作用的范围，通过给出的测试用例就能确定被测试的类，或函数，或段。这种功能对于评估测试用例的效率，和对于修改以后指定的类或函数或段的再测试是非常有用的。
3．此外，TCA能从初始测试用例中自动地抽取最小测试用例集，并对基于类的、函数的、分支的、块的、段的覆盖等等各自分别进行划分。它可以对系统级的再测试节省大量的时间和费用。
训练新成员
1. 提供全面的静态和动态系统分析的能力，能抽取各种信息及自动生成系统文档，并且可以使被抽取的信息让新成员联机访问，大大的节省了设计人员和工程师的时间。
2.通过提供最新的和精确的各种系统概貌图和流程图(包括数据结构、类继承图、函数调用图和程序树)，全局数据分析的详细报告，详细的程序逻辑图和源代码的控制流程图，帮助他们了解系统和深入地理解代码。
3.使用的GUI接口,使开发组的新成员容易自我训练；具有一个从顶层到详细的代码系统动态的和图形化的表达能力；具有链接不同层次的结构图和流程图在一起的能力。
4.提供基于函数分析和流程图化的能力与基于类分析和流程图化的能力，使得一个面向对象的系统很容易被透彻地了解。
单元测试的考虑单元测试是要检验程序最小单位（模块）有无错误，它是在编码完成后，首先要施行的测试工作。一般由编码人员自己来完成，因而通常把单元测试看成是编码步骤的附属品。单元测试大多从程序的内部结构出发设计测试用例，即采用白盒测试方法，多个程序模块可以并行地独立开展测试工作。
单元测试是针对每个程序模块，解决5个方面的问题：模块接口、局部数据结构、边界条件、独立的路径和错误处理。
1.模块接口:
对模块接口的测试，是检查进出程序单元的数据流是否正确。对模块接口数据流的测试必须在任何其他测试之前进行，因为如果不能确保数据正确地输入和输出的话，所有的测试都是没有意义的。
2.局部数据结构:
在模块工作过程中，必须测试其内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。
3.独立的路径:
在单元测试中，最主要的测试是针对路径的测试。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。
4.边界条件:
软件常常在边界地区发生问题。
5. 错误处理:
测试出错处理的要点是模块在工作中发生了错误，其中的出错处理设施是否有效。
单元测试的过程
单元测试常常和代码编写同步进行，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试用例设计。 在对每个模块进行单元测试时，不能完全忽视它们和周围模块的相互联系。为模拟这一联系，在进行单元测试时，需设置若干辅助测试模块。辅助模块有两种，一种是驱动模块（driver），用以模拟被测模块的上级模块。驱动模块在单元测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。另一种是桩模块（stub），用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口。
驱动器和桩都是额外的开销，这两种模块虽然在单元测试中必须编写，但却不作为最终的软件产品提供用户。如果驱动器和桩很简单的话，那么开销相对较低，然后，使用“简单”的模块是不可能进行足够的单元测试的，模块间接口的全面检验要推迟到集成测试时进行。
文章来源于领测软件测试网 https://www.ltesting.net/