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

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

作为一个小团队的测开，应该是最熟悉业务的专家型人才，而不是埋头搞平台的纯开发

无比赞同，可惜有很多公司和很多人没搞懂。

弱弱问一句，大佬在广州做游戏的么

其实我也没用过，我现在也不清楚帮不了你。Please use MessageFactory.GetPrototype() instead 这里不是说用 MessageFactory 么，找下这个看看吧。

~~这个其实 4 楼已经指点了方向了，不过就是得咱自个花时间研究了。我以 go 为例子，https://github.com/protocolbuffers/protobuf-go/tree/v1.28.0 比如这里就有写相关的内容。

reflect/protoreflect: 包protoreflect提供接口来动态操作 protobuf 消息。
reflect/protoregistry: 包protoregistry提供数据结构来注册和查找 protobuf 描述符类型。
reflect/protodesc: 包protodesc提供将 descriptorpb.FileDescriptorProto消息转换为/从反射的 功能protoreflect.FileDescriptor。
reflect/protopath: 包protopath提供对消息的一系列 protobuf 反射操作的表示。
reflect/protorange: 包protorange提供了遍历 protobuf 消息的功能。

就是得花时间看看。。。。

一般我建议不点赞不回复这种帖子。

有很多的。比如副本掉落了不该掉落的物品；由于卡牌改了导致卡池物品异常；配置格式错误，中文逗号和英文逗号的问题；副本关卡衔接问题，配错了关卡衔接不上。有很多的，都是之前的事了。

醍醐灌顶啊老哥，我还是太嫩了当时没继续彻底研究。虽然历经沧桑（工作已换），脚本已经没办法继续调试了，但是老哥你这个指点真的是醍醐灌顶啊，我有空看看相关反射方法。特别感谢！！！

这个我也不知道哦，https://tools.ietf.org/doc/python-svn/pysvn_prog_ref.html#pysvn_client_diff 你看看官方的这个，参数都写的很清楚，可能对你有帮助。

不太清楚为啥你找的 pysvn 有各种问题不好解决。https://pysvn.sourceforge.io/downloads.html 我在这里下的，好像也没遇到什么问题，用的还算顺手。

啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊，我一直想去干 PC/主机游戏的，受不了手游了。
。。。。。。。。。。。。。。。可是我没主机工作经验。
打扰了

我们组有很多人看不懂，因为 90% 都是混功能的。现实和 testerhome 是不一样的，还是很多人只会功能，最多会个 jmeter 工具，或者一点点代码，并不能编写实战工具。我其实这么写用例也很难受的，但是现实很多时候得这么干才能减少坑。我记得以前游戏策划经常出现疑问，诶如果你这么操作会怎么样（或者交接的策划问这个功能以前是怎么样的文档不详细啊），那个时候我经常都是翻看用例就能解答。现在我做不到了。退步了。有时候我也在想，用这种 excel 规范好的用例格式，怎么编写游戏用例，比如复杂的抽卡机制，王者荣耀战斗 AI。我发现我好难做到，我必须带各种其他信息，才能使我以后重新看用例的时候能看明白。

还是得先求质量再求统一格式。高质量必然导致 xmind 格式复杂。excel 太简单了。出了一个新系统，测试人员写完用例，我问，你这个新系统改了哪些表加了什么字段没；诶你这个查询啊什么的操作用的哪个接口哪个协议，协议内容格式都有啥；有没有影响到旧功能旧数据，旧数据什么结构，程序怎么处理；等等一问三不知。我一直认为，用例不是简单的功能用例，因此是做不到格式统一的，但是见了太多人都是那种我去市场上随便拉一个人，也能写的用例。

我还是这个观点：用例=需求 + 技术细节 + 执行用例

但是做到如上，很难规范格式，或者说规范成本太高了。

我不太喜欢那些只有功能的用例，虽然有时候迫于时间有些我也仅写功能。。。。。不过这个和我不喜欢应该没冲突吧。。。。说实话，鄙人游戏出身，第一次看到 web 测试人员的用例时，我大惊失色，用例原来可以这么简单。。。。

以上纯属话唠，各位看官看看就行，别当真了。

思路打乱影响太大了，影响了思维。我 xmind 写，层级很多都不是固定的，但是固定后领导会要求格式统一，比如 tt -- tt -- tt--tt，不能超过 4 层，不能有图片，每一层要有前缀，比如 tt 表示 XXx，sd:表示步骤，ex 表示期望。那我以前扩散思维，三层的，我得使劲换成 4 层，超过 4 层的，我又得改成 4 层；我跑通一个用例，喜欢标记绿色勾，不通过打红色叉，但是又不给图片，说是转换 excel 不支持；那这样子跑完我又不知道那些用例跑了那些没跑，我又得换个方式记录。

还有我最喜欢的贴技术细节，贴一点代码，贴数据库字段（有时候是写有时候贴），都没得玩了。

真把用例格式都限制了，那人真的是一模一样的机器了，搞久我都怀疑每个测试思维甚至都九九归一了。。。。
我是坚决要求用例质量：用例=需求 + 技术细节 + 执行用例；但坚决反对用例统一格式。

最后感谢老哥码字那么多回复。我仍然很难改变我的坚持。（也许为了工作会卑微苟同，但测试思维一定要形成自己的一套）

看到这个我也是想说两句。最近也是被领导要求用例格式以便做转换。最大的痛苦就是完全打乱我的思考思路。像楼上这种我个人也很难接受。我自己认为，用例=需求文档 + 测试用例 + 技术细节。也就是说，我看我自己的用例，自上（需求）而下（技术实现以及用例执行），我自己全都能明白，我通常会贴不少图片，甚至贴代码，贴测试思路。请问楼主，像我这种贴图片，贴代码的，能解决吗？极度痛苦中。。。。

也不是吧。每个职位有每个职业的发展、擅长的方向。比如测试行业中的测试用例，你找个优秀的后端，或者优秀的前端，他没积淀也写不出好的测试用例的。没有好的测试用例，我基本就认定他测试做不好了。当然反过来，测试人员代码能力不如程序，那也很正常啊。还有，真别以为程序转行做测试就能比测试厉害，这说法没那么靠谱的。