2107人阅读
接口测试及其自动化
接口测试的依据，往往不是需求文档，而是接口文档。那么，接口文档的准确性便至关重要，本文推荐两种形式的接口文档，供大家参考。接口文档不管以什么形式存在，需要包含的内容有：接口名称接口类型输入参数& & & & & & & & & & & & & &每个参数名；& & & & & & & & & & & & & &每个参数类型；& & & & & & & & & & & & & &每个参数业务含义；& & & & & & & & & & & & & &每个是否可空；& & & & & & & & & & & & & &每个字段长度（可选，一般需要提供，有严格要求的字段需特别注明）；& & & & & & & & & & & & & &每个参数的单位（可选，金额类字段需注明）；d. 输出结果& & & & & & & & & & & & & & 每个参数名；& & & & & & & & & & & & & & 每个参数类型；& & & & & & & & & & & & & & 每个参数业务含义；& & & & & & & & & & & & & & 每个是否可空；& & & & & & & & & & & & & & 每个参数的单位（可选，金额类字段需注明）；& & & & & & & & & & & & & & 返回状态的取值范围及其业务含义。目前接口文档有两种存在形式，下面分别给出实例：文档型：接口名称账户转账接口接口类型:AccountTransferService.transfer请求参数AccountTransferRequest参数分类参数字段参数类型字段长度是否可空单位参数描述公用参数requestModuleString3N　系统统一编号，必须提供，构造函数的方式requestTimeDate　N　请求日期accountRequestNoString32N　外部系统请求账务请求编号extensionLinkedHashMap&String, String&　Y　扩展accountServiceCodeString20N　账务服务编码requestTypeRequestType3N　固定传 APPLY凭证参数merchantIdString50Y　商户号outTradeNoString50Y　商户订单号tradeNoString32Y　交易流水号originalTradeNoString32Y　原交易号tradeTypeTradeTypeEnum5Y　交易类型subTradeTypeSubTradeTypeEnum4Y　交易子类型payMethodPayMethodEnum3Y　支付方式payToolPITypeEnum4Y　支付工具类型tradeMoneyMoney　N分交易金额,必填，如果没有，请保持和payMoney一致。tradeDateDate　Y　交易日期tradeDescString200N　交易说明paymentNoString32Y　支付服务流水payReqTimeDate　Y　支付发起时间payTimeDate　Y　支付成功时间amountMoney　N分支付金额cardTypeCardTypeEnum2Y　卡类型channelTypeChannelTypeEnum6Y　通道类型，手工还是联机fundChannelCodeString32Y　资金渠道编码fundChannelNameString32Y　资金渠道名称instMerchantIdString32Y　资金渠道商户号instOrderNoString32Y　资金渠道流水号instInnerTradeNoString32Y　资金渠道内部交易流水号evidenceExtString1000N　　evidenceDescString128N　凭证摘要接口特定参数payerMemberIdString　N　付款方会员编号payerAccountNoString　N　付款方账户号payeeMemberIdString　N　收款方会员编号payeeAccountNoString　N　收款方账户号响应参数PaymentResult　responseCodeString　N　返回码　responseDescString　N　返回消息描述　accountRequestNoString　N　外部系统请求编号(支付基础服务号)　evidenceNoString　N　记账凭证号　accountingDayString　N　记账会计日Java doc型：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
APP自动化：
测试交流：
访问：145007次
积分：2100
积分：2100
排名：第14913名
原创：63篇
转载：26篇
评论：11条
(3)(7)(3)(2)(11)(17)(2)(1)(9)(6)(10)(9)(3)(1)2226人阅读
原：http://www.blogjava.net/qileilove/archive//400768.html
　　1.1&程序中的接口
　　1.1.1 典型的Web设计架构
　　web是实现了基于网络通信的浏览器客户端与远程服务器进行交互的应用，通常包括两部分：web服务器和web客户端。web客户端的应用有html，JavaScript，ajax，flash等；服务器端的应用非常丰富，比如的servlet，jsp，ssh框架，.net的aspx，还包括其他脚本如php，python。
　　web服务器端的设计架构近年来一直比较流行的是三层架构（3-tier application），通常意义上的三层架构就将业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。分层的目的在于降低代码见耦合，提高代码架构的可维护性。
　　总的来说，这三层架构的意义如下：
　　1）表现层（UI）：用户界面，即用户可见的操作界面或者入口。
　　2）业务逻辑层（BLL）：封装具有业务含义的操作函数。
　　3）数据访问层（DAL）：封装对或者其他存储介质的原子性操作。
　　1.1.2 Web接口的概念
　　web接口是服务器与客户端交互的方式，即浏览器或者其他客户端工具与web服务UI层交互的协议.常见的有两大类，一是浏览器与服务器交互的HTTP协议的接口，另一类web？service接口如soap，rmi，rpc等协议。
　　HTTP接口请求方法常用的有GET、POST两种请求类型。具有无连接无状态的特征。HTTP请求例如GET？/images/logo.gif？HTTP/1.1，表示从/images目录下请求logo.gif这个文件。
　　1.2 WEB接口自动化
　　1.2.1 Web接口
　　web接口测试即站在web服务程序UI层之上的一种手段，是站在用户的角度上测试web服务程序业务逻辑的正确性。测试的重点是围绕web服务暴露的接口检查接口数据的正确性，这个过程是将web服务程序当做黑盒，通过自动化测试技术提高测试执行效率降低人工回归的成本。
　　1.2.2 什么要做
　　下图说明了基于HTTP接口的web应用的整体架构特征，按照这种架构设计开发项目，引发两个问题：
　　第一、系统级测试一定要等到web服务器程序和浏览器端的程序都开发完毕后才能进行吗？参考以下传统的RD与QA合作进行的项目流程，可以看到，QA在RD提测程序后才能真正进入到测试阶段，那么项目的发布周期自然受到这种串行下来的安排影响，是1+1的时间周期。
　　第二、为了提高效率，公司的团队引入了系统级自动化测试的工具或方案，既然是从用户角度去测试，当然要寄希望于从模拟用户行为代替手工操作来进行测试。比如从浏览器操作的方式去测试，能很直接的覆盖用户的一手操作，但是需要思考的是，浏览器各个版本如ie6，7，8，chrome，firefox等，各自有各自特性，JavaScript在浏览器内表现效果又不尽相同，浏览器在不同windows环境下、不同网络条件下运行的状况又不一样，给QA带来一个难题：如何保证浏览器上的自动化case稳定、高效执行？
　　我们先分析第一个问题，项目团队需要提高产品发布效率，提前QA测试介入的时间点，我们可以想到有几种方案：
　　1）QA跟随RD进度，加入到各个层级代码参与：
　　假设我们没有引入TDD模式没有引入，那么常规的解决方式是一批被测函数代码由RD写完之后提交svn，然后QA
update代码后先花十几分钟阅读代码再加上对业务需求的理解然后再花费十几分钟写Xunit case，与QA预期结果一致则好，不一致则需要再花时间与RD沟通原因等等。其一QA花费更多时间，要深入到RD的代码逻辑深处；其二对QA？coding能力要求也很高，这取决于公司QA人员的定位，是要求QA更熟悉测试设计而代码能力次之呢，还是QA的整体技术能力都要很高，一般来讲大多数的QA强项在于业务需求的熟悉和测试设计能力，所以这种方式对团队整体人员素质的要求非常高。
2）QA不参与单测，RD依据需求纵向拆分功能点然后迭代提测，QA能提前一定时间介入测试：
　　对照如下的流程示意图说明这个过程，实际上是传统瀑布模型做了拆分，变为了多个短期的“小瀑布模型”，这样的效果能使得项目周期长的产品，可提前介入测试以提前发现问题。
　　在这样的迭代流程中，如何合理利用自动化手段来提高测试效率呢？一般来讲迭代周期不会很长，常规性的为3~5天一个周期，做太复杂的自动化投入成本较高。对于web系统来讲，为避免过多的自动化投入得不偿失，需要谨慎的判断web系统的特征适合哪种自动化模式。所以这里特别要关注的就是分层自动化测试：
　　如上图所述，web系统可以做几种功能测试：单元测试，集成测试，系统测试。大多数的产品QA不会太多介入单元测试，集中在集成测试和系统测试。结合上面提到的迭代排期，其实在一般项目中上层UI的开发往往比较滞后，赶工的结果也是提测质量不高。所以可推荐的一种模式是迭代周期内按照UI接口划分功能点做排期，UI的开发可以放在UI接口稳定之后提测。所以迭代周期内，面向UI接口的自动化就是一个将测试前置，并且积累自动化case以待回归时代替手工操作的大好机会。
　　就着上面这个结论，再分析一下本节开头抛出的第二个问题：“系统级自动化测试的稳定性与可靠性”，先提出几个观点如下：
　　1）有一些测试点，从系统级角度做自动化的性价比不高：
　　第一：目前技术手段上还不具备低成本的实现手段的，比如flash、js实现的一些效果、不规范HTML标签、对浏览器运行版本环境考虑不周等引发的问题。导致开发成本高，运行的稳定性较低。
　　第二：UI实现逻辑比较薄，比如只是查询DB一个字段然后显示在页面，把重点放在后端逻辑检查上性价比更高。
　　2）系统级测试和集成测试的关注点不同：系统级测试关注的是用户从UI直接操作所能见到的结果，而集成测试关注的是UI接口数据的准确性。比如报表功能，页面上看到的就是一个表格，而对UI接口来讲需要覆盖N种参数组合。
　　上面两点说的是系统级测试和集成测试的区别之处，在自动化实施过程中，推荐分层的测试思路，既能够细化测试也能综合衡量自动化的投入成本，总的来讲就是以下几点：
　　1）传统瀑布项目，持续周期长，通过迭代模式可提前介入测试，而迭代周期内系统级功能可能不具备可测性，但是接口可以具备可测性。
　　2）基于UI的自动化有利有弊，需要结合系统特征综合考虑分层测试的必要，分层后各有测试的侧重点，比如UI自动化重点关注UI的操作流程和显示，集成测试更关注UI接口的参数等价类覆盖和数据正确性。
　1.2.3 接口可测性分析
　　接口显而易见要比UI简单的都，只需要知道协议和参数即可完成一次请求，从自动化测试实施难易程度来看，有以下几个特征：
　　1）驱动执行接口的自动化成本不高：HTTP，RPC，SOAP，RMI等各类都可以依据相应的协议封装一个client作为接口请求的执行器。
　　2）整个自动化测试中综合性价比高：接口测试还是属于黑盒范畴，所以比单元测试难度要低；而相比UI自动化稳定性可靠性更高。
　　2、接口测试工具选型
　　2.1 常见测试工具
　　2.1.1 JUnit
　　JUnit作为单元测试框架常被用作白盒测试，框架具备的一些优良特征有：
　　1）提供丰富API支持多种验证结果正确性的逻辑
　　2）通过参数化、@before、@after等特性，支持用例代码可复用
　　3）suite的模式支持case的批量运行
　　4）有展现良好的报表
　　5）与eclipse ide集成，使用方便
　　2.1.2 HttpClient
　　HttpClient是一个功能丰富支持HTTP协议的客户端编程工具包，具备以下主要功能：
　　1）封装实现了所有HTTP的方法，如GET，POST，PUT，HEAD
　　2）支持redirect，会话保持
　　3）支持文件上传
　　2.1.3 HttpUnit
　　HttpUnit是一个HTTP请求的测试辅助工具，能处理web测试的需求。通过模拟浏览器的行为，处理HTTP请求、会话保持、重定向以及对HTTP？response做DOM解析。
　　相比于HttpClient，不同之处在于：
　　1）HttpUnit能对HTTP返回的结果页进行解析，比如DOM元素定位
　　2）HttpUnit能自己启动一个servlet来运行被测服务
　　2.1.4 HtmlUnit
　　HtmlUnit相比HttpUnit功能更加强大，就像一个浏览器，HtmlUnit是Junit的扩展测试框架之一，该框架模拟浏览器的行为，开发者可以使用其提供的API对页面的元素进行操作。HtmlUnit支持HTTP，HTTPS，COOKIE，表单的POST和GET方法，能够对HTML文档进行包装，页面的各种元素都可以被当作对象进行调用，对JavaScript的支持也比较好。
　　2.1.5 JWebUnit
　　JWebUnit以HttpUnit和JUnit为基础的一个web测试工具。可以用来验证链接跳转、表单输入和提交、表格内容以及其他？Web？应用程序特性的正确性。相比于HtmlUnit，JWebUnit封装的更友好，编写case也会更加简单。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：30826次
排名：千里之外
原创：27篇
转载：10篇
(2)(1)(1)(1)(1)(1)(1)(2)(14)(9)(4)12270人阅读
新手入道，做了几个月的自动化测试，还没有接触过接口测试，看了一些文章，总结一下
什么是接口测试：
是项目测试的一部分，正如其名，它测试的主要对象是接口，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。
接口测试的目的：
的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为来看待的。
如何进行接口测试：
不是所有的团队都可以在一个隔离的测试环境中进行测试的，因此使得对外部接口的测试显得困难。我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试。等等这些都增加了实际测试执行中遇到的风险，但有些时候是可以避免的。
如何设计接口？
　　首先，明确出发点。和所有的测试一样，接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向，你的设计行为就会尽量朝这个方向发展，更易发现问题，不会出现大方向的偏差。
　　其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口，每个接口如果分别测试，那将是很痛苦的一件事情，不光繁琐浪费，而且任何一个内部接口的变动，都将导致我们用例的不可用。这里推荐把整个系统作为一个整体，选择整个系统提供给外部使用、交互的最外层接口作为你的测试对象，以此为测试对象的用例将有很好的健壮性，并且更高效。另外，根据数据的流向，又可将这些最外层的接口分为两类：一类是数据进入系统的接口；一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。数据从哪里流出，流出时的状态如何，此时系统又是什么状态都是我们所应该验证的。
　　然后，确认完整的测试对象的功能：确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。
　　最后当出发点、对象、功能都确定了，就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。
　　接口测试用例设计和测试用例设计一样，都应该本着尽可能的发现bug的目标。用例设计的内容应该包括：主要测试功能点、测试环境、、执行操作以及预期结果。
　　1）接口测试环境分为两种:一种是程序内部的环境；一种是程序的所调用外部接口的环境。用例在设计环境上有一个原则即：设计真实而危险的环境，不忽视偶发环境。真实，即你的用例在测试某种功能时，应该去思考这种情况发生时内部、外部环境是什么，通过各种手段将最准确的环境模拟出来。危险，即在这种环境下系统出问题的概率会很大。在设计用例环境时，如果两种环境都能达到你本用例的要求，更推荐选择更危险的环境。所谓偶发，即这种环境出现的概率很小。不要因为这种环境很少出现就无视它，开发很可能也是这种想法，此处很有可能隐藏着问题。
　　2）接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计学问大，不要在设计、准备测试用例的数据上偷懒。要通过好的测试数据使用例查错的功能充分发挥。接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据，使用例更容易发现问题。
　　3）测试功能点，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。
　　4）接口测试用例执行操作非常简单，就是所测接口的调用。
　　5）预期结果验证，这也是接口用例设计的很关键的一步，应该细而不冗余。所谓细，用例中应详细列出应该验证的点。每个用例均需验证，不要因为前几个用例有验证就认为全部是正确的。避免一个用例中重复做相同的验证，提高测试用例的效率。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：134241次
积分：1507
积分：1507
排名：千里之外
原创：27篇
转载：55篇
评论：11条
(1)(4)(5)(2)(2)(1)(1)(6)(2)(1)(1)(3)(4)(2)(6)(16)(18)(7)转过路角忽然发现，3岁的儿子已在路口等着自己回来。
在0℃的江苏无锡街头，环卫工用双手疏通下水道。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　通过以下总结的内容，想必会对想了解测试的人以及刚进入测试的“猿”，有个总体的概括，希望能帮到大家！
　　1.什么是接口测试
　　接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
　　2.为什么做接口测试
　　首先，节省测试成本，数据模型推算，底层的一个bug能够引发上层的8个左右bug，而且底层的bug很容易引起全网的宕机。相反接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。其次接口测试不同于传统开发的单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。最后接口测试是自动化并且持续集成的，这也是为什么接口测试能够低成本高收益的根源。总之接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益的驱动作用下的最佳解决方案，接口测试是一个完整的体系，也包括功能测试、性能测试。
　　3.接口测试的适用范围
　　接口测试一般应用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比。接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
　　4.在接口测试中如何应对需求的频繁变化
　　在现在这个互联网软件时代，需求的频繁变动已经不是什么新鲜事。客户的需求变更、市场需求的变更，项目本身的调整，以及新需求的出现等等都会导致需求的变化。这种需求的变化常会出现在项目开发阶段，根据需求的变化开发人员会对项目进行调整，而作为在项目开发阶段就接入进行测试的接口测试人员同样也会被影响，这种影响有时是巨大的，影响着我们的工作效率，它会导致我们需要重复以前的部分测试工作，甚至会让我们以前所做的测试工作白费。而且越是大型的、复杂的项目，这种影响越大 ，暴露出的问题也越多。
　　针对这段期间我在项目中的体验，将需求变化对接口测试的影响和出现的问题罗列下：
　　1. 需求变化，接口测试人员不知道或过了很久才知道。由于某些原因，常常会导致新需求变动接口测试人员不知道，或是过了很久才知道。往往接口测试人员是通过用例回归发现用例跑不通，然后会进行错误排查，最后发现问题后和开发确认后才知道是需求变化。这样是很浪费时间，甚至会遗漏一些需要测试的新需求的功能点，导致测试不全，遗漏bug。
　　2. 需求变化，对原有测试用例及其代码的影响.这个也是最让我头痛的、最直接的影响。需求变动有时会打乱了原有的测试规划，甚至包括对测试特性的划分原则，相应的测试结果分析验证、测试需求跟踪等都不到位。并且我们接口测试会对一个项目写上百个测试用例，为了尽可能的发现bug，测试用例里面有无数的验证点。往往一个很小的需求的改变会影响到很多的测试用例代码不通过，我们需要对很多测试用例进行调整，需要对测试数据以及测试代码进行修改，有时甚至需要修改我们的测试框架。这对我们接口测试人员来说是一个不少的挑战。
　　3. 新需求变化测试时间短，开展详细的测试有难度。由于新需求的提出已在开发期间，其测试时期短，接口测试有时没有人力和时间投入对新增修改需求的测试分析和设计上，基本上很难像对待老需求一样，开展详细的测试分析设计。
　　针对以上所写的这些，我说说我的拙见，如何减少需求变更对接口测试的影响：
　　1. 良好的心态。从心态上，接口测试人员应该把需求变化当作是一种项目常态，平常心应对。但是，我们也要学会控制这种需求变化的趋势，不能任其发展。
　　2. 及时沟通，最快知晓需求变更。和需求相关人员和开发人员做好即时沟通，第一时间知道需求的变更，及时做好测试策略更新。知道的越早对我们的影响越小，需要的测试成本也越低。
　　3. 良好的团队合作。接口测试人员和开发人员的良好合作，分工明确，对新的改动及时通知对方，短时间内开展最有效的团队协作。接口测试人员要主动关注开发代码的修改，对测试用例和测试代码及时调整，做到小粒度的修改。
　　4. 接口测试人员反应快，用例代码灵活性高。接口测试人员反应快，提前做好新需求的测试规划，包括测试设计和测试执行规划，并且在设计中要考虑新需求对老需求的影响；并且我们原测试用例和代码也要有一定的灵活，可以在一定程度上适应需求变化，将未来的新需求的影响尽量降到很小。这里就不详细说了，下次就具体的MC的项目说说如何增强测试用例代码的灵活性，减少新需求对测试代码的影响。
　　5. 做到及时的需求跟踪。通过测试用例代码的不断回归，尽早的主动的发现需求的变更。我们接口测试人员要成熟、快速、有序、灵活、有责任心的应对需求的变化，把我们的接口测试工作做得更好。
　　5.接口测试中测试与开发的配合
　　作为一名测试人员，工作中接触最频繁的应该要数开发人员了。在整个测试过程中，开发人员是与测试人员是走的最近的，因为从最初测试的需求到测试中发现的缺陷的处理以及最终测试的总结，都需要和开发人员紧密合作。接口测试因其天生的代码亲密性，为了更好地提高产品质量，就要求测试人员更加地深入到开发的工作中去（从需求出发深入到代码、页面中去），甚至是与开发并行地工作。那么这就对测试人员和开发人员的合作与互动提出了更高的要求。
　　1、测试与开发的互动应该贯穿项目始终，时刻保持和开发的联系也许有人会认为开发和测试在项目中相互独立会更加好，在此对这个问题不作讨论，只想说说从始至终与开发保持联系的好处。时刻保持联系，可以使双方对于项目的进展有一个明确的共同的理解，使项目的执行更加顺利。减少一些缺乏沟通而可能造成的工作内容的冲突，例如对于需求理解的不一致、需求变更等。
　　2、测试需求不光来自于PRD和UC，还要倾听来自开发的需求，这往往是他们担心的内容诚然PRD和UC是测试需求的主要来源也是测试工作的依据，然而从PRD和UC出发的测试需求往往是功能性的，会遗漏不少细节，特别是在接口测试工作中，这些细节又往往体现在开发的工作中，或者某些具体的实现中。因此倾听开发的测试需求，同时提出测试对于开发的要求是十分必要的。开发的需求经常是体现了在开发中他们没有把握的地方，这些光靠分析PRD和UC是很难得到的。
　　3、测试与开发应当相互了解对方的工作内容和方式，并交换意见让开发知道测试在做什么是怎么做的，当前测试的状况是什么样子的，测试也要了解开发的进度和工作内容。开发了解测试的方法和内容会有利于提高代码的可测性以及代码的品质。测试了解开发的工作方式和进度，就便于和开发进行合作加快缺陷的修复和验证。不仅要了解，在了解的基础上相互交换意见和看法，这往往能相互提高工作效率。
　　4、职责明确，测试应全面负责测试的工作环境、配置、代码，开发不应当随意改动。讲了很多互动的地方，但是有些内容却不应是互动的。就接口测试来说，测试环境配置和测试代码应当全部由测试工程师来维护，因为测试工程师主导整个测试的过程并对测试的结果负责。可以请开发协助配置环境这是必要的，但是出现任何测试方面的问题，开发都不应该在没有和测试工程师沟通的情况下介入测试环境和测试代码的变更。因为这样往往会导致测试用例无法通过，测试环境被破坏，测试结果可信度下降。会给项目进度带来不必要的影响。相应的，由于接口测试的代码往往和工作代码在一个工程下，测试也不应该去改动开发的工作内容，这会带来十分严重的后果。
　　5、测试应当高度关注测试持续集成的结果，第一时间分析问题，并初步定位后转交开发。在此我想强调下初步定位并转交开发的问题，可能有些同学会觉得缺陷被发现后直接转交开发就可以了，定位缺陷的事开发完成就可以了。我有一些不同的想法，能够定位缺陷意味着对于项目有着较为深入的了解，将有助于提高缺陷修复的效率。例如，同样是查询结果异常的问题，原因可能各有不同，如果初步将问题进行定位，必定能提高这些相似但实质却不同的缺陷的解决效率。
　　6.如何简单设计接口测试用例
　　接口测试是项目测试的一部分，它测试的主要对象是接口 ，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。
　　如何设计接口测试用例？
　　首先，明确出发点，和所有的测试一样 ，接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向 ，你的设计行为就会尽量朝这个方向，更易发现问题其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口 ，每个接口如果分别测试 ，那将是很痛苦的一件事情，而且任何一个内部接口的变动 ，都将导致我们用例的不可用。可将这些最外层的接口分为两类：一类是数据进入系统的接口；一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用 ，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。数据从哪里流出，流出时的状态如何 ，此时系统又是什么状态都是我们所应该验证的。
　　然后，确认完整的测试对象的功能：确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。最后当出发点、对象、功能都确定了，就可以真正设计用例了。
　　下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。接口测试用例设计和测试用例设计一样，用例设计的内容应该包括：主要测试功能点、测试环境、测试数据、执行操作以及预期结果。
　　1）接口测试环境分为两种：一种是程序内部的环境；一种是程序的所调用外部接口的环境。
　　2）接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列 ，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据 ，使用例更容易发现问题。
　　3）测试功能点，如果一个接口功能复杂时推荐对接口用例进行结构划分 ，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。
　　4）接口测试用例执行操作非常简单，就是所测接口的调用。
　　5）预期结果验证，这也是接口用例设计的很关键的一步 ，应该细而不冗余。每个用例均需验证 ，避免一个用例中重复做相同的验证 ，提高测试用例的效率。
　　本文转自：CSDN博客
　　微信号：IdeaofSE
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：