首页 » 漏洞 » 单元测试的二三事儿

单元测试的二三事儿

 

单元测试的合理性

对于软件开发过程中,是否必须执行单元测试,即使对于那些已经开始推行软件工程的组织来说,也存在不同的意见,而且其中持反对意见的占多数。

个人认为单元测试应该是推进软件工程的组织中必须经历的一个环节。原因有二:

  1. 职业道德

在IEEE发布的《软件工程师职业道德规范和标准》中,明确指出“软件工程师应当确保自己的产品以及相关的修改满足最高的专业标准”。单元测试是对程序模块的正确性进行测试,而程序模块是软件工程师进行软件开发活动的产品。软件工程师有责任确保自己的产品满足高质量的要求,不会在其中遗留致命的Bug。正如车间生产的各个环节那样,上一环节的责任者不应将自己的错误传递给下一环节。确保自己产品的正确性是每一个产品生产者的职责。

  1. 修复成本

在软件工程实践中,对于修复软件缺陷有一个共识:缺陷越早发现,越早修复,所需付出的成本越少。如果软件工程师在编码实现软件模块功能时,就通过单元测试排除了编码引入的缺陷,他所付出的成本是很小的;而如果没有单元测试,使得编码过程中引入的缺陷直到验收测试时才被发现,这时再进行修复,所需的成本会放大几十倍不止。

单元测试执行起来有多难

单元测试之所以被很多人反对,确实是因为单元测试要执行起来要付出很大的代价。

  1. 人力成本

单元测试多采用白盒测试技术,要满足代码覆盖率、路径覆盖率等的要求,所以所需的人力成本是非常高昂的。一个4000多行的嵌入式软件,仅进行代码走查就需要1~2个人月;如果再加上测试用例设计、测试代码(如桩模块)的编写,这个工作量还要多出几倍。

  1. 工具成本

人力成本能否通过工具的使用减轻呢?答案是肯定的,但是同样带来的是工具成本。

测试需要多少工具?测试工具的种类包括:测试设计工具、静态分析工具、动态分析工具、GUI测试驱动和捕获/回放工具、负载和性能测试工具、测试评价工具、测试BUG跟踪管理工具等。

而且同类的工具的成本也会有所不同。比如代码规范检查,有的工具支持标准的代码规范检查,有的工具支持自定义的代码规范检查,而是否支持自定义代码规范检查就决定了工具的成本的高低。还有工具支持的开发语言的种类多少也决定了工具成本的不同。

缺陷跟踪也不易

单元测试是白盒测试策略,它要求测试人员要深入了解代码的结构。所以单元测试通常由软件开发者进行。但是,很多开发者并没有存档缺陷的习惯,他们常常是在发现单元测试问题后直接进行修改,然后通过回归测试就结束了单元测试。由于没有单元测试的问题记录,很容易留下一些隐患:

  1. 没有单元测试问题记录,就无法对单元测试结果进行分析,这样不利于发现潜在的BUG

  2. 如果要进行单元测试的回归测试自动化,要考虑哪些单元测试的测试用例放入回归测试的用例集中。而没有单元测试的问题记录,回归测试用例的选取就缺少了一些依据

而要解决单元测试BUG跟踪的问题,就应当给软件开发者提供用户界面友好的工具,并且做好测试工具与测试BUG跟踪管理工具、需求管理工具的集成。

微信赞赏专用通道

单元测试的二三事儿

原文链接:单元测试的二三事儿,转载请注明来源!

0