正常的，因为上面代码是 btn 和方法处于同一个级别作用域，大白话来说，对象管理只有下个级别的可以访问上个级别的。
如楼上所说需要把 btn 加一个关键字 global，来标记 btn 是当前文件内全局可以访问的，btn 泛指在堆上的，不同方法之间不共享。
推荐用类来写。

有一个坑点说下，go mod build 会安装 viper last tag v1.7.1，但是最新版本不是一个经过验证的稳定版本，官方的依赖有问题。
请使用 go get github.com/spf13/viper@v1.6.3

...我知道 R 语言可以做啥啊🤦‍

要看什么模型的，也就是你选择用的包。有的样本数不用很多。

测试和统计学是不分家的，上面第一段写了场景。

https://testerhome.com/topics/27949 第二个文章出来了。

单测我是这么看的，使用状态位，只用断言 True 就行，这样代码更容易做模板类代码

//var 在@Before里面是定义为false
//当满足条件在if区域内把 var=true
然后用assertTrue(failMsg,var)进行判断。

挺好的分享，字符串模板形式的。
boomer 刚出时玩了一会，mq 那层后的确比 locust 本身好。
set 那层测试任务，安利一种注册的写法。

func NewCatLocust() *boomer.Task {
    task := &boomer.Task{
        Weight: 1,
        Fn:     TaskList,
        Name:   "TestType+游戏名称",
    }
    return task
}

TaskList 内部通过 registerFunc(taskName string, f func() error) 注册到一个支持权重范围的 WeightedFuncs() Map 对象里面后，进行压测。

func registerFunc(taskName string, fc func() error) {
    st := time.Now()
    err := fc()
    if err != nil {
        boomer.RecordFailure("xxGame", taskName , e.Milliseconds(), err)
    } else {
                end := time.Since(st)
        boomer.RecordSuccess("xxGame", taskName , e.Milliseconds(), 0)
    }
}

原来我也是，但是只检查这些会漏一些问题啊。
举个例子：
在静态表规则里面，道具 ID 为 10001 的道具，这样的道具有 10 个，在背包内不可叠加，参数包含获取唯一。
通过配置表规则扫描，道具 ID 列表长度为 10，然后匹配参数，和 ID 匹配是 ok 了。
但是在动态配置表（接口配合造正常获取不到的环境情况下，去验证服务器健壮性和表设计），10001 道具在已经获得 1 个的情况下。
在各场景添加道具副本，比如仓库，临时背包，邮件内添加等，然后就出错了，这种出错基本就是攻击性的。

今天就会有。

好的没问题，这些一点点从客户端往服务器发去展开。不过多路复用是在服务器端的，也会讲的。

感谢会持续创作的，后续帖子里面还会发布一些关于业余时间用 Python 游戏服务端的一些组件设计，配合 client 端调式。

工具开发思想是从小做大，多个小工具需要串联占领部分流程，先谈需求再做。
再用小工具抽象进化成通用的，不同通用工具有不同的隐式分类，回头可以关注社区的一个白皮书。

测试还是开发？大数据有很多中间件，消息队列和查询引擎，处理引擎。
测试的话就从 ETL 的 ET 开始搞起好了，比如 kettle 和积累一些不同流程需要的数据特征进行造数，造数和入数仓 hive 等是必学的啊。
测试要做好造数和倾斜数据需要用模型去对抗开发模型，只是老的方式填充数据到分区，造 N 套，效率更不上的。
宽表特征和必备数据用建模和加工自己去创建测试数据。
开发的话从 docker-->Flink 集群这块先搞起来。

不一定要刷很多算法题啊，不如找几个小工具开发下。算法可以以下学习路线：
1.大 O 评估核心代码复杂度理论知识，知道循环体内外的差别，最好结果和最差结果，学习 O(1),O^{和 O(log(n)) 分别是什么，这个多练就行，（不同数据量下面是不一样的）最糟糕是 O(n2)。}
2.排序常见算法，选择排序在于比较和交换，希尔排序在于学会分桶和处理余数，这些对于跑任务用多线程/多进程分治有关系。
3.如果是 Python 的还是先学生成器吧，这个是灵魂啊，不学一跑就爆栈了。当然你可以用缓存和设置更多的栈长，这些是没掌握生成器前的。然后再看贪心算法（不用回溯的）
4.树相关的，需要会写树和前后序，Btree 和哪些有关。
5.数据库相关的合并排序等等。
后面都可以自己补充了，祝你早日找到心仪的工作。多来 Testerhome 看帖子。

不好意思，刚看到
首先：websocket 正常情况下是没有做分包，所以不用从包头取包体对象。
客户端序列化数据-->服务端，但不代表服务器发回给客户端的一定是同样序列化方式，具体看业务。
websocket 收包按游戏来说需要设置为二进制的形式，默认是 text。
代码不是很全，logininfo 应该是 一个 pb 对象函数返回，然后 logininfo.ParseFromString(xxxx) 才能进行反序列化。
messageId 是协议号。另外 websocket+pb 一般会做一些签名验证的方式来确保包安全性，所以可以问问是否在发包前和后需要对这块进行签名和解签名。

最后，让 pb 对象可视化一点，可以用 pbjson.py。网上开源的。

第三条和我司（同为魔都三姐妹的友商）去年招聘的一样，今年已经扭转过来了。讲真，4 门语言测试开发成型的很少，很容易出现一种情况，是人少没办法的路数。米哈游测试开发那么多完全没必要啊，比如原神就 10 个。

加精理由是 pykka 的应用和 actor 模式，这块在测试上属于相对跨学科，建议都可以学习下。并且是个系列作品，期待后续。

service mesh 本身是有网络开销。多用户跑设置集合点跑了吗？

websocket 默认是 text，但是可以设置为发二进制。

加油加油

脱离前端框架的方式，UI 前端访问微信，拦截一层拿到这个变量存持久层比如 Redis(内存也行，取决语言)，试试这个。
如果可以的话就用变量继续做接口测试。

我来说下感受，如果只是看个热闹还是比较伤感的。行业车轮是在进步，稍微学习下起码不会落下太多。
测试也不要绝对的划分，测试就是不需要有太多开发实力的，测试是一门职业，也是服务质量的最重要的担当者，职业发展需要众人拾薪，空等着行业发展，是挺难的。
至于工具/框架/平台从 0-1 比较简单，是否从 1 做到 5，需要考虑推广和持续开发。
1.0 工具是一种辅助方式，2.0 平台后更多的是抽象统一化的工具变成平台，楼也是一点点盖高的，高屋建瓴也是碎片时间一点点盖高的，毕竟内部业务很少是靠 PPT 画个饼就给招一批人的。

内容还是挺有意思的，会和同事一起开发，不是就一个人孤军奋战。而且那边还在开发很多常见质量品类之外的。快点联系发帖人吧。

觉得能解决问题就是好东西啊，这块可以在宣传和讲解这个平台产品上多下功夫，好比一个项目立项也不是一番风顺的。
我个人觉得可以不要灰心继续投入。因为很多内部工具是否成为"高需求和爆款"更多不是一开始就很明确了作用，而是越改和越开发越好。
抱璞守真，跳出测试工具只有接口，自动化，压测这 3 个内容。