• 我们主要是 web,我们大多数是因为环境不稳定。 因为我们的产品关系。 会起非常多的分布式任务, 这些分布式任务有 hive 的, 有 spark 的, 有 k8s 的。 环境依赖很重,这些分布式系统本身就有抖动, 比如 k8s 某个节点出现点问题, 可能就有一些 case 直接失败, hadoop 如果出现 IO 抖动, 可能任务就超时了, 训练某些模型的时候,需要从外网下载数据, 如果当时网络卡了一点, 可能也失败了。 当然还有一些 case 就是不稳定, 有些 UI 交互很恶心, 就是非常不稳定的。

  • 基本上 UI 自动化稳定性超过 95% 的地方, 要么是用例太少, 要么就是把不稳定的直接删除了。 我们之前维护过几千多的 UI 自动化测试用例, 后来稳定性在 97%。 但是你要知道我们曾经删除了上千条不稳定的测试脚本。 想不删用例达到 95% 很那。 我现在的项目目前是 1700 条 UI 自动化测试用例。 这一次我们没有删除不稳定的 case,每一次跑少说也是几十个 case 的失败。 都是因为不稳定。

  • 第四范式

  • 其实路径有很多的,在不同的行业和领域下,需要学习的东西是不一样的。 当然了通用的能力都差不多, 比如需要学习 python 和 java,在语言的基础上写自动化测试 (UI,API) 和自己写点小工具和平台,还有 linux 基础技能这些都是作为测开需要的通用能力, 属于基本上在哪都用的上的。 但是接下来需要我们在某个领域上进行深耕,学习更底层的技能。 就像我之前说的 k8s,因为我是混容器圈的,这是我选择的领域,所以这个领域内的所有东西都要去学, 包括 docker,k8s 以及在他们之上构建的容器生态里的很多开源项目。为此我专门去学了 golang 语言,并用 k8s 的 client-go 自己编写 k8s 的 CRD,controller 以及编写针对 k8s 的混沌工程项目。 这些都是在容器这个领域内需要用的技能。 它跟通用技术不一样,它是服务端技术,并且是特定领域的服务端技术,虽然它跟通用技术不一样,这些技术被限定在了一个领域内才能发挥价值。 但是往往拥有比较深的领域技能才是通向高阶测开的门票。 所以选择一个领域比较重要, 我之前确实说要多学一学容器的东西,比如 k8s。 因为这是一个之后服务端的主流技术,到今天可以发现 k8s 的势头非常猛,各个厂商的容器化已经成了定势。 而且从最近开源出来的项目来看 k8s 已经侵入了 AI,大数据,分布式计算等领域, 所以我一直认为这是一个值得去拼的领域。 还有其他领域,比如大数据领域,AI 领域。 就看你个人如何选择了。 当然这些是从我的经历和角度去看的。 我没有移动端的经验,所以不知道移动端有什么领域值得去深入研究。 你要做一个选择, 选对行业,挑对公司, 努力是排在这两个之后的。

  • 求教不停机更新如何实现 at 2019年05月27日

    冗余啊~~~ 多实例设计就好了。 更新的时候在备上升级, 然后一切换。

  • 恩~ 我理解楼主纠结的是如果要重复进入 125 分别进行操作 1 和 2,重复的工作会带来运行时间的延长等问题。 那是其实在自动化项目里, 可维护性 > 性能 。 适当的把 case 进行拆分是必要的, 不能把太多的逻辑放在一起。 性能问题可以交给分布式运行策略来提升

  • 一般都是业务形态不一样导致的。 尤其 TO C 和 TO B 的发版周期差别巨大。 在 TO C 的业务上,隔几天发一个版本都是正常的。 但是在 TO B 领域动辄几个月甚至一年。 面对的用户群体不一样, 节奏就不一样。

  • selenium 定位问题 at 2019年04月30日

    是不是不在一个 frame 里?可以下载一个在浏览器上使用 xpath 搜寻控件的插件试试

  • 其实我没明白, 自动化上不去,他们是怎么有胆子重构的

  • 不是调用其他 case, 就是你应该封装一个业务逻辑层。 case 是去调用业务逻辑层的东西的。 比如所有 case 都要登录,那就专门有个地方是写登录的逻辑的。 比如有很多的 case 在测试的时候依赖一些数据, 比如要测试查询订单那就要先有这个订单存在。 那么就可以专门有一个地方是封装的下单的逻辑。 理论上,case 要是精简的。 大部分的逻辑要封装到业务层里去。

  • 第一个楼主纠结的应该不是独立性, 而是纠结一个 case 依赖的太多其他业务逻辑到底是不是好的。 其实你都已经是 UI 自动化了, 测试的就是系统集成, 这时候为啥还要避免这个情况呢。 case 尽量避免依赖这是单元测试的思路~ 所以才有各种 mock 技术么。

    第二个就是测试数据到底是应该预先创建好的,还是实时调用系统功能来创建的。 看你们的情况了, 个人建议是团队水平不错就实时调用系统功能创建 (我们团队目前是这么做的),水平不好的就预先创建吧。

    PS: 建议楼主现阶段尽量少看这些纯理论书,没啥好处。

  • 其实现在 kubeadmin 已经比我写文章那会好用多了~~~ 我写的时候还是阿尔法版本, 现在应该已经正式 release 了。 用那玩意装 k8s 还是挺简单的

  • 没用过 minikube。。。。为啥不直接正式安装。 用这个玩具呢。。。

  • 简单不代表就好。。。。。如果真的好, 不会基本所有 liunx 发行版本都用 systemd 作为默认选项了

  • 现在还有人用这东西么? 不是都用 systemd 了么

  • 当你用坚持 这两个字来形容你的工作的时候。 就是你快坚持不住的时候了。