使用Fitnesse进行接口自动化测试
使用Fitnesse进行接口自动化测试
随着云计算以及SOA以及敏捷软件开发的热火朝天，对于测试工程师的要求也渐渐增加。目前很多公司特别是互联网公司都已经开展接口测试这样的工作，随着web架构的日趋复杂，接口的种类也多种多样，有http,webservice,hessian,dao,message以及简单的api接口，那么如何设计或者选择一款测试框架来完成对这些接口的测试成为了一个很大的挑战。本文将简单介绍一款由java开发的开源测试框架Fitnesse在接口测试方面的使用，并且列举一些简单的demo来进行演示和说明。
&&&& FitNesse是一个轻量级的开源框架，能够帮助开发和测试团队方便的定义接口验收测试（Acceptance Tests）。Fitnesse支持多语言软件产品的测试，包括（java,c,c++,python,php）等等。具体使用可参考：http://www.fitnesse.org/.FitNesse.UserGuide，因为关于Fitnesse工具的介绍不是本文的主要意图。在Fitnesse框架中，总共包括三个部分，Wiki，Test system，Fixtures。其中Wiki部分将展现具体的Test case以及Test suite甚至是Test Requirement，Test system包括两部分Slim，Fit，也就是Fitnesse的执行引擎，Fixtures也就是真正的测试代码。Fitnesse具体架构图如下所示：
&&& 从上图大家可以看到，在Wiki pages上描述的是关于业务逻辑的测试用例，Fitnesse将会根据你所选择的Test System(slim或者fit)来解析Wiki pages所传送过来的Test cases, 假如我们选择了slim作为我们的test system，那么slim runners将会把网络传输过来的Wiki 脚本转换为一系列的指令，然后slim executer将会解析并执行这些指令来调用我们所编写的测试代码也就是Fixtures code，fixtures可以是java语言测试代码，C语言测试代码或者其他语言编写的测试代码，测试代码将会调用被测对象来执行测试用例。同理当你选择fit作为Test runner的话过程也是一样，只是fit在解析wiki脚本的时候与slim不一样，fit会将wiki page作为html页面，然后通过解析html页面来调用后台的测试代码来执行测试用例，相对于slim性能上较差。另外在使用fit的时候设计测试代码也必须继承fit的类来进行编写，相对slim测试代码编写相对受限。因此我推荐大家使用slim，因为slim会更加的轻量和高效，在过去的两年时间里面我们团队一直使用slim作为test runner，并且在slim的基础做了很多二次开发和改进，相对来说比较稳定。
&&& 我们可以使用Fitnesse做单元测试，集成测试，接口测试等相关测试。本文重点介绍Fitnesse在接口集成测试方面的使用，废话少说，下面上主菜，在下面的例子中，将利用Fitnesse slim 做TestRunner，进行Java环境下的接口测试。
Http接口测试
可以利用第三方工具httpClient.jar编写http接口客户端发送Request.在此我们做一个简单的http接口测试，如对infoq登录接口进行测试。
首先编写测试代码如下：
1. 发送Post请求：
(1) 设置请求参数
该方法有两个参数第一个参数为Map类型表示请求表单参数，第二个参数用来表示表单参数的个数，其中parameters为NameValuePair数组，并设为全局变量。
(2) 发送请求
该方法参数为请求URL，postResponse为服务端返回值。
(3) 检验返回值
当然这里的postResponse可能要根据业务需求的检查点来做一些具体的解析，在本用例中不做详细的解析。
接下去用Fitnesse来设计测试用例并执行测试：
(1) 设置表格环境变量，指定使用slim作为Testsystem，并且定义classpath，便于fitnesse能够驱动测试代码执行用例。
(2) 定义测试数据，如提交的表单数据用户名和密码，我们是用来测试infoq的登录功能。
(3) 定义预期输出值，在登录infoq成功之后，服务器返回参数中会返回”ok”字符串，该测试用例就是用来描述是否登录成功的scenario。
点击Test按钮执行该case结果如下所示：
该用例有一个检查点，也就是调用checkPostResponse方法的时候输入预期值ok，该方法检查返回字符串的时候找到该字符串，因此测试用例通过，测试用例pass,因此执行结果为绿色。
只需要更改参数就可以设计其他测试用例，组成infoq登录功能的测试集。
该节主要介绍fitnesse对http接口类型的测试。
Webservice接口自动化测试
目前大多数互联网公司都采用SOA架构，因此对于webservice接口类型的测试显得更加重要。通常测试工程师可能会借助SoapUI等工具进行web service的测试，不可否认SoapUI在进行单一webservice接口测试中具有非常好的效果，但是在接口组合测试，以及在测试结果需要进行数据库校验的情况下就显得不是那么的自动化，总是需要人工干预，这在一定程度上导致测试效率偏低，因此我们在这里介绍如何使用Fitnesse这块开源产品实现接口测试自动化。
首先我们简单的搭建了一个WebService demo.
该webservice接口总共包括4个方法，我们要测试一下addUserToTheWorld和getUserFromTheWorld这两个方法组成的一个Scenario。
首先，设计测试代码，思路和http接口测试一样，设计webservice client端发送请求，利用spring和cxf设计webservice client端，当然也可以通过cxf或者axis自带客户端生成工具产生客户端代码，但是还是建议自己动手写客户端，这样可以使代码简单清晰。
Spring context配置如下：
客户端测试代码如下所示：
我们再来看在Fitnesse中如何设计case描述上述代码：
测试用例描述如下所示：
上图中的用例描述为调用testAddUserToTheWorld方法将用户加入数据库，然后调用testGetUserFromTheWorld从数据库中取出相关数据，这样就作为一个组合场景调用了webservice的addUserToTheWorld和getUserFromTheWorld这两个方法，当然还可以设计更多的场景来测试，如果用soupUI的话起码得做两次操作，如果有数据库检查的需要的话可能需要3次操作，不便于做自动化。接下去我们看一下该用例执行结果。
执行结果如上图所示测试执行通过。我们再来看一下用例失败的场景：
我们将预期输出结果的Age的值改为了27，测试用例执行失败，与实际结果不符合。
Database校验测试
我们再来讨论一下数据库校验测试，开源社区已经有很多相关的数据库测试工具如Dbunit等等，以及Fitnesse/Fit测试引擎的DBFit都是很优秀的工具，笔者根据DBFit的功能设计了Fitnesse/slim测试引擎的DBSlim,来方便对数据库测试的操作。
DBSlim目前有增删改查的功能，支持对oracle、mysql、sqlserver的操作，源码已上传google.code开源，具体在Fitnesse中的使用场景如下所示：
使用dbslim首先要设置相关环境变量，由于是使用maven做代码的管理，因此使用的时候需要配置好如上图的dependency。上图中有三个Wiki table，第一个table表示所引用的包名，第二个表格是用来连接数据库，我们使用的mysql所以就调用ConnectToMysql方法，依次配置好数据库url和端口号，数据库名称，用户名和密码。第三个表格是对fitnesse的query表格做了一些改进，用来做数据库的查询工作，Query:Query是Query表格的书写方法，第一个Query表示是查询表格的关键字，第二个Query是指调用Dbslim中的Query类，后面的参数为要查询的sql。表格的第二行表示要查询的字段和sql中查询字段一一对应，第三行表示期望值，由此组成了一个数据库查询操作的场景。关于Fitnesse中表格的使用方法同样可以参考Fitnesse官方的User guide。我们看一下执行结果：
本文再此只介绍查询操作，其他操作不再一一介绍。
本文主要介绍Fitnesse在接口测试以及集成测试中的使用，从上面的Demo中可以看出，使用Fitnesse做接口测试，有以下几点好处：
1. 测试代码编写简单，风格自由。
2. 测试代码和业务逻辑分离，fitnesse上面只负责业务story的编写，测试代码和业务用例方便维护。
3. 测试代码冗余度大大降低，同一段测试代码可以组成多个业务场景使用。
4. Fitnesse是完全有Java开发的测试框架，跨平台并且便于与其他测试框架的合并，笔者曾经做过Fitnesse与TestNG，Junit以及Selenium的集成。
5. Fitnesse执行方式多种多样，便于后期的持续集成和持续交付，以及敏捷测试，笔者以完成Fitnesse测试报告的解析并且配合Hudson做持续构建。
6. 更重要的是Fitnesse可以用于敏捷测试，这个也是Fitnesse的作者，Uncle Bob的初衷。
目前存在很多开源测试框架，但是如何选择并且设计需要根据公司的业务需求来决定，比如说互联网公司就比较适合使用Fitnesse这样的测试框架来构建自动化测试框架，使得测试设计、执行以及
管理都显得相对简单和清晰，并且对于测试框架的选择最重要的就是要考虑其扩展性，这个便于后期与其他工具和框架的集成，否则我们在后期的工作当中将会遇到想象不到的困难。
发表评论：
TA的最新馆藏[转]&基于标准工具的ECU自动化测试----TestCASE
发布时间： 16:10&&&&
供稿单位：
TestCASE被设计用于进行ECU的自动化测试和验证。多款标准测试工具已经被整合，而且可以一起进行测试。TestCASE用于设计，实现，运行和评估测试。
基于标准工具的ECU自动化测试
TestCASE被设计用于进行ECU的自动化测试和验证。多款标准测试工具已经被整合，而且可以一起进行测试。TestCASE用于设计，实现，运行和评估测试。
用户友好性
友好的用户界面可以使您在不熟悉各种软件和硬件的基础上进行高效的测试。除了开发测试用例，可以通过插件和变量控制工具。客户机/服务器的解决方案可以使您在同一个测试网络环境中控制不同的软件和硬件接口。
测试用例可以被参数化和结构化。由于通用测试描述，测试用例生成几乎是独立于具体测试环境的硬件/软件，因此可以广泛的重复使用。
所有的测试结果都被记录，而且易于分析。出于这个目的，总览被用来快速了解测试结果，可以查看每一个测试的细节。测试报告易于分析，保存和打印用来存档。
支持软件平台
ndSPACE ControlDesk
ndSPACE ControlDesk Failure Simulation
nETAS LabCar Operator
nETAS INCA
nETAS ASCET SD
nMathworks MATLAB/Simulink
nNational Instruments LabVIEW
nSOFTING EDIABAS
nSOFTING DTS7
nVector CANoe/CANalyzer
nVector CANape
支持硬件平台
ndSPACE Real-Time Interface CAN Multi-Message Blockset
nIXXAT CCM
nMicroNova LabVIEW/Simulation Interface Toolkit
nVector CANcardXL
n车载网络的自动化和系统测试
nECU测试在仿真的车辆环境HIL和SIL
n测试预备，即使没有ECU和ECU配置
n支持大多数的测试系统
n可重用性高
n直观的图形用户界面
n通过客户机/服务器方案实现测试环境网络化
n集成支持的颠覆
n易于扩展满足客户特定需求
京公网安备:
电视节目制作证：（京）字第1101号1.&testcase中很多步骤都是在准备测试，反而真正的验证点不多2.很多testcase有重复的步骤&所以，综合起来就是，“我们实现了一些testcase，但这些testcase的覆盖效率和执行效率都不高，即使自动化执行了所有的testcase，我们并没有感到足够的信心“。说实话，对于自动化项目的一个主要实现者来说，这挺让人沮丧的。&但是，仔细想来，这样的反馈并不奇怪。我先描述一下我们自动化开发使用的testcase的base。我们采用的testcase base是QA为而开发的。这种testcase的特点是，多个testcase围绕一个功能点做多方位的覆盖，以尽可能的发现bug。比如针对一个创建用户的功能，用各种输入组合来测试。所以这种testcase base的testcase量是很大的。&Testcase的这种设计思路本身是没有问题的，它非常适合对新功能验证的测试需求。但问题是，这样的testcase适合以regression
test为目的的吗？&一个事实是，QTP开发的自动化的testcase，主要是应用在Regression test中。而regression test的目的是：保证产品的已有的功能没有因为新的代码更改而产生质量问题。Regression& test的目的不是穷尽各种方法去发现这些已有功能的bug，因为这些功能并不是新功能，而是已有的功能，这些功能的全面测试已经在一起的功能验证测试中执行过了。&所以，对于Regression test来说，把所有的功能验证testcase都执行一遍是不经济的，因为执行了十几个testcase，却仅仅测试了一个“功能点”。但不幸的是，大多数我经历的测试组织都是简单把功能验证的testcase作为regression &testcase。其原因是值得思考的。