关于‘Testing’

单元测试相关视频和播客

发表于2008年12月26日

StackOverflow的关于单元测试的讨论中看到了如下资源,列出备查

At Dnr TV there are two episodes with JP Boodhoo, where he gives an introduction to test driven development:

If you want to see unit testing and TDD used together with a whole bunch of other agile practices, I would recommend watching the sceencast series Autumn of Agile. This series shows the development of a fully unit tested application from start to finish.

As for podcasts, check out the following:

Since mock objects are a quite important part of unit testing, these podcast episodes might be of interest as well:

.NET Testability Explorer

发表于2008年12月3日

在负责一个Unit Testing on CAB的内部培训项目期间,我阅读了Miško Hevery的一系列文章,他目前在Google担任敏捷教练。我对他的Testability Explorer(简称GTE) 产生了浓厚兴趣。

虽然Java和.Net世界已经有一些类似工具存在,但GTE这个项目实现功能比较专一,输出结果也直接易懂。相对NDepend强大但相对复杂和FxCop官方但略显强硬,GTE这个项目从形式上来说更有亲和力。所以我和Joe同学在Google Code上开始了一个新项目: .NET Testability Explorer(简称NTE)。
功能受众是期望对输出的.NET Assembly进行分析的开发人员,报告中提供的信息可以帮助他们对设计进行调整,从而使code base更容易测试和维护。

计划是,首先实现圈复杂度的度量,然后实现输出类似GTE形式的报告。希望能够在09年农历新年前发出第一个版本。
目前TE的成本模型支持对全复杂度、全局变量和笛米特法则的计算。

技术层面可以参考Gendarme这个项目,一个基于Mono.Cecil的代码分析工具。

Updates 20081221
项目分成两部分:IL分析,基于规则的成本模型计算

IL分析:目前IL分析方面的技术调研实现了类型,字段,方法级别的读取。剩下最大的一部分是方法中instruction的decompose,这部分估计占全部的40%工作量。但是我需要从成本模型分析的方向进行分析,确定在decompose过程中所需要收集的信息,所以先完成大概10%遍历所有instruction构建一个草图模型。目标是实现最简单的圈复杂度的计算。
成本模型:完成大概10%-20%的基础模型构建,支持全复杂度的计算。
下一步,重构设计使其能支持更多的规则考量,并增强其可扩展性。
目前从代码量来看完成了TE全部功能的1/6,考虑到TE支持对C++语言的分析,折半其工作量,目前大概完成了全部工作的1/3。

目标定于在完成一半的时候提交代码到Google Code,并发布第一个可运行的版本。时间定于08年圣诞节期间。新的计划是春节之前,发布第一个可运行的版本,并将代码提交。

Watir rocks!

发表于2006年10月12日

最近我关注了一下Ruby(还在入门阶段~)。发现了一个Web测试的框架-Watir,想起前一段,组里讨论为QA们购买一套自动化软件测试的工具,如果这个框架够用且好用,为啥还要花钱呢~

现在这个基于Web的项目在UI部分比较复杂,使用的第三方控件,在页面中生成了很多iframe、嵌套表格等。在样式上有很大的灵活性、使用起来也很方便,但是其服务器端代码、客户端代码还有生成的代码,看起来都有点糟糕。

Selenium也很优秀,不过因为在学习Ruby的缘故,呵呵!

我对Selenium了解的并不深入,但这两种测试工具并不是互斥的,Selenium也支持使用Ruby写测试代码。而且Selenium可以和CC/CCNET等工具结合,以便自动化功能测试的过程。

到目前为止,我觉得Watir的形式让我从程序员的角度很容易接受。

Watir通过COM的对IE进行了封装,然后用Ruby简洁的语法就可以很方便的调用IE的方法,以及获取IE容器中的DOM模型。之前我试过通过.Net来控制IE然后自动化一些测试,可是需要编译,这使过程复杂化,而用脚本语言则Happy的多。

一些功能强大却也价格不菲的测试工具也提供了各自的脚本语言,以便Tester在需要的时候手写测试代码,但与其学习一种与大家毫不相干的语言,不如使用通用一点的脚本语言。

老胡说,研究这个东西可能没有太大的价值,因为一些强大的工具都能满足QA自动化测试的需要。

固然有道理,但好奇心杀死猫,不试一下我怎么知道。

李玉鹏说,设计一个好的测试用例才是关键,而不是采用何种工具。

我同意他的说法。就像软件项目服务于需求,而并不以技术论成败。