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

有赞测试团队的一个亮点是,他们对平台上的开发和使用。他们的有赞QA平台提供了「构造测试数据」「项目质量报告」「项目日报」「环境健康检查」能力。性能测试平台简化了性能测试的步骤,提高了测试的效率,使得普通测试工程师也能方便地进行性能测试。以及他们正在建设的carmen该平台可以实现测试用例管理,又能够将用例自动化与用例绑定在一起;还有他们的集成测试平台,测试工作台等等,这些平台规范了他们的工作流程,提高了他们的工作效率。

再者从自动化来说越底层的自动化,收益越高,有赞的自动化分布图正是这样的金字塔结构,从而创造最大的效益。一个人的工作量是有一定范围的,自动化测试可以有效的减少单一重复的手工测试,去做更多更有意义的手工测试。

最后,质量不是测试人员一个人的事情,而是所有参与人员的事。

有赞测试团队–读后感

看了有赞测试团队的分享内容,了解到了团队与团队之间的差别;

1.团队把所有精力都投资在接口自动化层面,有效的减少了ui层面的工作量
youzan1
2.项目周期中,测试人员较早介入
3.测试用例开发人员辅助添加,开发人员应该是最了解业务逻辑及代码逻辑的,会相对容易挖掘出一些隐藏的业务逻辑、或者异常场景;
4.前期的自动化接口测试,有效保证了项目的提测质量,大大缩减冒烟测试,ui层功能测试时间
5.线上监控开发、安全扫描、性能测试能够有效的测出有些手工测试无法达到的测试场景
6.持续集成平台实现了可流程化配置业务应用发布顺序并与测试自动化相结合的工作流,同时提供自动运行及外部触发的运行模式
youzan2
7.测试质量报告及风险评估,可以起到在迭代中加强对某部分功能的关注

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

读完《有赞测试团队介绍》有了一点小感想,之前一直做黑盒测试,公司需要的时候会做一些性能和自动化,还未曾接触过白盒测试。现在测试开发职位也越来越多了,之前也一直苦于没有这样的机会,如今部门日益壮大,测试开发还是很有必要的。希望以后我们的日常工作也能像有赞一样。白盒测试能力、CodeReview能力或许现在我们还不具备,但是我们可以跟部门一块成长,总有一天会越来越成熟。

虽然暂时不能达到有赞的水平,但是我们可以一点点实现,首先做好第一步也就是有赞的2.1,然后在效仿后面的,相信会有很大的改善,让我们一起努力吧!

具体项目测试:

有赞的项目分为标准需求项目、技术重构项目、优化项目、缺陷修复项目。有限的测试资源通过不同策略支持着绝大部分业务产品的测试工作。
第一、对于标准需求项目或者跨多个业务的项目,一定会有测试投入,并且会有一位PTM来协调测试工作。PTM需要确保所有需求点都拆分到各个业务测试同学手里,跟踪相关测试同学按时提交标准测试方案。当测试方案汇总后,PTM需要评估后续测试过程中,测试人员如何投入。即哪些业务的功能测试PTM可顺带执行掉,哪些确实需要对应业务线测试同学来完成,以避免一个项目投入过多测试同学。
第二、技术重构改造项目,这种一般是单应用或者极少应用改造,但不改变业务使用规则。这类项目测试同学只要设计测试方案并完成测试用例落地即可,用例的执行由开发自行完成。测试同学要做的就是对新系统进行自动化覆盖。如有需要,测试会在上线前做质量check。
第三、对于小型项目,如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。
有赞测试同学拿到具体需求后,按照有赞测试对需求分析和测试方案统一要求,完成相关工作。

                                                   有赞.项目协作图

 

 

有赞测试团队读后感想

下边这张图,从需求评审到代码编写再到提测后的测试结束上线,这个来看是相对很完整的一个开发测试流程,从开发阶段到上线阶段,测试人员是不断在跟进,其实这么来做能在提测时解决掉大部分的bug,可以大幅度减轻测试人员在页面功能方面的测试压力,这个是很值得学习的。也能充分深入了解需求,更深入的挖掘潜在的bug,提升产品交付的质量。
1
在文章中也提到了自动化部分,有赞测试团队采用金字塔分层比例的方式来分配自动化涉及部分,从他们的比例来看,和人们所认识的的金字塔有相似有区别,区别在于最底层的单元测试是由开发来做,这个也有好处,开发自身开发的代码,自身最了解,但是也有弊端,自己开发的代码,发现问题也是比较难的。再说接口测试部分,有赞团队90%的精力都在接口层部分,而且还是分接口的上层和底层,这样在开发做完单元测试的基础上,来实现接口测试或接口测试的自动化方式来检测代码的入参以及返回是否是按照预定的要求来返回的。这样就会发现在接口层出现的一些数据传输之间的问题。那么到做UI测试时候大部分就只停留在处理页面一些显而易见的问题了。
2
3
现阶段我们处于一个基本的功能测试以及少部分的页面功能自动化的实现阶段,在后期一定需要改善这种工作模式,接口的测试加入到测试部分,自动化部分能更深入到接口层,更深入的发现更多的问题,更有效的提升测试效率和质量。

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

读了“有赞测试团队介绍”的这篇知乎分享,确实能感受到有赞测试流程的规范和成熟,有些我们可以借鉴起来;接下来我主要从如下几个方面同时结合公司现状(我刚来公司一周,可能会有些现状了解的不是很透彻,如果有片面或是不全面的欢迎大家指正),发表一下读后感言。
一、流程方面
项目协作
如上图,通过有赞的项目协作流程,个人总结有如下优点:
1、测试人员参与的时间比较早,从需求评审就介入,而且跟踪项目较完整,从需求评审一直到项目上线
2、测试流程很规范,从前期的需求分析,测试方案设计,设计评审,再到测试用例及提测用例的编写;有比较合理的时间去消化需求,落实用例,为后期的测试场景覆盖打下良好基础,避免后期时间紧张,场景考虑不全;
3、对于需求分析比较重视:需求分析后,需要输出对象生命周期图、业务时序图、用例图、待确认的问题、风险点清单。并就相关问题、风险与产品、开发进行多次沟通,直到问题得到明确答复。
这样前期重视需求分析,可以将一些需求不合理或是遗漏问题在前期暴露,在开发阶段就会解决一些问题,避免到后期测试阶段才暴露一些需求或是流程问题;同时能够更合理的评估测试范围,避免一些其他的业务功能兼容遗漏;
4、对于开发质量比较重视,开发阶段增加了单元测试,这样能够进一步保证开发功能的提测质量,把一些问题截止在前面,而不是到后期测试才发现,才去修改;
5、测试用例管理:在测试产出用例的时候会有两份用例,一份是测试用例,一份是提测用例;顾名思义,提测用例,就是开发在提测之前需要保证的流程功能用例,而且在开发流程中也有冒烟测试(个人认为冒烟测试直接执行提测用例即可,实际可能不太清楚是不是一套)和提测报告。这样,就保证了提测之后测试程序的质量,避免测试前期还因为主流程不通等严重影响测试进度的问题出现;
6、对于测试效率提升的重视,引入了测试自动化以及白盒测试,这里可能包括接口、UI等自动化

总结概括:流程比较完善,测试全程介入,提测之前的流程是比较多的,比如需求分析确认问题,设计测试方案,测试用例,单元测试,提测冒烟测试等等,前期介入比较多,可以将部分问题控制在前面解决,毕竟问题越是遗留到后边,修改的成本越高;

接下来通过这段时间与同事沟通以及自己总结,与公司现有情况做一下对比以及一些自己的建议想法:
1、测试人员介入和项目跟踪时间,以及测试流程:
需求评审会有人员参与,但是可能存在项目忙,参与项目需求的人员和实际执行测试的人员不是同一个人;
测试有的时候在项目提测的时候才开始介入项目测试,之前没有时间或是很少时间去充分的分析需求,以及评估测试范围,制定测试方案,有时候都没有时间编写测试用例。
当然以上问题也是测试资源和项目周期紧张,这就需要以后平衡,要想流程规范且质量有一定保证,多少是需要投入一定的时间和前期合理规划的;
2、对于开发质量,及提测质量的重视
缺少开发单元测试和自测的阶段
建议先把提测之前的自测做起来,在提测之前至少保证主流程,提测用例是通过的,后期可以再将单元测试推广;
3、测试效率提升
就如之前的计划,正好把接口测试和UI自动化引入,在提测之前保证接口质量,同时自动化用例也可以同步上线,对线上环境做相应的监控,以及后期其他项目兼容的一种辅助,避免大范围回归;后期大家能力提升之后可以考虑是否引入白盒测试等。
4、项目总结
对于一些优先级比较高或是项目周期比较长的项目,可以考虑要不要加入项目站立会的流程,这样每天或是几天同步一下进度,以及项目问题解决;
项目上线之后可以做定期的总结及复盘,对线上反馈问题进行总结,确认是用例场景考虑不全,还是测试范围评估不准确,还是环境需要完善等等,总结才能有进步。
二、工具建设
QA平台、有赞mock服务、安全扫描工具,性能测试平台,Carmen测试平台,持续集成平台,测试工作台等等;
这里对于工具和平台的构建其实还是需要时间和人力去搭建和维护的,如果前期达不到构建如此规范的平台,可以先重点关注这些平台中主要涉及到的一些内容,或者通过其他方式或是其他已有平台等来进行一些相关内容反馈。。
比如:
  • 有赞QA平台提供了「构造测试数据」「项目质量报告」「项目日报」「环境健康检查」能力;测试报告,包含项目质量报告及项目日报。用于跟踪项目过程质量、进展、风险及最终项目上线的质量。
  • 测试工作台:该工作台的目标是把测试小伙伴平时奋斗的成果展示出来,测试同学参与了哪些项目,项目的提测质量、测试质量、相关报告及风险点
我们可以考虑要不要先发起这些平台中的项目质量报告,项目日报,项目提测质量,测试质量等内容的补充;
三、线上监控
现在开发有线上的监控服务,加上后期的接口及ui自动化测试上线,后期如果通过定期执行,个人认为监控力度还是比较完善的。
四、发布管理
在发布管理上可能需要运维多费心,尽量梳理统一的环境部署规范,使环境部署不会占用太长时间;暂时发现以下一些情况,可能阻碍测试进度:
  • 前期测试环境搭建有时候比较费时间,有的时候提测之后好几天部署不成功;
  • 在有项目并行的时候,有的项目分支代码不完整,导致在分支下测试时候其他功能报错等不能使用,可以讨论是否可以优化;

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

有赞的测试和开发的边界比较模糊的,甚至延伸到了运维,已经有了一套交叉的套路,开发可以做测试工作,测试有开发能力,只是分工不同
同样我们研发人员也应该向外延伸,去多了解测试工作,也必须做好测试工作,简单的单元测试还不够,要做到具体流程测试,测试人员提供测试用例,及进一步验证
各个环节测试是非常耗时耗力的,要让开发人员尽量在提测前发现bug,就需要一个好的套路,这个套路需要各种测试工具和平台做支撑,如有赞的UI自动化、测试工作台、性能测试平台、全链路性能压测等。开发人员在开发的过程中能方便的进行测试,不当减轻了测试人员的工作压力,还可以及时让开发人员对代码进行调整,避免排查bug时耗费大量的精力。
我们曾经上线事故发生概率较高,除了上线规范没有做到位,还有一个就是缺乏一个线上业务级可用性监控。
然而我们目前这块还处于较为初级阶段,开发和测试套路交叉还比较少,还是偏向于测试找bug,开发改bug。要达到开发与测试的边界逐渐模糊,互相默契加深,只是在分工上做事的侧重点不同。我们还需要不断的努力,共同进步。

有赞测试团队介绍读后感

       看了有赞测试团队的分享,让我对优秀的测试团队有了更清晰的认识,一个优秀的测试团队需要具备以下几点:人员分工明确,团队目标一致,相互学习资源互补,有条不紊的测试流程等方面。有赞测试团队的强大不是一朝一夕能够实现的,我们可以吸收他们的长处补充自己的不足,设计出一套适合本公司的一个测试平台,让我们的测试团队更加强大。
       1.对于测试平台的搭建。我们需要探索出适合本公司发展的测试平台,让自动化测试不断的融入我们的测试过程中。对于功能测试,UI测试,安全性测试,性能测试,自动化测试要有一个合适的平台去合理的分工协作。
       2.对于自动化测试,每个测试人员都应有意识的去学习,去探索更好更快更精准的测试方法。自动化是必修课,我们也要学着从接口层、端对端的数据层、端对端的UI层来做自动化建设,尽可能的去朝着自动化 的方向去发展,不能一味的停滞不前,要不断的学习,不断的向自动化测试靠拢,尽可能的减少不必要的人工测试。
       3.对于不同的项目有不同的解决方案。对于标准需求项目或者跨多个业务的项目,一定会有测试投入,并且会有一位PTM来协调测试工作。即哪些业务的功能测试PTM可顺带执行掉,哪些确实需要对应业务线测试同学来完成,以避免一个项目投入过多测试同学。 对于重构改造项目,测试同学要做的就是对新系统进行自动化覆盖。对于小型项目,如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。
        以上几点是我读完有赞测试团队后的感想,一个强大的团队必有它的强大之处,我们要正确的认识自己,去努力追赶超越他们。加油!!!

有赞测试分享读后感

       看完有赞的测试团队建设与测试日常工作,让我对测试有了一个新的认识。
       之前也经历过几家公司,相对来说,对测试的重视程度都不高,都只是开发完成之后,将代码提到测试环境,然后测试人员根据需求文档,主要对功能进行测试。如果有必要会做简单的性能测试与自动化测试。
但是有赞对测试团队却很重视,他们的测试团队负责相关项目具体测试工作、自动化建设、合并发布流程管控、设计开发线上业务级别可用性监控、同时在研发提升测试效率的工具。 相对的,他们对测试技能要求也很严格,需要具备白盒测试能力、CodeReview能力、业务功能测试。另外,测试的规范性也很重要,有赞的根据项目来划分测试资源很有借鉴意义。我们也可以效仿他们,对每个项目进行评估,需要投入几个测试,测试负责的业务线,哪些项目测试只负责写完测试用例,后续执行由开发自己执行即可。测试只需要在上线前走一下checklist即可。对于一些小型项目,开发自行搞定即可。再次,有赞的测试方案很规范。可以让大部分公司直接拿来使用。 除此之外,有赞在性能测试平台,接口测试平台,QA测试平台等方面都很成熟。
        相对于有赞,首先,我们在白盒测试能力、CodeReview能力这两方面都比较欠缺。其次,我们测试的规范性也不健全,每次提测代码质量不高,这个其实可以通过项目规范解决问题。比如,开发先自己执行测试用例,没有问题了再提测,测试只需要走一下checklist即可。我们测试现在花费了过多的时间在跟开发一起走主流程,往往主流程需要走2天,然后正式再开始测试。这样导致接口测试,性能测试,复杂业务流程测试都没有时间进行。再次,有赞的测试方案我们可以直接使用。如下:
33
       面对如此大的差距,我们只有一步步慢慢来。现在我们的自动化测试平台robotframework已经成功使用起来,同时doclever接口平台也正在渐渐使用起来。其实再大的骨头我们只要有了目标都可以慢慢啃下来。后续如性能测试,接口测试,兼容性测试等方面的建设,也需要找准方向,慢慢开始进行。我相信我们QA部门可以顶住压力,创造一个不一样的明天。

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

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

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

15029627816175

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

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

2

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

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

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

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

1505283244927

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

有赞测试团队介绍读后感

感觉有赞的业务和我们有相似之处,他们的自动化建设、测试工作、监控等对于我们来说有很多可以借鉴的地方。各种效率工具覆盖到了开发测试监控的各个阶段,节省了很多重复性的劳动。能让六百多人的团队有条不紊地工作,确实很了不起。希望我们将来也能做到他们那样。