谈谈fitnesse(整理版)

谈谈fitnesse（整理版）1。使用命令行来添加用户和用户密码:D:\fitnessejava-cp-f-cSophia('D:\fitnesse”是fitnesse的安装目录)2。当用户加入一个成功,将会产生FitNesse文件下的根目录。3。开始使用普通模式:FitNesseD:\FitNesserun–p80804。改变页,你想使用的用户控制在意想页面上,点击属性按钮在左侧面板。在属性对话框之前,togglethe---------------------secure-writesecure-read/,/secure-test,点击保存5。开始FitNesse认证模式。使用D:\fitNesserun–p8080–a重新启动服务器后,你会看见一个弹出对话框,提醒你输入您的用户名和密码后,你点击控制页。Fit接受输入Null代表空指针，Blank代表空的字符串，而Slim不接受，因此对于Slim的输入，我们需要写一个Converter来进行转换。类似于publicStringconverter(Stringinput)if(null)returnnull;elseif(blank))return;这样也就解决了转换的问题。上次在第二季中介绍了Fitnesse中不同Table的类型。最近在工作中一直有遇到使用ActionFixture。在这里分享一下使用后的感受。今天先介绍一些Fit中的ActionFixture。有一个需求大概就是说，addStudent(inti)这个函数会每次增加学生的数量，count()这个函数则是统计学生的数量。那么在测试过程中，我们需要先增加学生，再看看学生数量是不是已经正确增加。这个时候我们发现用ColumnFixture是很难完成的，这个时候我们就想到了选择ActionFixture。它可以让我们按照Case的流程来设计我们的自动化脚本。先来看看我写的ActionFixtureCodePackageQUERY;publicclassStudentFixtureextendsFixture{privateintstudent;先要在！Path中声明我们的Fixture的类路径，不要包括包在内2.先声明是ActionFixture表示要启动那个Fixture是要invoke一个void，且不带参数的函数是要invoke一个带有参数的，void的函数就是对于一个有返回值的函数进行期望值的比较这样在这个case中，我们先初始化环境，然后给学生人数加1，然后再统计人数看看是不是返回了1.这样一个简单的Action的case就写好了Fitnesse之框架介绍（一）上一篇/下一篇2011-09-0209:55:11查看(29)/评论(0)/评分(0/0)Fitnesse是一款开源的验收测试框架，完全有java语言编写完成，支持多语言软件产品的测试，包括（java,c,c++,python,php）等等，本人使用这款框架已长达两年之久，目前在公司测试及开发团队中推广使用fitnesse进行接口测试。关于接口测试的重要性及定义可以参考本人写的前面的博文《关于接口测试》，再此系列中将着重介绍fitnesse框架以及fitnesse在接口测试以及持续集成中的使用，系列第一篇将介绍fitnesse整体架构。在fitnesse框架中，总共包括三个部分，wiki，testsystem，fixtures.其中wiki部分将展现具体的testcase以及testsuite，testsystem包括两部分slim,fit,也就是fitnesse的执行引擎,fixtures也就是真正的测试代码。具体见下图所示：从上图大家可以看到，在wikipages上描述的将是关于业务或者其他逻辑的测试用例，fitnesse将会根据你所选择的testrunners(slim或者fit)来解析wikipages所传送过来的testcases,假如我们选择了slim作为我们的testrunner,那么解下去，slim将会把网络传输过来的wiki脚本解析为一系列的指令，然后slim执行器将会根据这些指令来调用我们所编写的测试代码也就是fixtures，fixtures可以是java测试代码，c测试代码或者其他语言编写的测试代码，这些测试代码将会根据你所调用的被测对象来执行你的测试用例。同理当你选择fit作为你的Testrunner的话过程也是一样，只是fit在解析wiki脚本的时候与slim不一样，fit会将wikipage作为html页面，然后通过解析html页面来调用后台的测试代码来执行测试用例，相对于slim性能上较差，fit是比较老的测试引擎，再此我推荐大家使用slim,因为slim会更加的轻量和高效，在过去的两年时间里面我们团队一直使用slim作为testrunner，并且在slim的基础做了很多二次开发和改进，在后续的文章我会继续分享这些成果。大家可能会问，fitnesse教其他框架有什么优势，本人把fitnesse和junit,testng做了一些简单的比较，fitnesse最大的优点是完全将业务逻辑（测试用例）和测试代码进行分离，功能测试人员负责在wiki上编写测试用例，测试开发工程师负责编写测试代码，这不但利用测试用例和测试代码的维护和管理，也促进了测试人员和开发人之间的沟通，使整个软件开发和测试变得更加敏捷（后面的文章将介绍fitnesse在敏捷测试中的使用），先对于junit每写一个testcase都要增加一定量的测试代码，fitnesse大大降低了冗余的测试代码，因为fitnesse可以进行参数化，相对于testng的xml参数化，fitnesse的参数更加的人性且便于操作（后续文章将推出fitnessewiki语法）。这一系列优点使fitnesse可以适用与各个级别的测试，可以在单元测试，集成测试，验收测试中使用，也可以用于白盒测试和灰盒测试。此外fitnesse是一款开源的软件，有很多东西可以根据我们自身的应用进行定制，如增加参数类型，分布式测试等等，后续文章都将进行分享，敬请期待。Fitnesse之框架介绍（二）上一篇/下一篇2011-09-0521:03:04查看(11)/评论(0)/评分(0/0)本篇将重点介绍Fitnesse测试引擎slim,slim是（simplelistInvocationmethod）的缩写，使用来代替的fit的测试引擎，不同于fit的是，slim将html的解析，比较以及颜色的改变都放在了fitnesse上面去完成，而不是像fit一样放在被测系统这一端去完成，slim是一个自定义的协议，是一个准RPC协议，通过此协议fitnesse可以驱动被测系统的方法。下图是slim源码的结构其中核心的包是此包为slim协议的核心,此包为slim中变量参数转换器以及此包为slim中表格类型。如果我们要使用slim作为测试引擎，那么必须在wiki页面上定义测试类型!defineTEST_SYSTEM{slim}slim本身总共包括10种表格类型，首先介绍decisiontable:我们经常使用decisiontable作为一个真假表该测试用例对应的测试代码如下所示：publicclassShouldIBuyMilk{privateintdollars;privateintpints;privatebooleancreditCard;publicvoidsetCashInWallet(intdollars){=dollars;}publicvoidsetPintsOfMilkRemaining(intpints){=pints;}publicvoidsetCreditCard(Stringvalid){creditCard=yes.equals(valid);}publicStringgoToStore(){(pints==0&&(dollars2||creditCard))yes:no;}首先看表格的第一行shouldIbuymilk对应测试代码ShouldIBuyMilk测试类，再看表格第二行第一列cashinwallet对应测试代码setCashInWallet方法,第二列creditcard对应测试代码setCreditCard，以此类推后面几列，我们看到最后一列有点比前面几列多了一个号，这个问号表示最后一列是一个方法，也就是我们需要得到的结果，前面几列表示参数，所以他们需要在测试代码中加上set。从表格的第三行开始就是我们的测试用例参数，总共8个测试用例在一张decision表格中就全部描述完成，当我们点击Test按钮就可以得到以下结果：我们可以看到从第三行开始绿色的表示通过的case,红色的表示失败的case并且会有实际值显示出来，这样我们在一次执行中就完成了8个case的执行。下一节中我会重点剖析decision表格的源码结构。浅谈Fitnesse框架（四）上一篇/下一篇2009-10-2722:01:07/个人分类：API测试框架查看(408)/评论(1)/评分(0/0)Fitnesse已经使用了一段时间了，对Fitnesse也有了一定的了解。正好最近项目开始空了，所以在这里做一个总结。也许处于项目的开发模式的原因，我们对于Fitnesse的使用似乎并没有体现出Fitnesse的加强沟通的左右。对于我们这种传统的瀑布模型的开发方式来说，Fitnesse似乎只是变成了一个自动化测试框架。根据Fitnesse官方的说法，Fitnesse是更多的适用于TDD（测试驱动开发）的发展模式。在我看来Fitnesse也更加适合Agile敏捷开发的模式。因为对于敏捷开发而言，我们需要更多的是沟通，Fitnesse的Wiki可以成为一个非常好的沟通的媒介。但是我们也需要思考一个问题，我们如何在敏捷开发中真正的去实施Fitnesse呢首先的一个问题就是分工，对于Fitnesse而言是由两部分组成，一部分是Wiki，一部分是Fixture。两者看似不同的却有着非常紧密的联系。那么这两个部分是应该都有测试工程师来负责，还是说可以让BA，也就是产品人员更多的加入呢。我个人觉得其实应该让产品人员更多的参与到Wiki的编写中去。因为相对于Fixture而言，Wiki的语法相对比较简单，而且Fixture也是基于Wiki来构建的，所以可以说先确定了Wiki，再去写Fixture。相信这个也是Fitnesse本身的初衷吧。Fitnesse的Wiki脚本在使用中也存在很多弊端，比如说它的语法结构相对来说比较麻烦，起码没有一个自动纠错机制，而且对于错误的处理也很不清楚。一个最简单的例子。我们在工作中发现Fixture中我们引用了很多第三方的包，但是在运行Wiki脚本的时候，我们发现总是提示我们没有找到Fixture，但是我们对于Fixture的配置一直是正确的。最后我们发现，是因为在Wiki脚本里面没有引用正确的第三方的包。Fitnesse本身对于测试的管理没有任何作用。对于一个理想的测试框架，我们希望他可以和管理工作相结合。但是目前我们的fitnesse只是提供了一个脚本的管理和一个执行的工作。相对于测试项目的管理没有一个机制。在我看来，其实Fitnesse如果可以加上一个对于测试版本的管理的模块，应该是锦上添花的啊。先说这点，对fitnesse还是有很多的感想和大家分享从Fitnesse中学习Java单元测试发布时间:2011-7-2611:05作者:邵育亮来源:51Testing软件测试网原创字体:小中大|上一篇下一篇|打印|我要投稿|推荐标签：软件测试单元测试从第一次知道Fitnesse这个集成测试工具到现在也已经差不多有2年多的时间了。在这个期间把Fitnesse的源码也算是反反复复阅读了很多遍，算是对其实现的原理和方法有所了解。在最近一次对Fitnesse最新版本代码的研究中我发现，Fitnesse除了是一个很好的开源集成测试框架之外，它的源代码还是一个非常好的实施Java单元测试的例好