• 步子迈大了容易扯着蛋。做事要踏实从黑盒做起,名词说太多没啥用的。别学阿里那一套。

  • 好几年没搞游戏了,出局人献丑两句。测试这些东西,我个人思想就一点,由点及线,由线及面。
    如果你让我测试战斗公式:
    1、每个英雄基础属性都是配表决定的,那么你要有一个高效的导表方式去更改游戏中的数值(最好要有一键导表之类的工具)。比如让 A 英雄攻击力和防御力变为 0,B 英雄攻击力和防御力为 100,导表重启服务,看看是否生效。
    2、验证初步的公式计算,比如你这个非常简单的:伤害=攻击 - 防御。首先需要确定如何看伤害:可能有 debug 方式可以界面显示,也可能服务器日志能打印(打印伤害值还是打印英雄血量?另外配置也可以更改攻速方便测试)。然后快速指令进入战斗,看 A 攻击 B。你需要设计不同的数值来验证。比如 100-0=100?100-101 那么不扣血?比如法抗随便改,防御不变,伤害没变说明法抗不起作用是对的?比如有小数点怎么算伤害?
    3、验证前后端是否一致:前端显示的伤害数、血量显示变化等,或者前端如果有日志更好;以及后端的伤害日志;
    至此完成点的测试。
    至于线的测试,不好意思上班中,没想出来,最好有点实际业务场景以及策划文档看,一般我都是喜欢看着文档看着实际场景才会想的出来。。。通常说,你多测几个点,差不多就形成了线了。

    (看到 1L 的概率)多说一句:类似概率暴击这种,也是在第二步中测试的。通常来说怎么测试,取决于你们的战斗公式,取决于具体业务设置。假设有个很简单的概率暴击。那么第一,你需要把概率改成 0,测试。第二,你改成 50%,测试看看伤害;第三,你改成 100,改成 200 等看看;第四,你需要由点及面,需要验证很多次的情况下概率正确与否。两个验证方式:1、让战斗多次打,打的很快都行。反正 A 英雄你可以设置很多血。B 设置攻速很快,然后看日志去算。2、把开发的概率那段代码看一下,单独拉出来在你本地执行单元测试,设置一些固定变量去跑代码。至此,点的测试完成。复杂线以及面,比如多并发下代码是否会出问题,讲道理这个阶段你可能并不需要把重点放在这。这块要看具体场景来搞了。

  • 你连不上是因为你两个容器都没在同一个网络。否则不可能连不上。你现在妥协用这个 ip,等你下回呢,继续妥协?
    两个办法,一是让已有容器加入同一个网络
    docker network list
    //重新根据镜像 run 过程中加入参数指定网络
    --network=my-network
    //创建一个网络名字叫 haha
    docker network create haha
    //让已有的容器加入
    docker network connect haha 4b7017ae794f
    二是重新用 docker compose,两个容器写在同一个 yml 文件里执行 docker compose

  • 你这肯定不行啊
    //特别注意:grafana 的 influxdb url 配置应为
    http://influxdb1.8:8086
    //不能写 localhost!!!也不能写 id 地址!!!容器之间互相通信直接用容器名字!!!

  • allpairspy 可以考虑用这个库,去实现正交用例设计,不需要用笛卡尔积,也能覆盖全面

  • 总感觉你被资本洗脑了,但我不想说什么。说一个假如吧,如果你给一个外包多少钱,让这个外包干匹配这个价格的活,让外包准时下班,不用跟着发版,不用熬夜,就那么正正常常上下班,做个普通人,遵守一下劳动法,我想每个外包都会很开心吧。可惜他们连个普通人都做不了。再说一个可能,有没有可能,外包只是因为资本想榨取更多的利益?好比美团外卖骑手,不想给你交五险一金,不想给你干啥干啥,那么你就不是公司的人了,你是一个个体户了。

  • 难度这种测不出来的,是多次游戏体验出来的,这种感官不是很靠谱。建议策划给公式算指标,类似于期望这种,通过计算期望得出难度值。如果策划给不出来,我只能说,水平不太够了。

  • 1、不需要去测试能不能通关的。一般来说给个保底机制就好了,就是界面上没有任何可以合成,也就是死局的时候,再重新随机一下(或者其他措施,策划看着办)
    2、后端逻辑测试过了就没问题(后端逻辑和你关卡多不多没啥关系)。一般保证前端不报错就可以了(因为前端有可能棋盘模板配错等问题导致报错)。这种考虑写个脚本搞搞咯。比如前端有入口可以发请求直接进入某一关卡,然后截图全屏,然后再指令通关,然后不停循环即可。这种效率慢一点咯。双管齐下的话,建议脚本检查棋盘配置文件即可,找出规律就没问题了。两个一起搞,铁定不会棋盘 G 的
    3、棋盘通关率这种东西,策划如果没法子那这个策划就 low 了。不用花太多时间关注棋盘难不难。体验游戏的时候再关注这个。发版你还关注这玩意?
    一时就想到这么些了。年代久远了。

  • 内容有点多,就不多说,针对下面这个说下我的想法。

    用客观数据说话

    本身我觉得用数据说话也没毛病。但实际上施行起来,我觉得还是弊端不小的。
    首先说下用数据说话的目的:为了证明你说所非假。
    譬如,证明测试确实做了很多,证明开发提测质量差(这块我们就喜欢这么搞,统计各种 bug 数量来论证,有什么提测中的 bugP1P 分别多少个,有什么集成后的 BUG,影响到其他系统的 bug,每个 bug 都填写各种各样的原因,统计原因归类,比如属于 A 原因属于 B 原因,QA 侧原因分析,PM 侧原因)。
    我以我们搞的这块来说说弊端。
    1、数据有水分(这就不用细说了吧)
    2、增加很多不必要的工作量,而且本人切身感受增加的工作量不少。。。(比如会去纠结这个算 p 几的 bug,这个 bug 开发和 QA 两边原因没统一等乱七八糟的事)
    我不太清楚 LZ 打算怎么搞,但是我个人角度认为,数据说话,稍微差了点。
    如果去细细询问在一线的人员(这个人员可不要太多水分了,有不少 QA 以及开发,确实不少水分),从他的谈话中大抵你就明白这个开发提测如何,甚至质量原因都能问清楚。不过这个做法很难,因为很多人不说实话(这个时候就看你怎么当领导了)。
    从这个角度上说,我是比较认可询问一线人员得出的结论,而不认可数据。但是前者需要你问出实话,以及这个被问的人的和你(你是个提问者)的关系。虽然很难做到,但是团队总归还是有那么一两个人这样靠谱的人的。

    至于 “数据说话”,倘若数据假了,起的反作用,我想(这个负作用)是很大的。我是非常建议各位负责人深思熟虑之后,再去做 “数据说话”。

    ------------补充一下温馨提示:建议 QA 还是以和开发保持良好关系作为首要考虑点。kpi 的东西教不会你什么的,甚至你的 QA 领导也教不了你什么。而你需要的东西,不管是工作上的东西,还是个人技术提升,你都可以从开发那边偷学到的。

  • 组件化这个方向深感赞同,学习了。未来 UI 自动化大抵都得往这个方向靠。