：转载时请以超链接形式标明文章原始出处和作者信息及本声明
在上海做软件测试工资多少，现在软件测试这个行业在中国的发展怎么样，什么时候软件运维工程师薪资就要达到饱和期，谢谢了！
我是上海人，做flash项目开发的，据我所知，软件测试的工资在国内水平还比较低，转正也就3000左右，测试工资仅高于维修工程师的，在很多企业都远不及开发的高，软件测试行业在中国的发展水平还很低，和国外的同行地位是不能比的，而且目前能支持的起专业测试团队的基本都是合资或外资的大企业，而几乎所有的私营的中小规模企业不是外包就是由开发承担测试工作，但是呢，测试的市场是很广阔的，就我看来目前国内许多企业认识到软件测试的价值还需要一个过程，还远远没达到饱和，但是短期内的待遇不会特别高。而且我自己的切身经验是，做开发的都可以了解和清楚测试工作的运行方式，而且直接做后台代码的做起白盒测试也更有优势，而对于长期从事测试工作的人员却未必能接触到比开发更多的东西，许多国内做测试外包的，比如我熟知的上海张江的博彦，就是做测试外包的，为HP等做软件测试，招进去的测试人员多进行黑盒测试，而且测试工作缺乏科学手段，很多都实际是繁琐的重复工作，所以给LZ的建议是先想办法从事些开发工作，有了技术背景后再转测试，做测试主管自然手到擒来，对于职业发展空间也更有利，如果对LZ有帮助，请采纳^_^
历史上的今天：
Trackback:30号排卵 今早测的 大家看看是有了吗？？谢谢-播种网论坛
努力加载中...
10){window.location='forum.php?mod=viewthread&tid=&extra=page%3D1&page='+ doane(event);}">跳转
30号排卵 今早测的 大家看看是有了吗？？谢谢
谢赞，祝你好孕快快来
已邀请用户 ： （此提示只有您可以看到，其他用户无法查看）
<td class="t_f" first="1" id="postmessage_号排卵 今早测的 大家看看是有了吗？？谢谢
恭喜楼主！传我好孕
七级宝宝, 积分 474, 距离下一级还需 126 积分
| 来自疯狂造人
恭喜楼主！传我好孕
十一级宝宝, 积分 1954, 距离下一级还需 46 积分
| 来自疯狂造人
很明显就是有了
七级宝宝, 积分 474, 距离下一级还需 126 积分
| 来自疯狂造人
七级宝宝, 积分 432, 距离下一级还需 168 积分
| 来自疯狂造人
有了，恭喜恭喜
六级宝宝, 积分 372, 距离下一级还需 28 积分
| 来自疯狂造人
恭喜哦！有了！
六级宝宝, 积分 380, 距离下一级还需 20 积分
| 来自疯狂造人
妥妥的了～传我好孕吧～
六级宝宝, 积分 363, 距离下一级还需 37 积分
| 来自疯狂造人
回复 肉肉，我爱你～ 妥妥的了～传我好孕吧～传传传！！
六级宝宝, 积分 363, 距离下一级还需 37 积分
| 来自疯狂造人
回复 q0 恭喜楼主！传我好孕传你好孕！传传传
八级宝宝, 积分 777, 距离下一级还需 23 积分
| 来自疯狂造人
恭喜宝妈！接宫内好孕！
九级宝宝, 积分 1134, 距离下一级还需 66 积分
| 来自疯狂造人
恭喜楼主 接你宫内好孕
六级宝宝, 积分 323, 距离下一级还需 77 积分
| 来自疯狂造人
有了，恭喜恭喜！接好孕！
九级宝宝, 积分 915, 距离下一级还需 285 积分
| 来自疯狂造人
有啦，恭喜！接好孕！
八级宝宝, 积分 757, 距离下一级还需 43 积分
| 来自疯狂造人
恭喜你祝加深接你好孕
九级宝宝, 积分 1006, 距离下一级还需 194 积分
| 来自疯狂造人
恭喜恭喜，有了~
九级宝宝, 积分 803, 距离下一级还需 397 积分
| 来自疯狂造人
有了有了，恭喜啊，接宫内好孕
十级宝宝, 积分 1576, 距离下一级还需 24 积分
| 来自疯狂造人
超级明显呀！恭喜楼主了
十级宝宝, 积分 1311, 距离下一级还需 289 积分
| 来自疯狂造人
今天才测到吗？
七级宝宝, 积分 503, 距离下一级还需 97 积分
| 来自疯狂造人
恭喜恭喜接你好孕哦
七级宝宝, 积分 545, 距离下一级还需 55 积分
| 来自疯狂造人
恭喜恭喜 穿我好孕
10){window.location='forum.php?mod=viewthread&tid=&extra=page%3D1&page='+ doane(event);}">跳转
分享到站内：
分享到站外：
姐妹都在抢
疯狂造人(备孕怀孕APP)
其实,怀孕可以很简单!
关注微信微博
瞪谁谁好孕966,690 十一月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
HTTP API自动化测试从手工到平台的演变
HTTP API自动化测试从手工到平台的演变
相关厂商内容
相关赞助商
8位阿里技术大V解密双11背后黑科技！
图-1-分计费单元查询带宽
优点（文中已有详细介绍，这里简单列举）：
要点清晰简洁展现
所有测试故事点经过用例评审，产生质量高，研发参与感强；
版本同步保持一份
API测试脑图带来的问题：
脑图用例对测试人员的素质要求相当高
完善的脑图用例编写，需要有资深的测试人员，对业务精通、对测试技能精通，很强的思维能力；如果研发人员仅仅参考这个脑图用例进行测试，往往很多时候需要花费大量的沟通时间，其中有很多测试API的过程、措施，在脑图里面没有具体体现，造成一些信息丢失。
重复执行不变的是规则，变的只是参数，要消灭重复部分
还可以深度优化脑图用例，API接口规范，再怎么天马行空，也得有个度，应当把重复思考的部分交给工具去做，需要发挥创造力、值得关注部分，交给人工完成；按照这个测试流程，，测试人员编写完用例，去验证API接口，如果失败了，打回给研发人员重新修改，但是下一次研发人员提交测试，测试人员又得重新验证一遍，这一遍中实际没有多少有价值的思考，是重复工作，要去挖掘测试价值。另外，如果测试人员请假了，那是不是测试就需要延期了呢？消除等待、消除单点作业，改变是唯一出路，尝试过如下方式：
(点击放大图像)
图-2-Chrome DHC组件
组员通过使用Chrome DHC（是一款使用chrome模拟REST客户端向服务器发送测试数据的谷歌浏览器插件），进行API自动化测试，用例文件保存到本地并且同步到svn，简单粗暴解决重复请求问题，注意强调的是解决重复请求，并没有包括参数和结果的自动化验证的过程，还是需要人工参与，至少前进了一步，当然我们也解决了单点问题，其他组员可以更新用例本地运行，还差参数校验，数据校验等等一堆关键业务点要用自动化去突破。
俗话说：术业有专攻，DHC只是玩玩而已，并不擅长做那么多活，也做不好，更期望的是平台化。
平台雏形：没有经验，多么痛的领悟
经历了手工测试的繁琐操作，丢弃了简单的DHC，决定另寻新路，API测试最简单的场景请求参数组合产生各类别的测试用例。思路很简单，做一个WEB平台，登记API接口，填写请求参数，对响应结果进行校验，初期进行了技术选型，使用Django做Python Web开发，后台脚本执行使用开源框架RobotFramework，RF优点如下：
是一个通用的关键词驱动自动测试框架；
易于使用的表格数据展现形式，采用关键字驱动的测试方法，使用在测试库中实现的关键词来在测试中运行程序。
是灵活和可扩展的，适合用于测试用户接口；
在这个平台中，RobotFramework主要用于后台执行Robot关键字脚本，而关键字脚本，是平台通过读取YAML文件生成，该文件是通过笛卡尔乘积产生的用例，工作原理如图所示：
(点击放大图像)
图-3-工作原理
那话说回来，YAML干什么呢？为什么不是XML呢？
YAML的可读性好
YAML和脚本语言的交互性好
YAML使用实现语言的数据类型
YAML有一个一致的信息模型
YAML易于实现
听起来YAML试图用一种比XML更敏捷的方式，来完成XML所完成的任务。下面通过一段实际例子说明配置生成的YAML代码段：
主接口配置界面：
(点击放大图像)
图-4-接口配置页面
设置API参数：
(点击放大图像)
图-5-设置API参数
配置文件byChannelsDaily.yaml（列举一个参数示例）：
- byChannelsDaily:
method: get
#与服务器交互的方法
format: json
#API数据格式
url: /reportdata/flux/byChannelsDaily
#API的URL，与奇台配置文件里面的host变量组成整个URL的前半部分。
url_params:
#URL参数部分，固定写法。
#API的参数名。
required: true
#该参数是否必须（true/false）。
value: chinacache
#该参数的值。如此值是从另一个接口获取的，可在from_api设置，此处可不填。如果值是Boolean，必须加双引号。
type: string
#该参数值的类型。
#该参数值的长度。
#该参数值的最大值。-100相当于忽略此参数
#该参数值的最小值。-100相当于忽略此参数
#如参数的值是从另一个接口、global.yaml中获取的，请设置from_api，如global
#可通过jsonpath来指定取值范围，如 $.version[2:4]
verification:
success: []
#success是一个list, 它的元素也是list，success[0] = [ RF关键字 ，验证字段，正则匹配]
failure: []
error_msg: []
#错误信息集合
测试报告：
(点击放大图像)
图-6-rf测试报告
按照这个思路做下来，得到什么收益呢？
(点击放大图像)
说到这里，其实，真没有带来多少收益，思路对了，但是方向有偏差了，主要体现在：
使用了笛卡尔乘积来生成不同参数的测试用例，发现一堆的测试用例生成文件是M的单位，而且也给测试服务器带来性能问题，数量4980个中占95%的用例都是没有实际意义的，对服务器频繁请求造成压力；
(点击放大图像)
图-7-庞大的测试用例文件
通过WEB配置将YAML文件转为robot可以识别的，这种做法坑太深、维护难，参数越多， 文件越臃肿，可读性差；
后来尝试将笛卡尔乘积换成全对偶组合算法，效果改进显著，无效用例数明显下降，有效用例数显著提升；
败了，就是败了，没什么好找借口，关键问题是：
有效的测试用例占比例很低，无效的占了大部分；
没有化繁为简，前端隐藏了配置，复杂的配置还是需要在后端处理；
没有实际测试参与动脑过程，测试人员不会穷举，会根据业务编写实际用例；
平台易用性很重要：需要测试人员直接在上面编写，合理的逻辑步骤，有利于引导测试参与；
重构：发现测试的价值
回到起点，测试要解决什么问题，为什么要做API自动化测试平台？做这个平台，不是为了满足老板的提倡全民自动化的口号，也不是为了浮夸的KPI，更不是宣传自动化可以解决一切问题，发现所有bug。叔本华说过一句话：由于频繁地重复，许多起初在我们看来重要的事情逐渐变得毫无价值。如果API测试仅仅依靠纯手工的执行，很快将会面临瓶颈，因为每一个功能几乎都不能是第一次提交测试后就测试通过的，所以就需要反复bug修复、验证，以及回归的过程。另外，很多的API测试工作手工做起来非常的繁琐，甚至不便，比如针对接口协议的验证、针对返回数据格式的验证，这些都依赖于测试自动化的开展。因此，真正的目的是解放测试人员重复的手工生产力，加速回归测试效率，同时让研发人员在开发过程及早参与测试（自测、冒烟测试），驱动编码质量的提升。
回顾以往，重新梳理头绪，更加清晰的展现：
(点击放大图像)
图-8-HTTP API自动化测试图解
HTTP API传统手工测试
重复请求参数基础校验、正确参数查询返回数据校验，测试工程师没有新的创造价值，不断重复工作，甚至可能压缩其中的测试环节，勉强交付；
HTTP API自动化测试
重复步骤（请求接口是否有效、参数校验可以作为冒烟测试，研发参与自测）用自动化解决，关键业务步骤数据对比人工参与和schema自动化校验；
最大的收益，重复步骤自动化后，不管是研发人员自测，还是执行功能回归测试，成本可以很快收回（前提是你这个项目周期长，构建频繁；如果仅仅是跑几个月的项目，真没那个必要凑热闹去自动化，当然有平台的另当别论），测试的关注点会落实到更加关键的业务环节去；
总体规划如下：
(点击放大图像)
图-9-HTTP API重构规划
由于原来的测试平台使用Python编写，为了保持风格一致，从界面录入到文件生成处理依然采用Python、Django，去掉了全对偶组合算法，改为根据测试人员思维去产生用例；去掉了后台RobotFramework框架，采用Python的HTTP类库封装请求。
HTTP API项目管理Web前台
使用Python+Django+MySQL进行开发，分为项目首页、项目配置、API配置、全局配置四大部分
(点击放大图像)
图-10-管理Web
& 项目首页
介绍：列出API规范、API测试用例、定时任务数量，以及某段时间内的测试结果趋势图形。
(点击放大图像)
图-11-项目首页
重点介绍：全局变量、常用方法、验证器。
设计思路：在API测试过程中，可以切换生产、测试环境进行对比校验，如果写两套测试用例是冗余，全局变量功能，是一种在执行测试用例时动态改变用例属性的方法。
作用范围：当前项目内
使用方法：{变量名}
能在以下测试用例属性中使用：URL、请求头、请求参数
(点击放大图像)
图-12-全局变量配置页
在API用例库的URL可以直接填写：{host}/reportdata/monitor/getChannelIDsByUserName；当运行测试用例的时候，可以选择不同的参数套件，后台代码执行会直接替换，这样子可以分别快速验证生产环境和测试环境的API接口执行结果的差异。
(点击放大图像)
图-13-用例执行页
(点击放大图像)
图-14-常用方法列表页
√ 设计思路：常用方法是一个Python函数，对入参进行处理并且返回结果，例如：
gen_md5 作用是生成MD5，对应代码直接填写：
import hashlib
def gen_md5(raw_str):
m = hashlib.md5()
m.update(raw_str)
md5_str = m.hexdigest()
return md5_str
√ 应用场景：
在API请求中，有些参数例如pass需要加密处理，可以通过引入[常用方法]来解决。
在参数pass的值中直接填写：
{{get_apipwd("{123456}","ChinaCache")}}
(点击放大图像)
图-15-接口配置页
(点击放大图像)
图-16-验证器配置页
√ 设计思路
验证器是一个Python函数，如果函数返回True，则测试通过；返回False，则测试失败。平台默认提供一个默认验证器。
默认验证器是验证期望结果与实际结果（response body）是否完全一致。如果结果不一致则判断为失败，默认验证器只适用于静态的响应结果对比。
自义定验证器，如果默认验证器不能满足某些特殊的测试需求，用户可以在“项目配置-验证器”中添加自定义的验证器。
√ 应用场景：在API测试的返回结果中，可以添加自定义验证器对数据进行校验，判断测试是否通过。
(点击放大图像)
图-17-测试用例验证展示页
重点介绍：通用响应配置、API依赖库、API用例库、定时任务、测试报告
& 通用响应配置
(点击放大图像)
图-18-通用响应配置列表页
√ 设计思路
在合理的API设计中，存在通用的错误响应码，[用户名错误，返回期望响应内容]，如果所有API的响应结果中都需要重复写是相当繁琐的，作为共同配置调用即可。
(点击放大图像)
√ 应用场景
查询接口遇到用户名密码为空，可以自定义写返回内容，以及选择[通用响应配置]下的相关错误类型，例如：用户名密码为空(计费单元)，自动填充期望的返回值：
&BillingIDs&
&Result&fail&/Result&
&DetailInfo&invalid userName or password&/DetailInfo&
&/BillingIDs&
(点击放大图像)
图-19-期望返回值校验页
& API依赖库
√ 设计思路&应用场景
API-A的参数r_id依赖与API-B返回结果的某个参数（多个参数同样道理），这里登记API-B，并且提取返回参数。除了特有的变量提取器，基本信息与请求，与后面提到的API接口一致的
填写方式 ：
(点击放大图像)
图-20-变量提取器展示页
该接口返回数据如下；
"r_id": "567bbc3f2b8a683f7e2e9436"
通过[变量提取器]，可以获取r_id的值，以供依赖API-A作为参数使用。
(点击放大图像)
图-21-用例中参数包含r_id变量展示页
其中请求参数的获取如下：
(点击放大图像)
图-22-请求参数变量提取设置
测试结果：
1-显示依赖接口；2-显示为需要测试的接口，依赖接口返回的r_id会传入作为测试接口的参数；
(点击放大图像)
图-23-测试结果中展示运行时变量提取结果
(点击放大图像)
图-24-用例库设计脑图
√ 设计思路
通过自助配置：请求头、请求参数，响应头、响应结果校验，来聚合测试人员日常思考产生的测试用例。
√ 应用场景
支持HTTP1.1协议的7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。最常用的方法是GET和POST：
支持query（问号后）带参数、path的GET|POST请求
POST请求支持application/json、text/xml
示例如下：
请求头设置：Content-Type:application/json
请求体设置：保存为JSON格式
"username": "ChinaCache",
"password": "123456",
"callback": {
"url": "",
"email": []
"/news/test.html"
结果如下：
(点击放大图像)
图-25-body参数展示页
支持返回结果的schema验证
在返回大量数据的场景下，把数据格式的正确性交给程序去判断，通过之后进行人工干预的数据对比，假如返回几百K的数据，你不知道格式是否正确，就开始去做数据对比，这个方向是不对的。
"r_id": "567cfce22b8a683f802e944b"
Schema验证如下：
"$schema": "http://json-schema.org/draft-04/schema#",
"required": [
"type": "object",
"id": "http://jsonschema.net",
"properties": {
"type": "string",
"id": "http://jsonschema.net/r_id"
√ 设计思路&应用场景
定时任务是在计划好的时间点自动执行指定的测试用例。一个项目支持多个定时任务，如果同一时间点有多个测试任务，将依次执行。定时任务有两种类型：定时、循环（间隔：秒，
分钟，小时，天，周）。通过定时任务，可以做到晚上运行，早上查看结果报告分析。
(点击放大图像)
图-26-添加定时任务
测试报告&邮件通知
√ 设计思路&应用场景
每次执行测试用例（包括手动执行和定时任务）之后，都会生成一份测试报告。
报告会详细列出每个接口的基本信息（名称，请求方法，验证器等），请求信息（URL和body参数），响应信息包括headers, body, schema, content type, status code 5部分的测试结果，每一部分都有实际结果、期望结果（失败时显示）以及DIFF对比（失败时显示），当在
执行测试时出现错误，也会把错误信息显示出来 。
(点击放大图像)
图-27-测试报告列表页
(点击放大图像)
图-28-邮件通知
API实战：324个用例（包括GET|POST请求，参数有加密、依赖场景，返回结果有简单验证数据、错误码验证、schema验证），运行耗时：8min，猜想下，如果人工去跑，需要多久呢？
提速：研发测试流程改进
(点击放大图像)
图-29-使用HTTP API平台改进API研发测试过程
改进前：传统手工测试
测试用例掌握在测试人员手里，研发人员无法运行，修复bug之后，只能等待测试人员验证，交付过程繁琐、效率低；
改进后：HTTP API自动化测试
研发、测试协作同步，研发人员可以及早通过平台执行用例，验证功能可用性、正确性，测试人员可以释放部分劳动力，重点关注业务数据正确性；修复bug之后，研发人员无需等待，可以自助配置用例执行、查看结果，驱动过程质量的提升，同时做到夜间构建、邮件通知，工作时间review、bug fix。
问题：何时收回投入成本？
API项目周期不超过半年的，不建议做自动化，有自动化平台基础的另当别论，因为在最初API测试用例编写需要投入大量的时间；这种投入，只有不断进行回归验证、多次运行，成本才可以回收，往后都是收益，这个道理浅显易懂。
“由于频繁地重复，许多起初在我们看来重要的事情逐渐变得毫无价值”，在提测过程有个重要环节：冒烟测试，但是频繁的去做的话，就是重复性的工作了。
那HTTP API接口测试痛点是什么？研发人员提测之后，需要等待测试人员进行验证；测试人员发现bug，需要等待研发人员bug fix；这里就产生大量的等待成本（当然，测试人员可以切换到其他项目中去，但是这种上下文的切换成本很高）。通过HTTP API自动化测试平台，研发人员在提测之前，首先进行一轮冒烟测试，根据自动化测试用例检查结果，提升提测之前的功能质量；一旦提测之后，测试人员的关注重点落到返回结果对比上，这种研发测试过程的效率会得到很大的提升，或许有人要问，到底提升多少呢？这个每个团队的痛点不同，研发、测试人员磨合程度不同，不能一概而论，大胆迈出一步去尝试，就会发现价值；当然，往深处去想，下一步可以接入性能的自动化测试，喝杯咖啡的时间，等到自动化运行结果报告产出，是有可能的场景。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
Re: 简单的事搞复杂了
有开源吗？
Re: 简单的事搞复杂了
Re: 简单的事搞复杂了
Yang Sheep_Love_Ley
Re: 简单的事搞复杂了
请问有开源吗？
Zhou Joney
Re: 请问有开源吗？
Re: 请问有开源吗？
Zhou Joney
Re: 简单的事搞复杂了
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。