• 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 消息的功能。
    

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