2007-03-12

演讲：单元测试及测试自动化

关键字: JUnit与Ant
前天，公司安排我给同事做了一个单元测试和测试自动化的培训。
前后花了一个半小时，声嘶力竭，总算不辱使命，反响良好。
其实单元测试是一个相对复杂却很重要，但在现实项目中往往难于实施的一个问题。
往往和refector同步进行，相辅相存。
特把PPT放出来，共感兴趣的同仁参考，也希望反馈好的想法。
评论
hiwzg 2007-06-20
嘿嘿，坚持转向TDD。

gurudk 写道
找到知音了，我也想在公司里普及单元测试,测试驱动开发和重构等， 讲课效果不理想，心里也很郁闷
这里可以看到我的培训资料，包括PPT,源码，类图，里面用一个例子实践了TDD， 不过是用.net开发的，
我做过一年多的.net，后来转到java，我现在写代码已经习惯了采用TDD的开发方法，感觉踏实了很多，
基本不用调试，优点是在是太多了，看着全绿的感觉，别提多爽了。
下面是我的测试驱动开发与代码重构的培训资料。
http://www.sourcelive.cn/test_driven_development_and_refactoring.htm
hiwzg 2007-06-20
今天我在公司做单元测试的培训，项目组里面来的人也不多。这可是项目经理上周五任命的授权我代表项目组所做的工作，但是，仍然很多开发人员都没有来，没来的主要是学生和头头。

第一次培训，主要就是在测试观念上进行培训。测试观念上项目组成员没有达成一致意见，就不用谈后面真正真枪干了，会有很大阻力的，这也是我为什么要首先培训观念的原因。

凤舞凰扬 写道
对于技术人员来说，怎么去使用JUnit，ant以及一般工具来说，都不是什么难事。单元测试之所以重要，单元测试的培训之所以重要，首先要让受训人员知道为什么要去单元测试，单元测试包括哪些；其次，怎么样去写一个好的测试用例更加重要。
在我对我们公司的员工培训效果来看，问题往往集中在测试用例的编写上。几乎所有人写的测试用例都是简单的通过测试，要么就是将注意力过分关注在简单方法上（对此，我认为是许多将Junit的书籍经常用所谓的add或者div方法所导致的误区）。
对于楼主的培训文档，我提一些建议，供你参考：
1.增加代码静态检查部分（包括Code Metric/Code Audit/Code Review）
2.增加测试模式部分（包括Pass/Fail Testing,Transaction Testing等）
3.增加Coverage部分，测试覆盖是测试的重要组成部分。
4.设置常见的Check List，这个对测试流程非常重要。
5.增加讲解仿真测试中Mock使用的优缺点。
6.更着重讲解一些测试的基本概念，包括回归测试，冒烟测试等。
dearwolf 2007-05-16
我同意透明的看法
gigix 2007-05-16
hyysguyang 写道
呵呵，Cruisecontrol没有那么强大的，只会构建失败的时候通知没，不让你提交我可还没发现这个功能.

这是制度。如果明知道当前的codebase有问题还在往里面提交新的修改，你不觉得这说明团队的管理存在很严重的问题吗？
jzx19770812 2007-05-16
我觉得是否能应用TDD还是和老板还有公司项目类型有关，如果老板不懂没什么软件工程的理念，而且没有预留单元测试的时间，那么TDD就是个美丽的泡泡。
gurudk 2007-03-19
找到知音了，我也想在公司里普及单元测试,测试驱动开发和重构等， 讲课效果不理想，心里也很郁闷
这里可以看到我的培训资料，包括PPT,源码，类图，里面用一个例子实践了TDD， 不过是用.net开发的，
我做过一年多的.net，后来转到java，我现在写代码已经习惯了采用TDD的开发方法，感觉踏实了很多，
基本不用调试，优点是在是太多了，看着全绿的感觉，别提多爽了。
下面是我的测试驱动开发与代码重构的培训资料。
http://www.sourcelive.cn/test_driven_development_and_refactoring.htm
hyysguyang 2007-03-19
呵呵，Cruisecontrol没有那么强大的，只会构建失败的时候通知没，不让你提交我可还没发现这个功能.
JeffreyHsu 2007-03-19
我在公司也致力于普及单元测试和TDD，建立规范什么的，但是发现最大的问题不是程序员会不会测试，而是原不愿意测试的一个问题。
新项目可能还好一点，特别是对于既有代码的单元测试的跟进，开发人员就更不愿意做了，那你之前辛辛苦苦所搭建的各个tier的测试框架就形同虚设
后来看到一个持续集成的工具CruiseControl，可以帮你建立一个完整的迭代开发测试框架，可以保证在单元测试没有通过的情况下不允许提交到代码库（似乎是有这个功能），最近整考虑有时间看看这个东西。
hyysguyang 2007-03-19
凤舞凰扬说的极是,支持.
Godlikeme 2007-03-18
凤舞凰扬 写道
对于技术人员来说，怎么去使用JUnit，ant以及一般工具来说，都不是什么难事。单元测试之所以重要，单元测试的培训之所以重要，首先要让受训人员知道为什么要去单元测试，单元测试包括哪些；其次，怎么样去写一个好的测试用例更加重要。
在我对我们公司的员工培训效果来看，问题往往集中在测试用例的编写上。几乎所有人写的测试用例都是简单的通过测试，要么就是将注意力过分关注在简单方法上（对此，我认为是许多将Junit的书籍经常用所谓的add或者div方法所导致的误区）。
对于楼主的培训文档，我提一些建议，供你参考：
1.增加代码静态检查部分（包括Code Metric/Code Audit/Code Review）
2.增加测试模式部分（包括Pass/Fail Testing,Transaction Testing等）
3.增加Coverage部分，测试覆盖是测试的重要组成部分。
4.设置常见的Check List，这个对测试流程非常重要。
5.增加讲解仿真测试中Mock使用的优缺点。
6.更着重讲解一些测试的基本概念，包括回归测试，冒烟测试等。


这些内容更具有实际的指导意义，
管理制度是一方面，让开发人员养成良好的测试习惯和能力更多的还是需要引导。
Godlikeme 2007-03-18
snakeguang 写道
向大家推荐JOLT大奖系列丛书：

《单元测试之道JAVA版——使用JUNIT》
《单元测试之道C#版——使用NUNIT》
《版本控制之道——使用CVS》
《项目自动化之道--如何构建、部署、监控JAVA应用》
《版本控制之道——SUBERVERSION》


pragmatic programmer系列的书还不错，相对实用性强些。

junit这本我有看，还翻译了其中一部分放到blog里，有空大家就拍拍。

http://godlikeme.javaeye.com/admin/show/30932
hyysguyang 2007-03-18
bitlong 写道
呵呵，大家都忽视了一个问题。不是程序员不想写，只要公司规定写unit test，肯定都会写。国内的项目99%有需求不明，人力不足，Team内不水平差异，项目周期预算没有考虑单元测试的时间。

另外，所有的单元测试的培训，都是泛泛谈。大家真正的理解并解决自己的问题还是有难度的。

单元测试不应该只是简单的Assert一下就完了，在不同的场合下，有不同的潜规则，这些全是靠经验来的。正式模式一样，有不同的场景，为解决某一个问题而出些。单元测试的也是在测试不同的问题，不同的场景，而这些是培训没有办法给出了。

空的理论只是鸡肋。
我们公司就要求必须要写unit test的，可是，我看到的很多单元测试要么就是测试方法里面是空的，里面的内容是//todo，要么问题很多，比如不是采用assertxxxx，而是采用System.out.println();试想这样能有什么好处，这样纯属浪费时间。
事实上要掌握单元测试这一基本而重要的技术，是有一定难度的，至少我是花了很大的精力才开始习惯于写测试的。实践这一基本的技术的最好的方法就是Just do it!不去写你永远都不会写单元测试用例的，而且最好的办法是和在这方面非常有经验的人一起写效果会更好.我当初的方法是看开源组件的代码，看他们的测试代码，每次当对某种情况的测试不知道怎么测时，我就看看他们怎么做的，这样，很快的我也就会了.
我同意楼上的“空的理论只是鸡肋。”,单元测试实践当然非常的重要，但我认为，理论也很重要，比如，那些基本的测试方法，基本的测试策略以及其他的测试技术，如怎么让测试更容易的一些技巧，我认为这些都很重要，如果你不了解这些，我想你在进行单元测试的时候估计会困难重重的。
总之，不论如何，理论要联系实践的，正如其他的技术一样，我认为单元测试也不例外.
bitlong 2007-03-18
呵呵，大家都忽视了一个问题。不是程序员不想写，只要公司规定写unit test，肯定都会写。国内的项目99%有需求不明，人力不足，Team内不水平差异，项目周期预算没有考虑单元测试的时间。

另外，所有的单元测试的培训，都是泛泛谈。大家真正的理解并解决自己的问题还是有难度的。

单元测试不应该只是简单的Assert一下就完了，在不同的场合下，有不同的潜规则，这些全是靠经验来的。正式模式一样，有不同的场景，为解决某一个问题而出些。单元测试的也是在测试不同的问题，不同的场景，而这些是培训没有办法给出了。

空的理论只是鸡肋。
hyysguyang 2007-03-16
呵呵，大体看了一下，和我以前培训的思路差不多，只可惜我的收效并不高.基本上所有的人都不愿意写测试，除了很多原因之外，有一个很重要的因素就是，即便他们写测试也是习惯于先写代码在写测试，只可惜写的代码很难测试，所以也就不愿测试了。就这样，还是没有人写测试。
培训文档我没传，但是完整的资料可以看看我的blog：http://hyysguyang.javaeye.com/
抛出异常的爱 2007-03-16
凤舞凰扬 写道
对于技术人员来说，怎么去使用JUnit，ant以及一般工具来说，都不是什么难事。单元测试之所以重要，单元测试的培训之所以重要，首先要让受训人员知道为什么要去单元测试，单元测试包括哪些；其次，怎么样去写一个好的测试用例更加重要。
在我对我们公司的员工培训效果来看，问题往往集中在测试用例的编写上。几乎所有人写的测试用例都是简单的通过测试，要么就是将注意力过分关注在简单方法上（对此，我认为是许多将Junit的书籍经常用所谓的add或者div方法所导致的误区）。
对于楼主的培训文档，我提一些建议，供你参考：
1.增加代码静态检查部分（包括Code Metric/Code Audit/Code Review）
2.增加测试模式部分（包括Pass/Fail Testing,Transaction Testing等）
3.增加Coverage部分，测试覆盖是测试的重要组成部分。
4.设置常见的Check List，这个对测试流程非常重要。
5.增加讲解仿真测试中Mock使用的优缺点。
6.更着重讲解一些测试的基本概念，包括回归测试，冒烟测试等。


有没有这方面说的更清楚的文档呢
凤舞凰扬 2007-03-15
对于技术人员来说，怎么去使用JUnit，ant以及一般工具来说，都不是什么难事。单元测试之所以重要，单元测试的培训之所以重要，首先要让受训人员知道为什么要去单元测试，单元测试包括哪些；其次，怎么样去写一个好的测试用例更加重要。
在我对我们公司的员工培训效果来看，问题往往集中在测试用例的编写上。几乎所有人写的测试用例都是简单的通过测试，要么就是将注意力过分关注在简单方法上（对此，我认为是许多将Junit的书籍经常用所谓的add或者div方法所导致的误区）。
对于楼主的培训文档，我提一些建议，供你参考：
1.增加代码静态检查部分（包括Code Metric/Code Audit/Code Review）
2.增加测试模式部分（包括Pass/Fail Testing,Transaction Testing等）
3.增加Coverage部分，测试覆盖是测试的重要组成部分。
4.设置常见的Check List，这个对测试流程非常重要。
5.增加讲解仿真测试中Mock使用的优缺点。
6.更着重讲解一些测试的基本概念，包括回归测试，冒烟测试等。
tianlinzx 2007-03-14
楼上说的对，测试确实是很重要的一个环节，不仅是对软件质量的一个保障，更是对软件开发进度的一个保障。不仅是一个技术问题，更是一个项目管理上的问题。在项目中要尽早规划，尽早布局。
newman 2007-03-14
在JavaEE项目中进行单元测试有一个先决的技术条件，就是需要先架构好整个一套的测试框架，比如server端用Cactus，数据层用dbUnit，把整个测试架构搭建起来后，还需要对开发人员进行培训，逐步建立测试意识，指导开发人员在开发当中执行测试，因此，单元测试既牵涉技术关乎过程控制。
dongbin 2007-03-14
TDD没有提到
Godlikeme 2007-03-14
现在项目中类似的单元测试规范文档也有，对单元测试只是口头上要求，并没有严格要求，具体的写法，测试程度靠个人喜好了，甚至有人不写。
lcllcl987
搜索本博客
博客分类
最近加入圈子
存档
最新评论