我对测试团队的理解

在技术团队中,大概至少也会包括两部分,对这种两部分的团队,一部分是研发团队,那么另一部分就会是测试团队。就我个人经验而言,测试团队会稍微小一点,但扮演的角色非常重要。但是不同的公司读测试团队的期望和定义不同,鄙人认为这才是导致了不同公司的测试团队的产出差异的最关键因素。那么首先测试是什么呢,或者说怎么定义测试团队会比较好呢?下面的部分我们会进行详细说明。

测试团队的目标:尽量提前发现bug,尽可能避免开发过程中引入新的bug,保证线上系统的稳定。

实现上面这个目标,一般我们会有两种做法。

  1. 功能性的测试,人工测试:对新功能的人工测试,就是通过真机安装,测试亲自体验产品的过程,观察在各种操作下,产品的表现是否符合产品设计的预期,如果符合就没有问题。因为产品功能是一个逐渐累加的过程,每次验证的话都会侧重在新功能上,所以对产品的其他功能不太能覆盖,所以如果引起了其他模块的问题,能不能靠人工测试发现,就比较看脸了。这个过程,主要的侧重点在功能的验证上。如果产品为安卓平台的话,可能还需要做不同机型不同版本的测试验证,这个过程往往也会产生大量的工作。人工测试的弊端在于,效率比较低,但对于客户端测试,除了这种方式,并没有太好的方法了,所以为了发现问题,测试要非常辛苦的尽可能多的操作,以期能发现更多的问题。

  2. 后端系统的回归测试:一般情况,对于前后端协作的产品,当然现在绝大部分产品都是这种类型的。同样的,每次功能都会包含后端的新feature。后端系统如果某个接口出问题了,运气不好就会直接引起系统的闪退。如果团队开发流程不是太规范的话,这个问题如果带到线上的话,会直接导致事故的产生。所以,后端系统的回归测试很重要,这个职责可以不放在QA这边,但是这个测试系统应该是测试团队提供。所以测试团队也是要写代码的,并且写得代码也不少,要提供尽可能全的测试用例,覆盖尽可能多的业务接口。这样,每一次上线,通过这个项目的保证,可以大大减少偶然引入的bug而导致系统出问题的可能,可以让测试更专注于新功能的验证,而不必担心其他任何地方会不会出问题而坐立不安😂。这一部分的工作一般会和jenkins集成起来。jenkins是另外一个主角,和项目管理工具和git同样重要,在提高团队协作效率方面也很重要。关于jenkins,我们后面会专门开文章讲解一下。自动化测试的体验影响到研发自己测试需要的时间,所以尽可能好的体验,会提高整个团队的开发效率哟。

  3. 压力测试: 对于业务中的核心接口,例如电商系统中的商品详情和商品列表页,登陆接口,加购物车,或者秒杀活动的接口,这些接口都非常核心,承载着系统中的绝大部分流量。所以,在上线前,对这些接口的性能评估也显得尤其重要,对于一个完善的业务系统而言,这是一个非常重要的环节。压力测试框架,开源的框架应该也有不少了,具体的我还没有了解过,会在后面的文章中做一个补充。在压力测试的过程中,需要观察系统的每一部分,例如观察数据库,还有观察代码及,看一下在系统所能承受的最高qps下,业务的瓶颈处在什么地方。以后如果需要提升系统瓶颈,可以从这个地方入手。一般情况,问题可能会出现在系统后面的数据库层面,也可能和代码机器相关,需要试对具体情况的分析而定。压力测试的机器,和线上机器应该做一个折算比例,应为线上机器一般和测试机器的配置不同,折算的比例*测试机的QPS,应该就是线上系统的QPS。可以用这个作为线上系统的一个性能评估参数,来指导以后业务的开展。压力测试,也可以自动化,做得方便易用,让研发可以自己测试,从而保证开发效率。

关于测试,根据我工作三年的经验,想到的就这么多了,关于jenkins压力测试框架,我也只是用过,并没有研究过或者尝试过亲力亲为搞一套出来,所以目前没有太多经验,等以后有时间自己搞起来了,会补上相关的文章。有任何意见,欢迎留言交流。

点赞

Leave a Reply

Your email address will not be published.