多谢解答，据我的了解，你说的大数据团队自测也是一种很普遍的选择。

我说一下我对 test oracle 的了解，“测试准则” 不太能表示它的意思，它是指到底怎么判断测试结果对或者不对，oracle 对应的翻译（神谕）更能表明这层含义，举个例子，比如你测试一个函数实现了加法，大部分人一看就知道对不对，又或者点某个按钮要弹出一个提示，这种就不存在 test oracle 的问题，它的正确性对绝大部分人都是显而易见的。但是涉及到大数据数据的准确性/正确性，这个就很难。例如，你算出一个指标你甚至很难在数量级上肯定它对不对，更别说它的准确性/正确性了。所以我说 test oracle 是大数据测试的一个根本性问题。即使你掌握了比大数据开发工程师更多的技能，当领导问你：你怎么确定你测试过的的数据是对的，你其实依然无法保证，本质上你只是把开发的流程走了一遍，那怎么保证你自己不出错呢？自己说自己开发的东西没 bug，这不符合基本的逻辑。

最后我没有说不需要了解业务和学习技术，我知道这两点的重要性。但是回到我讨论的这个问题，了解业务、学习技术，是能提高正确性的可能，但还是没从根本上解决问题。如果这是正确的解决方案，我相信对数据准确度要求高的团队无疑可以招聘两倍的大数据研发来解决问题。

先回拽专用名次的事情，这是一个测试论坛，test oracle 算不上高大上，但是没有很好的对应翻译，所以才用，不知道你为啥反感。按照你的逻辑我是不是也要反感一下 shuffle。不妨讲讲你是为啥感到反感？

其次我也是技术派拥护者，只是我没有局限在技术里面，你到管理的位置上不要思考团队人员配置吗？精英配置是好，但是具有普适性吗？
我在讨论一个大数据测试领域一个很具体的问题，想探讨一下你的方法论，结果就是了解复杂业务、学大数据技术。这是你的方法论，我指出问题点就是作为方法论它缺少普适性，而且没有根本性上解决问题。

嗯，多谢解答。这是一种思路，问题点是：

1. 举例的例子比较简单，在实际问题中，离线计算的指标业务逻辑比较复杂，而难点就在于复杂的逻辑。所以这个例子很难显然的推广到实际的工作场景中。
2. 算不上大的问题点，就是要求测试人员掌握比较好的大数据数据开发技能，当然从方向上是好的，但是问题也很多，实际也较难具备这种条件。如果没有相关技能，这种方法就不太可行。

这种思路抽象一下，就是不同的人（研发、测试）分别实现需求，然后对比，或者降级一些，测试人员只需要对结果数据做一些性质严重。但是没法解决 test oracle 的问题，例如研发、测试算出来的结果一致，而很有可能是他们都算错了。

提一个 topic，大数据测试一个难点是数据准确性测试，根本性的原因是大数据量的准确性的 test oracle 问题，有什么系统的方法论吗？

欢迎投递简历。

好的，静待简历。

大数据测试方向岗位，对开发能力要求不高。另外一个岗位主要做 devops 相关平台，要求有一定开发能力。可以先投简历试试，还有别的组，业务部门测开也招人～

是没什么问题，还没习惯这个逻辑。

没想到匿名帖的逻辑默认竟然是匿名回复，而且改不了。

可以来试试哦，欢迎投简历～

递归写了一个：

import copy


def get_all_combination(chs, deep, ret, rets):
    if deep == 0:
        ret = ["&" for x in range(len(chs))]
    if deep == len(chs):
        rets.append(copy.copy(ret))
        return
    else:
        for c in chs[deep]:
            ret[deep] = c
            get_all_combination(chs, deep + 1, ret, rets)


rets = []
get_all_combination([["a", "b", "c", "d"], ["e", "f", "g"], ["h", "i"]], 0, [], rets)
print(rets)

Pythonic 的写法：

import itertools

print(list(itertools.product(*[["a", "b", "c", "d"], ["e", "f", "g"], ["h", "i"]])))

可以看一这个资料：https://docs.microsoft.com/en-us/cpp/cpp/trivial-standard-layout-and-pod-types?view=msvc-160
总的来说就是，C++ 语法规范里面对类和结构体的内存布局没有约定规范，但是 C++14 里面增加了几种特殊的情况对内存布局有约定。再具体到你这个场景，CPerson2 不符合 trivial/standard-layout 的要求，所以不能假定内存的布局。

今年的情况，应该很少到学校宣讲招聘了吧，大部分都是线上进行的，可能这也是研究生比例上升的原因之一：求职成本降低，那有求职优势的学生就会增加自己的求职次数。

至于项目，其实不见得是优势，研究生大部分都是科研项目，而且是为了毕业做的项目，如果专业背景不接近，项目都沟通不清楚。

并不是，大部分还是比较相近的专业，例如软工、通信、自动化之类。生化环材一个也没遇到。

没有图，有也不能放。这不是什么严谨的结论，就是个人的一些感觉。

这个数字很保守，实际我面试的人里面应该超过 90% 了。

多谢指出，已修正。具体的压缩比根消息内容和一批消息的大小有比较大关系，在我们的场景压缩比能到 7:1～10:1，快一个数量级了。

1. 没有绕过 tcp 流量控制一说，写这个文章一个原因是高延迟带宽对传输速率的影响这个应该很少有人注意到（我也是第一次遇到这类问题），跨机房的传输速率只能到那么高（而且费用很高），所以合理的方式就是降低传输量。
2. 压测就是模拟的生产的某个业务场景，消息体的大小是一个很关键的参数，这个是从生产环境统计了一部分消息获取的。文中提到的优化肯定是都应用到了生产环境的。
3. 别的解决方式，增加并发度方向：可以增大 Kafka partition 数量，但是不是越大越好，有一定的副作用。进一步减少网络传输量考虑：可以使用更紧凑的数据格式，例如 pb，但是这需要在 consumer 端做一定的开发。

qps 到几千的规模，考虑用 wrk 吧。

赞一个，之前也想也写一下我的实践过程，觉得这篇基本把我要写的都写了。
静态扫描不是简单的引入一个工具、部署一下就完事儿的，这也是这个文章的优点，写了一个完整的技术 topic 实践过程。

补充几点：

1. 多分支支持是 sonarqube 的收费版本的特性之一，但是社区也有开源插件支持，比用多项目区分效果好一些。
2. 规则集的选择不仅要考虑问题等级，还要考虑业务特性，比如有些业务比较在意安全性，可以把安全相关的规则都加上。
3. 除了 Jenkins，还可以尝试一下 gitlab ci，这种方式接入成本更低，体验更好。有插件可以直接把问题展示在 commit 页面，对研发的体验更好。

理论上有可能，但是实际上会有很多问题，就文中的例子，有打出堆栈，代码也是开源的，当时我们很多人定位这个问题，包括熟悉该框架的算法工程师，都没有找到原因。再举个例子，美团技术博客的文章：https://tech.meituan.com/2018/10/18/netty-direct-memory-screening.html ，之前也找了不少资料，个人觉得 Java 的内存泄漏很难做到仅凭堆栈就一目了然，不如你给个例子？

多谢指出问题。

1. 你说的对，但是似乎原文没有体现 GC 一定有问题的意思，如果有请指出以便修正。
2. 实践了一下 top -H 看到的线程的内存信息和进程一致（同一 Java 应用进程的程的内存信息一样）。实际上当时面对的问题是 CPU 使用率报警，并不是一开始就知道是内存问题。另外 “Jstack 找到有内存问题的线程然后再看干了啥”，具体是指什么呢？

1. 看的很细心，是有点问题，原因是这样，报警的是线上服务机器是 8C 的，当时持续时间较长，而且服务是混部的，为了整体服务稳定，让 op 手动重启服务了，所以没留下现场信息。后面的截图都是线下测试环境重现时候的截图，线下机器配置是 4C，已在正文指出。

2. 当我们说内存泄漏：https://en.wikipedia.org/wiki/Memory_leak ，其实隐含了是内存不合理的使用行为，相对应的是你提到的程序正常使用（其实两者没有严格的区分，存在一些灰色的地带），这些都是对内存使用行为的描述，但我们关注的是结果，也就是内存不足时引发的频繁 GC，这回导致 CPU 高占用，服务不可用或者延迟突增。所以，是什么原因其实没有不重要，出现这种情况都是需要暴露出来的问题。
   然后是技术层面，如何确认造成内存高占用原因的合理性（前面提到的灰色地带），首先需要定位到根本原因，然后要结合实际情况看合理性。举几个例子：如果一个程序，为了高性能，需要大量的内存作为缓存，但是客观实际是机器没有那么多内存，那就不合理，如果内存很多那就很合理。然后看文中指出的例子，对程序基本没有好处，但是内存占用却很大，那合理性就基本没有。

Update：看了你补充的问题，没遇到过类似问题，信息不足，所以给不出什么建议。另外，我定位这个问题之前之前对 Java 也基本没什么了解，相关知识都是定位过程中学习的，也不是什么大佬，同样你也不用小白自居。遇到问题解决问题就行了。

对的，JVM 有很多优化的技术（编译器同理），所以除非对 JVM 实现细节很熟悉。不要自己写 benchmark 代码，而是用 JMH，这个框架会去掉这些优化。

你这么测试一段代码的性能是不科学的（主要是指使用循环放大语句耗时），里面有很多想像不到的坑。正确的思路是使用 JMH 测试，可以参考一下这个文章：https://www.cnkirito.moe/java-jmh/。