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

好几年没搞游戏了，出局人献丑两句。测试这些东西，我个人思想就一点，由点及线，由线及面。
如果你让我测试战斗公式：
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 自动化大抵都得往这个方向靠。