收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
软件测试 > LoadRunner > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

单元测试应该测什么,不应该测什么?

来源:互联网 日期:2012-09-22 20:30
自动化的单元测试应该测什么。

最近有朋友提出意见,觉得我写的文章比较空洞,写的很长,但是很不实在。可能原因是这样的:代码太少了。今天就从一段代码开始吧,这段代码描述电信营业系统中的缴费开机的过程: User user = User.getUserByServiceId("13309790280");//通过电话号码找到用户
Account account = user.getAccount();//与用户关联的帐户
user.pay(100);//用户缴费100元

//判断用户余额+帐户的信用度-用户欠费是否大于0
if (user.getBalance() + account.getCredit() - user.getDebt() > 0)
{
Service service = user.getService();//与用户相关的服务
//判断这个服务是否处于欠费停机状态
if (service.getState() == "欠费停机" || service.getState() == "限制呼出")
{
…//向交换系统发出开机指令
}
}

这是电信营业系统中最常见的的一个业务。电信系统最基础的模型应该说是"三户模型",三户模型描述的是客户(Customer)、帐户(Account)、用户(User)以及服务(Service)等等概念的一个关系模型。实际的模型比代码里的复杂,这里简化了很多,主要用来举个例子。

要开发一个电信系统,首先要做的就是在系统中实现最基础的几个模型,比如三户模型、联机指令模型、业务办理模型、合作伙伴模型……,其中三户模型处于非常重要的地位。首先要做的是在软件系统中真实的反映这个模型,绝不可以将其隐含扩散在各个业务过程中。然后就可以在这个基础上,从一到二、从二到三、从三到万,实现各个子系统和复杂多变的业务需求

按照TDD的开发思路,我们应该先写测试代码,再来写实际程序,用测试来推动开发的前进。这里先把代码写出来,表达一下业务。下面我就说一下,单元测试代码应该测什么。

我们拿User举个例子,现在我们要写User类的测试代码。

需要测什么?

我们需要测试User类的外在表现。比如我们要测试pay方法,应该这样:

我们建立一个User对象,这个User余额是0,欠费38元。现在缴费100元,缴费完成后,余额应该是62元,欠费应该为0,这是一个Case。

我们建立一个User对象,这个User余额是30,欠费0。现在缴费50元,缴费完成后,欠费应该仍然是0,余额应该是80元。这是第二个Case。

我们建立一个User对象,这个User的余额是0,欠费150元。现在缴费70元,缴费完成后,欠费应该是80元,余额应该是0。这是第三个Case。

我们应该测试的是User类的外在表现,而不应该过问他如何实现。

在测试的时候,我们需要一个可以重复的稳定的环境(真实环境往往不行),有时候无法直接建立User对象(比如User对象要依赖一个数据集),有时候真实的环境很难实现一些测试条件(比如边界值、非正常值)。这时候,我们就可以使用Mock、Stub这样的方法,把User建立起来,也把环境建立起来,然后测试User的表现。

不需要测什么?

还是拿User举例子,还是测试pay方法,我们不应该测试这些东西:

缴费如何实现,这个费用保存到哪个数据表的哪个字段里去了,是否符合某种数据关系。

缴费以后的余额、欠费按照什么变量加减或者从某个数据字段中得到自己的值。这个不需要测。User类应该负责自己的费用问题,不应该把任何业务逻辑暴露给其他类(费用保存到哪里、什么数据结构,User应该负责)。外界只关心User的表现。

缴费后应该不应该向交换机发送开机的指令,这个就更不需要测试了,这是User的调用者应该负责的事情。

测试代码保证了什么?

测试代码只保证接口是正确的,至于业务正确不正确不是最关心的事情。比如User的测试代码,User把费用保存在数据表里、还是写在文件里,他是不关心的。甚至根本没有持久保存,他也不管,只要接口正确就通过。当然,内在实现上的错误总会通过接口表现出来。假如User没有把用户缴费保存起来,当我们在另外的空间中建立相同ID的另一个User对象时,就会得到错误的余额和欠费。

单元测试究竟有什么用?

从某种角度上说,单元测试并不能保证业务的正确性,而只能保证接口的正确性(严格的说,其实连接口的正确性也无法保证,他只能保证接口"没有这些错误")。如果一个类总是自己在默默的工作着,不提供接口告诉外界他干了什么,测试他的业务是很难的(也不应该去测试,否则必然要插手他的业务)。那么单元测试究竟有什么用呢?

单元测试保证模块修改后的兼容性。可以通过单元测试来判断一个模块在修改后是否与修改前保持兼容、多大程度上不兼容、影响范围有多大。开发者就可以更加专注于模块内部的业务。单元测试无法代替人工的工作,他能够做到的是衡量一个模块修改后会不会影响其他模块的工作。这对程序的维护和升级有非常大的好处。

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的!
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号