如果为了提升效率，搞平台还不如多研究下框架如何改善，真的，框架搞好了，你会发现比用平台快
平台维护的成本是非常大的，功能越多越是
当然，如果是为了其他，累积点项目经验也不错

android 拼错了

• 密码、密钥等一系列与身份验证相关的加密、防泄漏问题

• 防伪造、篡改信息问题

• 手机、图形等一堆验证信息，控制有效时间、有效范围问题

• 用户信息隐私问题

• 客户端安全问题（如：xss、csrf 等）

有空闲时间是好的，确定自己该干的干完后，就要利用好，暗暗的提升自己，不然你以为所谓的 “大佬” 都是天上掉下来的吗？

测试开发在整个大环境下，谈其瓶颈不太现实，因为自身只是身处在大环境下的某个小旮旯里，你怎么知道其他旮旯跟你一样？而在某个小旮旯里谈瓶颈，倒是有可能，毕竟不能排除真的有些公司就是有发展瓶颈，所以这个旮旯不行就跳到其他旮旯里，如果跳不过去就多提升自己

额外话题：说到青蛙视角，我突然想到一个问题，就算从青蛙的视角变成长颈鹿的视角，也不一定能看到卫星能看到的东西。。。不过有时候就算你能看到所有东西，可现实却只需要你使用青蛙视角的技能

已经开源了，在另一篇开源篇里面有详细说明

这个不用拜师啥的，按照软件工程的步骤，先调研收集问题定好需求，然后开始拆功能，设计整体架构、数据库等，然后开始计划，先做啥再做啥，最后一个模块一个模块的功能完成拼起来就好了，具体功能实现的思路还是需要多做项目多思考多总结才会有感觉！
如果刚开始做开发，就咬着牙继续走下去，测试往深的走，不比开发简单，但往往比开发地位低！
题外话，我从学校就开始接触 java，基本保持每年至少有个自己写的小工具或项目，一直到现在差不多 6 年了，因为断断续续的，不是从事开发，所以至今感觉仍在基础徘徊，学 1 年的开发，应该只能算是踏入这个门，还是多做些小项目练练感觉，一下子整大了会吃不消

github 上面有 sql 脚本啊，直接运行就好了

如果你是测试，只在环境的问题上做动作，那还不如运维在环境的问题上思考的多，测试不先解决测试自身的问题，怎么能称为测试开发，还不如叫运维开发。。。在我看来，测试开发主要工作是为测试服务的，在提高测试效率后，再协助其他能影响到测试的周边部门开发可以提升效率的工具（如开发、运维、项目管理等），这样才能证明测试开发存在的价值，当然以上纯属个人看法

如果比较的话，建议用 postman、jmeter、robotframework 这三个工具做接口测试进行比较，看看你的平台还欠缺哪些比较好的功能需要补足，顺便可以思考一下自己的平台比这些免费产品又多了什么更吸引用户使用的功能，然后再考虑一下安全隐私性问题

不用太纠结，技术是永远学不完的，能帮助到别人的东西才是有用的东西，其他酷炫牛逼的技术在没有用前都是浮云，不管小公司还是大公司都一样，你知道他们的痛点并能解决，你就牛逼

v1.2.0（20191118）

新增内容：

1. 新增邮箱配置并发送测试报告到指定邮箱功能

修复优化：

1. 优化任务执行规则：
2. 定时任务执行器只执行等待中、开始时间小于当前时间并且没有开启循环的测试任务；
3. 按任务名执行器只执行等待中或已完成、匹配任务名并且有开启循环的测试任务

数据库

1. 新增 emial 表
2. task 表添加 isSend、emial_id 字段

v1.1.1（20191101）

新增内容：

1. 增加请求参数、用例变量导入功能，利用请求报文可批量新增对应参数名和参数值（新增用例页面）
2. 新增 Custom_toDbRCUD() 函数，可对数据库进行操作
3. 函数参数值可直接使用绑定变量（测试集变量）

新增功能
平台：
替换信息：替换对应环境地址或替换对应用例的用例变量值（包括任务前置里面的用例）（常用使用场景：测试环境切换）
产品项目管理：按对应产品项目名管理测试集

执行器：
增加按任务名执行开启循环的任务

哦，可能我的叫法跟你不一样，我用 jmeter 的界面来跟你解释一下我的环境（域名、host）、接口（api）的分别，不过大概明白你指的是什么了，如果是相同域名切换不同服务器 ip 的话目前这个平台还没支持，如果测试必须的话，建议使用 ip 来代替域名访问，或者弄个转发服务器，通过转发规则配置来实现切换（这里涉及到运维部署的活了，详细的我也不是很清楚，有兴趣的话可以百度一下）

已经开源了，初始 beta 版，欢迎试用提建议~

1、以最小单位来分解元素，例如最小单位是接口请求的话，就有请求域名、api、请求头、请求参数等，看看哪个可以统一管理
2、复用率高的有请求的元素，也有常用请求流程（如：登录），元素管理可以参考上一条，流程式管理具体管理要根据你系统设计来思考
3、目前想到两种：
1）准备多套测试数据，取值用参数化，执行的时候，根据选择的环境来决定用哪套测试环境数据
2）把测试环境的数据同步一下

1、对于 case 的处理，我的做法是把一个 case 所有组成元素全都拆开分析，复用率高的统一抽出来管理，这样，只要数据一改，就可以动全部相关联（当然，细节问题还要根据实际情况进行思考）

2、对于多环境的问题，我的做法是最后节点进行确定（测试任务设置），目前还没实现，有个想法是，测试任务设置的时候可以根据环境地址进行替换，否则使用默认环境地址

首先对图片内容赞一个，我最初全凭一个数据库关系表格设计系统，灵感一来，需要实现什么功能，直接一个 txt 记着，后来慢慢的，功能越来越多，如今这几天就开始还债的慢慢长路，开始整理功能图了

对于兼容其他工具的问题，其实有打算后面版本加导出 Jmeter 脚本的功能，不过 swagger 我倒不太想做导出它，根据它进行导入测试数据倒是我想做的，因为在我看来，swagger 是属于接口测试的上层活动，毕竟接口测试还是基于接口 api 文档的，如果反过来约束，反而不太适合，就算是 ttd，也是从最基本的单元测试起步，中间插一脚反而觉得会拖慢脚步（没怎么用过 swagger，也不知道接口测试数据导出给 swagger 有没别的什么用处？）

最后，关于在接口自动化平台加执行性能测试这个问题，我的看法是不要，性能测试最重要的是策略及分析，至于写脚本，在现有的工具下，基本上可以不用写代码就可以解决问题；就算要搞个全方面测试，完全可以集成个工具，没必要给自己增加麻烦，还不如花时间做好接口自动化核心的功能，当然啦，一般接口测试是性能测试的上层活动，利用测试数据导出性能测试脚本也是不错的思考点

加油，希望能给你带来灵感！向大佬学习 +1

不好意思，因为这星期准备开源，这两天忙着优化、补注释、写 readme，各种头痛的组织语言，现在才回复你

关于问题
1、function a() 这里是怎么实现的？
答：截图里面，那 v1 变量值是 js 内容，我用来做测试的数据，可以用 ${_Js(${VAR(v1)})}执行取值
2、关于任务调度这块是如何实现的？
答：
1）因为是刚开始，这版需求核心不是任务调度这块，所以还没研究框架，先用 ScheduledExecutorService 过渡一下，之后版本再迭代
2）先说明一下这个平台的关联：一个任务下关联多个用例集，一个用例集关联有多个用例，每个用例关联 api，api 关联域名，测试场景和用例间的关联，可以通过测试集执行优先级及测试集变量解决，所以我没增加其他流程（或者有具体测试场景问题，欢迎讨论，我看看能不能解决）
3）因此定时执行的东西也很简单，先找出符合条件的任务 list，遍历任务 list 开线程找关联的测试集 list，遍历测试集 list 开线程找关联的用例信息 list，用例信息 list 根据优先级遍历执行请求和断言并保存信息（不知道这种方式有什么弊端，欢迎讨论学习）

关于建议
1、哈哈，很多人都讲过，我前面也有说到，后面会有的
2、加密方法可以自定义函数，我弄了个类，用 java 反射机制，动态调用里面的方法，也可以用 JavaScript 文本，或者脚本文件，java 自定义类和 JavaScript 脚本只支持线下更改内容并放到服务器里
3、额。。。不知道你具体指的是什么，如果是请求断言异步回调的话，这个问题倒是值得好好思考，如果是发送回调的话。。。就不太明白想要断言或处理什么东西了，如果是扩展第三方功能的话，之前有说过，后面会有的（如果有其他问题，可是具体说明一下）
4、这个场景也不太明白，如果指跨域请求访问的话，可以看看平台关联，测试集里面支持不同 host 请求，如果是要支持测试任务里有相同 api 不同域名的请求的话，可以建两个相同的 api 和用例，api 分别关联不同的 host 就好了，如果是要换域名，直接去环境里面改就好了，如果是要同时使用多套测试环境且又不想重复建用例，那就只好等后期版本迭代啦～

1、前端真的是我弱到不能在弱的点，jquery 还是为了做这个项目才接触的，打算后面自己慢慢弄，反正不急，我这项目本身就是开源的，没打算商业化，哈哈哈
2、断言我有 7 个方法：等于、不等于、包含、不包含、正则匹配、以。。。开始，以。。。结束，也不知道够不够用，不够用后面再加
3、整个平台的关联是：任务下有多个用例集，用例集下有多个用例，每个用例关联 api，api 关联域名，层级关系必须得有，不然怎么管理
4、历史测试数据我一直有保存，就是不知道该怎么处理好，存太久了又占地方，不存着有浪费，反正这一版任务结果里面都是有历史数据的，具体优化等后面再说，日志目前没弄，我都把报错抛到控制台里，后期再看要不要弄个
5、性能测试啊，嗯，我是有考虑过，但并不打算在平台做性能测试，利用平台里面的用例数据生成性能测试脚本，倒是我想做的，毕竟不浪费用例数据是我目的之一，我不知道其他平台目的是为了啥，我做接口自动话测试平台最初始的目的是为了开发提交代码后，能自动执行接口用例，来达到回归测试，所以还是交给更好的工具去处理吧，我就不造轮子了
6-10：都是考虑过的，后期会慢慢加上去，一个人利用空闲时间 solo 项目有点慢的，而且还要保证不能猝死的，慢慢来慢慢来。。。

最后，关于独立的设计与共享这个问题是在设计系统的时候考虑过很久，有些东西不是照搬就好了，还要考虑实际应用场景，唉，很头痛，先放着（懒！）至于自动记录返回的 cookie，是不错的思考点，毕竟比起人工赋值，自动总是方便许多！（唉，又要加个需求了，泪奔～）

不同点其实是有考虑的，目前这个基础版可能不怎么能看出来，毕竟基础问题大家都是有考虑到的，剩下比的大概就是附加功能了

看的开源系统不是很多，以下问题是之前看过的系统在不修改代码的情况下是没法解决，也不知道其他系统能不能解决：
1、针对跨域拿身份认证问题，这系统在设计用例时就关联在接口下面，所以用例集添加用例时便可任意请求，无需担心跨域问题，并且在用例集里加了变量，每个用例返回的信息可以赋值到变量里，就可以使测试集里其他用例也可以调用，后期考虑要不要搞个封装功能，方便管理
2、针对返回格式不统一且未知格式情况下的问题，特地加了截取函数来针对这问题，尤其是一些关键信息需要在 html 里面获取。。。
3、针对用例维护成本问题，我把一个接口用例拆分三部分管理，一个是环境（域名），一个是接口（api），一个用例信息（请求头、请求参数、断言），域名、api 这块维护成本没什么问题，主要是用例信息这块，目前在用例里面变量这功能，不仅为了灵活，还为了减少测试数据的冗余，降低数据的维护成本，因为经验不足，还不知道在维护接口用例这块各位还有什么痛点，希望能提供建议，后期考虑优化进去
4、针对系统学习成本这块，我主要是做减法操作：没必要的管理尽量不单独弄个页面，也尽量不分开操作；能重复利用的数据就利用，没必要操作冗余，尽可能让人在设计用例有连续性（我也是很讨厌在我写用例的时候被打断的），例如，这个系统在用例设计界面，一个页面就可以解决，有什么特殊赋值的就拿函数解决（函数说明提供），不用去设置什么东西

看了一下你的建议，其实大部分是我后期打算做的
1、持续集成方面的对接，我把执行器独立出去就是为了后期分布式啊，集成 jenkins 啊，等等做准备，这也是我暂时不用框架的原因，在满足现有功能的情况下，减少没必要的负重
2、流程问题主要是在用例集解决，用例集有执行优先级设置、用例集变量设置，如果你想引用其他用例集信息，也可以使用复制功能，直接把其他用例集里面用例信息弄过来就行了，至于多个用例集一起运行，任务里面就可以添加（忘记截图了），整个系统的关联是：任务下有多个用例集，用例集下有多个用例，每个用例关联 api，api 关联域名
3、在设计这系统的时候，是有设计过产品、项目的，不过。。。最近工作比较忙（其实是懒），先弄个核心功能就好了，其他的下版本再弄，哈哈
4、同上。。。

最后，维护用例成本也是我考虑的重点问题，推动规范统一自然是最好的选择，但现实是残酷的，理想永远在书本上，不能把希望完全寄托在外部（开发、产品、运营、老板等）身上，在做好自身时，降低外部因素对用例成本的影响，才是做这系统的初衷（也不知道能不能成功，当个实验）

之前我也想过此类问题，框架还是平台？

其实没有硬性的选择，要看面向的对象：
假如是土豪公司，招各个都是有技术傍身的人，用框架写代码，各种测试场景想怎么飞怎么飞；
如果是穷公司，考虑各种人力成本，只有极少数会点代码，其他全是手工测试，难道还指望那几个人敲代码去维护庞大的用例场景？
血的教训告诉自己，少数人牛逼没有用，没有一个团队的支持，再怎么厉害也是白费

真好，公司能推的起自动化，那就是对自己最大的鼓励了

哈哈，之前我也考虑要不要用 testng 的，但想想还是先把核心问题解决，等之后版本再弄，感谢推荐神器，搜了一下，感觉比 testng 方便，尤其以后集成 jenkins！