测试管理 2018 第四季度马上结束了,回顾这一年做的东西,除了远程真机外,其他的都没落地,现在真的是很迷茫

heygrl · 2018年11月15日 · 最后由 不二家 回复于 2018年11月22日 · 1619 次阅读

年初基于 STF 二次开发,实现了远程真机,这个落地效果超出了预期;
基于 360 火线扫描实现了代码增量扫描,将增量问题和责任人在平台上展示出来,没有落地;
实现了打包平台化,没有落地,大家还是习惯于原生的 jenkins 打包;
后基于 APM 性能数据,拿到每个包的性能数据,生成性能报告,没有落地;
自动化测试基于 jenkins 接持续集成,主干每日定时跑自动化,没有落地;

某互联网的测试开发工程师,职级在团队里面算是中等,前段时间从某管理平台 PM 角色被抽出来了,领导说去搞移动端专项,从现阶段看,弄什么都落地不了,同时已经没有新的 idea,不知道要做什么,即使有想法跟其他人交流,要么就是困难重重,要么就是没有立项的意义,性能大家不 care,crash 率老板也不 care,每天写日报都没有实际输出,工时在组内也算是倒数,都不知道要怎么挨到过年,领导也支持转岗,感觉要被淘汰了,中年危机要提前了么

共收到 24 条回复 时间 点赞

很多执行层面的落地,单枪匹马是很难落地的。比如我,这一年抽空,研究代码静态扫描、apollo 配置管理、docker、infer 之类的技术,也搭出来了,但是没有落地到实际生产。原因很简单,我们这个团队现阶段不适合,业务价值为首要目标,业务优先驱动下,优化性质的工作,实际上并没有多大的投入产出比,就算有,也没有人手来做。比如要推 apollo 配置管理,框架是优秀的,但是我们的的代码框架已经固定,生产若干服务,要换下来,折腾个把月,还面临着生产不确定的风险,自己评估了一下,找几个技术到老和 leader 开会 3 次,我自己就放弃了,因为它落地真的在公司这个阶段不合适。这一年,我计划中所有落地的都是我自己能控制的技术,对团队干预最少,风险最小,投入产出比合适的。楼主说的性能大家不 care,这个对团队来说就是在欠账,等业务规模上来,迟早要还的。要落地,感觉还是得沉到业务里面,找真的痛点啊。。。。中年危机真到了,加油干

heygrl #23 · 2018年11月15日 Author
另一种蓝 回复

其实老板不怎么了解移动端业务,所以他也不知道怎么落地啥的

分析一下为什么都不能落地? 遇到的阻力是什么?
好奇楼主的这几个项目都是同时开展吗?

同感落地之艰难,楼主好赖是做出了东西,我这空有 title 啥都做不出来的才叫纠结,更别提落地了😩

没落地的原因说出来,大家一起帮你想(kan)办 (re) 法 (nao)

有的公司尾大不掉,部门之间事情很难推动,什么事情都是领导拍脑袋,底层的人即使有想法,也只能是想想。

heygrl #17 · 2018年11月15日 Author
simple 回复

因为现在上面领导不关心这些,不是技术型领导,不懂业务,所以业务都是我们自己去想,做出来了,业务线的同学们都只是点点点,并不关心工具的使用

heygrl #16 · 2018年11月15日 Author
hello 回复

是的

heygrl #10 · 2018年11月15日 Author
Jerry li 回复

就是今年一个一个开展的,自己想的自己做的,可能现阶段对只有一个产品的公司来说弄这些并不能提升多大用处把,业务线的同学也都仅限于功能性测试

heygrl 回复

关于效率提升方面,不同阶段的需求是不一样的,尤其是能效团队的同学,在准备做一件事之前一定要和业务线的同学达成一致,否则咱们造出来的东西很容易得不到认可或者满足不了需求等等原因而流产,辛苦弄了大半年发现没人认可,积极性和成就感倍受打击。
不过话说回来了,既然你有时间能捣鼓东西,说明团队是给予了你时间,无论如何也算是个人的收获和产出,你后面不光要考虑系统该怎么实现,还要关心需求方的痛点是什么。(360 火线就是这么推广的)

heygrl 回复

我们也是做产品的团队,说一下我们今年做的事情吧:

  1. web UI 自动化平台。
  2. 在 web 平台集成 ATX 执行 android 测试 UI 自动化。
  3. Jenkins + allure+pytest 组织接口自动化测试。

关于落地:
因为我们是小团队,自己开发自己用,所以不存在怎么落地的问题,反正就是日常工作中遇到痛点,就想办法解决;工具做好了就用,边用边调整。 工具不一定要做到尽善尽美,能最大力度匹配和解决团队遇到的问题才最重要。

如果楼主同时开展那么多项目,都卡在最后的落地, 那我觉得需要分析一下原因:

  1. 是否是伪需求? 例如上面提到的打包问题,既然 Jenkins 已经可以打包, 而且大家都用熟了,是否有搭建一个打包平台的必要?
  2. 是否已开发完整? 例如自动化测试, 是否已完成了完整的功能开发和环境搭建,能让用户马上使用?
  3. 关于推广落地: 我理解代码增量扫描和 APM 性能数据这两个是不需要测试执行人员配合、直接拿到代码仓库权限或者打出包就可以跑的, 为何也存在落地的问题? 或者如果落地执行的工作量不大,能否自己先做起来,有了报告结果之后再找领导谈推广?

把你的远程真机分享一下吧 哈哈

楼主,可以分享下你的 STF 二次开发思路👍

heygrl #10 · 2018年11月15日 Author
simple 回复

对对对,后面这个管理平台就是和业务线达成一致才做的,以前有什么 idea,都是默默无闻的做,最后他们也不关心,落地困难

阿森 回复

有分享哦

heygrl #17 · 2018年11月15日 Author
Jerry li 回复

确实很多东西都是结合大厂来看的,在大厂适合,在小公司确实不符合,之所以做了打包平台化是先前从大厂回来的,当时一来这个公司,发现还在 jenkins 上操作,分支很多,job 没法管理,想着搞持续交付平台,所以先把打包这一环节平台化,结合打包做一些自动化测试,覆盖率统计,APM 性能报告啥的,结果大家不还是不习惯在平台上打包(里面还牵扯到一些 KPI 问题,有些人专门维护 jenkins 打包的,不愿意放手交接给我们),因为不在这里打包,这些功能就白费了

heygrl 回复

习惯比较难改,但是如果你的功能像上面说的尽善尽美又能解决一些痛点问题还是很好落地。
需要落地的东西一定不要把 level 定得太高。

heygrl 回复

打包平台化是不是意味着将 Jenkins 后移?我想请教,这样相对于直接在 Jenkins 内操作有什么优势呢?在你写的平台打包不是一样会有分支选择,Job 管理,证书管理,代码拉取等等的问题?你有什么很好的解决思路吗?

楼主想问下远程真机是啥意思?STF 不是本来就可以实时显示真机画面的么~

zlp 回复

一个意思

heygrl #22 · 2018年11月20日 Author
不二家 回复

可以参照下业内持续交付平台

和老板聊聊他 care 的,把该落地的落地。

heygrl 回复

可否举个小例子,😆,我搜了一下不知道哪些是对应描述的内容

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册