Web自动化测试中的接口测试
1、背景
1.1 Web程序中的接口
1.1.1 典型的Web设计架构
web是实现了基于网络通信的浏览器客户端与远程服务器进行交互的应用，通常包括两部分：web服务器和web客户端。web客户端的应用有html，JavaScript，ajax，flash等；服务器端的应用非常丰富，比如java的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，rm i，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不会太多介入单元测试，集中在集成测试和系统测试。结合上面提到的迭代排期，其实在一般项目中上层U I的开发往往比较滞后，赶工的结果也是提测质量不高。所以可推荐的一种模式是迭代周期内按照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等各类都可以依据相应的协议封装一个c lient作为接口请求的执行器。
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测试的需求。通过模拟浏览器的行为，处理H TTP请求、会话保持、重定向以及对HTTP？response做DOM解析。
相比于HttpClient，不同之处在于：
1）HttpUnit能对HTTP返回的结果页进行解析，比如DOM元素定位
2）HttpUnit能自己启动一个servlet来运行被测服务
2.1.4 HtmlUnit
HtmlUnit相比HttpUnit功能更加强大，就像一个浏览器，HtmlUnit是Junit的扩展测试框架之一，该框架模拟浏览器的行为，开发者可以使用其提供的API对页面的元素进行操作。HtmlUnit支持HTTP，H TTPS，COOKIE，表单的POST和GET方法，能够对HTML 文档进行包装，页面的各种元素都可以被当作对象进行调用，对JavaScript的支持也比较好。
2.1.5 JWebUnit
JWebUnit以HttpUnit和JUnit为基础的一个web测试工具。可以用来验证链接跳转、表单输入和提交、表格内容以及其他？Web？应用程序特性的正确性。相比于HtmlUnit，JWebUnit封装的更友好，编写case也会更加简单。
接口自动化测试方案 2018年4月9日 文档编号：（V1.0） 目录 目录 1测试需求及范围 (2) 1.1测试目的 (2) 1.2测试需求 (2) 2测试方法 (3) 3测试工具及框架拓扑图 (3) 3.1测试工具 (3) 3.2自动化测试拓扑图 (3) 4流程示例 (3) 5测试环境 (5)
2.1硬件配置 (5) 2.2软件配置 (5) 6测试思路 (6) 6.1通用测试场景 (6) 6.2逻辑场景 (7) 6.3断言检查 (7) 1测试需求及范围 1.1测试目的 随着公司项目的不断增大，接口的服务随之增多，回归的任务量越来越大，需要对接口进行定时回归测试来保证系统的稳定性。 1.在开发提交新的接口前进行冒烟测试，以保证系统是能够正常开展测试的 2.功能测试完成/bug回归完成后进行回归测试，保证bug修改完成后没有引入新的问题1.2测试需求 1、目前提供的接口多为Rest 规范的接口，需要使用JMeter进行自动化接口测试，核对接口入参及返回报文格式、内容的正确性，最终通过Jenkins持续集成生成测试报告。 2、对开发人员的需求 接口文档的规范，如：输入输出模板，输出类型是否全面 2测试方法 根据开发人员提供的接口访问地址、入参格式、请求格式，进行接口请求数据拼接，并查看返回结果及返回报文、响应时间，检查返回Json内容是否符合接口定义规范，是否符合预期的返回结果。
3测试工具及框架拓扑图 3.1测试工具 Jemeter+Jenkins 3.2自动化测试拓扑图 4流程示例 测试数据从csv或者txt文件里读取，包含入参、出参、预期结果/断言 用例通过jemter维护
7.6 AutoRunner简介 (1) 7.6.1 AutoRunner的组成 (1) 7.6.1.1 AutoRunner功能简介 (4) 7.6.2 AutoRunner的安装要求 (6) 7.6.3 AutoRunner的安装 (6) 7.6.4配置AutoRunner (9) 7.6.4.1配置AutoRunner (9) 7.6.5 AutoRunner的使用流程 (10) 7.6.5.1 AutoRunner使用流程简介 (10) 7.6.5.2创建项目 (11) 7.6.5.3 创建脚本 (14) 7.6.5.4 录制脚本 (15) 7.6.5.5 录制回放 (17) 7.6.5.6 脚本参数化 (18) 7.6.5.6 属性校验 (22) 7.6.5.7 脚本调用 (24) 7.6 AutoRunner简介 7.6.1 AutoRunner的组成
集成开发环境： (Integrated Development Environment 简称IDE)软件是用于程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面工具，也就是集成了代码编写功能、分析功能、编译功能、Debug功能等一体化的开发软件套。所有具备这一特性的软件或者软件套(组)都可以叫做IDE。如微软的Visual Studio系列，Borland的C++ Builder、Delphi系列等。 IDE环境菜单栏 AutoRunner3.9中的菜单栏如上图所示，主菜单包含文件、编辑、录制、执行、设置、许可证、帮助等菜单项，下面对每一项做一个简介。 文件菜单 如图所示，所有对脚本的管理操作都可以在文件菜单下完成，包括对脚本的新建，导入，保存，另存为，关闭，改变工作空间，最近打开，退出等等。 编辑菜单
移动app、接口、web自动化测试区别 先说说WEB的UI自动化测试： 很多人在说自动化测试的时候，基本上现在指的是WEB的UI自动化测试，但其实这是不对的，自动化测试包含了很多开发的技术，不只是界面上的自动化测试。WEB的UI自动化测试只是其中的一种，但它的工具确实最多的，有WINRUNNER\QTP(UFT)\TESTCOMPLETE\SILKTEST\ROBOT\SELENIUM\RF\WAITER等等，。而对于没有开发基础的测试人员，可以考虑QTP这个自动化工具，掌握比较快，但要学精还是需要掌握开发技术。但当总体来说根据自己的需求来选择符合自己公司的工具和开发语言。 接下来我说下WEB的UI自动化测试的优缺点： 缺点：开发效率低、维护成本高、执行速度慢等等 优点：用户操作真实性强。 接口自动化测试： 接口自动化测试在后来出现，但现在大部分的互联网公司都喜欢用它作为测试工作辅助。原因很简单，UI自动化的缺点它都能进行弥补，但同时它也存在一个最大的问题：用户操作真实性不强。其实个人觉得接口自动化测试和UI自动化测试可以产生互补的测试。因为我们做接口测试时更多的是根据开发的技术进行测试HTTP\SOCKET等等（接口测试基本上不需要用到什么工具进行，如果一定需要的话建议是用SOAPUI），而非真实的进行对系统进行操作验证系统是否存在问题。 APP自动化测试： APP的自动化测试应该也要分为UI和接口自动化测试，接口测试与上面说的一样都是技术层面上的事情就不说了。那么还是关注APP的UI自动化测试，APP 的自动化测试工具方面也有很多，但也都不成熟，我选择了APPIUM，主要考虑到的它可以进行跨平台测试，但最大的问题还是不稳定。所以也不敢大面积的布置其自动化测试用例。APP刚才说过了主要分为NATIVE和WEBVIEW，NATIVE的对象还好获取，像android可以直接使用uiautomatorviewer进行获取。而WEBVIEW就比较麻烦，不能直接获取要么就让开发提供给你，要么就直接下代码自己找，还有就是通过google的一个方法进行获取....... 说了一下这三种技术的一些内容，其实我想说不管什么类型的自动化测试，我们测试的过程中都需要和开发进行紧密的结合，但测试优于开发的测试思想。另外这三种技术我们在实际的应用中更应该将其进行混合的测试： UI（WEB）自动化测试走主流程的测试、接口自动化测试走全面的测试：先布置接口的自动化测试用于测试和回归测试，特别在敏捷测试中，接口自动化测试应
Jmeter接口自动化测试方法简介 一、思路简洁 1.了解待测接口参数规范，具体参考wiki，明确get参数和post参数，是否需要验证cookie、ua等 2.Jmeter参数化方式配置请求host、url、header消息头等 3.配置csv文件，编写测试用例参数和预期结果格式校验 4.根据需要编写beanshell脚本或导入辅助性jar包，用于解析接口返回结果，比如解密数据 5.在Jmeter中添加必要的断言或监听器，用于收集用例执行的结果 6.执行测试，查看用例结果，重点分析Fail的用例，和开发沟通，上报bug 二、一个简单的性能测试 QPS 解释 QPS : Query Per Second 每秒查询率。是一台查询服务器每秒能够处理的查询次数。在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。 为了达成预期的测目的，需要需要在jmeter中建立一个测试计划。因为本次测试仅要求完成对https://www.doczj.com/doc/7d7847660.html, 和 https://www.doczj.com/doc/7d7847660.html, 两个博客首页请求，因此只需要使用 HTTP Request Sampler 即可。 建立测试计划 启动jmeter后，jmeter会自动生成一个空的测试计划，用户可以基于该测试计划建立自己的测试计划。 添加线程组 一个性能测试请求负载是基于一个线程组完成的。一个测试计划必须有一个线程组。测试计划添加线程组非常简单。在测试计划右键弹出下拉菜单（添加-->Threads(Users)--->线程组）中选择线程组即可。
jmeter中每个测试计划至少需要包含一个线程组，当然也可以在一个计划中创建多个线程组，那么多个线程组之间又会怎样的顺序执行（串行还是并行）？在测试计划下面多个线程是并行执行的，也就是说这些线程组是同时被初始化并同时执行线程组下的Sampler的。 线程组主要包含三个参数：线程数、准备时长（Ramp-Up Period(in seconds)）、循环次数。 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。 准备时长：设置的虚拟用户数需要多长时间全部启动。如果线程数为20 ，准备时长为10 ，那么需要10秒钟启动20个线程。也就是每秒钟启动2个线程。 循环次数：每个线程发送请求的次数。如果线程数为20 ，循环次数为100 ，那么每个线程发送100次请求。总请求数为20*100=2000 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。
测试工具的比较和选择（仅供内部使用）
修订记录 2
目录 一．白盒测试工具集 (2) 二．黑盒测试工具集 (3) 三．测试管理工具典型产品比较 (4) 四．商业化自动测试工具比较 (6) 五．测试工具的选择 (7) 六．测试工具在实际中运用的瓶颈 (8) 七．总结 (9)
关键词： 白盒测试工具集、黑盒测试工具集、测试管理工具集、自动化测试工具集 摘要： 随着软件测试的地位逐步提高，测试的重要性逐步显现，测试工具的应用已经成为了普遍的趋势。目前用于测试的工具已经比较多了，这些测试工具一般可分为：白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具。总的来说，测试工具的应用可以提高测试的质量、测试的效率。但是在选择和使用测试工具的时候，应该看到，在测试过程中，并不是所有的测试工具都适合我们使用，同时，有了测试工具、会使用测试工具并不等于测试工具真正能在测试中发挥作用。因此，要发挥测试工具的价值,必须根据公司的实际情况合理选择测试工具, 本文拟从测试工具的选择和使用方面着手，讲述一点个人的心得,供公司参考
一．白盒测试工具集 白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。公司目前的测试水平尚不具备使用白盒测试工具进行代码测试的能力，这里只作简单介绍 1．静态测试工具 静态测试工具直接对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。静态测试工具的代表有Telelogic公司的Logiscope软件、PR公司的PRQA软件。 2．动态测试工具 动态测试工具与静态测试工具不同，动态测试工具的一般采用"插桩"的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。 动态测试工具的代表有Compuware公司的DevPartner软件、Rational公司的Purify系列等。 Parasoft白盒测试工具集 Compuware白盒测试工具集 2
接口自动化测试框架实例详解教程python+requests 前段时间由于公司测试方向的转型，由原来的web页面功能测试转变成接口测试，之前大多都是手工进行，利用postman和jmeter进行的接口测试，后来，组内有人讲原先web自动化的测试框架移驾成接口的自动化框架，使用的是java语言，但对于一个学java，却在学python的我来说，觉得python比起java更简单些，所以，我决定自己写python的接口自动化测试框架，由于本人也是刚学习python，这套自动化框架目前已经基本完成了，于是进行一些总结，便于以后回顾温习，有许多不完善的地方，也遇到了许多的问题，希望大神们多多指教。下面我就进行今天的主要内容吧。 1、首先，我们先来理一下思路。 正常的接口测试流程是什么？ 脑海里的反应是不是这样的： 确定测试接口的工具—> 配置需要的接口参数—> 进行测试—> 检查测试结果（有的需要数据库辅助）—> 生成测试报告（html报告） 那么，我们就根据这样的过程来一步步搭建我们的框架。在这个过程中，我们需要做到业务和数据的分离，这样才能灵活，达到我们写框架的目的。只要好好做，一定可以成功。这也是我当初对自己说的。 接下来，我们来进行结构的划分。 我的结构是这样的，大家可以参考下： common：存放一些共通的方法 result：执行过程中生成的文件夹，里面存放每次测试的结果 testCase：用于存放具体的测试case testFile：存放测试过程中用到的文件，包括上传的文件，测试用例以及数据库的sql 语句 caselist：txt文件，配置每次执行的case名称 config：配置一些常量，例如数据库的相关信息，接口的相关信息等 readConfig：用于读取config配置文件中的内容 runAll：用于执行case
主流测试工具介绍 选自：https://www.doczj.com/doc/7d7847660.html, WinRunner:强大的企业级自动化测试工具 Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。 企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。 如果时间或资源有限，这个问题会更加棘手。人工测试的工作量太大，还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行，你需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。 轻松创建测试 用WinRuuner创建一个测试，只需点击鼠标和键盘，完成一个标准的业务操作流程，WinRunner自动记录你的操作并生成所需的脚本代码。这样，即使计算机技术知识有限的业务用户轻松创建完整的测试。你还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式，满足测试团队中业务用户和专业技术人员的不同需求。 插入检查点 在记录一个测试的过程中，可以插入检查点，检查在某个时刻/状态下，应用程序是否运行正常。在插入检查点后，WinRunner会收集一套数据指标，在测试运行时对其一一验证。WinRunner提供几种不同类型的检查点，包括文本的、GUI、位图和数据库。例如，用一个位图检查点，你可以检查公司的图标是否出现于指定位置。 检验数据
接口自动化测试方案初稿 使用场景 当系统需要添加新的接口时，将对应接口按格式添加到系统中，即可快速按定义的规则进行测试，快速发现问题。 接口测试是比较讲究效率的，测试人员会希望很快能得到结果反馈，然而接口的数量一般都很多，而且会越来越多，所以提高执行效率很有必要 当系统版本更新时，对所有接口进行一次完整的自动化测试，可快速完成回归测试，判断系统更新对相关接口的功能是否产生影响。 接口测试的用例其实也可以用来兼做简单的压力测试，而压力测试需要并发 接口测试的策略 主导成员：杜帅 依赖条件：接口文档，产品原型，开发人员配合实现部分自动化接口 工作流程： 1. 参与code review 2.测试接口文档（需求文档/产品原型） 3. 根据接口文档编写测试用例 4. 编写测试脚本 结果产出： 自动化测试报告 接口自动化测试规划 1、开发方便测试和开发使用的工具： 使用场景： 测试和开发过程中，重复操作特别多，这些重复操作严重影响了产品周期，使用接口的方式实现流程性功能，降低功能测试成本。 测试准备： 1）借助功能测试人员配合，熟悉业务流程，获取测试人员需求 2）完善合理的接口文档 3）开发配合实现部分自动化接口 具体安排： 1）创建服务（营销系统平台端） 2）下单流程（营销系统PC端） 3）创建门店、车辆（租赁系统） 4）租车流程（门店系统）
5）申请售后流程（售后系统） 工作流程： 1）邀请相关测试和开发人员，讨论设计方案，并确认产出 2）功能测试人员根据产品原型编写功能脑图 3）接口人员设计业务脚本 结果产出： 1）生成测试报告和日志 2）生成简易web测试框架 3）配置到服务器 2、需求迭代，进行新增修改功能接口自动化测试脚本编写，尽早介入测试： 使用场景： 新版本迭代需要设计和修改的接口，尽早介入自动化测试，降低功能测试风险，提高测试覆盖率，降低功能测试成本。 工作流程： 1）参与需求评审 2）设计接口自动化测试方案 3）参与code review 4）设计脚本 5）后端开发接口完成后，进行接口测试 6）前端后台接口联调 7）提测，进入功能测试 结果产出： 1）生成测试报告和日志 2）配置到服务器 3、自动化脚本实现回归测试，提高测试效率： 测试准备： 1）借助功能测试人员配合，熟悉业务流程 2）完善合理的接口文档 3）开发配合实现部分自动化接口 工作流程： 1）设计接口测试用例 2）设计测试脚本 结果产出： 1）生成测试报告和日志
软件自动化测试工具介绍 一、功能测试工具 1、QTP测试工具 全名 HP QUiCkTeSt ProfeSSional SoftWare ,最新的版本为HP QUiCkTeSt ProfeSSional 11.0 QTP是 quickteSt PrOfeSSiOnal 的简称，是一种自动测试工具。使用QTP的目 的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等 QUiCkTeSt针对的是GUl应用程序，包括传统的Windows应用程序，以及现在越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。 2、WinRUnner MerCUry Interactive 公司的 WinRUnner是一种企业级的功能测试工具，用 于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRUnner能够有效地帮助测试人员对复杂的企 业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。 企业级应用可能包括 Web应用系统，ERP系统，CRM S统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。 3、RatiOnal Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational TeSt Manager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。 4、AdVentNet QEngine AdVentNet QEngine是一个应用广泛且独立于平台的自动化软件测试工具, 测试、 可用于Web功能Web性能测试、JaVa应用功能测试、JaVa APl测试、SoAP测试、回归测试和 JaVa
使用分层的Selenium框架进行复杂Web应用的自动测试 软件工程师,IBM 王晨，是IBM中国系统与科技研发中心的软件工程师。从事IBM Systems Director开发测试工作。对自动测试、Web2.0和Open Source等相关领域感兴趣。 简介：在复杂Web应用程序的自动测试中，会产生大量冗余的测试脚本，同时，由于测试场景复杂多变，测试用例的灵活管理与调用是不可回避的需求。在本文中，作者通过将开源Web自动测试框架Selenium从逻辑上进行了分层，从而提高了测试脚本的复用性与可维护性。通过本文的实例讲解，您将了解该项技巧的原理与关键实现。 发布日期：2010年2月22日 级别：中级 Selenium概述 Selenium是一种Web应用的自动测试工具，通过模拟用户对Web页面的各种操作，可以精确重现软件测试人员编写的Test Cases步骤。Selenium包含三个工具：Selenium-IDE，Selenium-RC以及Selenium-Core。其中，Selenium-Core是驱动Selenium工作的核心部分，作为一个用JavaScript编写的测试引擎，它可以操作Web页面上的各种元素，诸如：点击按钮、输入文本框，以及断言Web页面上存在某些文本与Web元素等。 Selenium-IDE是一个Firefox插件，能够录制回放用户在Firefox中的行为，并把所记录的Selenese(Selenium Commands)转化为 Java/C#/Python/Ruby等语言，在Selenium-RC中修改复用。对于较为复杂的Test Cases，Selenium-IDE的功能有限，往往用它录制大致的步骤，再转化为测试人员熟悉的编程语言，在此基础上完善，形成更为强大且灵活的Selenium-RC Test Cases。 Selenium-RC（Selenium Remote Control）在Web浏览器与需要测试的Web 应用间架设代理服务器（Selenium Server），使得JavaScript引擎与被测Web应用同源，绕开同源策略的限制（Same Origin Policy），进而取得对Web页面进行各种操作的权限。 开发环境配置
软件测试自动化与软件测试工具 目录 一、软件自动化测试基础 (2) 1、1 软件自动化测试的产生 (2) 1、2软件自动化测试的概念 (2) 1、3当软件开发过程中具有下列情况时首先需要考虑引入自动化测试： (2) 二、自动化测试的作用和优势 (2) 2、1概述 (2) 2、1、1产生可靠的系统 (2) 2、1、2改进测试工作质量 (2) 2、1、3．减少测试工作量并加快测试进度 (3) 2、1、4友情提醒 (3) 三、自动化测试工具 (3) 3、1软件测试工具分类 (3) 3、1、1白盒测试工具 (4) 3、1、2黑盒测试工具 (5) 3、1、3测试管理工具 (5) 3、2自动化测试工具一览 (5) 3、2、1 Rational Robot (5) 3、2、2 WinRunner (6) 3、2、3 LoadRunner (6) 3、2、4 Parasoft C++ Test (7) 3、2、5 QACenter (7) 3、2、6 WebLoad (8) 3、2、7 Web Application Stress (WAS) Tool (8) 3、2、8 TestDirector (8) 四、附录 (9)
一、软件自动化测试基础 1、1 软件自动化测试的产生 随着计算机日益广泛的应用，计算机软件越来越庞大和复杂，软件测试的工作量也越来越大。随着人们对软件测试工作的重视，大量的软件测试自动化工具不断涌现出来，自动化测试能够满足软件公司想在最短的进度内充分测试其软件的需求，一些软件公司在这方面的投入，会对整个开发工作的质量、成本和周期带来非常明显的效果。 1、2软件自动化测试的概念 软件测试自动化就是通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动的测试，它是软件测试的一个重要组成部分，能够完成许多手工无法完成或者难以实现的一些测试工作。正确、合理地实施自动化测试，能够快速、全面地对软件进行测试，从而提高软件质量、节省经费、缩短产品发布周期。 自动化测试能够替代大量手工测试工作，避免重复测试，同时，它还能够完成大量手工无法完成的测试工作，如并发用户测试、大数据量测试、长时间运行可靠性测试等。 1、3当软件开发过程中具有下列情况时首先需要考虑引入自动化测试： 非常重要的测试 涉及范围很广的测试 对主要功能的测试 容易自动化的测试 很快有回报的测试 运行最频繁的测试 二、自动化测试的作用和优势 2、1概述 使用测试工具的目的就是要提高软件测试的效率和软件测试的质量。通常，自动化测试的好处有： 产生可靠的系统； 改进测试工作质量； 减少测试工作量并加快测试进度。 2、1、1产生可靠的系统 测试工作的主要目标一是找出缺陷，从而减少应用中的错误；另一个是确保系统的性能满足用户的期望。为了有效地支持这些目标，在开发生存周期的需求定义阶段，当开发和细化需求时则应着手测试工作。使用自动化测试可改进所有的测试领域，包括测试程序开发、测试执行，测试结果分析、故障状况和报告生成。它还支持所有的测试阶段，其中包括单元测试、集成测试、系统测试、验收测试与回归测试等。 通过使用自动化测试可获得的效果可归纳如下。 （1）需求定义的改进 （2）性能测试的改进 （3）负载/压力测试的改进 （4）高质量测量与测试最佳化 （5）改进与开发组人员之间的关系 （6）改进系统开发生存周期 2、1、2改进测试工作质量 通过使用自动化测试工具，可增加测试的深度与广度，改进测试工作质量。其具体好处可归
IAT框架设计 1 背景 1.1项目背景 在移动平台服务端接口测试覆盖度为零的情况下，根据服务端接口的特点，以及升级更新的速度较快等，需要开发此框架来实施服务端接口的自动化测试。 1.2接口测试 接口测试属于灰盒测试范畴，通常不需要了解接口底层的实现逻辑，但需要测试人员能够使用代码的方式来调用接口。接口测试主要用例测试接口的功能以及接口返回数据的正确性。根据接口测试的复杂度接口测试分为两种。即单一接口测试，以及多接口组合功能测试。由于接口测试是通过代码调用的方式完成，而且接口测试与前端 UI 属于松耦合（或无耦合）因此通过自动化手段将极大提高测试效率以及回归测试的复用率。本文中提到的接口测试主要是指基于 http,https ，rpc 协议的 web 接口。 1.3 适用性分析 移动平台大部分以 http 接口方式提供服务，通过前台 App 调用接口方式实现功能。同时大部分接口功能，以及表现形式稳定，对于前台变化敏感度较低。基于上述接口测试的特点，认为移动平台项目非常适合接口层级的自动化测试。 2 IAT 框架 2.1IAT 介绍 IAT 是 Interface Automation Testing 的简称。通过热插拔的方式支持 http,rpc,soap 类协议的 web 接口测试。框架支持单一接口，多接口组合测试，支持用户通过自定义方法实现精确验证结果的需求。 2.2框架特点 提供多种接口测试方式。即单一接口测试，多接口业务流程测试。目前多见的为单一接口的测试。根 据用户需求不同，不同的接口测试方式，用例开发难易度不同。用例开发门槛低，用户只需要将接口用例 数据填入格式化文件即可自动通过工具生成用例。对于高级需求，框架提供自定义配置包括数据构造，精 确匹配测试结果等。框架对于不同域名下的相同接口支持自定义配置，只需要简单修改测试平台配置即 可轻松将用例
python webdriver 项目实战
第5章测试模型与测试脚本优化 第一节、测试模型介绍 线性测试 通过录制或编写脚本，一个脚本完成用户一套完整的操作，通过对脚本的回放来进行自动化测试。这是早期进行自动化测试的一种形式；我们在上一章中练习使用webdriver API 所编写的脚本也是这种形式。 脚本一 脚本二
通过上面的两个脚本，我们很明显的发现它的问题： 一个用例对应一个脚本，假如界面发生变化，用户名的属性发生改变，不得不需要对每一个脚本进行修改，测试用例形成一种规模，我们可能将大量的工作用于脚本的维护，从而失去自动化的意义。 这种模式下数据和脚本是混在一起的，如果数据发生变也也需要对脚本进行修改。 这种模式下脚本的可重复使用率很低。 模块化与库 我们会清晰的发现在上面的脚本中，其实有不少容是重复的；于是就有了下面的改进。 login.py quit.py 测试用例：
注意，上面代码并非完整代码，不能运行。 通过上面的代码发现，我们可以把脚本中相同的部分独立出来，形成模块或库；当脚本需要进行调用。这样做有两个好处： 一方面提高了开发效率，不用重复的编写相同的脚本；另一方面提高了代码的复用。 数据驱动 数据驱动应该是自动化的一个进步；从它的本意来讲，数据的改变（更新）驱动自动化的执行，从而引起结果改变。这显然是一个非常高级的概念和想法。 其实，我们能做到的是下面的形式。 d:\abc\data.txt
图4.x #coding=utf-8 from selenium import webdriver import os,time source = open("D:\\abc\\data.txt", "r") values = source.readlines() source.close() #执行循环 for serch in values: driver = webdriver.Firefox() driver.get(".xxxx.") driver.find_element_by_id("kw").send_keys(serch) ..... 不管我们读取的是txt 文件，还是csv、excel 文件的之类，又或者是数组、字典函数。我们实现了数据与脚本的分离，换句话说，我们实现了参数化。我们仍一千条数据，通过脚本的执行，可以返回一千条结果出来。 同样的脚本执行不同的数据从而得到了不同的结构。是不是增强的脚本的复用性呢！ 其实，这对开发来说是完全没有什么技术含量的；对于当初QTP 自动化工具来说确是一个买点，因为它面对的大多是不懂开发的测试。
7.7 PerformanceRunner简介 (2) 7.7.1 PerformanceRunner的组成 (2) 7.7.1.1 PerformanceRunner功能简介 (11) 7.7.2 PerformanceRunner的安装要求 (12) 7.7.3 PerformanceRunner的安装 (12) 7.7.4配置PerformanceRunner (15) 7.7.4.1配置PerformanceRunner (15) 7.7.5 PerformanceRunner的使用流程 (17) 7.7.5.1 PerformanceRunner使用流程简介 (17) 7.7.5.2创建项目 (17) 7.7.5.3创建脚本 (19) 7.7.5.4 录制脚本 (21) 7.7.5.5 录制回放 (24) 7.7.5.6 关联脚本 (25) 7.7.5.6 属性校验 (26) 7.7.5.7 添加事务 (29) 7.7.5.8 场景的创建与执行 (29) 7.7.5.9 测试结果和数据分析 (33)
7.7 PerformanceRunner简介 7.7.1 PerformanceRunner的组成 用户界面-生成器 测试或监控环境时，需要在系统中模拟用户的真实行为。PerformanceRunner 测试工具模拟多个用户在系统中同时工作或访问系统的环境。为了进行这种模拟，用虚拟用户（即 Vuser）代替现实生活中的人。Vuser执行的操作在 Vuser 脚本中进行描述。用于创建 Vuser 脚本的主要工具是脚本生成器。生成器不仅录制 Vuser 脚本，它还运行 Vuser 脚本。使用生成器运行脚本有助于进行调试。使用生成器可模拟 Vuser 脚本在大型测试中的运行情况。录制 Vuser 脚本时，生成器会生成多个函数，用以定义录制会话期间所执行的操作。生成器将这些函数插入到脚本编辑器中以创建基本 Vuser脚本。
IAT框架设计 1背景 1.1 项目背景 在移动平台服务端接口测试覆盖度为零的情况下，根据服务端接口的特点，以及升级更新的速度较快等，需要开发此框架来实施服务端接口的自动化测试。 1.2 接口测试 接口测试属于灰盒测试范畴，通常不需要了解接口底层的实现逻辑，但需要测试人员能够使用代码的方式来调用接口。接口测试主要用例测试接口的功能以及接口返回数据的正确性。根据接口测试的复杂度接口测试分为两种。即单一接口测试，以及多接口组合功能测试。由于接口测试是通过代码调用的方式完成，而且接口测试与前端UI属于松耦合（或无耦合）因此通过自动化手段将极大提高测试效率以及回归测试的复用率。本文中提到的接口测试主要是指基于http,https，rpc协议的web接口。 1.3 适用性分析 移动平台大部分以http接口方式提供服务，通过前台App调用接口方式实现功能。同时大部分接口功能，以及表现形式稳定，对于前台变化敏感度较低。基于上述接口测试的特点，认为移动平台项目非常适合接口层级的自动化测试。 2 IAT框架 2.1 IAT介绍 IAT是Interface Automation Testing的简称。通过热插拔的方式支持http,rpc,soap类协议的web 接口测试。框架支持单一接口，多接口组合测试，支持用户通过自定义方法实现精确验证结果的需求。 2.2 框架特点 ●提供多种接口测试方式。即单一接口测试，多接口业务流程测试。目前多见的为单一接口的测试。 ●根据用户需求不同，不同的接口测试方式，用例开发难易度不同。 ●用例开发门槛低，用户只需要将接口用例数据填入格式化文件即可自动通过工具生成用例。 ●对于高级需求，框架提供自定义配置包括数据构造，精确匹配测试结果等。 ●框架对于不同域名下的相同接口支持自定义配置，只需要简单修改测试平台配置即可轻松将用例
Web自动化测试中的接口测试 1、背景 1.1 Web程序中的接口 1.1.1 典型的Web设计架构 web是实现了基于网络通信的浏览器客户端与远程服务器进行交互的应用，通常包括两部分：web服务器和web客户端。web客户端的应用有html，JavaScript，ajax，flash等；服务器端的应用非常丰富，比如java的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，rm i，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的时间周期。
主流自动化测试工具介绍 一、功能测试工具 1、Selenium （浏览器自动化测试框架） Selenium[1] 是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE（7, 8, 9, 10, 11），Mozilla Firefox，Safari，Google Chrome，Opera等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。支持自动录制动作和自动生成 .Net、Java、Perl等不同语言的测试脚本。据 Selenium 主页所说，与其他测试工具相比，使用 Selenium 的最大好处是： Selenium [2] 测试直接在浏览器中运行，就像真实用户所做的一样。Selenium 测试可以在 Windows、Linux 和 Macintosh上的 Internet Explorer、Mozilla 和 Firefox 中运行。其他测试工具都不能覆盖如此多的平台。使用 Selenium 和在浏览器中运行测试还有很多其他好处。 下面是主要的两大好处： 通过编写模仿用户操作的 Selenium 测试脚本，可以从终端用户的角度来测试应用程序。通过在不同浏览器中运行测试，更容易发现浏览器的不兼容性。Selenium 的核心，也称browser bot，是用 JavaScript 编写的。这使得测试脚本可以在受支持的浏览器中运行。browser bot 负责执行从测试脚本接收到的命令，测试脚本要么是用 HTML 的表布局编写的，要么是使用一种受支持的编程语言编写的。 2、QTP测试工具 全名HP QuickTest Professional software ，最新的版本为HP QuickTest Professional 11.0 QTP是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等 QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以及现在越来越流行的
接口自动化测试方 案
接口自动化测试方案 4月9日 文档编号：（V1.0） 目录 目录 1测试需求及范围 (3) 1.1测试目的 (3) 1.2测试需求 (3) 2测试方法 (4) 3测试工具及框架拓扑图 (4) 3.1测试工具 (4) 3.2自动化测试拓扑图 (4) 4流程示例 (4) 5测试环境 (6) 2.1硬件配置 (6) 2.2软件配置 (6) 6测试思路 (7) 6.1通用测试场景 (7) 6.2逻辑场景 (8)
6.3断言检查 (9) 1测试需求及范围 1.1测试目的 随着公司项目的不断增大，接口的服务随之增多，回归的任务量越来越大，需要对接口进行定时回归测试来保证系统的稳定性。 1.在开发提交新的接口前进行冒烟测试，以保证系统是能够正常开展测试的 2.功能测试完成/bug回归完成后进行回归测试，保证bug 修改完成后没有引入新的问题 1.2测试需求 1、当前提供的接口多为Rest 规范的接口，需要使用JMeter进行自动化接口测试，核对接口入参及返回报文格式、内容的正确性，最终经过Jenkins持续集成生成测试报告。 2、对开发人员的需求 接口文档的规范，如：输入输出模板，输出类型是否全面
2测试方法 根据开发人员提供的接口访问地址、入参格式、请求格式，进行接口请求数据拼接，并查看返回结果及返回报文、响应时间，检查返回Json内容是否符合接口定义规范，是否符合预期的返回结果。 3测试工具及框架拓扑图 3.1测试工具 Jemeter+Jenkins 3.2自动化测试拓扑图 4流程示例 测试数据从csv或者txt文件里读取，包含入参、出参、预期结果/断言
web自动化测试 序：此只是简单的一个打酱油似的B/S架构的自动化测试调研，希望能对大家一点点启发，最好集大家之所成能给我一些建议和启发，万分感谢 一、目的 为了能够提高B/S架构的应用程序测试的测试效率。 二、应用范围 B/S架构的应用程序的应用功能测试与验证测试。 三、工具选型与比较 3.1 主要应用工具介绍 主要应用的测试工具包括以下几种 1）QTP, QuickTest Professional. 采用了关键词驱动（Keyword-Driven）测试的理念,关键字驱动或者称为关键词驱动（Keyword－Driven），是为了解决通过录制的方法来产生脚本的问题。就是先把所有需要的Web对象都添加到对象库中，然后在关键字视图中手动添加测试步骤. 2）RFT, Rational Functional Tester，是一个面向对象的、自动测试工具，它能够测试各种应用程序。可以应用其进行WEB对象的抓取。 3）Selenium，ThoughtWorks 专门为Web 应用而开发的自动化测试工具，适合进行功能测试、验收测试。 4）Watir ( Web Application Testing in Ruby) 是一个优秀的开源工具，用于开发基于Web 应用的自动化测试程序。它使用Ruby 脚本语言，提供了轻量级的自动化测试程序框架和丰富的开发库，有效地加速了自动化测试程序开发。 3.2、工具应用比较 1)、QTP采用关键词驱动和描述性编程的方法，其成熟度广，应用普及率较广，框架搭建较简单，但其价格昂贵，采用的是activex驱动模式，灵活性低，不易与自身平台进行结合。 2)、RFT可以支持WEB自动化测试，但仅仅是对其对象的获取，而且其还对C/S架构的APP支持，其灵活性低，价格昂贵，但其的自动化测试架构可以重用C/S类型的。自动化测试项目。 3)、selenium 优点：a）其原理即基于WEB内核机制。其直接运行在浏览器之上，所见即所得，就像真实用户所做的一样。Selenium 的核心，也称browser bot，是用JavaScript. 编写的。这使得测试脚本可以在受支持的浏览器中运行。 b）灵活性高，易整合到自己平台，其测试用例可以采用两种方式撰写：test runner （HTML 文件）和driven（脚本语言编写），其语言包括Java, .NET, Perl, Python 和Ruby. 使用driven 脚本，测试有一部分在浏览器之外运行，而如果使用test runner 脚本的话，测试是完全在浏览器中运行的。 c）开源，且应用较广泛，有一定的技术基础。 缺点：a）selenium不能简单的处理WEB上一些第三方插件，例如：当要从Web 上下载一些东西，自然此时就会弹出一个“下载框”，由于那个框框是Windows窗口，Selenium 是处理不了的，所以必须通过第三方的脚本处理。 b）selenium是轻量的测试框架，脚本所处理的测试用例构成简单，其实质就是通过HTTP协议，发送请求（request）来完成测试用例，所以很困难处理业务逻辑关系强的测试用例。