看有赞测试团队的读后感

看了他们的团队介绍,不由得感叹有赞团队是个很优秀的团队,有很多值得我们学习的地方。
项目流程方面,有赞的测试人员从需求评审开始介入,设计用例,提测用例,用例自动化,到由测试进行发布,全面把关产品质量。而我们的测试多数时间是用来进行功能测试,测完立刻上线,之后用例自动化主要由于鹏进行,很多是上线以后才开始进行。发布阶段,我们是由运维进行发布,并且有些项目的开发到发布测试人员不参与,应该跟有赞一样,由测试人员进行用例编写交给开发自测,这样能提高产品的质量,也能提高开发自己的代码能力。
人员技能方面,有赞测试人员需要具备白盒测试能力、CodeReview能力、业务功能测试,而我们在这方面的能力还有所欠缺,我们也应该提升自己各方面的能力。
我们和他们这样高效的团队之间确实是有差距的。所以我们要吸取对我们有用的经验,提高效率,快速进步。

有高度,有深度——有赞测试团队介绍读后感

附链接:有赞测试团队介绍

一、有高度:有赞的测试团队基于“提高产品质量”的立场,参与到产品研发流程各个环节:技术评审后的测试方案制定和评审、测试用例编写驱动开发、codeReview、集成测试、多环境测试,并且积累了一系列高效的工具:QA平台、mock服务、安全扫描工具、性能测试平台、持续集成平台、基于测试历史数据分析的工作台。

二、有深度:深入到跟质量相关的各个层面:RPC接口、http接口、线上服务监控等。

他们的测试团队打破了我对测试团队固有的看法:界面点一点、顶多用工具做一下接口测试和压测,他们能基于自己的使命主动出击,做了很多严格意义上讲并不属于测试职能的工作:codeReview、服务监控等,但这些也确实与产品质量和服务质量息息相关。

还有一点,他们的自研能力很强,能基于测试需求开发自己的工具,达到了可持续测试,并且基于测试数据做产品的宏观质量分析。

最大的感触,测试团队也大有可为!

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

有赞测试团队的一个亮点是,他们对平台上的开发和使用。他们的有赞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部门可以顶住压力,创造一个不一样的明天。