#15 楼 @chenhengjie123
1，我们也有通用的 returncode、messge、result 结构体，对这部分做了统一处理，当 returncode 码正常的情况下，会去验证 result-json 结构，否则的话就直接返回对应的 messagecode 了，结构解构目前也没有想到太好的方法，做了一个递归的通过方法。 当 returncode 码正确，就取 result 下的所有结构与预期结构进行比对验证。
2，对于上行接口这部分，除了提供自选外，也会把这种依赖集成在规则配置中，做成一个全局的变量参数，供选取。不过为了方便各种情况建议多入口模式。
3，主开发算一个人吧，零零散散整了一个月的样子，现在进入优化调整阶段；还有一同事也会帮忙做一些零散性的工作。

#35 楼 @gaopeng1106 预留有缘人吧。。。

#33 楼 @gaopeng1106 应该么有了吧

#12 楼 @zsx10110 这个你有 QQ 没，咱们 QQ 上侃~

#7 楼 @zsx10110 前台就是用 jquery 的一些简单 UI，都是测试自己做的

#2 楼 @574155375 学历必须本科嘛？

我老是对惊喜感兴趣~~

#22 楼 @jamesparagon 这个东西只能参考，每个公司都不太一样，适合自己的就行，参考这些个方式整一套思路就可以了，再慢慢去实践就好了

超爱吃榴莲的~~

不会被恶意抢注了吧。。。

职位不错哦~~

+1

可以的

#28 楼 @tbya 框架都是一步一步搭起来的，数据库验证也完全可以定义验证点，集合 UI 数据到后台进行查询验证，怎么配置拼接，就看诉求了。
我相信只要有规则，数据验证是可以解决的，不过就看坑值不值得填补了~

#27 楼 @jackie
#26 楼 @alwans
49875183

求组团啊~~~

我们初步是打算先对接口的输入、输出参数做相关配置；
根据不同业务，在新建每条用例时，根据配置好的接口信息选择输入节点和预期的输出节点 ，录入输入节点值，后台再去调用接口去分析，接口是否正常调用、输出节点是否与用例的预期结果一致，批量调用是否正常等 ；
后期再考虑加入数据和业务的关联性 ，持续集成等；
现阶段框架应该没有走太偏吧？@seveniruby

我们也正在搞接口这一块 找时间@gaopeng1106 带我一起去请教。 @seveniruby 哇，不知道我们框架走偏没有 。。。。。

好怀念 ，上家公司也这节奏 ，我好想念我的 CTO~~ 人好好 ~，~

#11 楼 @dancingcat_ 哪里悠闲啊，要合理安排工作呀~ 主要我刚来，工作还没有很饱和 0，0

#7 楼 @lihuazhang 牛氓~

#5 楼 @monkey @lihuazhang ＝ 。 ＝ 要加些工作内容上去嘛……还是指 呃……