首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

追求代码质量 不要被覆盖报告所迷惑(6)

追求代码质量 不要被覆盖报告所迷惑(6)

仅仅给我数字[size=1.0625]现在,对清单 7、8、9 的测试覆盖率的分析结果不再会使您感到惊讶。在图 4 的报告中显示我达到了 75% 的行覆盖率和 100% 的分支覆盖率。最重要的是,我执行了第 10 行!
图 4.愚弄的报酬[size=1.0625]从第一印象看,这让我骄傲。但是这个报告有什么误导吗?只是粗略地看一看报告中的数字,会导致您相信代码是经过良好测试的。基于这一点,您也许会认为出现缺陷的风险很低。这个报告并不能帮助您确定 or 缩短操作的后半部分是一个定时炸弹!
质量测试[size=1.0625]我不止一次地说:您可以(而且应该)使用测试覆盖工具作为您的测试过程的一部分。但是不要被覆盖报告所愚弄。关于覆盖报告您需要了解的主要事情是,覆盖报告最好用来检查哪些代码没有经过 充分的测试。当您检查覆盖报告时,找出较低的值,并了解为什么特定的代码没有经过充分的测试。知道这些以后,开发人员、管理人员以及 QA 专业人员就可以在真正需要的地方使用测试覆盖工具。通常有下列三种情况:
  • 估计修改已有代码所需的时间
  • 评估代码质量
  • 评定功能测试
[size=1.0625]现在我可以断定对测试覆盖报告的一些使用方法会将您引入歧途,下面这些最佳实践可以使得测试覆盖报告可以真正为您所用。
1. 估计修改已有代码所需的时间[size=1.0625]对一个开发团队而言,针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比,经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何 工作的,所以还可以充当内行的文档。此外,如果被测试的代码发生改变,测试案例通常也会作相应的改变,这与诸如注释和 Javadoc 这样的静态代码文档不同。
[size=1.0625]在另一方面,没有经过相应测试的代码更难于理解和安全地 修改。因此,知道代码有没有被测试,并看看实际的测试覆盖数值,可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。
[size=1.0625]再次回到饮水机边上,可以更好地阐明我的观点。
市场部的 Linda:“我们想让系统在用户完成一笔交易时做 x 工作。这需要多长时间。我们的用户需要尽快实现这一功能。”

管理人员 Jeff:“让我看看,这个代码是 Joe 在几个月前编写的,需要对业务层和 UI 做一些变动。Mary 也许可以在两天内完成这项工作。”

Linda:“Joe?他是谁?”

Jeff:“哦,Joe,因为他不知道自己在干什么,所以被我解雇了。”
[size=1.0625]情况似乎有点不妙,不是吗?尽管如此,Jeff 还是将任务分配给了 Mary,Mary 也认为能够在两天内完成工作 —— 确切地说,在看到代码之前她是这么认为的。
Mary:“Joe 写这些代码时是不是睡着了?这是我所见过的最差的代码。我甚至不能确认这是 Java 代码。除非推倒重来,要不我根本没法修改。”
[size=1.0625]情况对 “饮水机” 团队不妙,不是吗?但是我们假设,如果在这个不幸的事件的当初,Jeff 和 Mary 就拥有一份测试报告,那么情况会如何呢?当 Linda 要求实现新功能时,Jeff 做的第一件事就是检查以前生成的覆盖报告。注意到需要改动的软件包几乎没有被覆盖,然后他就会与 Mary 商量。
Jeff:“Joe 编写的这个代码很差,绝大多数没经过测试。您认为要支持 Linda 所说的功能需要多长时间?”

Mary:“这个代码很混乱。我甚至都不想看到它。为什么不让 Mark 来做呢?”

Jeff:“因为 Mark 不编写测试,刚被我解雇了。我需要您测试这个代码并作一些改动。告诉我您需要多长时间。”

Mary:“我至少需要两天编写测试,然后我会重构这个代码,增加新的功能。我想总共需要四天吧。”
[size=1.0625]正如他们所说的,知识的力量是强大的。开发人员可以在试图修改代码之前 使用覆盖报告来检查代码质量。同样,管理人员可以使用覆盖数据更好地估计开发人员实际所需的时间。
山不在高,有仙则名;水不在深,有龙则灵。
返回列表