那这样是不行的。 你得在 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， 你跳槽可能就是从阿里妈妈跳槽到百度凤巢，你是一直在这个圈子里混的，那业务经验就跟技术经验一样重要了。

我觉得我自己的能量没大到能改变测试这个职位的， 我只想输出一下自己的观点和经验， 让多一点的 QA 能多拿点工资，少加点班，多被人尊重一点。 认可我观点的能有方向去努力就好了， 不认可的话我也接受。 尽人事， 其他的随意了。

一定要记住， 免费的才是最贵的。

这个事情其实是很简单的一个问题， 咱们都是拿最终结果说话的， 用户看的也是最终结果， 用户不会管你用的第三方组件有没有 bug， 他只管你给他用的产品有没有 bug。 所以如果第三方组件有 bug，那也是你们自己选的， 也要承担相应的后果，这个没什么好说的。

而且就拿 kafka 来举例子吧， 怎么能保证 push 消息的时候不丢数据，不重复数据？ kafka 是给了方案的，但是需要启动 broker 的时候启动参数是有一定的设置， 并且在调用 producer 的 client 的时候把幂等和分布式事务打开， 并且在 consumer 端把 uncommited read 设置为 false。 并且不同的场景设置的方式不同， 比如官方 client， spark 流式对接 kafka， flink 流式对接 kafka，调用的时候怎么设置参数，怎么写 client 的代码都不一样，甚至相同的 client 但是产品不同，场景不同调用的方式也不同。 那这里面研发就容易出错， 所以虽然 kafka 是公认的解决了这种问题的，我们暂且相信他自己没问题，但是他只提供方案，怎么用是研发自己写的代码，所以你是测还是不测？ 只要它放到了产品里， 产品就得负责， 只不过如果你选择相信研发，相信第三方组件，你不测了，也是 OK 的，这是你的测试策略的选择， 策略上选择降低人员学习成本不去测试这些高难度场景，那相应的也得承担万一这里面出了 bug 所带来的风险。 出问题了就得为你选择的策略买单。

我也同意能力不是一蹴而就的，它是一个循序渐进的过程。 但是质量标准不因为能力而降低。 而且如果 QA 都由于自己能力的问题而理所应当的放弃大量的测试场景， 那么这个 qa 这个职位就永远放弃进步了。

我也没理解

解释这个东西呢要从以下几个方面讲。

• 中间件是第三方产品， 但也同样是你们产品中的一部分， kafka 是开源的第三方产品， redis 也是，memcached 也是，mysql 也是， 甚至连你们开发用的框架 react，vue，spring，连开发语言本身都是开源的第三方产品。 难道 java 出 bug 了造成用户的损失他们得去起诉 oracle 么？ kafka 出 bug 了用户要去找开源社区索赔么？你们研发用的所有的语言，框架， 中间件全是第三方开源产品， 那所以你们的所有 bug 都需要用户找他们去索赔么？ 这就好比有个人拿这菜刀砍人了， 然后他说这把刀是 XXX 造的，你去抓他去， 你猜法律会不会同意？
• 即便是第三方产品，但是用的人是你们自己， 怎么用是没问题的怎么用是有 bug 的是一门很专业的学问。 即便是启动参数的错误也会招致很严重的后果。 所以你不测试，那就等着用户来承担后果。
• 调度规范从来不是 k8s 自己的出的， 也不是什么云厂商的的规范。 这个就是单纯的自己的产品要搞定的。 你的服务要怎么运行， 要怎么调度，是你自己在使用 k8s 的时候自己编写的配置文件， 还是那个问题， 你自己编写错误导致的后果你让 k8s 或者运营商来买单， 这不是耍流氓么？

我们怎么评审 test plan？ 这个太复杂了， 但我们的 test plan 的原则是一切为了保证质量， 保证最终用户拿到的是质量合格的产品， 而不是在做 test plan 的时候就想好了，如果开发调用 kafka 的时候出 bug 了就甩锅给阿帕奇社区。

找个开源平台， 上面 UI 设计的已经很漂亮了。 然后自己改就是了

所以我也是坚持方法论不是万能的，理论能力再强没有足够的技术支撑也是苍白无力的。这也是为什么我在这篇帖子里回答的第一个答案就是要对产品足够熟悉。 这个对产品熟悉，不仅仅是业务上的，也有对研发架构上的。有了足够的理解才能设计出更完善的测试场景。这也是测试人员的分水岭，非常多的 qa 会被卡在这个分水岭上不得寸进，这是测试人员职业生涯中的一个大坎。 只关注业务的人是很难能体会那些已经熟悉研发架构的人所看到的天空的。 这就像我很难能体会我们公司那些做算法的人所看到的天空一样。 所以实在劝不动了就算了吧。 别影响你们同事之间的关系。 能不能迈过这个坎看他自己的命吧。

有一次听我们 CEO 和我老大聊天，我觉得他表达的还是很准确的， CEO 的意思是大多数互联网产品是不重视质量的， 出了什么事线上直接处理也是可以接受的， C 端用户对错误的容忍度也高。CEO 说我们的 QA 不能学那些互联网的做法，我们要测试的足够深入。

我觉得 CEO 描述的这个不重视质量的现状造成了大量的 QA 在整个职业生涯内都是只对着业务功能进行测试的。 所以他们自然而然的就会觉得这些就是测试的全部了。 这个倒是很正常的， 没见过的东西自然就很难理解。 就像上面的那个哥们说产品经理不需要很懂技术一样， 因为他只见过业务型的产品和业务型的产品经理， 没接触过技术型产品和技术型产品经理。 所以他就以为产品经理都是不需要懂技术的。 这个是大环境造就的结果。 只要他们有机会经历过一次这样的经验，就会转变想法的。

所以我们要坚持在测试圈子里推广技术型的 QA，转变很多人的这种思维。 也转变圈外人对 QA 行业没技术含量的误解。

不知道实现哪种技术的话， 那我们怎么测试高可用和稳定性？ 比如怎么能测试出来产品中的消息是不会丢的， 不会重复的？ 因为都不知道有消息中间件这么个东西。 那到时候线上只要一个网络抖动，用户下单的时候消息丢了， 或者消息重复了， 导致点了下单但实际没下单，或者只下一次单却花了两份钱。 这个 bug 算谁的？

或者再给你举个例子， 如果一个产品有离线任务来计算数据，而这个产品所有的服务和任务都运行在 k8s 集群里， 集群调度领域是有调度规范的， 比如离线任务不能和产品服务一起被调度到同一个机器上，为什么呢，比如离线任务很可能是 io 密集型或者 cpu 密集型的大数据任务，如果和产品服务调度在同一个节点上会造成离线任务占用大量资源而影响产品服务的稳定性甚至会造成产品服务的崩溃。这种极端情况一般在测试环境是不会触发的，只有在线上极其复杂的流量和大量的压力下才有一定的概率触发。 所以我们团队有个测试用例是检查所有批处理离线任务的调度策略是否是正确的，会不会跟产品服务混部。 这种测试场景是不可能出现在 prd 里的，正如你所说 pm 只关注业务，他不关心底下是怎么实现的。 甚至不少研发都不懂集群调度的规范的，因为他也只关注业务开发，不懂集群的猫腻。 所以如果 qa 不懂 k8s 这门技术， 这个场景怎么测？ 都不是怎么测的问题了，而是有几个人能想到这个测试用例

这就好像之前飞机挡风玻璃在飞行中碎裂的那个事故。 我记得原因是一个螺丝离标准差了 0.1 毫米。 这种螺丝应该达到什么样的规格肯定不会出现在飞机的设计图里的。 如果只根据设计图来测试飞机，这样肯定是不行的。 而是在针对组成这架飞机中的每个部件进行测试。 设计图就是这架飞机的 PRD， 除了要测试这些外，也要保证针对每个部件进行测试。

我觉得这个道理还是比较好懂的，测试不是只有业务上的功能测试和性能测试。大量的不存在于 PRD 中的非功能性测试都是需要 QA 来保障的。

我的第一感觉就是， 楼主单纯的就是来打广告的。 第二感觉是，楼主是不是对大数据的测试有啥误解

这个水平比我当初强， 我 5 年的时候没楼主强。 来一线城市应该不愁找工作。 就是能到多少钱得看你实际掌握到什么程度了。 楼主说的皮毛我也不知道是不是谦虚。

我们假设一个场景， 如果我们的团队的消息中间件是 kafka 的话， 我们怎么设计这块的测试用例？ 产品经理是不懂 kafka 的， PRD 里是肯定写不来这里面的逻辑的， 他只会写业务上的数据流向，属于功能上的设计， 他甚至不知道底下用的是 kafka， 这种情况下， 在不了解开发使用的技术的前提下， 我们怎么测试？ 我们怎么知道分布式消息系统的测试点？

我觉得一般是找不到所有的等价类的， 太多的隐含逻辑藏在代码里是 qa 不知道的。

岗位太少， 求职者太多， 人家不能一个个的拉来面试， 所以只能拿点什么来筛人。 这个挺正常的，我 N 年前去华为求职也是这样， hr 看了一眼院校就给我拒了。