服务相关测试内容整理
自2020年6月以来,带领团队完成了40多款app的测试交接工作,期间整个研发+测试+运维团队出现过几次线上事故。近期对公司所有发生的线上事故进行复盘,问题的现象大致有以下几种:
1、线程阻塞影响到主业务;
2、三方接口没有设置超时,导致线程阻塞;
3、对于异常没有捕获,导致协议处理队列无法消费,不断堆积堵塞;
4、日志消费单线程,存放任务的队列无限长,导致崩溃;
5、代码未判空处理,导致空指针异常,未对异常进行处理,导致线程异常直至崩溃;
6、代码和功能的相关联的地方未考虑到;
发现线上事故的发生原因大致可归类为以下几种:
1、专业能力不足: 包括专业技术能力(①、开发方案设计缺陷;②、编码能力不足,未考虑到性能等因素;③、测试宽度和深度不够,测不到深入的问题)、业务能力(对产品和代码不熟悉,开发和测试考虑不周全)
2、意识不足: 包括安全开发意识、责任意识、敬畏心
3、规范执行不到位: 对已有的规范执行不到位
4、规范缺失: 在发生问题之前没有相应的规范制度
复盘每次线上事故,细细琢磨,测试团队目前还存在的问题:①、对交接的业务熟悉度不够;②、缺少专业技术上的广度(很多测试点由于认知不足导致想不到而测不到);③、缺少专业技术上的深度(会存在一些当前专业能力下想得到,但测不到的内容);
今天主要是结合公司当前业务以及近期的线上事故,梳理出一些服务相关测试知识,希望能帮助小伙伴们拓宽知识面,在后续的测试过程中能想到更多。
一、概念解释
为了方便大家理解能够理解一些服务相关术语,整理了一些和开发沟通性能测试过程中,较高频率的词汇解释。
响应时间(RT) :服务对请求做出的响应时间。
PS1:一款产品内包含很多的功能,每个功能的逻辑不一样,响应时间不一样;
PS2:同一功能内不同的输入数据、数据量的大小都有可能会影响响应时间;
(针对这些需要提前想到,并通过客户端限制请求数据,或者通过服务端的合理处理请求数据来规避出现线上问题;
PS3:响应时间的接受程度较为主观,不同的人接收程度不一样,但测试过程中,在不去平衡服务消耗等方面,响应时间
越快越好,兼容更多的人;
对于单机游戏,没有并发操作的app而言。响应时间可以作为衡量性能的指标。
吞吐量(TPS) :服务(包含多个接口)在单位时间内处理请求的数量总和。
PS1:如果只有一个用户使用时系统的平均响应时间是t,当有你n个用户使用时,每个用户看到的响应时间
通常并不是n×t,而往往比n×t小很多(当然,在某些特殊情况下也可能比n×t大,甚至大很多)
对于并发系统,吞吐量是用来度量服务性能的关键指标。
并发用户数 :服务可以同时承载的正常使用产品功能的用户数量。
PS1:不同的单个用户在产品内做的操作不一样,对服务发送的请求不一样;所以会笼统一些考虑玩家在
正常使用产品功能的情况下,所能承载的最大用户数。
每秒查询率(QPS) :单个接口每秒所能处理请求的数量(最大吞吐能力)
连接池 :允许多个客户端使用缓存起来的连接对象,这些对象可以连接数据库,它们是共享的、可被重复使用的。
PS1:打开/关闭数据库连接开销很大,连接池技术允许我们在连接池里维护连接对象,这样可以提高数据库的执行命令
的性能。 多个客户端请求可以重复使用相同的连接对象,当每次收到一个客户端请求时,就会搜索连接池,看看
有没有闲置连接对象。如果没有,要么所有的客户端请求都进入队列排队,要么在池中创建一个新的连接对象(这
取决于池里已有多少个连接存在以及配置支持多少连接)。一旦某个请求使用完连接对象之后,这个对象会被重新放
入池中,然后会被重新分派给排队等待的请求(分派给哪个请求要看使用什么调度算法)。因为大部分请求都是使用
现存的连接对象,所以连接池技术大大减少了等待创建数据库连接的时间,从而减少了平均连接时间。