为什么要对程序做代码覆盖率测试

关于代码覆盖率，之前6年的工作经历中，只是依稀听闻过。之前的组织里，从未关注过这个指标，只是有一段时间用NUnit做了单元测试，主要是测试一些关键类关键方法是否正常，对代码覆盖率的印象就真的一直是停留在听闻的程度。汗一个!

前些时日，关于自动测试的讨论中有人提及到代码覆盖率，激发了我的好奇，到底什么是代码覆盖率最重要的是于测试工作而言有怎样的价值呢今天花了一点时间查了一下，有了初步的认识。大致归纳如下：

一、基本概念

代码覆盖率是单元测试活动任务之一;

覆盖率分语句覆盖率(即通常所说的行覆盖率)和分支覆盖率。

二、价值

代码覆盖率的分析能在一定程度上评判代码质量，一般覆盖率高的代码出错的几率会相对低一些。但是高覆盖率只是表示执行了很多的代码，并不意味着这些代码被很好地执行了。所以，似乎覆盖率测试结果出来并不能帮我准确的评价代码质量。那么我们为什么要做覆盖率测试呢如何让它给我们带来价值呢

1 尽早评估代码质量

比如在开发的过程中，定时的去看整个项目的代码覆盖率，监控覆盖报告可以帮助开发团队迅速找出不断增长的但是没有相应测试的代码。例如，在一周开始时运行覆盖报告，显示项目中一个关键的软件包的覆盖率是 70%。如果几天后，覆盖率下降到了 60%，那么您可以推断：软件包的代码行增加了，但是没有为新代码编写相应的测试(或者是新增加的测试不能有效地覆盖新代码)。能够监控事情的发展，无疑是件好事。定期地查阅报告使得设定目标(例如获得覆盖率、维护代码行的测试案例的比例等)并监控事情的发展变得更为容易。如果您发现测试没有如期编写，您可以提前采取一些行动，例如对开发人员进行培训、指导或帮助。

2 为功能测试关注点提供情报

假设覆盖报告在指出没有经过足够测试的代码部分方面非常有效，那么质量保证人员可以使用这些数据来评定与功能测试有关的关注区域，可以更有针对性地加强这些区域的测试，因为没有被测试代码覆盖到的区域，出错的几率应该相对更高。

3 估计修改已有代码所需的时间

对一个开发团队而言，针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比，经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何工作的，所以还可以充当内行的文档。在另一方面，没有经过相应测试的代码更难于理解和安全地修改。因此，知道代码有没有被测试，并看看实际的测试覆盖数值，可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。

当然，这样的理解还是比较浅层的，我想实际应用中除了以上三点之外，还有一个很重要的工作就是提高测试代码的质量来更好的体现代码覆盖率的价值。

不同的程序不同的测试工具

程序大都开发完成后 生成编译一般都提示第几行编写的程序错误。解决后再看做出来的效果。如果有bug问题，在进行源代码的修改，反复进行直到满意为止。当然还有其他环境下提供的测试及自己累积的经验进行测试。

黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否

都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的

情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序

是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”

法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输

入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测

试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是

否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按

预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证

。 “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在

使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的

独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序

违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错

。第三，穷举路径测试可能发现不了一些与数据相关的错误。

还有一个灰盒测试

灰盒测试

灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内

部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运

行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来 ***

作，效率会很低，因此需要采取这样的一种灰盒的方法。 灰盒测试结合了白盒测试盒黑盒测试的要素它

考虑了用户端、特定的系统知识和 *** 作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测

试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试

以增强测试效率、错误发现和错误分析的效率。 灰盒测试涉及输入和输出，但使用关于代码和程序 *** 作

等通常在测试人员视野之外的信息设计测试。

你可以先用内存监控工具，进行监控，看看这个功能到底用多少内存。如果不多，其实都不需要实现你说的代码监控的。如果你要使用代码监控，你可是使用Runtime类的几个属性，MaxMemory、FreeMemory、TotalMemory。然后实现个线程，在下载pdf功能前开启线程，然后完毕时关闭线程，如果内存即将溢出（设定个阈值，比如说15%），就报错，跳转到错误页面。

以上就是关于为什么要对程序做代码覆盖率测试全部的内容，包括:为什么要对程序做代码覆盖率测试、怎么测试自己编的程序、请问用Java代码，怎样测试一段程序占用了多少内存等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！