为什么需要单元测试?
彻底测试:仅依靠系统测试会存在大量未覆盖的“死角”,单元测试可以实现代码级彻底测试,从根本上保证代码质量。
成本最低:排错成本随时间推移和范围扩大直线上升,单元测试是最早阶段的测试,且目标最小,因此,排错成本最低。
自动回归:单元测试将代码功能“定格”,代码修改后自动检查是否引入新的错误,避免陷入“系统测试->修改->引入新的错误->新一轮系统测试->修改->引入新的错误”的怪圈。自动回归也使开发过程适应频繁变更的需求,使开发过程自动“敏捷”。
促进开发:利用单元测试还可以实现测试驱动开发和可视编程。可视编程使开发过程中程序行为可视,大幅提升开发效率、降低劳动强度。
什么是单元测试?
单元测试是针对代码单元的独立测试。从实用角度出发,“单元”是指函数,以类为单元则过于复杂。“独立”是指将代码从原始项目中隔离出来,针对各个单元单独进行测试。
单元测试的基本方法是?
根据程序功能设定输入、执行测试、自动判断输出是否符合预期。测试过程需要以下关键元素:驱动(用于执行测试的代码)、用例(输入及预期输出)、桩(用于隔离耦合代码、或代替未实现代码)。
企业项目的单元测试面临哪些难点?
测试简单独立的代码是很容易的,测试复杂项目则是另一回事。企业项目的单元测试面临以下难点:可测性问题、失真、不可控、静态局部变量的外部控制、内部输出的自动判断、复杂间接输入难于初始化、白盒覆盖逾后逾难等等。不解决这些难题。测试将无法进行,后面的条目将进一步阐述。
单元测试的具体目标是?
单元测试是针对代码单元的独立测试,“独立”状态下易于发现的错误,都是单元测试的目标;集成后才易于发现的问题,则不是单元测试的目标。
代码单元本身的功能错误都是单元测试的目标,而性能问题(时间性能如执行速度,空间性能如存储空间大小、内存泄漏)难于在最小单元内测试,不是单元测试目标。
编码规范检查与单元测试无关,无论是否实施单元测试,编码规范检查都是必不可少的工作。
静态分析属于全局扫描,严格来说也不是单元测试,提高编译器的警告级别,就是最简单高效的静态分析。
单元测试是意义重大且困难的工作,目标应该具体而明确,将不属于单元测试的工作牵扯进来,其结果往往是“拣了芝麻,丢了西瓜”。
选择工具时不要被“功能多多”所迷惑,要首先检查工具能否解决企业项目单元测试的难点,并用实际项目评估。“多”和“精”从来就是一对矛盾,要判断工具是不是因为无法解决单元测试的难题,故意把其他东西牵扯进来转移视线。
什么是测试用例?
测试用例就是程序功能的实例,对于单元测试来说,把函数功能明确化、实例化,用什么输入应该产生什么输出的形式记录下来,就是测试用例。
如何设计用例?
根据功能点设定输入,再根据设计功能设定预期的正确输出,这样就构成了一个测试用例。
通常,一个功能点对应一个等价类,“等价”是指测试效果上的等价,等价类中可能存在一个、多个或无数个值,取其中任何一个,如果测试通过,就表示同类中所有值都会测试通过。
所谓“彻底测试”,是指等价类划分正确且完整,且设定了正确的预期输出,做到了这一点,代码可以保证不存在功能错误。
什么是测试驱动开发(TDD)?
首先编写测试代码,然后编写产品代码,使编译和测试通过。
优点:编写测试代码是一种设计行为,将程序功能细化、明确化;编程时目标具体而明确,避免多余动作;强制实施单元测试,避免编码后忽略测试。
缺点:手工编写测试代码,比较费时;过于强调测试,很多代码是不需测试的,且往往在编写实现时才知道是否有必要测试;对编程过程的帮助不足,很多函数,都是在代码基本完成时,主要用例才能通过,在此过程中,TDD不能提供帮助;改变思维习惯,有些程序员难于接受。
http://meiwen.anslib.com/