• 我就喜欢频繁提交代码,提交的代码说明是想要的,有时候大量代码没提交,中途又觉得有些代码不满意,手动回滚太麻烦,还容易出错。对于一个稳定的运行的项目,小范围提交不至于破坏性太大。

  • 多进程需要解决进程间通讯的问题,更复杂。建议多线程,做好线程安全就可以了。更优的做法是异步 IO,技术难度高

  • 数据分段,分布式,多线程,高效的代码自然带来编码的复杂性。如果不是特别紧急,还是用 python 慢慢跑吧

  • 不焦虑了,谢谢大家 at 2022年09月16日

    咋俩还挺像,没人带。能坚持这么多年,都是摸爬滚打过来的。看得出你很上进,但是没遇到一个促使你成长的环境。面试的时候多考虑下这个公司的业务适不适合自己发展和提高,问一问测试部门负责人有什么未来规划,自己能在未来的工作当中做什么。

  • 内存基础知识 at 2022年09月01日

    好多文章都说 “可用内存 = free+buff/cache”,但就我实际做性能测试这么多年来说,free 没有了,等着程序崩掉吧,buff/cache 并没有那么容易释放出来的。

  • 了解一下科学计数法

  • 新技术的出现需要时间检验的,就算摆在你面前,你也不懂,也不会认为是多牛叉的设计

  • 我想利用 poco sdk 测试 h5 游戏,但是浏览器不能监听 5003 端口,能不能用一个代理服务器进行中转,SDK 通过 websocket client 连接代理,airtest 也连接到代理服务器

  • 这有啥,我当年测试转 c 后端开发,还不是一个星期后就开始写业务,半年后随便写什么,轻松拿捏,不过我现在是测试开发

  • 开发干什么,你就去学什么,什么时候你觉得自己能干开发了,你就会发现,通过对开发过程的深入了解,可以更好的改良测试方法,完成更加深度的测试。

  • 不错的工具,看样子主要针对开发调试,用于优化服务器性能。我们目前的项目使用 skynet(c+lua),服务器就是实现了类似系统,功能更加完善,再配合测试自动化工具,尽早暴露服务器性能问题。

  • 这里估计没人会做发动机性能测试

  • 一个性能问题咨询 at 2022年06月15日

    静态资源适合使用录制回放的方式压测

  • 跟我使用的思路类似,不过我采用的是 socks5 代理的方式,非侵入式,不修改客户端代码和配置

  • 测开造轮子漫谈 at 2022年06月06日

    不管是不是造轮子,一切为业务服务。我做游戏服务性能测试,就是用 C\C++ 造网络库开始的,不过是在业余时间造的,现在已经成功应用到多个公司多个项目,不管是公司内部日常开发调试还是海外部署测试服务器性能,目前公司的项目也都使用这套系统,只能说自己造的轮子真好用。工作中,还是更倾向于快速完成业务,需要评估时间成本。而且我觉得用几个开源框架拼拼凑凑成一个平台,并不算造轮子。别人的框架也不一定适用,我们公司项目用 skynet(C 嵌套 lua),所以我们测试开发所用的核心技术也是围绕 c 和 lua,更具有项目亲和性。不同公司的公司架构、工作流程不完全相同,二次开发的学习成本不一定比自己开发的成本小,甚至还因为别人的框架限制,实现一个功能绕太多圈子。我还是鼓励大家多造轮子,甚至测试领域的轮子目前还远远不够。

  • 没有报错堆栈信息不敢断定,就我简单使用 net/http 而言,发现用它发送 http 请求,可能回因为网络抖动或者对端意外掉线导致协程永久阻塞(底层网络库稳定性还不如我自己 C 写的网络库,属实有点垃圾),我的办法是加一个超时,可以使协程正常退出。可能你遇得到的也是同样的问题,导致资源得不到释放。

  • 感谢解答

  • 有个疑问,用例步骤都规定了是读还是写,在读的时候不确定要读几个包怎么办?

  • 【fiddler】 at 2022年05月10日

    安装信任证书什么的太复杂了,直接让运维设置防火墙,只允许公司 IP 可以访问 http 服务器即可

  • 造轮子挺好的,不知道我用 c++ 造轮子写了个压力测试工具会不会被不理解,过几天我也发出来大家玩玩

  • 完成业务我会随便选一个框架,最好是网上一搜资料比较多的。写着玩的话我习惯自己用套接字编程实现 http 服务,可以加深自己对 http 协议的了解,从更底层的方式理解接口测试

  • 框架设计合理的话,还是写代码效率高,并且灵活。我觉得低代码就是一个伪命题,各种框架或者库的封装就是为了少写代码提高效率。很多的低代码实际上是往无代码上靠,而完成业务肯定需要实现逻辑,低代码平台就变成了另一种形式的编程语言。即使不写常规意义上的代码也需要掌握技术理论和编程思维,如果缺乏基础,小白上手很慢,会代码的人可能又不太愿意使用,不过造轮子的精神还是值得肯定

  • 首先你应该测出 1000 个线程所产生的 qps,纠正一下,我前面描述有误,rps 应该为 qps,也就是测试出 1000 个线程每秒能发送多少个请求,假如你的 CPU 特别垃圾,1000 个线程只能产生 100 个 qps,那你的 CPU 负荷太高,线程可能处于任何状态。假如 1000 个线程产生的 qps 远远大于 100,那说明 CPU 负载有余,那性能瓶颈在服务器,线程大多在等待服务器响应

  • Tps 是服务器每秒处理的事务数量,跟多少个线程没有任何关系。多线程只为了产生更大的 rps,而 tps 不可能大于 rps。多线程并发在单核 cpu 上其实是交替执行的,只是切换时间很短,以纳秒计,所以看作是同时运行,这称为并发。还有一个相似的概念叫并行,必须不同的线程运行在不同的 CPU 核心上

  • 我是把协议解出来,修改再发送。服务器返回的重要参数先做记录,需要发送的时候替换录制的参数