有赞测试分享读后感

认清差距,方能追赶

通过有赞测试团队的分享,我深受鼓舞,指明了我们测试组未来的发展方向,让我知道一个测试团队可以做到这么强大。下面我简单分析一下我的看法

1.有赞是一个纯粹的互联网企业,在开发、技术方便很重视,这一点,从测试人员质量就可以看的出来,需要具备白盒测试能力、CodeReview能力、业务功能测试的测试工程师,而且必须是BAT团队出来的。这点我想我们是可以看得出差距的。可是这种人员的差距怎么缩小呢?假设,我们有两种方法:1.统一招BAT团队的资深测试工程师,2.选团队最优测试工程师给整个团队业余时间培训,公司给与支持,然后培养成具备这种能力的工程师。那么我想,第二种方法是最优解,培训成本较低、人力成本低,现有测试人员业务熟练。可以快速介入测试。

2.对于测试日常工作分配,我觉得可以学习有赞团队,将项目细分成标准需求项目、技术重构项目、优化项目、缺陷修复项目。第一、对于标准需求项目或者跨多个业务的项目,一定会有测试投入;第二、技术重构改造项目,这种一般是单应用或者极少应用改造,但不改变业务使用规则。这类项目测试同学只要通过doclever设计测试用例即可,用例的执行由开发自行完成。测试同学要做的就是对新系统进行自动化覆盖。如有需要,测试会在上线前做质量check。 第三、对于线上反馈、缺陷修复项目,如如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。

3.对于测试流程,如果是现在功能测试为主,那现在的测试流程相对之前,还算比较完整合理,但是提测质量不高,所以我们也需要在接口完成时介入编写接口自动化用例,但是有赞团队所说的:“需求分析后,需要输出对象生命周期图、业务时序图、用例图、待确认的问题、风险点清单。并就相关问题、风险与产品、开发进行多次沟通,直到问题得到明确答复。”对于敏捷开发,那启动开发的时间其实很紧急,没有那么多时间去评审风险和业务缺陷,流出更多是时间去写自动化用例兼其他测试项目的功能测试。

4.对于提测分支冲突问题,我们也可以学习有赞团队的搭载公交车发布模式,每一个服务都可以拉出一个test测试分支,所有开发提测时都把自己代码合并到test分支,以后解决bug也要同步自己分支,如果没问题了,可以把自己分支合并master,可以独立上线。

5.对于测试,分为三部分,第一部分是单元测试,这部分属于白盒测试,介于测试代码能力不足,这部分可以由开发自测;第二部分为接口自动化测试,这部分属于灰盒测试,测试会通过开发在doclever写的接口文档编写接口自动化,可以由测试介入进行接口集成测试;第三部分为UI自动化测试,由robotframework实现,同时做手动UI测试,验证功能展示效果和一些边界测试,测试完成后,验收通过上预发布测试,测试通过,上线上正式环境后通过UI自动化测试实现业务全覆盖。

6.对于压力测试,介于对服务器的要求高,所以我们最后通过第三方压测平台实现,如果后期资源到位,可以使用压测工具在测试环境实现。

7.对于线上环境监控,主要又运维来做好,比如宕机监控、服务挂点监控,sql超时监控等等。

好了,罗马不是一天建成的,我们只要重视了,并且有推进,就一定会有成绩,虽然我能力自愧不如,但是我愿意去学习,和测试组一同成长。

 

发布者

高凯林

爱学习技术部就是牛!

发表评论

电子邮件地址不会被公开。 必填项已用*标注