功能测试填补单元测试留下的空白,并可增强小组对代码的信心。单元测试漏掉许多错误。尽管它可以提供您所需的全部代码,但它可能无法提供您所需的全部系统功能。功能测试将暴露单元测试遗漏的问题。一套适当的自动化功能测试也不可能捕捉到每个错误,但是它能比最好的单一单元测试捕捉更多的错误。
单元测试与功能测试
单元测试向开发人员表明代码正确执行操作;而功能测试向开发人员表明代码执行正确的操作。
单元测试
单元测试是从程序员的角度编写的。它确保类的某个特定方法成功执行一系列特定的任务。每个测试都确保只要给定输入,方法将输出预期的结果。
如果没有测试框架,编写一套可维护的自动化单元测试几乎是不可能的。在开始编写测试之前,请选择一个小组公认的框架。您将经常性地使用这个框架,因此您最好对它有点好感。极限编程网站提供了几个单元测试框架(请参阅参考资源)。我最熟悉的框架是JUnit,它专门用来测试 Java 代码。
功能测试
功能测试是从用户的角度编写的。这种测试确保系统执行用户期望它执行的工作。
很多时候,系统开发好比建筑房屋。尽管这种类比不很恰当,但为了理解单元测试与功能测试的区别,我们可以扩充这种类比。单元测试好比房屋建筑现场的建筑监理员。他关心房屋的各个内部系统,如地基、构架、供电系统和管道设备等。他确保(测试)房屋每一部分的工作都安全、正常,即符合建筑说明。这种情况下,功能测试类似于视察同一建筑现场的房主。他假定内部系统将正常运作,并假定建筑监理员在执行其任务。房主关心的是住在这所房子里将会怎样。他关心房子的外观如何,各个房间的大小是否合适,房子能否满足家庭的需要,以及窗户的位置是否有利于采光。房主对房子执行功能测试。他从用户的角度考虑问题。建筑监理员对房子执行单元测试。他从建筑工人的角度考虑问题。
就像单元测试一样,如果没有测试框架,编写一套可维护的自动化功能测试实际上是不可能的。JUnit 非常适合编写单元测试;但是,当试图编写功能测试时,它就显得力不从心了。就功能测试而言,没有与 JUnit 相当的框架。也有几种用于功能测试的产品,但我从来没见过它们应用于生产环境。如果找不到满足您的需要的框架,您就必须创建一个。
无论我们多么擅长于构建手头的项目,也不管我们正在创建的系统多么灵活,如果我们的产品不合用,那我们就是白费时间。因此,功能测试是开发最重要的部分。
由于两种测试都必不可少,您就需要了解编写它们应遵循的原则。
如何编写单元测试
刚开始编写单元测试时很容易恢心。最佳的入手方式就是为新代码创建单元测试。(尽管为现有代码创建单元测试比较困难,但并非无法实现)。首先从新代码着手,待您习惯了整个过程以后,再针对现有代码创建测试程序。
如上文所述,应该首先编写单元测试,然后再编写这些单元测试要测试的代码。如何为尚不存在的代码编写测试呢?问得非常好。掌握这一方法需要 90% 的思维加 10% 的技术。我的意思是,您只需假定您正在为其编写测试的类已经存在。接下来的任务就是编写测试。起初会犯很多语法错误,但您先别管它。这一步您要做的就是定义该类要实现的接口。下一步就是运行您的单元测试,修正语法错误(即,编写一个类,使它实现您的测试刚定义的接口),并再次运行测试。重复这一过程,每次仅编写修正故障的代码。运行测试,直到测试全部通过为止。一旦通过全部单元测试,代码也就完成了。
一般而言,类的每个公共方法都应有一个单元测试。但是,功能简单的方法(例如,getter 方法和 setter 方法)不需要单元测试,除非它们以某种特别的方式进行获取和设置。应该遵循下面这条很好的原则:即只要您认为有必要对代码中的某个行为加注,就编写一个单元测试。如果您像其他许多程序员一样不喜欢为代码加注,则单元测试是记录代码行为的一种方法。
将单元测试与被测试的相关类放在同一个包内。这种组织方式使每个单元测试都能访问被测试类中带有 package 或 protected 访问修饰符的方法和引用变量。
在单元测试中避免使用域对象。域对象是特定于某个应用程序的对象。例如,一个电子表格应用程序可能包含一个注册对象;这个注册对象就是一个域对象。如果您有一个已知这些域对象的类,则在测试中完全可以使用这些对象。但是如果您有一个根本不使用这些域对象的类,在测试中就不要将这些对象联系到该类上。应该避免这种情形完全是因为代码重用。为某一项目创建的类经常要用于其他项目。重用这些类可能很简单。但是,如果对重用类的测试中用到了另一个项目的域对象,则使测试能够正常运行这一工作就会相当耗时。通常情况下,这个测试将被删除或重写。
文章来源于领测软件测试网 https://www.ltesting.net/