还有的是跨页面的业务流程的封装。 就是在 page 这一层上面还会有一层。 比如有一个比较长的业务流程是涉及到好几个页面的， 偏偏这个业务流程还非常常用， 很多 case 都要用。 所以就专门封装一个业务层。

现在的 page object 都是封装业务逻辑了， 不再只封装元素了。 也就是比如你这个登录页面， 就有一个 login 方法， 你 case 是调用这个 login 方法， 并不直接跟元素交互。

慢慢磨吧~~ 加油

我不建议普通的测试人员学 AI， AI 是只有大厂才有成本玩的东西。 普通测试学了基本没什么用。

翻译链接失效了

据说好像是测试开发做的， 我还跟作者聊过。不过我倒是没问过他到底是开发序列还是测试序列的。 但是这个东西是测试开发的我觉得也挺正常的， 因为难度也不高。

楼主和评论中的很多同学质疑的假大空也好，KPI 工程也好我觉得都质疑的挺合理的， 有这种质疑很正常。 就像我前两天还在质疑就目前看精准测试和 AI 测试的实际用处到底能有多少，我还真跑去跟人家讲师说去了 (虽然我自己就是测 AI 产品的，但不妨碍我目前对于 AI 在测试领域中的应用表示悲观的态度)。 我质疑的点其实主要就是成本大于收益。 我相信好多同学也是觉得这些高大上的东西真落地后到底还能有多少效果， 尤其是 AI 这种这么玄学的东西。 虽然我对于 AI 在目前的测试领域用的应用处于悲观状态， 但是这不妨碍我支持大家去研究这个方向。 我记得我们公司的 CEO 曾经说过， 科学的发展都是一开始不计成本的先把事情做出来，然后再是想尽一切方法把成本降下来。 这就好像手机一样， 我小的时候有几个家庭能买的起大哥大的？ 当时大哥大成本太高了，很难能普及开来。 但是到了今天我们已经人手一台智能机了。 这个就是科学发展的规律。 所以如果以后 AI 发展的随便用个工具人人都能建模的时候， 我们再来看这些 AI 的测试方案， 也许就不会这么想了。 我们现在仍然是处于探索阶段， 我们需要的是更多的可能性，而探索阶段付出的成本就是很高的，就像制药业一样， 砸了几个亿研发了 10 几年的药最后还失败了的大有人在。 但这不能阻碍我们探索更多的可能性的脚步。 科技的进步就是这样一步步探索出来的。 附一个我之前跟我这边的同学的聊天记录吧，当时他担心搞的方案会做砸了， 所以我在开导他。

我认为做测开就是这样的， 去探索所有的可能性， 就算最后是失败的也不能停止脚步。 正因为我们之前尝试了， 所以现在才有那么多有用的测试技术， 但是这些测试技术在一开始探索的时候，可能都是饱受争议的。 所以我质疑归质疑，但是我一直保持开放的态度。

最后虽然测试行业里关于这些东西的争议一直就没断过， 但是总体来看我觉得这一行已经是对大家很友好了， 喜欢技术，有野心的同学可以在各个名企发光发热。 不喜欢写代码也没有那么大野心的同学也可以在这行里活的不错，因为不管再怎么强调测试技术的重要性但还是有大把的中小企业，外包公司和事业单位都是需要普通的业务测试的。 我媳妇在 29 岁的时候也能找个 18K 的纯手工测试的工作呢， 前几天我一个朋友也找了一个 20 来 K 的纯手工测试工作 (他已经 32 岁了,坐标北京)， 我觉得这样也挺好的。 测试行业能兼容不同人群的需求， 大家根据自己的情况进行选择就好了。

拿当前时间戳作为随机种子再加上随机字符串， 怎么会撞车呢。。。。

啥意思？

我们这的规范是同一个环境， 自动化测试跑 n 遍，要求每一次必须互不影响，互相不依赖。 所以我们所有的数据都是在代码里创建的。创建的时候名称，标题，id 啥的生成必须是随机字符串。 所以我们基本不考虑删数据的事。

先从自己的项目下手， 让你的 leader 先认可你， 然后再辐射到其他的团队。

这个怎么说呢，要从几个角度看。首先你可能把顺序弄反了。 如果你想自己推动一些东西，前提是你已经在团队里走到一定的位置有了足够的影响力。 你现在没有权力就是人微言轻， 需要靠领导帮你推动是正常的。 就像我在推广提测系统的时候那是在约束研发给研发戴上镣铐。 这一点没有测试总监和研发总监同时点头是肯定推不下去的，就算他俩点头了在执行的时候也是各种阻力和不配合，这个是正常的，做测开要习惯与人打交到。 你开发的每一样东西想推广出去都不是那么容易的， 就好像销售想把产品卖出去也不是什么容易的事一样，不是产品好就一定能卖出去。 所以我们总说要提升影响力，因为同样的话在不同人的嘴里说出来，效果是不一样的。

第二个是你现在仍然是站在跟其他人竞争的位置上思考和推动事情的，就像你说的其他人不喜欢用，怕用了以后自己没有机会提升了。 人家这么想是人之常情，说白了你们还是竞争关系。 在这种情况下你推什么人家都抗拒是非常正常的， 因为他们觉得只要给他们时间他们也是有能力研究出跟你一样的东西或者替代品来用的，只要自己不是一点希望没有他们就会想自己试试来提高自己。 也就是说你们还是在一个维度上的。 也许你的能力比他们高，但是还没高到能跨越一个等级的程度。 所以在开发工具上你们还是竞争对手的关系。 这个阶段你自己开发工具自己用没问题。但是说服其他团队的人用，遇到阻力是正常的，没阻力才是不正常的。 所以我说你要尽快的给自己升一个 level。 那时候你看一个事情就不是一个工具一个框架的角度去看了，而是从整体上看，从体系上看。这时候你产出的东西都是影响产研体系的，跟他们不是一个维度的东西自然也就不会产生竞争的态势。 比如我在我们这里设计持续集成的时候，我关注的是所有团队按我定的 pipeline 框架来， 至于 pipeline 里到了测试步骤的时候你用的什么测试框架我不管， 我只规定了 report 格式要统一，方便系统抓数据。 比如在项目管理系统里我是要去抓研发环境中 dailybuild 的测试通过率来设置卡点 (通过率低于 90% 不准提测)， 所以 dailybuild 里的自动化测试要怎么做也是每个业务线的 QA 自己来定，我并不干涉。 所以你看我这里不存在你遇见的一些问题，因为我们不在一个维度上工作， 我着眼于产研体系，他们着眼于具体的事务。 我这边推什么事他们都不会觉得我侵犯了他们提升的空间，相反他们还很配合。

第三个是我们做事得给其他人留活路， 不能把事情都做尽了。 让其他团队的人觉得用了你的东西自己就没有发挥空间了，那人家肯好好配合你才怪了。 一个大馒头得掰开了分给每个人吃， 你别一个人吞了。 首先你要是都自己包圆了全做完了， 那你的精力也就是扯在这一个事情里了， 长期陷入一件事情里是不利于发展的。 其次这种不给他人留活路的做法也会让其他人不爽。 还拿我自己来说我这边发起的工具平台框架什么的这几年来没有 100 也有几十了， 要是每一个都我一个人包圆了我也做不完，光撸代码了我也没时间去思考怎么改进产研体系了。 所以我现在都是初期自己做一下， 技术都熟悉了就直接跟业务线上的 QA 谈，他们愿不愿意来做。 像一个 pipeline 里涉及了好多东西， 怎么部署微服务， 怎么部署中间件， 怎么初始化环境， 怎么跑自动化测试， 怎么保证研发和测试环境一致性等等等等， 每一个都是挺花时间的， 这里面我就做了第一个 pipeline 后， 然后就丢给业务线的 QA 们了， 上面说的每个东西都是不同的人做的。 我希望有人帮我分担工作， 他们希望有提升能力的机会。 一拍即合，这样不是很好么。

我觉得后面的留言里有小部分对楼主有一些恶意。 楼主也许现在还没有设计出成体系的可以辐射到所有团队的东西来。 但谁也不是一上来就是高手的， 人在成长期的时候除了鞭策也需要鼓励的。 能开始开发一些工具就说明楼主已经迈出了非常重要的一步，而且效果还不错。 继续努力下去，增加自己的技术和影响力，最终会成为整个质量团队的灵魂人物的。 届时站的位置够高， 视野更广，就有机会去设计可以影响公司产研体系的东西出来。

楼主也不必太过失落，人生不如意十之八九，要习惯。 很多人失败在自己的心态上，遇到挫折后就不愿意继续前进。 你得知道团队大了以后上面的大领导是不关注底下人都具体做了什么的。 他站的位置更高，他要管理更多的团队，所以他更关注的是跨团队的协作设计，可以影响整个产研体系的方案。 所以从他的角度看他是没错的，他没有时间关注和评估他下面的一个小 team 的一个工具的产出和优化。 如果有人能做出更大的影响力的东西来，你自然会被比下去。如果大家都差不多那也要看谁的直属 leader 更给力，或者谁的业务更核心。 所以楼主要么你混派系站队伍，要么就作出吊打其他人的东西来，让影响力大到直接让大领导关注。 我希望你走的是后面这条路

这种事怎么说呢， 每个人的期望是不一样的。 每个人站的角度也是不一样的。 看你的描述其实这确实是一个效能提升的点， 从你自己个人的角度来看， 你感觉从这个点上提升了很大的效率。我觉得在你们组内适当表扬你是没问题的。 但是从整体上来看，这就是一个点的提升而已， 很小的一个点。 不知道你们评优的名额有多少， 但是优秀的肯定也就是 5%~10% 左右的占比吧。 这个点在季度的优秀名额上确实不占优势， 要知道 3 个月是很长的时间了， 看你们一个部门就 10 几个人了， 所有部门加起来大几十人吧得， 3 个月时间足够不少人做出相应的成绩了。 他可挑选的东西太多了。 说白了就是上面看不上点状的提升，每个人坐的位置不一样，眼界也不一样。 如果你做到了那个位子上， 你也会看不上的。

那这样是不行的。 你得在 allure 的装饰器里填写的字符串上做手脚了， 别用写死的字符串， 用变量。 外部你运行 case 的时候传递设备名称或者别的唯一标识符进来， 然后生成这个字符串

想象不出来他的目的。。。每个人都不一样， 别老猜他什么想法了， 没准就是他今天心情不好， 或者面试前没准备， 就随便先问了一个拖延时间， 然后自己赶紧现场看简历

因为你这俩 case 的名字是一样的， 它认为是 retry 的结果。 你 case 换个名字就行了

在模型领域不说正确性，都是说效果的。 比如精准率，召回率。 往模型发数万数十万数百万的数据，在大量的数据下统计预测正确的概率有多少。 是通过这个方式来评估模型的。

allure 好像现在还是做不到把

我记得是可以的， 就用 allure commandline 启动的时候就有个参数是指定端口号的

allure 产生的 allure-results 放到不同的目录， 再使用 allure commandline 去指定从多个目录生成 report 就好了。 jenkins 上也有 allure 的插件。 很好做的

rest allure

文章中描述的失败经历里的那一段感觉挺那啥的， 测试 repo 里维护不同的分支以应对不同的版本和环境是最基本分支管理策略，怎么会在这种地方出问题呢。 正式员工设计测试用例，外包人员写脚本这个也挺迷的， 这都是多少年前的操作方式了。 而且外包人员本身的能力就非常有限， 怎么可能会写出好的代码呢， 没有好的代码设计又怎么能快速的兼容需求变化呢。 把覆盖率当成 KPI 也挺魔幻的， 大家都知道覆盖率就是个参考，不能作为主要的考核目标。 我们这边评估自动化最主要的指标是减少了多少的人力成本。 比如我们我们一条产品线上执行一遍全回归测试需要这里所有的 qa 一块上，执行一周时间 (机器学习产品，TO B 业务， 产品庞大，业务复杂)， 我们在积累了 2000 多条 UI 自动化后，这个时间缩短到了 1 天。 提升了多少效率才应该是我们评估自动化的方式。

这是一种恶性循环，一开始就没有用好的方式和有足够能力的人去做自动化， 后面就会导致效果越来越差， 脚本越来越难维护，最后就是把这玩意当成 KPI 了。

大家都淡定

明确的说， 都重要，没了哪个都不行。 只不过是在面试中，技术占比会高于业务，但是从实际工作和职业发展的角度看， 这两个其实都是很重要的。 只不过很多人在跳槽的时候都直接选择跳槽到另外一个领域里， 所以之前的业务经验就有一种白学了的感觉。 但是如果你一直在一个固定的领域内工作，比如你是做广告系统的 QA， 你跳槽可能就是从阿里妈妈跳槽到百度凤巢，你是一直在这个圈子里混的，那业务经验就跟技术经验一样重要了。