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

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

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

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

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

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 个测试，主程来自某大厂（我就不点名黑了）。因为是大厂，说话权很大，但是程序对于质量管理流程不是很感冒，你如何做到推动 “开发代码管理规范”？你是测试还是开发？你如何在开发中有话语权？你进入公司前肯定已经有一套代码管理规范了，你如何推动新的代码管理规范？新旧规范又如何不同，旧规范是如何产生？太多了就不说了。哪天你去分享沙龙，能够不这么宽泛，那一定会给测试界带了不小影响的。

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

我目前这个，已经实施一年多了，完全没问题，而且适用性很强，配置极其简单，复制黏贴规则，改几个参数就完事了。说实话比我之前见到的其他做法是要好很多的。不是自夸哈~~

之前项目都不需要这么多表格的。这个项目特殊，我没什么说话权，提优化搞不定。也就这样了。以前一个表格可以有多个 sheet，现在一个表格就只能一个 sheet，不支持 2 个 sheet，所以表格 100+ 了。说多了都是泪。

我举个游戏的例子。对于游戏随机来说，如果采用时间戳来生成随机种子，高并发下是有可能产生一样的数值的（比如你用秒级别的时间戳,是很容易出现的）。所以如果你让我来高并发随机一定不一样的字符串，我可能会试一下毫秒级的时间戳（13 位）+ 唯一的自增 id（例如游戏中的 playerid）来确保绝对不会出现相同的情况。自增 id 要定多少位，就看你需要并发多少了。反正唯一 id 和毫秒时间戳 13 位，组成 40 位应该还有不少剩余位的，剩余位定一样或者不一样的字符串应该就无所谓了。
我实际没做高并发取随机过，就说个想法~~

额，看了一下你的贴子，你刚好就是搞游戏的嘛。。。那上面就不难理解了。

今天做了一点优化：

_, message, _ := c.ReadMessage()
   serdata := &pb.ServerCmdData{}
   if err := proto.Unmarshal(message, serdata); err != nil {
       log.Fatalln("failed----------:", err)
   }

这块代码单独取出来放在协程的循环中

go func(){for{
如果连接关闭，退出循环;
否则处理接受到的信息，并写入log日志}
}

这个协程写在 websocket 连接之后；同时新增了发送协议也写入日志，如下：

主要解决服务器会回很多协议的问题，同时记录所有协议返回。另外为了解析协议，不得不写对应的 case 去解析，因为每个协议有可能多层嵌套，就需要多次反序列化。暂时只能用 case 办到，毕竟 go 不是动态语言。

恩，先这样吧。其实我只是想要实现发送协议就行，毕竟目前我也就用这么个功能了。结果越写越多了。

V2 看了一遍，这里再看一遍哈哈。不过底层测试也没怎么说话权（其实我有时候会觉得测试最好不要在组内推荐这些，因为涉及面太广了，涉及前后端的开发习惯，测试眼光很难覆盖全。因此我觉得一个测试提出这些东西的时候，有时候是好心但是实际没能特别明白组内需要），一般小公司都是主程拍板用啥，比如 Yapi。

https://docs.mitmproxy.org/stable/concepts-protocols/
看了下文档，发现 V7 文档写着还不能修改重播？有点奇怪。另外看 issue 问题似乎也挺多的。

说实话，我认为你不应该喷轻了。我觉得社区的管理者，第一应该要做的就是喷他（当然不是公开喷）。喷他什么？喷他戾气太重，说话带怒气，骄傲狂纵，鄙视其他人。为什么后面会有人开始粗口了呢？有点素养人看个两天不一定会粗口，但是持续那么多天全是这种无聊的话题，带来的负面影响是很大的（影响了很多看社区的人）。持续几天的交锋，使得一些人也开始暴躁了。这就是为啥我说你们需要先私信喷他并且禁言他。应该告诉他这里是公共平台，说话首先要稳重求和，不要带戾气。你可以说任何话，但是不要把你的情绪发泄在这里。

我是想从辩论中，找到我们的问题究竟出在哪里？

我完全不认可恒温这句话。带着错误的情绪说话，这能算辩论？这能辩论出结果？这只会引出更多的负面能量，最终引爆社区。做不到心平气和，就先别发声，别一上来就各种鄙视别人宣泄各种负面能量。希望管理者，带点雷霆之势。及早处置，等到今天处置，已经是略晚了。

看看人家的要求，好好说话。好好说话都不会，估计现实都不太会好好做人。毕竟祸从口出。

我对很多事情也是很悲观的态度，所以不知道勉强能算的上理解老哥的话。

恒温你无不无聊？还辩论。你觉得人是能被说服的么？

我其实也想说一样的话，觉得辩论没啥用，估计也没实际效果。但是可能有点违背我的处事原则之一：如果做不到积极鼓励他人，那就尽量不要给别人带来负面影响，别去打击别人的尝试。诚然有人给老哥你扣帽子，或者带给老哥你各种其他负面因素。但是我始终觉得，即使恒温的辩论无任何作用，我也不能够去说 “恒温你无不无聊，辩论没啥用，没必要搞 “这样的话来。说实话，楼主格局小了。
反而恒温老哥，虽然我不知道辩论到底什么情况（到底举办了没，情况咋了，毕竟我也没关注这个辩论），我仍然还是觉得，恒温愿意去做，实属不容易了。个人表示对你的尝试，表示一下辛苦了。（虽然我不认可辩论，但是我对你的行动本意表示认可）
PS：我完全不认识恒温，无利益关系，没有在那两篇讨论反智的文章下发表过任何看法。

好吧，我孤陋寡闻了

我这里用 XMLHttpRequest 只是把客户端的 log 收集到我自己写的简易服务器，因为我觉得在客户端源码（混淆过的）上处理我要的数据有些麻烦，所以我就用 http 协议转到我自己服务器处理。整个游戏通讯肯定都是用长连接的。

恩。。。我这个就是 socket 的，而且数据格式用的 protobuf。我的协议工具也是基于 protobuf 数据来发送的。游戏不可能用 http 的吧，肯定都是长连接，要保持通讯的。

确实。以前做个某个贸易类测试（python 写的），其中某个算法刚好 diff 可以看到，于是饶有兴趣地复制下来在自己本机上测试。这种最经济实惠了，而我也很开心。给别人算法研究 bug，能不开心么。

老哥说的对，单测有一定是最好的；数据统计也是要有的。前者是在代码层面来保证问题，后者是给策划、测试一剂定心丸，在有数据的基础上，策划会更放心，测试也可以更有信心说没问题。不过，我感觉单测真的国内没法展开的。敏捷开发嘛，要的就是速度。老哥是否见过国内厂商做单测的，多不多？我对此挺好奇的。

其实效率很高的。具体为啥效率高，真的得看环境的（游戏行业超多外包以及众多小公司，我相信很多外包同学以及小公司小测试，拥有的环境就是能看到 debug 窗协议内容、能知道抽卡协议，除此之外什么都没有）。如果按照你说的，那么我也可以说，你直接让程序写个单测给数据，那不是效率最高了。