如何做接口测试

如何做好接口测试？发布时间:2012-1-1910:44作者:小刀来源:51Testing软件测试论坛字体:小中大|上一篇下一篇|打印|我要投稿|推荐标签：软件测试接口测试sgbtmy：基于selenium的自动化框架开发，我主要是想问一下，你的框架除了前台的自动化，后台的数据的测试是否集成在你的测试框架中？小刀：你好，个人理解的你所说的后台的数据的测试是指的是对数据的校验，不知理解的是否正确，那么根据这个理解，我的解释是，在我们框架中，增加了很多的功能方法用来帮助进行自动化脚本的编写和结果校验，其中就包括后台数据校验方法，当我们的测试用例需要在后台进行数据校验的时候，调用这些数据校验方法即可。相当于是，前台页面操作的自动化是封装selenium的方法去操作页面，而对后台数据的校验是通过增加功能方法来实现的，可以理解为不同的两部分，但是在编写测试脚本的似乎，根据测试用例的设计，这两部分都可以拿过来使用。不知道是否解答了你的疑问，如果没有，请你指出，谢谢你。tjy688：你们做接口测试的流程一般是怎么样的？小刀：接口测试的流程其实和功能测试的流程类似，因为接口测试依赖的主要对象也是需求说明书，所以，最初的流程就是参与需求讨论，评审需求。需求确定以后，开发会根据需求进行接口设计，会产出接口定义，在开发设计过程中，有能力的话，可以给出一些针对设计的建议，提高可测性，针对需求及设计，进行测试计划，测试设计，然后还需要和配管确定测试环境相关的事情。在开发完成接口定义之后，就根据需求文档及接口定义进行测试用例设计，测试用例设计主要从业务场景，功能，以及异常测试几个方面考虑。测试用例设计完成后，针对测试用例进行评审，然后，如果开发代码部分可测时，即可进入测试了，因为是部分可测，可能会使用到mock方法。已有测试代码时，就要进行测试代码的持续集成了，我们是使用hudson来进行持续集成的在项目结束后，会对每个项目进行总结。如果有问题，请指出，我们一起讨论。xinhuayw：我想了解一下你们现在是怎样保证项目测试用例的重复运行的。小刀：对于接口测试来说，项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的，也就是说，每一个测试用例的运行除了依赖被测对象和对应的数据库环境外，是不依赖于其他任何测试用例的，并且这个测试用例执行完毕后，对系统来说，也是没有任何痕迹的，这样就保证了每个测试用例运行时，都在一个干净的环境中运行。要实现测试用例的独立性，就必须对被测系统的设计有详细的了解，这样，不会出现测试用例执行后遗漏数据，环境未改变，另外，还需要对测试用例进行详细的设计。另外，要保证测试用例的重复使用，还需要做到测试用例的及时更新，在这个方面，我们是做接口测试的人会维护对应的系统的接口测试用例，要保证，代码每次更新，测试用例都必须全部执行通过。csun888：什么是接口测试，基础知识什么的讲讲吧！小刀：你好，接口可以分下面几种1、系统与系统之间的调用，比如银行会提供接口供电子商务网站调用，或者说，支付宝会提供接口给淘宝调用2、上层服务对下层服务的调用，比如service层会调用DAO层的接口，而应用层又会调用服务层提供的接口，一般会通过3、服务之间的调用，比如注册用户时，会先调用用户查询的服务，查看该用户是否已经注册。而我们所要做的接口测试，先要了解是基于哪一种类型的接口测试，不同类型的接口测试方法可能是不一致的，总体来说，不管是那种类型，我们只要把被测接口当做是服务方，而把我们的测试手段当做是客户方，我们的目的就是，通过我们的测试手段，去验证服务端满足了他声明提供的功能。至于说到具体的测试方法，http协议的接口测试，一般会用jmeter去测试，jmeter的好处是不用写测试代码，直接使用jmeter提供的http请求去测试，也可以使用HTTPClient去测试，好处是可以方便集成和自动化。java接口的测试，则需要编写测试代码去测试，有点类似于单元测试，但是需要更多的考虑业务场景。gulun：接口测试的数据准备，应该怎么做呢？小刀：接口测试的数据准备，可以从下面几个方面去考虑：1、如果是只测试一次的接口，可以使用硬编码的方式准备测试数据，在写测试代码的时候，使用到什么数据就写什么数据，为了避免数据重复，可能比较多的会用到随机字符或随机数2、可以直接通过调用其他API的方式准备测试数据，这种情况在测试最上层服务的时候比较有用，比如测试团购购买服务，就需要准备要购买的团购数据，购买团购的用户数据，这个时候，可以直接调用生产团购的api和生成用户的api直接生成测试数据3、使用excel或xml准备测试数据，这种准备测试数据的方式，主要针对对象数据的准备，比如可以将一条团购数据对应excel中的一条数据，因为一般开发都会使用pojo映射，而在准备测试数据的时候，这些pojo对象属性的设置往往是重复和大工作量的，用excel或XML方式准备，则可以减少在代码当中重复去准备这些数据。4、也可以使用工具方法的形式去准备测试数据，通过在代码中写工具方法去实现数据生成，而在测试代码中调用工具方法去得到所需数据。水生哥哥：你好，我想问一下：接口测试怎么设计测试用例呢？小刀：你好，我觉得接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的，而接口测试所依赖的也是需求说明书，但是，因为接口测试毕竟是通过代码去测试代码，所以，为了保证覆盖率，可能会使用到单元测试的方法，具体的测试用例设计，我考虑的如下，请参考，如果有错误，一起讨论。输入参数测试：针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长；功能测试：接口是否满足了所提供的功能，相当于是正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；异常情况测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何的异常都进行处理。永远的测试者：才开始测试，对接口测试感兴趣，可是，当前的能力又无法进行接口测试，怎么样才能进入接口测试呢？小刀：你好，如果要做接口测试，是需要一定的编程能力的，需要学习相对应的开发语言的，然后还需要学习开发所使用的一些框架，比如ibatis，spring等，对数据库的操作也需要了解一些，还有eclipse操作，这些内容并不需要了解的多么深入，如果只是一般的做做接口测试，这些能够使用就可以了，当然，要做好接口测试，就另当别论了。我不知道你当前是什么样的能力，所以，我的建议就是，1、学习编程语言，基础的语法，循环，条件等2、学习项目工程管理及开发框架：eclipse，maven，svn，ibatis，spring等3、学习Xunit4、自己尝试去写测试代码其实，上面的过程除了第一步是必须具备的意外，其他的都可以一边写测试代码，一边学习，最好的办法就是看开发写的代码，并且，请开发写一个正常的测试代码，然后照着开发的测试代码去模仿。iTest99：你认为接口测试由开发团队做好还是测试团队好？各有什么优势和弱点？小刀：我觉得，还是要区分一下单元测试和接口测试，单元测试一般来说，是针对具体的代码逻辑进行测试，尽量减少这些功能单元集成起来出错的可能性，一般是由开发人员来完成，而接口测试，更注重从用户的角度设计用例，更偏向于功能测试，单元测试设计测试用例的时候，可能更多的考虑是代码覆，而接口测试，则需要更多的考虑业务覆盖。单元测试由开发人员来做，可以保证从代码角度来看是没有问题的，但服务保证业务角度来看也是没有问题的，而接口测试，则通过业务的角度去设计测试用例，其实，也可以说是从更早的时候，以功能测试的方法，先保证项目的流程及功能是正常的，而不至于在页面开发完成后，又修改主要功能代码，导致项目赶工及一系列的重写。所以，我觉得，单元测试由开发人员来做，接口测试由测试人员来做。至于你说的学习接口的成本，我觉得这个成本并不高，原因是：1、接口测试的用例也是依赖需求文档的，并不是根据开发代码去设计2、接口测试的用例可以在功能测试中复用。3、接口测试看似增加测试时间，实则不然，因为，接口测试会更早的发现bug，而使得修改bug的成本更低，接口测试会减少功能测试的时间，应该接口测试会确保主要流程功能的正确性，接口测试更容易实现持续集成，从而减少回归测试的次数。txTester11：我想请问：接口测试盒单元测试有什么区别？接口测试和白盒测试又有什么区别？小刀：单元测试是针对具体的代码逻辑进行测试，主要测试被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list中去，然后确认该值出现在list的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。尽量减少这些功能单元集成起来出错的可能性，单元测试一般是由开发人员自己去完成，单元测试可能不会考虑业务是如何的，会更多的考虑，我这个单元模块逻辑是否正确。接口测试指的是针对程序内部的或者外部的接口进行的测试，一个接口方法可能会包含多个单元模块，而且，一个接口会有自己特定的业务定义，所以，做接口测试的时候，更多的需要从业务的角度去考虑如何测试这个接口。不管是接口测试还是单元测试，其实都属于白盒测试的一个阶段，白盒测试具体的方法有很多种，比如代码审查，比如代码覆盖。