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

  • 其实我也没用过,我现在也不清楚帮不了你。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 消息的功能。
    

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

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

  • 想做好的配置表检查工具 at 2022年03月23日

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

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

  • 这个我也不知道哦,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 不支持;那这样子跑完我又不知道那些用例跑了那些没跑,我又得换个方式记录。

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

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

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

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

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

  • 吹牛逼其实有部分原因也是因为听的人喜欢。。。。我刚入行的时候也是说 “我喜欢测试”。因为面试官喜欢听我 “我喜欢测试”,不喜欢听我说 “没办法,开发能力不够,只能做测试”。现在很多吹牛逼也都是因为这样的,听的人喜欢,没办法。

  • 想做好的配置表检查工具 at 2021年09月13日

    恩。。。以前老东家有个人就是这么搞的(当时这个是另外一个人独自负责的,我没参与),最后完全推动不了,胎死腹中,没人用。也不知道这位上海老哥能搞起来不。。。。。去实践,就知道有多少未知问题了。

  • 想做好的配置表检查工具 at 2021年09月13日

    大佬首肯,小弟受宠若惊。

  • 想做好的配置表检查工具 at 2021年09月13日


    我是 rule 文件直接写定义得规则 class

  • 老哥,就你一个人,不会是刚成立的测开部门吧。老实说,我不是很看好游戏测开的,容易成边缘 OB 部门。

  • 想做好的配置表检查工具 at 2021年09月02日

    class Table 封装 xlrd 的方法,方便调用。部分代码如下:

    class Table(object):
        def open_workbook(self, DOC_DIR, workbook):
            full_path = DOC_DIR + workbook
            # return xlrd.open_workbook(full_path, formatting_info=True)
            return xlrd.open_workbook(full_path)
    
        def get_head(self, doc_path, workbook, sheet_name,):
            wbk = self.open_workbook(doc_path, workbook)
            sheet = wbk.sheet_by_name(sheet_name)
            head = sheet.row_values(config.HEAD)
            return head
    
        def get_content_by_col_name(self, doc_path, workbook, sheet_name, col_name):
            wbk = self.open_workbook(doc_path, workbook)
            sheet = wbk.sheet_by_name(sheet_name)
            head = sheet.row_values(config.HEAD)
            col_index = head.index(col_name)
            return self.get_content_by_col(doc_path, workbook, sheet_name, col_index)
    
  • 主程走了,另一个老哥暂时充当。我答应过这个老哥,陪他一起支撑一下团队。

  • 说实话,我苦思冥想破局之法,如今苦战快 2 年,无不以失败告终。如今方明白,人之品德,重如泰山。在现在压力颇大的社会中,很多人的心早已变质了。只是唯恐我,哪一天也变成和他们一样。(我多说一句,我司有一人,上家公司开除过他,原因为嘴臭,此事是项目主管和我亲口所说。此人影响极大,因为该职位只他艺一人,其余众人皆与他矛盾,苦他久矣)

  • 老哥,你这个理解其实不是很准确的。软技能不仅仅指测试和开发关系好,更重要的是产品和开发关系好。有很多时候测试和开发关系不好,是因为产品(策划)和开发有矛盾,战火烧到了测试这边。真正待过小团队的人才深有感悟(鄙人不才,做过大厂外包(偷学技术,偷学流程管理),也待过小团队,真的是从 0 到 1 的那种小团队)。所以光是测试和开发关系好,没什么卵用的。至于硬技能,过硬的技术永远没有上限,开发信服你和你技术过硬没有必然联系,最多就是有那么一丢丢影响。我做外包,有个服务端老哥和我关系特别好,甚至主动开车送我下班(顺路),但那个时候我刚毕业,没有所谓的过硬技术。这种事要看人的,我那个服务端老哥深知,他做的系统质量不止我,还有他都是要负责任的,所以他也很希望我能够测试好;而有些人则是认为,系统质量和开发无关,出事了都是优先丢锅给产品或者测试,这种心态的人永远都教不好的。这种思想才是真正决定开发愿不愿意去相信一个测试,去和测试合作共扶质量。当你真心认为你是团队一员的时候,你就会愿意去相信你的队友,去和他们共同成长。

  • 说实话,细节不够,很多地方疑问很大。举个例子,第一点,质量管理流程规范化,这个怎么做到的?仅仅是与领导充分沟通?问个实际一点问题:一个团队就 1 或者 2 个测试,主程来自某大厂(我就不点名黑了)。因为是大厂,说话权很大,但是程序对于质量管理流程不是很感冒,你如何做到推动 “开发代码管理规范”?你是测试还是开发?你如何在开发中有话语权?你进入公司前肯定已经有一套代码管理规范了,你如何推动新的代码管理规范?新旧规范又如何不同,旧规范是如何产生?太多了就不说了。哪天你去分享沙龙,能够不这么宽泛,那一定会给测试界带了不小影响的。

  • 交流----PB 数据的协议测试 at 2021年08月06日

    受教了,老哥这番话点醒我了。感谢。