随笔-60  评论-98  文章-0  trackbacks-0

不论是单元测试还是接口测试,熟悉程序内部实现都是有用的——这种理解是有问题的,我们目前所做的测试除了集成测试就是小规模的集成测试。

现在测试组目前的所有测试都不是单元测试,因为单元测试最基本的单位是函数,接口测试是一种测试手段,不是一种测试分类。

编写测试用例跟程序实现没有必然联系,比如按照测试驱动开发的理论的测试用例编写是从函数接口都没有的情况下开始写的,此时接口都没有,更别说实现了,这样就写不出测试用例来了么?
编写测试用例关注什么,关注的是模块的行为,也就是通过输入看输出,是否和设计文档、接口头文件中的描述一致。比如一个函数声明为

// 为公司的数据库添加一位新员工的信息,包括工号,姓名,性别
// 约定工号始终为正数,男同事为1打头,女同事为0打头
// 姓名不得为空
// 性别0代表女同事,1代表男同事
// 添加成功则返回true,失败返回false
bool AddEmployee(int iNumber, String sName, int iSex);

有了上述这些信息就可以开始设计测试用例了,比如iNumber = 047788, sName = "li hong",  iSex = 1, 我们期待的返回值就是false,因为性别和工号有冲突。如果测试返回true,则说明软件有bug。

这是写一条测试用例的整个过程,其中并没有设计到函数的内部实现啊?

我们现在的开发离测试驱动开发还有很长的路要走。
我们能做的是什么呢?
是回归测试,开发人员对模块进行回归测试,带着反馈工作,尤其是在添加新功能,修正bug的时候,有了回归测试,就像有了杂技演员的身上有了保险绳,可以放心地在高空中做各种动作。

现在该怎么做呢?
我的想法是,测试框架的搭建是由开发人员做好的,因为一些解耦和的工作是必须开发组来做的(随着技术的进步,越来越多的解耦合方法被提出来,想详细了解这方面的东西,推荐看《修改代码的艺术》)。具体来说,比如我要做一个模块,现在已经做到一半了,基本功能都做得差不多了,但是心里没底,因为没有QA。这是后就可以用DUnit来创建测试工程,写一些测试用例。但是,现在版本压力大,没有这么多时间把测试用例写全面,怎么办?把测试框架给测试组,由测试组的同学来完善和丰富测试用例,因为测试组的同学比开发组的同学有更深厚的测试用例设计基础,能写出更好的测试用例,同时也有助于提高测试组同学开发水平,促进TEST向QA转变。另外,这也避免了开发人员在编写测试用例时的思维定势,导致明显的问题也测不出来。

这样,随着模块的不断完善,开发人员把测试框架进行补充,测试人员丰富测试用例。如此交替进行。

另外一个比较关键的问题是开发组测试组提供什么来进行测试。提供源文件的方式是行不通的,目前采用比较多的是提供DLL,同时为了避免测试规模增长,采用了DLL注册等一系列机制。
我的想法是由开发组提供模块代码的.obj文件和测试用例的源文件,这样测试人员可以随时构建出自己需要运行的版本,感觉上就像手里有模块的源代码一样,只是不能进去debug。

所以说,现在先做一个模块,解耦合、大框架、测试组编写测试用例,这一整套流程做通了,证明切实可行,方便有效。开发组自然就乐于接受了,测试组可以在模块的级别上进行QA,而不是在发布版本之后才进行集成测试。

一点小想法,具体实现,还需要各位都加把劲啊,呵呵。

posted on 2008-03-05 13:16 创建更好的解决方案 阅读(1846) 评论(7)  编辑 收藏 引用 所属分类: TDD软件测试理越辩越明

评论:
# re: 关于实战测试驱动开发的一点感想。 2008-03-05 22:09 | 魔域私服
# re: 关于实战测试驱动开发的一点感想。 2008-03-06 17:04 | LOGOS
尝试在遗留代码中使用单元测试有一阵子了,发现了以下一些问题:
项目压力
遗留代码的代码基非常差,解依赖消耗大量时间
所选择的遗留代码也是当前的开发项目,变动比较剧烈,以前写好通过的测试,在一段时间后,就因为依赖而失败了,甚至编译不能通过  回复  更多评论
  
# re: 关于实战测试驱动开发的一点感想。 2008-03-06 17:47 | 创建更好的解决方案
大家处境都差不多,探索出一条好的工作流程,可以添加测试用例不再那样痛苦,才是解决的办法。靠一己之力,过于绵薄了吧。@LOGOS
  回复  更多评论
  
# re: 关于实战测试驱动开发的一点感想。 2008-03-06 18:48 | LOGOS
我当然希望和同事共同努力,只是多数人对单元测试并没有太多认识,而我现在也没有信心能把这里面的概念向大家讲清楚,还需要再做些摸索才行  回复  更多评论
  
# re: 关于实战测试驱动开发的一点感想。 2008-03-07 10:51 | 创建更好的解决方案
是啊,通过半个月的沟通,在测试组码了两个人,负责完善测试用例的,我先趟趟水,随时交流进展。@LOGOS
  回复  更多评论
  
# re: 关于实战测试驱动开发的一点感想。 2008-03-11 14:19 | 创建更好的解决方案
我的想法是由开发组提供模块代码的.obj文件和测试用例的源文件,这样测试人员可以随时构建出自己需要运行的版本,感觉上就像手里有模块的源代码一样,只是不能进去debug。

这种设想有点问题。

首先obj文件没用,因为测试用例的源文件包含了接口文件和实现文件的头文件,hoho,更改之后的compile会把大家都牵扯进来。

修改一下:通过dunit框架load dll并导出对象,供测试组调试测试用例之用。这样的测试用例不仅可以用来测试dll,也可以用来做单元测试。  回复  更多评论
  
# re: 关于实战测试驱动开发的一点感想。 2008-03-18 18:02 | 创建更好的解决方案
通过添加DLL/源码测试开关,开发人员和测试人员共用一套测试代码,开始走上靠谱的道路。@创建更好的解决方案
  回复  更多评论
  

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理