我觉得不是数据类型校验不重视，而是由于数据类型不一致引起问题的情况比较少，而且就算不用 jsonSchema 也很容易发现。

举个例子，某个字段表示当前用户数，定义是 number ，实际传了字符串。会出问题吗？不一定，服务端拆装箱会自动把字符串改为服务端应用里的数字类型。如果这个字符串无法转为 number ，服务端拆箱就会自动发现并且抛出异常，没啥特别去测试的必要。

至于返回值，前端也是类似的情况，类型错得离谱直接会影响业务逻辑立即被发现，错得不离谱其实也没关系。

哪些业务最需要造数据，他们现在现状如何，要用上造数平台成本如何？
已经有脚本造数据的业务（一般也说明他们对造数据需求很大），目前用脚本造数据有什么痛点，上了造数平台可以解决其中哪些？

可以想想这两个问题。个人理解关键点是这两个。

能支持动态 java、python 脚本、jmeter 脚本的执行

部分业务线自己有自己的造数脚本等

快速变化的业务和平台自身稳定性之间存在矛盾

这三段话感觉有点矛盾。工厂支持脚本执行，业务本身也是有自己的造数脚本，为何业务要用的话会需要造数工厂跟着业务进行变化？

我们之前的经验是，先统一接口测试脚本框架，等到大家都熟悉后，再基于框架扩展 web 界面，达到直接通过 web 界面调用流程型用例造数据的能力。业务组接入只需要加点各个造数功能的定义就可以，成本不高，实现直接复用本身的接口脚本。

不过要推广到多业务线，要看其他业务线的需求如何，以及接入是否能给他们带来收益（我们这里接入得到的收益是前端开发、客户端开发、产品都能直接自助使用，不用再找测试去执行脚本，减少沟通协作成本。有这方面痛点的还是比较愿意接入的）。如果本身大家就有一些现成的东西，前期选型调研可能就要考虑到大家现成的内容，尽可能减少大部分业务的接入成本。

没写完？

ps：同事的可以抓到

同事的和你的有什么异同（比如手机系统差异、抓包方式差异等），可以分享下，然后再分析下原因？

如果安全要求高，一般会在 app 内置 https 证书校验功能，如果发现拿到的证书和实际服务器证书不一样（要抓 https 包，代理一定会在中途换掉 https 证书为自己的证书，否则无法把内容解密为明文），会认为网络不安全停止通讯。

可以参照楼上的解法。kwargs 本身就是个字典了，key 是参数名，value 是参数值。

我理解你这个需求的关键点是 2 个：

1、如果有传入这个接口参数的变量名 + 值，那就用传入的
2、如果没有，那就用程序里内置的默认值

**kargs 就很满足你需要了。参数名和值都由调用者自定义，只要用的人名字没写错，那就是一一对应的，可以用 for 循环遍历。

不过这个只能解决你最底下函数的问题，倒数第二个函数还是得写很多，所以本质上是这个模式有问题。不知道你具体业务上的场景是怎样，不好给更多建议，可以的话可以从用户需求角度说明下这是个什么功能，要实现什么效果？

wx.login() 应该是调用微信 app 通过 jsbridge 暴露的 Js 接口执行的，必须在微信 app 内调用，否则无法执行（类比一下，就是 python 自带 的 print 函数得在 python 环境下运行，你拿个 java 去跑这个函数会说无法执行的）。前端开发和你说的执行环境应该是指这个。

这个除非知道微信内部是怎么执行获得 code 的，否则绕不过。个人能想到的思路主要两个，仅供参考：

1、通过 UI 自动化之类的方式，在微信 app 里完成 wx.login 步骤，获得 code（可以搞个 alert 之类的弹窗弹出来）
2、服务端提供另一种登录入口（有点类似留个非小程序鉴权的后门，线上环境需要固定关闭这个入口），并生成自己内部的登录态且不与微信的信息关联。接口自动化从这个入口获得登录态，进行后面的业务逻辑调用。

使得传入一个变量 返回这个变量的变量名

这个需求好奇怪。原理上，运行时传入给函数的一般是变量的引用或者变量的值，本身就没有变量名信息。

**kwargs 打印的 “变量名”，实际是传入函数时给的参数名，不是本身变量名。比如

def get_para_name(**kwargs):
    print(kwargs)

b=1
get_para_name(a=b)

打印出来的是 a=1 ，b 这个变量名已经没了。从原理上只能想到用抽象语法树之类的静态工具来做，解析调用函数位置的语法树，找到当时放在参数位置的变量名信息。

能否详细说明下场景是什么？想象不到这个需求的应用场景。也许不一定要用这么复杂的解法？

自动化测试 ②、会限制软件的发展；③、对测试质量依赖大；

这两点不大理解？

两者不一定冲突的，可以先去找想去部门那边问下，了解下情况？不过确实如楼上所说，先想清楚自己想要什么，愿意付出什么，然后尽快做出决定。

多说一句，趁着还没生娃多努力，生娃后你可以掌控的时间就更少了。

我感觉自动化的作用不大呀，工作这么久我还是觉得点点点起到的作用最高。

可以详细分析下为什么会有这个感觉，作用不大的原因是什么，怎么调整才能起到作用还是本身就不适合？

不否认新功能测试绕不开点点点，但不代表只能无脑点点点。测试技术也不只是自动化，mock、fuzz、技术方案评审、代码 review 都能很有效的帮助用更低的成本、更少的测试范围来完成新功能测试。

要让自己价值更大，不能只是说我有 abcd 技能，而是针对各种具体问题，能从自己技能库里找到最合适的手段去解决。可以去想一下，针对 “这一个需求，要想减少 1/3 的测试时间，应该怎么改进” 这个问题，可以怎么解，然后去实践确认下是不是真的可以这么解。

+1，已经屏蔽了匿名区。

其实道理很简单，大环境是老板们都想尽可能用更少的人做更多的事，毕业生能干的就不会找社招生干。然后现在发现测试具备代码能力确实能更好地保障质量和提高效率，成本也不会高多少，也一样能招到人。自然就会逐步都加上这个要求了。

建议参考 robot framework 的 Library 方式，框架提供一种统一的模式去调用不同的库提供的不同能力，减少新库的学习成本。

不过如果预计要扩展的库不多，楼上说的是最简单有效的，由业务方法去分别调用不同的库，而非框架。如果说想要控制避免不同项目用不同版本或者不同解决方案，引起不一致和高维护成本，也可以框架里基于 request 封装一些 http 操作的方法，供业务项目使用。

楼主感到迷茫，感觉更多是想跳槽但因为年龄到了未婚不好找；维持现状也不大好；换项目组把性能和稳定性测试都做好好像也意愿不强

作为 13 年毕业的过来人，分享一些愚见：
1、迷茫期最需要的不是怎么去做长远规划，而是下决心做出具体的改变。其实前面提到的可供选择的 3 个方向已经很清晰了，需要的只是做出选择然后努力去冲。至于选哪个，个人觉得除了维持现状其它 2 个都挺不错的，最终还是要靠楼主做决定和下决心。
2、找榜样，找身边能接触到觉得能力不错的人，多交流学习别人的工作学习方式，以他为榜样。有榜样后会不那么容易陷入迷茫，榜样就是方向。
3、多思考总结和做分享，比如学到某个技术或者某个觉得有意思的点，分享到社区或者自己博客之类的。积沙成塔，以后你找工作什么的，这些积累能给你带来很好的加分点，也容易形成你的影响力。

问题已修复，麻烦你再试试确认下？

嗯嗯，认同磨合这个点，每个开发都有自己的特点，只要能做到互补并不一定就是坏事。

不过有一个点可能还是想讨论下，我接触到技术比较好且比较上进的，会以出低级 bug 为耻，所以自测一般会做得更完善，确保不会出低级错误，避免影响优化带来的好印象。优化后容易出错的容易是炫技型的，这种埋得坑可能更深。。。

如果是我的话，会分两种场景看：

场景一：连冒烟都跑不过的
沟通方式：调整下提测方式，改为提测的时候直接到开发座位，开发操作演示冒烟流程（控制在 30-60 分钟内可以操作完，服务端要部署到测试环境中）是 OK 的才算正式提测。如果现场都演示不过的那现场打回，开发修到演示过了再算作提测。

场景二：冒烟能跑过，后续修复 bug 中出问题
沟通方式：提醒开发做好自测，记录缺陷的时候也标记下哪些是修复 bug 引起的。同时也和开发沟通下，看是不是有什么困难导致没法做好自测（比如多项目并行、此场景不知道怎么自测）。直接沟通无效的话就向上级组长汇报，带上修复 bug 引起新增缺陷的数量数据增强说服力。

已经工作 7 年多了。

如果只是单纯批量远程到 windows 并启动 Jenkins agent ，直接写个脚本循环 ssh 到 windows 上，下载 agent 的 jar 包并运行起来，是不是比较简单？

很认同复盘的目的之一是对未来的优化。至于对认知的修正，个人觉得改进下统一认知的机制，遇到分歧能更快速统一认知就好。互联网项目基本需求文档不可能事无巨细，有分歧很正常，能快速统一认知就行。

个人经历，复盘后最大的难点在于如何落地复盘得出的结论，这方面主要有几个原因：

1、这个结论本身比较虚。比如很多时候有些代码里的隐藏问题，会得出一个 “加强代码 review ” 这种结论。但实际这个结论实际操作很难，怎么算加强，多看几次？谁去加强，leader 还是开发自己？连怎么确认是否有落地都难，那落地就更难了。

2、这个结论操作起来不符合人性。比如楼主举的例子 “分页不传参数的 BUG 多次出现” ，有时候产生的结论是 “以后每次分页记得传参数” 。说实话，这类 bug 容易出现，是不是说明这个地方写起来不符合人性所以容易遗漏？那是不是应该改进写法，比如这个传参数内置到分页库里，而不是开发每次手动加？

3、结论具体了，但没有负责人和约定的完成时间，或者就算有也没有人监督。复盘产生的结论很多时候不是业务中的日常事务，更多是额外增加的优化工作，优先级不高。如果没有明确负责人和约定的完成时间，可能项目一忙起来就都忘了。没有监督人在接近完成时间时及时催促提醒，也很容易导致超时甚至不了了之。

至于解决么，前两个主要依赖复盘主持人带节奏，主持人要注意不要得出这两类结论。第三个主要就是靠 leader 或者指定的监督者了，也可以依赖制度，比如周会的时候最近 1 周到期的改进项需要明确同步目前进度。前期大家还没自觉需要多刻意提醒，有了自觉后会逐渐变好。