常见的接口测试工具有哪些(web接口测试工具有哪些)

1、CTS，CTS 测试基于Android instrumentation 测试， 其又基于JUnit 测试。说白了， CTS 就是一堆单元测试用例。这也是Java 语言的擅长部分。 2、 Monkey工具，Monkey是Android中的一个命令行工具，可以运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试。Monkey测试是一种为了测试软件的稳定性、健壮性的快速有效的方法。3、ASE，ASE 意思为Android 脚本环境， 即我们可以通过脚本（比如Python）调用Android 的功能，从而定制一些测试。比如打电话，发短信，浏览网页，等。我们可以扩充它的API（Java 部分）, 并用python 脚本调用这些API, 从而实现丰富的测试功能。用于API 部分可以访问到Android 全部API, python 又能灵活部署测试，所以ASE 的扩展性非常好。4、Robotium，该工具用于黑盒的自动化测试。可以在有源码或者只有APK 的情况下对目标应用进行测试。Robotimu 提供了模仿用户操作行为的API，比如在某个控件上点击，输入Text等等。http://mag.big-bit.com/分层的自动化测试这个概念最近曝光度比较高，传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。相信测试同学对上面的金字塔并不陌生，这不就是对产品开发不同阶段所对应的测试么！我们需要规范的来做单元测试同样需要相应的单元测试框架，如java的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，几乎所有的主流语言，都会有其对应的单元测试框架。集成、接口测试对于不少测试新手来说不太容易理解，单元测试关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；那么集成、接口测试关注的一是个函数、类（方法）所提供的接口是否可靠。例如，我定义一个add()函数用于计算两个参数的结果并返回，那么我需要调用add()并传参，并比较返回值是否两个参数相加。当然，接口测试也可以是url的形式进行传递。例如，我们通过get方式向服务器发送请求，那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口，需要通过soapUI 等工具对其进行测试。UI层的自动化测试，这个大家应该再熟悉不过了，大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具非常多，比较主流的是QTP，Robot Framework、watir、selenium 等。为什么要画成一个金字塔形，则不是长方形 或倒三角形呢？ 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是UI层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。既然UI层的自动化测试这么劳民伤财，那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力，所以，我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。在自动化测试中最怕的是变化，因为变化的直接结果就是导致测试用例的运行失败，那么就需要对自动化脚本进行维护；如何控制失败，降低维护成本对自化的成败至关重要。反过来讲，一份永远都运行成功的自动化测试用例是没有价值。 至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书，对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试。
接口自动化： 如果是那种http协议的接口那么第一种，使用eclipse 自己封装下httpclient ，然后自己写java脚本进行接口测试 这种要麻烦点 第二种，使用jmeter工具，这个是专门针对http接口的进行性能以及接口测试工具
接口测试工具有jmeter、soapui、postman，工具有很多，不过你要懂底层的原理，懂原理换任何一个工具都OK，不懂的可以看下百度阅读《接口测试最佳实践》这本电子书，上面有很多案例

前后端经常会存在接口对接，为减少相互间的强依赖，双方能并行开发。接口的模拟测试就显得尤为关键。一些对外的接口，外部环境往往不可控，在开发、测试阶段为了减少其影响，通过接口模拟测试能减少很多不必要的麻烦。本文将介绍一款轻量级的java mock server工具，解决以上的常见问题。moco是一个java实现，轻量级的，开源的接口模拟测试工具，可以通过jar独立部署。简单json配置，即可实现接口的请求响应接口模拟。官方地址：下载官方Standalone Moco Runner文件到本地。下载完成对应目录下可以moco-runner-0.12.0-standalone.jar文件对应目录下新增foo.json文件以下内容。以上定义了全局接口的返回信息。以下命令运行moco server访问http://localhost:12306 ，将看到"Hello, Moco"返回信息。以上就完成了moco server的接口完整测试。是不是很easy。接下来我们再看看，比较常用的http restful的配置方式。一个项目往往有很多接口，moco的include属性支持多个配置文件的引用，通过不同文件的配置实现接口的分组定义，更便于接口管理维护。首先定义一个全局配置文件globalconfig.json（名称可以任意取）上面使用include属性，引入相关子文件定义。注意：若使用include的文件定义，在启动moco server的时候，配置文件前的启动参数是-g，而不是一开始介绍的-c参数，否则启动将包include字段识别错误。openApi.json文件内容如下上面定义了接口测试1、接口测试2两个接口。每个接口可以配置他的request和response信息。在接口测试时，必须request选项满足时，对应response才返回。更多属性配置可参见官方文档。另外moco server对配置文件的变更是实时检测的，以下控制界面可见openApi.json发生的change变更。这在测试联调时特别方便，一种返回case测试完后想改返回值，只需变更响应配置文件，无需来回重启moco server。通过使用moco server，是否感觉特别得简单、实用、高效？喜欢的coder们赶快使用起来吧！提高效率，珍惜生命！

曾经有一段时间，人们习惯于在MS Excel里面编写单元测试用例，然后开发人员就按照单元测试用例一步一步的来实现用例。这通常是很耗时的漫长的过程，尤其是如果应用很大或者UI很复杂的话。　　这一套单元测试的执行过程常常成为瓶颈，因为任何代码修改都会带来手工执行大量单元测试，以确保新的修改没有破坏原有功能。 　　如今是个快节奏时代，人们希望工作能够无需人工介入、自动化的快速完成。每个人都喜欢执行一个命令就能把工作搞定，而且在执行期间不需要人工介入。需要做的仅仅是检查一下最终的输出结果。　　当这个世界正在迈向自动化时，自动化测试也不甘落后，不论是在功能测试方面还是UI测试方面。每天我们都能听说自动化测试方面涌现出的新软件。　　本文提供了一些信息给那些想用Coded UI自动测试框架来进行应用界面自动化的.Net开发者。 　　什么是Coded UI 　　最近我一直在寻找一个自动化的用户接口测试的解决方案。用户接口测试需要用户多次进行手工输入操作，这是一个既枯燥又费时的过程。因此，我想寻找一种更智能的自动化UI测试的方案，这种UI测试在不需要人工干预下，能够被保存，记录并提供支持 ，快速测试代码的改变。　　Coded UI 采用用户接口来驱动应用的进行自动化测试。这些测试包括UI控制的功能性测试。他们使你可以验证整个应用的功能是否正确，其中包括了用户接口。Coded UI尤其适合用于用户接口中存在校验或者其它的登录方式的测试，比如网页。Coded UI也可以用于人工测试用例的自动化。 　　Coded UI 测试帮助用户测试应用程序的用户接口。这些测试允许用户验证应用程序的功能。Coded UI 多数时间用于帮助验证在UI层本身的有效逻辑。它能够验证值对用户接口的控制的正确性。　　其它方案　　市场有许多自动化用户接口的方案，比如HP的QuickTest Professional, IBM Rational Functional Tester. 其它著名的，易于使用的开源工具解决用户接口自动化问题的有Selenium，也能够记录测试，需要的时候回放。市场上还有来自Microsoft的也能不需要太多努力做同样的事。用Visual Studio Microsoft还有Coded UI的方案用于单元测试。 　　Coded UI适合在哪儿用 　　大多数安装了Visual Studio的开发者都喜欢在Visual Studio的环境里进行单元测试，而不是使用第三方工具。由微软提供的Coded UI，在Visual Studio环境里可谓上手即用。在开发者的机器上无需另外安装任何东西。一旦你安装了Visual Studio的Premium版或者Ultimate版，你就同时也安装好了Coded UI。　　Coded UI可用性 　　为了使用Coded UI，需要安装Visual Studio 2010/2012/2013的Premium版或者Ultimate版。 　　Coded UI 测试的组成　　Coded UI 测试的组成容易理解。它可分成下列文件：　　UIMap.uitest 　　这个文件是UIMap类的XML表示。UIMap类包括视窗，控件，属性，方法，断言和动作。　　UIMap.cs 　　对UIMap的自定义部分都存在这文件里。如果修改直接存在UIMap.designer.vb文件的话，那些修改都会在记录结束后丢失，因为这个文件重新创建e5a48de588b6e79fa5e9819331333339663264了。　　给每个在测应用程序中的每个模块创建一个独立的UIMap文件。　　UIMap.Designer.cs 　　这是部分类表达各种类。这各种类是给多样的控件和他们的范围，属性，方法的类。　　提示：不要直接修改 UIMap.Designer.cs。加入你这样做，这个修改会被覆盖掉。　　CodedUITest.cs 　　这类表示的实际的CodeUI测试类，方法调用，和断言调用，所有的方法和断言默认都是从UIMap.Designer.cs文件调用的。这类有具有【codedUITest]属性TestClass和包含具有【TestMethod]属性的多种方法。 　　Coded UI的特性/好处 　　进行用户界面测试的同时进行校验. 　　生成VB.Net/C#代码. 　　测试用例可以被记录和重放. 　　集成了ALM Story 　　能够作为每日构建的一部分来运行. 　　根据需要进行高级扩展. 　　和Visual Studio集成在一起，所以无需单独购买许可. 　　Coded UI对Web和Windows应用同样适用. 　　著名的Microsoft支持. 　　创建Coded UI测试 　　Coded UI测试可以用下列方式创建　　使用MTM进行快速自动构建　　从现有的记录(从手动测试中记录下来的操作)中创建Coded UI 　　在Coded UI Test Builder创建的底稿的基础上创建一个新的Coded UI测试. 　　自己写Coded UI. 　　这个白皮书的范围仅限于“在Coded UI Test Builder创建的底稿之上创建一个新的Coded UI测试”。　　小贴士: 尽量使用Coded UI Test Builder。　　Coded UI Test Builder 　　每一个Coded UI测试的生成都需要遵从下列步骤. 　　记录/停止/暂停　　编辑记录下来的步骤　　添加断言　　生成代码　　创建Coded UI 测试 　　创建新的Coded UI 项目　　要开始使用Coded UI，首先我们需要创建一个测试项目，用来保存所有Coded UI测试。创建一个新的Coded UI项目包含下列步骤　　打开Visual Studio 2012 　　选择 File > New > Project 　　选择需要的语言模板 (C# or VB.Net). 我们选择了C#. 　　选择Coded UI Project 　　输入一个名字　　点击 OK 按钮 　　添加 Coded UI 测试　　Visual Studio默认配置为创建Coded UI 测试使用 "Generate a new Coded UI Test from scratch using Coded UI Test Builder" 　　提示：在测试的应用程序中，当你创建UI控件时尽量使用有意义的名称，从而对于自动生成的控件显得更加有意义和可用。　　一旦 Coded UI 测试工程创建完成，将会自动打开生成Coded UI 测试代码的对话框，请给出以下选项的设置。　　记录操作，编辑UI地图或添加断言　　使用一个已经存在的操作记录　　默认情况下 选择记录操作,编辑UI地图或添加断言，无需做任何操作，然后点击 "ok" 　　Coded UI Test Builder 　　选择了上述选项后，Coded UI Test Builder就会被打开，同时Visual Studio窗口被最小化。这意味着我们已经为记录操作做好了准备。　　正如之前描述的，Coded UI Test Builder基于下列4个操作来做记录　　Record Steps 　　Update or Delete Steps 　　Verify Results (Add Assertions) 　　Generate Code 　　小贴士: 如果用户界面(UI)变化了，就重新记录测试方法或断言方法，或者重新记录一个既有测试方法中受影响的部分。　　记录一个序列的操作. 　　记录一个操作主要需要下列几步. 　　Start Recording, 通过选择Record按钮即可. 　　Pause Recording, 用来处理记录过程中的其它操作，即Generate Code. 　　Edit/Delete 操作, 以防错误的操作被记录。　　Generate code为记录下来的操作创建编号。会给每一个记录下来的操作都生成编号。　　Add Assertions 用来校验结果。　　小贴士: 创建断言最好使用Coded UI Test Builder，因为它会在UIMap.Designer.cs文件中自动添加一个断言方法。 　　为记录动作做计划　　任何事情的成功都取决于它计划得有多好。较好地计划最大限度保证了任务成功完成。这样总是比较好，在开始记录动作之前，我们计划好所有的所有要计划的步骤。　　这里我们将要使用应用程序Windows计算器来记录步骤。我们要自动地加和减两个数字。在记录加和减两个数字的时候，下面的步骤将会用到。　　。点击“开始记录”控件　　。到开始，点击执行　　。在执行窗口，输入”calc" 　　。停止记录，看记录的步骤　　。删除错误的步骤（存在的话）　　。产生代码；提供和动作相匹配的名字。比如，打开计算器。　　提示：当你产生一个方法时候，使用一个有意义的方法的名字，代替默认名字。　　有意义的名字帮助识别方法的木的。　　。重新记录，提供第一个数字，暂停记录产生代码　　。重新记录，提供操作（加或者减），暂停记录，产生代码　　。重新记录，提供第二个数字，暂停记录，产生代码。　　。加断言　　提示： 产生你的测试作为一系列记录的方法　　提示： 可以的时候，限制每个方法小于10个动作。这模块化的方法让UI改变时候容易替换方法。 　　我们已经看到了Coded UI可以使开发者的生活变得多么轻松，尤其是遇到每次都需要进行很多输入的复杂页面的时候。这时，测试用例只需要被记录一次，就可以按照需要执行任意多次。使用Coded UI比使用其它工具的好处是，它能自动适配Web页面和Windows窗口应用。Coded UI测试可以用Visual Studio 2010来运行，也可以用任何版本的VS来运行，它们的功能正变得越来越强大。无需多说，Coded UI是一个由技术领导者提供的强大工具，想要体验Coded UI测试的强大，我们应该开始在项目中使用它看看它能带来多少ROI，我确信Coded UI不会让你失望。

Apifox官网 但是, 他们也有区别我想这个工具吸引我的可能有以下几点: postman还是最合适的工具

接口测试的工具很多，比如 postman、RESTClient、jmeter、loadrunner、SoapUI等，本人首推的测试工具是postman和jmeter。
程序员接口测试软件，推荐这款免费软件，跨平台非常好用