你要曝光就把买家的信息发出来 不然又有是用么

那你来这曝光有什么用呢

对了，现在去了 OPPO

我们的 QA 从 360 过来的，号称以前是开发、懂架构、熟悉各种语言。领导后边拉测试开会评估后端性能测试，居然说在线上环境做压测。。。。

我们也是一直迭代开发。。一直很纠结要不要做自动化

插眼

有，专门对接领导的

有 SQA

有，专门有个部门叫质量部，规范各种文档归档和流程，发事故通告的

1 我们一直是迭代开发，一直有新的功能开发和调整，所以有些用例会失败

1. 有些用例对环境依赖比较大，而我们后台的环境比较复杂，所以是不是都会有一些用例因为这个原因失败

纯代码 Java+jsoup+jenkins +testng ,无需切换环境, 在 jenkins 上 job 配置不同的环境参数,一套代码; 虽是一套代码,不同的环境,执行不同的用例,如:测试环境执行用例 100% ,线上环境可能只执行 60%;

用例数看项目,最少的在 100+,数据都采用随机生成...

单接口,业务流程都有,基本每个页面的接口都有写;

1、restassured+testng+extentReport，集成放在 jenkins 运行，纯代码

2、
多环境切换：接口测试框架支持多种环境配置，通过 env（类似 spring 的 profile ）切换用不同的配置
前置数据处理：弄了个工具类自动生成一些需要用到的随机数据，比如手机号、地址等（信贷类业务）
上下文数据依赖：基本都是流程类测试，弄了一个类直接里面自动配置好整个流程需要用到的外部传入数据，用例里面按需获取
关键步骤封转：不知道你这个什么意思，如果说是怎么封装，我们采用了三层结构，底层是单个服务提供接口调用方法；中层是串起来的流程，后者基于前者扩展（比如 a-b-c 三个步骤，会 a-b 放到函数 d 里，然后 d-c 形成新函数）；顶层是用例，用例调用底层和中层的方法进行测试。

3、用例数大概几十个，主要是主流程用例，大概调用十几个接口。基本没有单接口参数组合的用例（对我们业务单接口意义不大，而且大部分开发直接用 JSR303 做参数的基本校验，所以直接 review 代码效率更高）。成功率在 90% 以上，发现十几个开发过程中多个导致环境主流程不同的问题，让环境出问题后排查效率提升到 30 分钟内（用例每 30 分钟会执行一遍，失败会直接通知），而稳定的环境和自动化的主流程回归，让交付速度提升 10% 左右吧（最占时间的还是新功能测试本身，最有效的手段还是缩小需求规模）。

1.测试平台
2.500 个接口左右
3.接口只搞正向测试，一两个用例。
4.还有一些冒烟流程的用例，这个步骤比较多，十几个接口连在一起。这种用例不多，就 20 个左右。

1.pytest+requests+allure, 集成放在 jenkins 执行，纯代码

1. 环境切换：启动命令传人对应的环境标志，执行对应环境的数据；前置数据放在 setup 里面；不同接口间的数据通过接口调用来获取
2. 用例数从年初的 0 到现在有三百多条，成功率 80 到 90 左右，看项目进展和环境稳定的情况

这类事情很多，你越是硬核越是专业就越容易被 diss，毕竟超出大家认知很多了，剩下就是做好自己，总有比你更厉害的人看到你的差异化的，多见见人就好了

这个东西，不要在意，技术是自己的后面满足自己使用就好，等时机成熟了在推动，毕竟你想推公司级使用是需要大佬在后面帮助的，平常心。

感觉是这样的...给组内做工具一类的经常会付出和回报不符；业务和功能上肯定没法大规模普及，组内又有各种稀奇古怪的需求，有的时候即使做了也没人用/没人反馈 只能放平心态吧

你看看 你每天都做什么工作啊
了解公司的业务啊
自动化测试搞起来啊 可以让自己轻松点啊

这个问题是你直系领导的问题：

1. 没摸清楚他的领导希望的方向和结果，对你的平台开发方向进行引导；
2. 平台开发后，没有及时上报成果和推广

所以对你个人，我觉得不用太在意，把自己遇到的问题、思路、成果整理清楚，沉淀下来往前看就可以

如果你这个事的出发点是想评优，那就按领导评优的条件来做事（这个一般不容易。。。）。
如果你这个事是想自己方便点，那就把评优的预期放低，自己爽了就行，别人看到你这么爽了，有时候有意外的收获。

业务支撑部门的价值体现，需要一个好的 leader。特别是你说的效能提示，如果只有测试团队能感知到，那就缺少

这步已经实现了，直系 leader 是认可的呢，上个月帮我提名了评优，可惜最后落选。
没什么意外的话，我这个月继续优化后，他还会再提名。

你说的很对，我目前确实和他们在同一个维度，存在明显的竞争关系。站在他们的角度思考，他们不接受也是很合理。
我也在想怎么样才能做到不仅仅是我一个人在进步，让其他人也能够共同进步，这样他们自然就不会抗拒了。
目前能够想到的就是：
1、让他们有人参与进来设计和开发工具。
2、先找缺乏工具的项目组，使用这个工具帮他们解决问题，提升他们的效率，同时也让大领导看到这个工具带来的效益，这样我个人也许会在团队内获得更好的影响力。

在关上别人一扇窗的同时，要给别人打开一扇门。

嗯嗯，只是最近太累了，找个树洞宣泄一下情绪，同时也希望得到一些友善的建议。
没想到一些评论超出了预期，还好很多大佬都很用心的回复了，还是蛮开心的。

说到设计的工具，功能已经是比较完善，这上家公司已经得到了验证，并且也根据现在公司业务做了适配。
不过推广到其他部门时，有些人很抗拒，怕以后用了我的工具，他们没法进步，反而只是我一个进步。
遇到这种情况，我单纯靠自己可能很难解决，所以只能靠直系 leader 的协助了。