海量用户高并发SAAS产品测试上线流程
SAAS产品测试上线流程-以Web插件产品为例子
在互联网产品中，IT公司之间更加注重产品功能之间的协作，SAAS形态的产品扮演着越来越重要的作用。
一个典型的完全由宿主代理的SAAS服务的通讯流程如下图：
这样的产品一般具有如下特点：
一般由第三方提供专门的服务
通常以网络为媒介来提供服务
具备嵌入的客户端功能
具备第三方服务端功能
一般不以独立的产品形式直接面向客户
一般需要集成&寄生&在宿主产品中来面向客户
SAAS形态的主要产品有：
天气预报插件
站长统计工具，如CNZZ
网络广告，如：百度广告，Google Ads
站内搜索引擎
分享社交插件，如：JiaThis
移动app数据统计插件,如：友盟
移动app广告插件
作为SAAS服务提供商，对于此类产品的开发和维护有优点也有缺点。
优点如下：
发布行为的成本很低，直接利用网络发布
版本维护成本较低，可以全网统一维护
小而快迭代发布能够避免重大问题产生
直接透明化地面向客户能够保证数据的快速通达和反馈
缺点如下：
服务器并发容量要高
因为此服务是提供给B端用户，B端用户再打包提供给C端用户，这个量的成长性是很可观的。服务器必须在性能上有较高要求
服务端和客户端接口稳定性要高（有版本包袱）
在使用量上升之后，作为SAAS产品，肯定是需要不断的快速迭代升级。由于此产品在和宿主产品集成之后，就相当于&&一言既出&&，可能已经有成千上万的用户在使用此接口了。必须要注意前后的接口兼容性
客户端兼容性强（有平台包袱）
一般对于涉及到前端的Web产品来说，IE6/IE7/IE8是在PC下绕不过去的历史包袱。如果Web产品还涉及到移动浏览器端，则以Android的碎片化设备的现状，不同的主流机型也是绕不过去的历史包袱
整体来说，一个完整的带&服务端&和&客户端&的产品的主要测试上线流程如下：
服务器/客户端各自单元测试
服务端接口测试
服务器端性能测试
端到端功能测试(集成测试)
平台兼容性测试
全网灰度测试
2&&&可测性架构
正如之前的文章里面提到过，一个适合做测试的系统，必然是一个架构上&可测性&比较好的系统。目前比较典型和主流的互联网应用的系统基本上都有比较好的可测性，其典型的架构如下图所示：
此架构最典型的特点就是，做到服务器和客户端的有效分离，现在随着平台的多样化，客户端已经有但不限于如下几种：
Windows Phone
为了便于描述，以上架构可以分别简称&A/S&、&B/S、&C/S&,整体架构图可以认为是&&典型的ABC/S网络产品架构图&
3&&&单元测试
单元测试是涵盖在每个子项目里面的，由开发人员完成的。主要涉及的内容是函数一层的，开发人员需要对主要的算法函数进行输入和输出的校验，这样在重构或者代码修改的时候，可以进行有效的回归测试，防止新的修改影响了旧的代码。
单元测试是必须的，单元测试做得越多，问题就会发现得越及时。但是在实际操作过程中，考虑到投资回报率，可以只对主要的核心函数功能进行单元测试的自动化代码编写，即只需要付出20%的代价就能产生80%的回报的这部分函数功能。使用这样的2/8原则，也并不用担心有&漏网之鱼，因为后续还有其它的测试会进行有效的补充的。
上面提到的2/8原则是指&单元测试自动化代码&的开发原则，而不是说单元测试的原则，单元测试其实在开发过程中就已经在做了，用于验证开发代码的正确与否，单元测试其实是一直在使用，只是没有写成自动化的代码，回归性差而已。对于回归要求很强的函数，则尽量编写自动化的单元测试代码。
4&&&接口测试
接口测试严格来说是属于&白盒测试&的范畴。在如上的系统架构中，服务器端为客户端提供接口服务，即：客户端向服务器端发起请求（Http或者socket），然后服务器端针对请求做相应的操作，并返回相应的流（一般是经过编码的json/xml字符串或者图片二进制流）。
接口层次做自动化相对其它层次是最容易的，同时也是&投资回报率（ROI）&最高的。因为最上层面向客户的UI，本质上是通过业务层的数据来驱动的。而此处业务层的数据的最直接体现就是服务端的接口。
以目前主流的服务端接口（通过http通讯，以json作为字符编解码）为例子，可以很容易通过一些自动化框架，例如：&pyunit，在数据层面模拟界面操作产生的业务流，进行数据的自动化比对判断。
一般通行的技术手段是：
pyunit自动化测试框架组织用例
requests库模拟http请求
json库进行编码解码
pyunit的assert的函数进行判断
具体执行效果如下：
上图使用了可视化的python的IDE运行pyunit程序得到的结果，左边的提示如果全部是绿色的，表示本文件中的所有单元测试用例都通过。
接口测试的主要内容：
请求接口，对单接口的输入和输出内容进行判定
模拟业务操作，对多接口实现的业务流进行判定
由于本文的重点在于讲述流程，关于具体的工具的使用，后续的文章里面会详细介绍，在此就略去不表。
基本上，如果测试用例足够而且基本上采用了自动化的方式，服务器端的90%以上的问题都能以很低的测试成本在此阶段给暴露出来。
5&&&性能测试
服务端通过接口测试之后，这样还不够，在正式在生产服务器上发布前，需要做性能测试。因为之前的接口测试也只是模拟了单客户端，在正式上线时，不仅仅是代码逻辑问题，还会涉及到代码性能问题。
比较典型的就是12306火车票在线购买网站，虽然在业务逻辑上是走通的，没有问题的。但是只要逢节假日，来自全国各地买票请求极度密集，但是服务器的负载能力没有跟上，就直接导致服务崩掉。所以在上线前，需要进行性能测试，能够得出一些具体的性能指标，然后和实际的生产环境做对比，做好一些预案工作。
预案工作包括但不限于如下几点：
Web应用程序调优
Web服务器内核调优
中间件缓存等等调优
增加Web集群机器
截至此时，服务器端的测试工作算是基本上完成了。
6&&&功能测试
并不是所有的功能都是可以做接口测试的。接口测试只是在数据层面对服务器端提供服务的能力进行检测，但是面向用户的程序，最终交互的对象毕竟是人而不是代码，所以就存在像界面显示等等涉及到最终用户的交互层次的问题，而这些问题只能通过&端到端（End To End）&的功能测试来解决了。
端到端的测试主要是对交互界面层的检测，由于有了接口测试，端到端的功能测试的工作量也会显著得到减轻。
在首次进行端到端的功能测试时，可能会讲究覆盖率，和接口测试的用例有大量的重复，但是随着时间的推移和测试次数的增加，测试人员也会变得有经验，后期的迭代工作中功能测试的工作量将显著减轻。有经验的测试人员会逐渐挑选出和接口测试等价的功能测试用例进行剔除，最后只留下少量的接口测试实在是无法完成的功能测试用例。
由于端到端的功能测试是把产品或服务当作一个整体进行验证，是模拟真实的用户场景的测试，而且基本上只能靠手工来实现，所以是最耗时和测试策略，而且回归性差，一般不建议大量使用此策略，建议能够在单元测试或者接口测试阶段发现和解决的，尽量在那些阶段发现和解决的，就不要留在用户级。用户级的功能测试只是用来验证，而不应该用来做发现。
此处所说的功能测试还不是平台兼容性测试，而是在接口测试的基础之上，在交互界面层进行&功能通透&的操作测试，只需要在最主流和平台上进行验证即可。例如，Web应用一般使用Chrome浏览器作为主流验证平台
7&&&兼容性测试
SAAS产品的优点在于不用过多考虑全网的版本统一的问题，但是缺点很明显，因为受众是全网的用户，所以要尽量保证全主流平台的兼容性问题。
目前流行的应用程序平台有：
PC端浏览器
IE6/7/8/9/10/11
搜狗/猎豹/360/QQ浏览器
移动端浏览器
微信/手Q/QQ浏览器
Andoird原生浏览器
iOS原生浏览器
搜狗/猎豹/360
XP/Win8/Win8以上
Linux Desktop
Windows Phone
测试人员需要酌情对这些平台进行兼容性测试。
这些还只是不同的平台，还没有考虑一些碎片化的设备，例如以&碎片化&著称的Android生态系统，不同的机型的表现力都会有差异。
通常，有经验的兼容性测试人员，会知道一些平台的问题&等价性&，从而尽量避免轮询式的测试。
下面分享一些兼容性测试的经验：
基本上IE6的问题最多，最老的古董
IE6/7/8可以划分为一个大类，IE7和IE8基本上也容易出问题
Chrome上测试没有问题的，IE9及以上基本上也不会有问题
缓存问题需要注意，防止出现测试环境就没有搭建好的误测
移动端浏览器
基本上Chrome没有问题的，其它浏览器都没有问题
因为移动智能终端出现得比较晚，出身的时候就是基于webkit内核来生成的浏览器
注意移动端浏览器的&云加速&功能
这样的缓存会导致出现测试环境就没有搭建好的误测
手机QQ和微信内置浏览器需要单独重点测试
这两个APP的使用用户量大，而且针对普通浏览器做了较多修改，目前很多基于IM分享的页面都是直接在此app里面内嵌打开
Android和iOS关于获取webview的宽度的方法不同，存在前端布局兼容问题
不是所有的设备都能对h5完美支持
Android/iOS/WindowsPhone关于Web的触摸响应会有一些不同
8&&&灰度测试（发布）
之前的测试要么是在开发环境要么就是在测试环境，但是最终服务是需要上线到生产服务器上来产生价值的。由于要往生产服务器上进行迁移，就产生了环境的变化，使用灰度测试（发布）有如下好处：
尽早发现&代码环境原理级&问题并提前解决
生产环境和开发环境无法保证完全一致，故可能存在&代码环境原理级&问题。虽然说已经事先约定了尽量保持开发环境和生产环境的一致性，但是显然也是无法完全做到一致（比如生产服务器一般使用linux-server，但是开发人员则可能使用的是linux-desktop或者mac-os）
尽早发现&规模量级&的问题并提前解决
面向生产环境的代码存在性能和网络节点等等&规模量级&的问题。对于并发量，实际承受值和理论值可能有差距;用户访问由于地域问题，可能存在网络不通畅或者缓存问题而导致服务不能正常
灰度测试（发布）可以避免&非黑即白&这种绝对的发布境况，能够有效避免新版本上线后造成全网所有用户功能不能正常使用的情景，能够在问题扩大之前，就发现并解决问题。
关于如何做好灰度测试（发布）也是有具体的方法策略，此处先只阐述流程，方法另讲。
灰度测试的具体实现方法，需要对软件工程，具体业务流程，应用程序部署，系统架构都要有相当的了解才能设计出比较好的针对自己应用的灰度流程，有如下注意事项：
应用系统具有可&灰度&性
这点和&可测性&差不多的意思，需要在结果上有所调整，能够通过一些配置来对同一时间的用户做A/B分开的测试
应用系统需要具有一定的&回滚&能力
一旦灰度过程中出现重大问题，需要回撤的时候，应该尽量有补救回滚措施
以上注意事项，都是需要有良好的技术能力才能实现好。
不同的测试策略应用于不同的测试阶段：
在开发阶段由开发人员编写和使用。用于函数级别的模块测试和故障诊断
在设计完毕后参考设计文档由测试开发人员进行编写，在服务器生产代码构建并部署测试环境后进行使用。用于接口级别的模块测试和故障诊断。基本上服务端的绝大多数问题都要在此处发现并进行解决，后面的流程只是做辅助验证工作而已
在测试环境下对服务的负载能力进行测试，提前知道其负载能力
在客户端和服务器端完成联调，构建好客户端，在用户层面用于功能完整性验证
对生产环境的迁移进行验证式的测试，形成平滑的发布
截至此处，本文也只是对SAAS产品的基本测试理论和流程进行宏观的介绍，后续再讲具体的实现方法，毕竟光有好的模式&还不够， 必须要有相应的&先进方法&进行实践落地，才能产生巨大的&生产力&。
欢迎以学习交流为目的读者随意转载，但是请&【注明出处】
如果文章对您有启发，可以点击博客右下角的按钮进行&【推荐】
阅读(...) 评论()在线HTTP POST/GET接口测试工具 - aTool在线工具
最新修改：增加https类型的url请求，目前支持http和https~。
最新修改：修改基本样式，增加header和body参数，增加返回值得header信息，采用codemirror作为返回数据的编辑器。
右上角QQ登录之后，可以记录自己测试的接口，不用每次输入好累~~！</span
请求Body参数
请求Header
Body参数名称
Body参数值
RAW批量添加
Response Header
Response Body
Requests Header | Http Header
指定客户端能够接收的内容类型
Accept: text/plain, text/html
Accept-Charset
浏览器可以接受的字符编码集。
Accept-Charset: iso-8859-5
Accept-Encoding
指定浏览器可以支持的web服务器返回内容压缩编码类型。
Accept-Encoding: compress, gzip
Accept-Language
浏览器可接受的语言
Accept-Language: en,zh
Accept-Ranges
可以请求网页实体的一个或者多个子范围字段
Accept-Ranges: bytes
Authorization
HTTP授权的授权证书
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control
指定请求和响应遵循的缓存机制
Cache-Control: no-cache
Connection
表示是否需要持久连接。（HTTP 1.1默认进行持久连接）
Connection: close
HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。
Cookie: $Version=1; Skin=
Content-Length
请求的内容长度
Content-Length: 348
Content-Type
请求的与实体对应的MIME信息
Content-Type: application/x-www-form-urlencoded
请求发送的日期和时间
Date: Tue, 15 Nov&:31 GMT
请求的特定的服务器行为
Expect: 100-continue
发出请求的用户的Email
指定请求的服务器的域名和端口号
Host: www.zcmhi.com
只有请求内容与实体相匹配才有效
If-Match: “c284d8af7add”
If-Modified-Since
如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码
If-Modified-Since: Sat, 29 Oct :31 GMT
If-None-Match
如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变
If-None-Match: “c284d8af7add”
如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag
If-Range: “c284d8af7add”
If-Unmodified-Since
只在实体在指定时间之后未被修改才请求成功
If-Unmodified-Since: Sat, 29 Oct :31 GMT
Max-Forwards
限制信息通过代理和网关传送的时间
Max-Forwards: 10
用来包含实现特定的指令
Pragma: no-cache
Proxy-Authorization
连接到代理的授权证书
Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
只请求实体的一部分，指定范围
Range: bytes=500-999
先前网页的地址，当前请求网页紧随其后,即来路
Referer: http://www.zcmhi.com/archives/71.html
客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息
TE: trailers,q=0.5
向服务器指定某种传输协议以便服务器进行转换（如果支持）
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent
User-Agent的内容包含发出请求的用户信息
User-Agent: Mozilla/5.0 (L X11)
通知中间网关或代理服务器地址，通信协议
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
关于消息实体的警告信息
Warn: 199 Miscellaneous warning
Responses 部分 | Http Header
Accept-Ranges
表明服务器是否支持指定范围请求及哪种类型的分段请求
Accept-Ranges: bytes
从原始服务器到代理缓存形成的估算时间（以秒计，非负）
对某网络资源的有效的请求行为，不允许则返回405
Allow: GET, HEAD
Cache-Control
告诉所有的缓存机制是否可以缓存及哪种类型
Cache-Control: no-cache
Content-Encoding
web服务器支持的返回内容压缩编码类型。
Content-Encoding: gzip
Content-Language
响应体的语言
Content-Language: en,zh
Content-Length
响应体的长度
Content-Length: 348
Content-Location
请求资源可替代的备用的另一地址
Content-Location: /index.htm
Content-MD5
返回资源的MD5校验值
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range
在整个返回体中本部分的字节位置
Content-Range: bytes /47022
Content-Type
返回内容的MIME类型
Content-Type: text/ charset=utf-8
原始服务器消息发出的时间
Date: Tue, 15 Nov :31 GMT
请求变量的实体标签的当前值
ETag: “c284d8af7add”
响应过期的日期和时间
Expires: Thu, 01 Dec :00 GMT
Last-Modified
请求资源的最后修改时间
Last-Modified: Tue, 15 Nov :26 GMT
用来重定向接收方到非请求URL的位置来完成请求或标识新的资源
Location: http://www.zcmhi.com/archives/94.html
包括实现特定的指令，它可应用到响应链上的任何接收方
Pragma: no-cache
Proxy-Authenticate
它指出认证方案和可应用到代理的该URL上的参数
Proxy-Authenticate: Basic
应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）
Refresh: 5; url=http://www.atool.org/httptest.php
Retry-After
如果实体暂时不可取，通知客户端在指定时间之后再次尝试
Retry-After: 120
web服务器软件名称
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie
设置Http Cookie
Set-Cookie: UserID=JohnD Max-Age=3600; Version=1
指出头域在分块传输编码的尾部存在
Trailer: Max-Forwards
Transfer-Encoding
文件传输编码
告诉下游代理是使用缓存响应还是从原始服务器请求
告知代理客户端响应是通过哪里发送的
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
警告实体可能存在的问题
Warning: 199 Miscellaneous warning
WWW-Authenticate
表明客户端请求实体应该使用的授权方案
WWW-Authenticate: Basic
在线接口测试工具 | Introduce
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试一般以用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。
最简单的应用就是，使用Web http的方式，为APP提供数据接口，这些接口具有一定的动态性，采用传入一定的参数，接口通过参数获取不同的数据返回给使用者，参数传入的方式有GET和POST方式两种，使用浏览器可以直接模拟GET请求，但是POST请求却无能为力，只能编写脚本测试，这就导致接口测试非常麻烦。
本工具提供任意接口的HTTP GET和POST测试，并且提供测试返回值，接口返回时间，并且已经对接口请求的异常状态进行获取，然后反馈给用户。
备注：接口执行时间与本网站服务器有关，仅供参考。
推荐功能 / 猜你喜欢 | Suggest
评论 | Comments没有更多推荐了，
不良信息举报
举报内容：
如何统计在线的人数
举报原因：
原文地址：
原因补充：
最多只允许输入30个字
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！百度数据开放平台最近看了很多接口测试 的帖子，都是拼接url、请求方法、参数调用的http请求来进行接口测试，很少有客户端(App端）的接口测试方法，目前是采用抓包/开发同学打出log来验证请求是否发送和响应成功、返回值抓取，期望有种自动化且可易用的方法来测试。接口测试包括
1、服务端HTTP接口测试&测试服务是否按接口文档完成，服务端接收请求/响应结果都正常)
1）拼接url、请求方法、参数调用的组合测试
已使用jmeter完成2、客户端HTTP接口测试
1）客户端发起请求，服务端响应正常，返回值符合预期
2）检查客户端操作某个功能后，是否发起请求，以及调用接口次数是否正确
3）服务端异常返回值，客户端能否正确处理
第1、2个小点目前采用抓包和log(收集log，格式化来对比结果)方式验证问题：
1）我目前的测试方法有遗漏吗？
2）如何自动化的实现确定真机在做操作APP某个功能时，客户端发起了请求/请求发送成功/服务器响应成功/返回值正确？
markdown 的 # 号和文字之间留一个空格。我们用的是严格的 markdown ，语法中的空格是不可忽略的。
已按规定修改好，帮忙重新审核下
方案：使用 json-rpc 或 xml-rpc 把app上的接口暴露出来，在外部用HTTP方式通信，理论支持多种语言自己造轮子，也能用JMeter来发请求断言验证。
Appium采用的也是RPC协议 (Remote Procedure Call Protocol)，selenium的json-rpc。我不知道大家有什么高效的方法来调试Appium代码，我的主意就是直接开一个JMeter随时发HTTP请求来验证一下我当前的操作是否可行（Chrome的POSTMAN插件也可以）。古时候用monkeyrunner，命令行方式来一步一步调试还是挺方便的。
RPC方式一般是被我们用来测试SDK (library)的，Python自带xml-rpc库，Android端有Apache的java xml-rpc server，剩下的就简单了。待我有空来详写一篇吧。
在做UI自动化测试时，可以抓取到URL请求，然后将URL请求传入http接口服务器进行解析就可以了
先判断接口参数是否符合规范，然后直接在HTTP接口服务器进行模拟调用，再判断结构和预期结果是否一致就可以了
或者直接用urllib requests模块直接写单元，然后format参数化进行测试和验证
mark有学到
—— 来自TesterHome官方
不走http，直接调用server端接口也可以吧
后方可回复, 如果你还没有账号请点击这里 。
keen_lau (keen)
第 163 位会员 /
共收到 12 条回复}