《有赞.测试团队介绍》读后感想

何为质量把控?如何进行有效且高效的质量把控?在读这篇文章之前,我对测试的认识还停留在简单的理论认识阶段,了解了有赞测试团队的工作后,对测试组的工作目标有了更加清晰的认识。这个团队对质量把控做到了业内领先的地步。

先来看看他们的项目协作图(与我们团队相关的协作工作日常可以做个比较)

15029627816175

先说协作,他们有“提测用例”,用来检查提测质量,约束研发的产品质量;再说流程,他们有“测试评审”,对测试用例的设计进行检查和规范(他们已经积累了很多规范),将测试这个事情提高到一定高度。此图中没有画出来,但有赞和我们一样,测试组一样会参与需求评审。

再说自动化测试,最打动我的就是这块,此前也看到很多关于自动化测试的理论文章,但没有看到哪一家真的可以落地到这么好的,在实施层面,有赞在自动化测试这块做的很不错。下面是有赞.自动化分布图:

2

这个金字塔下面还有一层,是mock测试,这图没有列出来。

让测试来负责发布,而不再是运维来发布,我觉得这个在当下来说,是非常正确的,符合质量把控原则。这并不是否认运维同事的工作,而是运维同事搭建好自动化发布平台后,有测试组来操作和管理发布。关于他们的发布系统,也有一个亮点,就是合并分支发布。这对“单项目”高频发布的发布系统来说,是个必然的产物,但也是非常有用的产物。

前面都是理论,但工欲善其事必先利其器,没有好用的工具,想的再美好也是瞎掰。有赞在各个环节上,都自研了很多有用的系统,不得不说他们的测试研发团队很强大。

数据,对于质量把控来说,犹如眼睛一般重要。没有数据汇总,没有数据分析,质量把控就会成为盲人过河一般只能摸索前进。这块也是和工具一样的重要。

1505283244927

最后,附上原文链接:有赞.测试团队介绍

为什么 Java 要把字符串设计成不可变的

String是Java中一个不可变的类,所以他一旦被实例化就无法被修改。不可变类的实例一旦创建,其成员变量的值就不能被修改。不可变类有很多优势。本文总结了为什么字符串被设计成不可变的。将涉及到内存、同步和数据结构相关的知识。

字符串池

字符串池是方法区中的一部分特殊存储。当一个字符串被被创建的时候,首先会去这个字符串池中查找,如果找到,直接返回对该字符串的引用。

下面的代码只会在堆中创建一个字符串

String string1 = “abcd”;
String string2 = “abcd”;

那么在堆里面,只有一个对象”abcd”

如果字符串可变的话,当两个引用指向指向同一个字符串时,对其中一个做修改就会影响另外一个。(请记住该影响,有助于理解后面的内容)

缓存Hashcode

Java中经常会用到字符串的哈希码(hashcode)。例如,在HashMap中,字符串的不可变能保证其hashcode永远保持一致,这样就可以避免一些不必要的麻烦。这也就意味着每次在使用一个字符串的hashcode的时候不用重新计算一次,这样更加高效。

在String类中,有以下代码:

private int hash;//this is used to cache hash code.

以上代码中hash变量中就保存了一个String对象的hashcode,因为String类不可变,所以一旦对象被创建,该hash值也无法改变。所以,每次想要使用该对象的hashcode的时候,直接返回即可。

使其他类的使用更加便利

在介绍这个内容之前,先看以下代码:

HashSet set = new HashSet();
set.add(new String(“a”));
set.add(new String(“b”));
set.add(new String(“c”));

for(String a: set)
a.value = “a”;

在上面的例子中,如果字符串可以被改变,那么以上用法将有可能违反Set的设计原则,因为Set要求其中的元素不可以重复。上面的代码只是为了简单说明该问题,其实String类中并没有value这个字段值。

安全性

String被广泛的使用在其他Java类中充当参数。比如网络连接、打开文件等操作。如果字符串可变,那么类似操作可能导致安全问题。因为某个方法在调用连接操作的时候,他认为会连接到某台机器,但是实际上并没有(其他引用同一String对象的值修改会导致该连接中的字符串内容被修改)。可变的字符串也可能导致反射的安全问题,因为他的参数也是字符串。

代码示例:

boolean connect(string s){
if (!isSecure(s)) {
throw new SecurityException();
}
//如果s在该操作之前被其他的引用所改变,那么就可能导致问题。
causeProblem(s);
}

不可变对象天生就是线程安全的

因为不可变对象不能被改变,所以他们可以自由地在多个线程之间共享。不需要任何同步处理。

总之,String被设计成不可变的主要目的是为了安全和高效。所以,使String是一个不可变类是一个很好的设计。

关于服务分层的意见收集

我先起个头,说一下我的想法。
服务分为4层,并将部分中间件服务划为第一层,从底层向上层如下:
第一层*中间件服务:可以被任何服务调用的服务,为了和以下两种服务区分,可称其为中间件组件
第二层*底层独立微服务:不需要调用别的微服务的服务(但可调用中间件服务),例如财务微服务、基础数据微服务
第三层*业务微服务:从业务角度划分出来的微服务,可调用上面两种服务,但不可调用业务微服务
第四层*组合业务微服务:为抽象重复聚合业务微服务而形成的第二级的业务微服务,是对于业务微服务的包装,可调用上面三种服务(同样不可调用组合业务微服务)

互联网人应该了解的一个数据结构Bloom Filter

先贴上已经写得非常好的一篇文章:http://blog.csdn.net/jiaomeng/article/details/1495500

Bloom Filter是一个用于标记和查找标记的一种数据结构,因为设计精妙,也有人认为它是一种算法。

它设计的大体思路是通过hash值来对一个二进制位的存储“条”上打上标记,同样判断是否已经存在时,只需要通过位运算进行匹配判断便可。

这里存在三种误判:1是因为存储空间的限制(根据使用的具体业务量计算或大致判断得出)导致可能存在多个hash值映射到了同一个(或一批:一批是指采用了拆分的方式将一个hash映射到了多个点)位置,导致误判;2是上一点中的拆分式的映射,导致位置标记覆盖速度加快,就可能存在某个hash映射到的几个点刚好是其他多个不同hash标记的点的组合;3是因为hash碰撞而导致两个字符串在Bloom Filter中存在相互误判。

这三种误判是不能完全避免的,只能是优化它,所以提取这三点中的关键部分-hash值,对其进行优化。于是,我们需要根据多套hash算法,计算出多个hash,将这些hash值都做标记,验证是否存在时,则需要所有的hash值都通过。通过这种方式,我们能很大幅度的减小误判。

因为Bloom Filter是存在误判的,所以我们只能使用于一些性能要求较高,但对准确率要求不高的场景。例如,我们可以做一个随机抽题的功能,就可以用它来标记那些已经抽过的题。