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

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

读完这篇文章给我最深的三点印象
第一是 测试,运维和开发在工作之中配合更紧密,这一点我们做的还不够,我们运维在工作很少涉及到跟其他团队之间合作,在以后的工作中也会更加注重这一点
第二点是 无论是测试还是运维都需要具备一定的编码能力,否则在工作中只能有心无力
第三点应用性能监控与发布系统相结合,项目发布完毕自动调用接口进行多节点检查,这一点也是我们要学习借鉴的,运维与测试配合对各个应用进行深层次的监控

<<有赞测试读后感>>

有赞测试读后感:
直接步入正题,说下我个人理解,和他们的差距:

1.高效的协作(PTM角色),全程跟踪:

项目协作
2.产品质量总结以及制定产品质量考核:
监控产品质量,从时间控制的角度来说,开发新功能和修bug是一个平衡。开发得太快就可能把交付给下一个阶段一个问题较多的版本,从而使得后面的问题更难处理。我们如何知晓每个阶段软件质量怎么样?具体的方法很多,回归测试,代码覆盖、压力测试等等。但是这些信息谁来收集和分析,怎么分析,能得出什么样的结论,怎样对RD的质量进行考核?

3.自动化覆盖率以及自动化工具:

有赞的自动化测试,从文章看来,在深度和广度都有一定的积累,比如UI、http接口、MOCK接口自动化覆盖率,深度上,他们有一套较为完整的测试工程(部分自研),广度上,在功能测试,性能测试,安全测试都有一定的体现。

4.监控系统:

随着系统网络拓扑与业务场景越来越复杂,发布频率越来越高,我们需要知道当前系统中核心业务场景的健康情况,目前我们OP开始设计并实施进程级别的监控告警,以及应用程序级别的ERROR监控。
4.定期组织业务分享,提高测试、开发人员的业务全局观及跨业务耦合与风险评估能力
5.提供《异常测试基本场景》指导测试人员如何考虑异常。

读有赞测试团队之读后感言

        之前对有赞不是很了解,看完过他们团队介绍,感觉这个测试团队做的很全面,监控到主网站到机器到每个接口,测试工作很全面而且是自动化,合并发布很厉害,每天能发布十几至二十几个代码分支,持续集成发布,值得为之点赞!

        我主要谈一下有赞的监控给我们的启发.随着系统网络拓扑的变大,业务场景越来越复杂,有赞这边专门开发了监控系统,监控主机状态,并模拟真实场景操作进行监控,一但某个环节有异常,及时告警之测试及开发,这样能第一时间了解问题,及时去处理.这也是我们所需要的,运维平台目前正在加入监控,目前完成所有项目运行状态的监控,异常及时告警.同时我们正在完成通过elk的api接口查询异常日志,反馈开发更好的完善我们的服务. 以后我们也要对每个接口监控,不论哪个点出现问题,我们都及时扫除这些异常.相信我们会越来越完善!

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

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

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

15029627816175

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

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

2

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

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

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

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

1505283244927

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