Junit 使用介绍软件测试基地论坛 - 软件测试 | 软件测试资料 | 软件测试管理 | 自动化测试


» 您尚未登录注册 \| 社区服务 \| FTP中心 \| 帮助 \| 社区 \| 无图版 \| 测试百科 \| 测试Blog

软件测试基地论坛 -> 测试开发技术 -> Junit 使用介绍

XML

RSS 2.0

WAP

--> 本页主题: Junit 使用介绍

加为IE收藏 | 收藏主题 | 上一主题 | 下一主题

Fastpoint

级别: 总版主
精华: 44
发帖: 5033
基地声望: 390 点
基地币: 1683 Bug
基地贡献: 0 点
好评度: 15 点
在线时间:818(小时)
注册时间:2005-10-08
最后登录:2008-07-22

Junit 使用介绍前一阶段，为在公司内部推广junit使用写的一篇稿件。 Jbuilder 集成了junit后使用很便捷，但对从没使用过的人来说毕竟还是有些门槛。原文是word格式，不知道怎么在“大富翁”上发布。只能另存为txt格式。图片、DEMO都无法上传，排版也不好。但本着“重在搀乎”的原则，还是发布一个txt版本。 ================================================= JUnit 使用介绍作者： tuti tut@citiz.net 关键字：单元测试，框架，JUnit 版本 1.0 JUnit 使用介绍 1 什么是单元测试(Unit Test) 1 常见的工作场景 2 场景1： 2 场景2： 2 场景3： 2 Java程序的传统测试方法： 3 Main测试法弊端： 3 理想中的单元测试的一些特征： 3 JUnit 使用介绍 3 测试框架 3 JUnit介绍 3 JUnit结构 4 Jbuilder7中Junit使用 5 Junit若干实践问题 8 JUnit实施 9 实施路线 9 不适用的范围 9 成功案例 10 结束语 10 参考资源 10 我们所要做的一切是尽可能快地犯错误。 ——约翰.阿奇博尔德.惠勒什么是单元测试(Unit Test) 程序设计领域中有很多种测试，单元测试只是其中的一种。测试只能找到程序中的部分错误，难以保证程序完全正确无误。单元测试定义：单元测试是在软件开发过程中，要进行的最低级别的测试活动，在单元测试活动中，软件的独立将在与程序的其他部分相隔离的情况下进行测试。完成单元测试是开发人员的日常工作，它是由程序员自己进行的测试工作。单元测试所测试的是“程序代码单元是否按照预设的方式执行而产生的合乎期待的结果”，也就是程序代码的正确性。单元测试的必要性：还有必要讨论吗？常见的工作场景场景1：甲：你那个“解析表达式”模块完成了怎么样? 乙：代码已经完成了，但还没测试，我现在很忙，等我把剩下的模块全部完成了再来测试。甲：那当你完成了 90%。心想：“但愿如此。。。”（悬！）分析： 1．单元测试实现起来需要简单方便，否则没人愿意做完整测试。 2．没有测试的进度估算，失真的可能性很大。场景2：甲：我需要使用你的那个“解析表达式”的模块。你的模块测试了吗？乙：测试过了。甲：都测试了哪些情况？乙：除了没测试的，都测试过了。甲：(晕!) 那测试文档有吗？乙：很忙，没时间写。甲：（再晕！）分析： 1．对于接口程序，需要能完整的描述接口的行为。 2．需要可读性良好的资料，使与该程序的相关各方面，能进行良好的沟通。场景3：乙：那个“解析表达式”的模块，效率太低，写得又乱，我想重写一下。甲：现在起码还能用，快交货了，你就老实点吧，别又搞出点BUG来。乙：（郁闷!）分析： 1．在没有完整的测试安全网的情况下，对代码进行修改的风险很大。 Java程序的传统测试方法：就一般java程序而言，程序员大多利用的在相应需要测试的类中添加main函数。在main函数中，建立对象实例，调用需要测试的方法并打印结果。程序员通过打印出来的结果，来判断执行是否准确。 Main测试法弊端： 1．在需要交货的程序中，混杂有多余的代码。 2．很难进行多了个类的集成测试。 3．过多的打印语句不利于判断测试结果。 4．逐个执行每个类的main方法，工作量很大。理想中的单元测试的一些特征： 1．完成一个测试，只需要少量测试代码。 2．多个测试可以集成，进行回归测试。 3．测试代码，和被测试代码完全分离。 4．测试的自动化、快速，测试结果一目了然。 5．测试代码有良好的可读性，具备文档作用，便于各方沟通。 JUnit 使用介绍测试框架为了达到以上理想中的单元测试，单个类或对象很难达到目的，而需要使用单元测试框架。框架（framework）是指构成一组特定软件可复用设计的一组相互协作的类。框架规定了你的应用的体系结构。它定义了整体结构，类和对象的分割，各部分的主要责任类和对象是怎么协作，以及控制流程。框架预定意义了这些设计参数，以便于应用设计者或实现者能集中精力于应用本身的细节。 JUnit介绍目前在Java开发社区中，JUnit是最为流行的测试框架。而且Junit是开放源代码的，不需要购买。打开JUnit的官方网站 http://www.junit.org 是这样来介绍Junit“JUnit是由Erich Gamma、 Kent Beck所写的用于回归测试的框架”。而Erich Gamma是《Design Partterns》的主要作者， Kent Beck是“Extrme Programming”运动的主要旗手。都是软件开发领域的重量级人物。（XP的简介见参考资源4） JUnit结构 Junit 提供了junit.framework.TestCase ， junit.framework.TestSuite基础类用来编写单元测试。提供3个运行器(runnners), TestUI, SwingUI, AwtUI,来查看测试结果。TestCase和TestSuite都实现了Test接口。不同之处在于，TestCase用以容纳一个个独立的Test方法,test suite用以将一系列相关的 test cases编成一个组。一个test Suite 可以容纳若干个 test case和test suite。TestCase 可以进行针对一个类的单元测试。TestSuite对TestCase进行了编组以后就可以对多个类进行回归测试。 Junit使用断言（Assert）语句来进行结果的真伪判断。类似MFC中的ASSERT宏。断言语句在junit.framework.Assert包中，例如： assertEquals() 判断是否对象是否相等。 assertTrue() 判断boolean型的真伪。 assertNotNull() 判断对象是否不为空。建立一个新的单元测试时，需建立一个TestCase的子类，在类中添加自定义的测试方法。测试方法名需要以 test来头，如testSum( )。一个testXXX的测试方法，必须是 public方法，无返回值，无参数。在测试方法中，使用的适当的断言语句，即完成了一个测试方法。例如： public void testSum() { assertEquals( 2, sum(1,1) ); } TestCase.setUp() 和 TestCase.tearDown()是2个重要的方法，在每一个被测试方法运行前后被调用。用以建立必要的测试环境亦即清理结果或释放资源，比如建立JDBC连接，或删除数据库中由前一个方法测试时，插入的记录等。保证每个test方法，不受前一个test方法的影响。一个完整的JUnit测试框架如下“图1” 图 1 Jbuilder7中Junit使用图2 Junit建立一个方便使用的测试框架，但仍然需要使用者自己建立测试类。而当Jbuilder开发环境集成了Junit以后，通过提供的程序向导，适得测试类也可以自动产生，使用者只需要添加少量代码即可完成，并将Junit测试环境集成在 Jbuilder的IDE开发环境之中，使用更为简便。在new 时的弹出的Object galley对话框中有一项Test页，用以支持Junit的使用。见图2。在Jbuilder中使用的junit的实例： Step1: 首先建立一个普通的myCar类，代码如下： package jbunitdemo; public class myCar { public int getWheels() { return 4; } } Step2: New 时选择图2中的TestCase 项，弹出对话框(图3) 图 3 选择需要测试类，并可选择该类中需要测试的方法。然后可直接按Finish按钮。产生Testcar类注意该类在\test\jbunitdemo路径下。与src目录下的代码完全分离。向导中可选择进行运行环境注册，也可手工Run->configuration菜单->弹出“Project Properties”对话框->选择Run分页->New按钮->弹出 Runtime Properties对话框->选择“Test分页”->在Main Class项中浏览需要运行的TestCase子类或者TestSuite子类，起一个适当的Configuration name保存（见图4）。保存后可在工具栏Run按钮的下拉列表中，显示你刚注册的运行环境名称。图 4 将 TestmyCard.java文件的testGetWheels方法，最后增加一行 assertEquals(4,mycar.getWheels()); 期待 mycar.getWheels()方法得到的结果等于4。 public void testGetWheels() { myCar mycar = new myCar(); int intRet = mycar.getWheels(); /** @todo: Insert test code here. Use assertEquals(), for example. */ assertEquals(4,mycar.getWheels()); //用户自己增加的测试代码 } 运行菜单，选择相应的“运行环境名”点击即可运行。运行结果见图5，绿色表示通过测试，红色表示测试未通过。图5 按照test方法的预定，就可以不断增加需要测试的情况，在test方法中使用适当assert方法进行判断被测程序的行为是否符合预期。当出现“红叉”表示改种情况测试不通过，需要检查程序的出错原因。写一个单元测试的代码，JBuilder环境基本可以完成60%-70%的代码量。用户所要做的就是设置适当的输入情况，并判断相应的输出情况，来判断代码运行是否符合预期结果。当类的数量逐渐增加时，类之间的调用关系也将变得复杂。当我们对一个类修改并测试完成后，并不能保证其他类完全不受影响。这就需要通过利用 TestSuite将多个有关联的 TestCase集成在一起。在Jbuilder环境中，你只需要通过向导提示，选择你所需要集成的 TestCase测试项目，几乎不需要写任何代码，就可完成集成回归测试。具体操作见“Jbulider帮助文件” （见参考资源2），这里不展开详述。示例DEMO 见JBUnitDemo目录，myCar.java，myCarport.java 实际工作类，TestmyCar.java用于测试myCar类， TestmyCarport.java用于测试myCarport类，AllTest.java用于集成TestmyCar.java 与TestmyCarport.java这2个测试类。（见参考资源5） Junit若干实践问题 1. 在EJB开发中如何使用JUnit？ Junit用于测试普通Java类，而EJB运行需要容器环境支持。在测试EJB组件时，可先建立EJB 客户端（在JBuilder中得到支持），然后使用启动EJB服务器组件，通过Junit对EJB客户端进行测试即可。目前有些junit的变种，可直接支持在EJB容器环境中，进行测试。 2. 在非JBuilder环境如何使用？目前主流的Java开发工具，基本都集成了对Junit的支持。即使不使用IDE的开发环境，也完全可使用Junit，但写测试用例时，代码量增加些。如果需要自动编译测试，可使用ant 工具。该工具已内置了对于junit的支持。 3. 在非Java环境中，如何使用XUnit工具? 由于JUnit在java开发中，广泛而成功的实践。陆续已经开发出其他语言环境中的Xunit版本（见参考资源3）。目前已经包括 C++环境和Object Pascal环境等多种环境。 JUnit实施实施路线从对JUnit基本介绍来看，JUnit工具本身并没有提出革命性的测试方法，更多的是对传统的测试方法的扩展与支持。这就使得我们能够比较平滑的将Junit这一测试工具引入我们日常的开发活动中去。第一阶段：单个开发人员，在具体模块代码写成以后，通过Junit对已完成的模块的代码编写测试用例。用以验证完成代码的正确性。（牵涉人员：单个程序员。代码范围：若干个不相关模块）第二阶段：项目组内，若干个程序员达成共识，以测试用例做为补充文档。并能对一部分人的若干程序模块的测试用例进行集成。 (牵涉人员：若干个程序员。代码范围：若干相互关联的模块) 第三阶段：项目组内基本达成共识，若干成员有一定的Junit使用经验。接受测试优先原则（先写测试代码，后写实现代码）。将测试用例作为项目管理正式文档。（牵涉范围：项目组骨干人员。　代码范围：核心模块）第四阶段：全面导入XP(extreme programming)开发方式。将测试用例融入，设计、编码、代码集成、系统重构全过程。使得开发过程平滑而可控。 (牵涉范围：全项目组，代码范围：项目的生命周期全过程) 不适用的范围如同所有的优秀方法一样，Junit也有着自己的适用范围。一般以下情况不宜采用Junit。 1．在相应的开发环境还没有类似的测试框架。比如J2ME等环境。 2．程序设计不良，违反“高聚能、低偶合”等设计原则。或逻辑代码和界面操作混杂在一起。无法写出相应测试用例。这种情况下，需要改进设计本身。成功案例目前广泛使用的Jboss EJB服务器，就采用了ant和junit进行自动测试。Jboss发布版本的doc目录下有个tests子目录，其中就存放着当前jboss版本使用Junit的测试报告。（见参考资源6）结束语 1. 普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的是先去尝试。富兰克林D. 罗斯福1 It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - FRANKLIN D. ROOSEVELT1 2. 没有银弹。 F.Brooks （意为：没有无坚不摧的利器，没有万能的灵药。） No Sliver Bullet. Frederick P. Brooks 参考资源 1.Junit主页 http://www.junit.org/index.htm 2.Jbuilder环境中junit的使用文档。 Jbuilder 7 Help KeyWord: JUnit 3.下载 xUnit 测试工具 http://www.xprogramming.com/software.htm 4.XP介绍性文章《XP 精华如何 java项目获得更大成功》 http://www-900.ibm.com/developerWorks/cn/java/j-xp/index.shtml 5.Jbuilder 7 JunitDEMO ：\JBUnitDemo 目录 6. Jboss 的test文档： \ Jbosstests 目录 (本文完)
可不可不要这么样徘徊在目光内你会察觉到我根本寂寞难耐即使千多百个深夜曾在梦境内我有吻过你这毕竟并没存在人声车声开始消和逝无声挣扎有个情感奴隶是我多么的想她但我偏偏只得无尽叹谓其实每次见你我也着迷无奈你我各有角色范围就算在寂寞梦内超出好友关系唯在暗里爱你暗里着迷无谓要你惹上各种问题共我道别吧别让空虚使我越轨
[楼主] \| Posted: 2006-06-29 21:39

Fastpoint

jUnit这个东西，重要的在于管理，而非编程。jUnit是一种所谓单元测验。XP理论认为，你写代码之前，应该写出你的test Case. 我在项目中用到了这个jUnit.实际使用中效果没有完全发挥。这应该是由于没有贯彻xp的管理思想。我们是在写完一个bean之后，再写这个test Case的，并且如果需要作修改，没有先修改testCase,再去修改代码。由于客户不断催促，情急之下就会直接改代码，用人眼测试一下是正确的，就发布了。这导致最后jUnit TestCase和实际class脱钩。后来能够跑的testCase不足50%了。 jUnit真的是个好东西。你看，当你看到小绿条规律的向前跳动，100%完成的时候，心情真的很欢畅。因为我可以确定我的代码是正确的，我从来没有感觉这么放心过。但是有了好工具，而没有好管理，只会带来更加重的灾难。要想把jUnit用好，我总结几个教训： 1,项目必须良好组织，有强有力的项目spec指引，再开发之前做好screen design ,db design 等等文档，不然你没有办法开始写testCase.如果连Unit的单位都没有，哪儿来的UnitTest? 2,TestCase必须有一定的粒度。你必须决定，哪些是应该被unit test的，哪些是不需要的。我们采用的是很小的粒度，每一个dbClass都有一个对应的testClass.最后发现这样的粒度是有问题的，因为往往testCase写的比被测试的class代码都长，而我们的dbClass本来就都是一些机械的操作。后来我们认识到这种基本的class是应该采用生成机生的。就算需test的话，要的话，这种机械的classTest本身也应该自动化。 UnitTest的粒度应该以Unit为单位。比如说，认为Order是一个Unit,那么整个操作过程会包含几个步骤，place order, order approve, order parse, generate Outbound Job,这是一个 “商业逻辑”,TestCase就应该按照这个商业逻辑来写。 3,修改代码，必须严格按照spec更改的流程来做。如果spec不更改，screen design 或者 db design不更改，你的已经经过unitTest的程序绝对不能改。必须先改UnitTestCase再来改程序。xp编程的精髓之一在于，确保你的每一行代码都是有价值的，是经过深思熟虑的。而写testCase这件事情就是这样一个必要的思考过程。 UnitTest在老外的project中，好像总是和CVS一起使用。jBoss有一个功能就是自动跑unitTest 每天晚上他帮你跑所有的unitTest,第二天早上你来一看，好，报告已经发到你的email box里了。哪些case没有通过，就可以了如指掌。（这个功能是通过ant来做的）如果testCase不写好，怎么能做到这样呢？其实我也是UnitTest的初学者，学习一些先进的open source的开发，应该会更有益处。欢迎大家一起讨论！
可不可不要这么样徘徊在目光内你会察觉到我根本寂寞难耐即使千多百个深夜曾在梦境内我有吻过你这毕竟并没存在人声车声开始消和逝无声挣扎有个情感奴隶是我多么的想她但我偏偏只得无尽叹谓其实每次见你我也着迷无奈你我各有角色范围就算在寂寞梦内超出好友关系唯在暗里爱你暗里着迷无谓要你惹上各种问题共我道别吧别让空虚使我越轨
[1 楼] \| Posted: 2006-06-29 21:40

lhxtest

级别: 测试员
精华: 0
发帖: 52
基地声望: 5 点
基地币: 6576 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:25(小时)
注册时间:2006-05-22
最后登录:2007-12-18

我们这里也在要求做到楼主说的“自动跑unitTest ”，“第二天早上你来一看，好，报告已经发到你的email box里了”，不过我们这里的test case是有开发人员写的，测试人员是不是需要必须做到写test case呢？
一个人一生的财富就是他一辈子的努力！
[2 楼] \| Posted: 2006-07-20 17:12


软件测试基地论坛 -> 测试开发技术

软件测试基地是上海测仕信息技术有限公司旗下网站
Copyright © 2005-2007 Cntesting.com, All Rights Reserved
沪ICP备06057721号

Powered by PHPWind Code © 2003-06 PHPWind
Total 0.171600(s) query 5, Time now is:11-23 21:39, Gzip disabled
You can contact us

每日一句：Loading...