我在面试过程中被问到对一个接口如何进行测试

作者:admin | 分类:接口测试面试题 | 浏览:110 | 评论:

在经历过了很多面试过程中,都会被问道给你一个接口你是如何对他进行测试的,我总结了一下我自己的回答,如有不正之处请大家提出,谢谢

====================================

==================================== 
分析:这个题是一个开放性的题,答得好要涉及到全面的测试,功能测试,安全测试,性能测试以及调优等。 
这也是一个考察逻辑思维的题,透过答题能看出一个人对测试流程的掌握,测试用例的涉及角度,测试覆盖面的广度,测试经验的丰富度,开发水平的功底,实战经验等,都能涉及到。

这也是一个考验智商尤其是情商的题,测试过程中我们要不断的和产品,开发进行沟通交流,反复确认,互相支持等。也会遇到比较尴尬的沟通人物,考验我们是如何处理协调这些关系的。

==================================== 
答题: 
1首先和产品进行详细的需求确认,可通过需求评审会,也可通过其他方式,保证我们要获取到一下内容:

业务难点,重点逻辑,产品高度重视的点,产品性能预估,使用场景,上线预期时间,以及未来的定位。 
这些内容为我们下一步进行设计测试计划做铺垫。

2找开发确认并了解实现逻辑,产品需求到开发代码实现会出现很多不一致的地方,尽可能的做一遍代码静态分析,了解代码类图,方法调用关系,并对私有方法、公有方法进行使用范围的确认,从代码层面设计测试用例。另外,对方法调用和代码逻辑,我们不能完全保证没有问题,还要从黑盒思想出发,设计测试用例,进行用例覆盖等。这样,测试用例就能具备精准设计,做到有的放矢。提升测试质量,也能提升效率,节省时间。

3具体的功能测试在case设计结束并实施后,我们还要关注安全角度。尤其对基本的sql注入,token验证,加密验签等进行重点测试和关注。 
4性能方面就内容很多了,这个也根据不同人员的基础选择性的去说。我所说的只能是我目前水平的最好答案。也特别欢迎帮忙指正错误提出建议。 
a,首先,我们要做一次负载测试,使用loadrunner建议使用自动场景,从低并发数逐渐增多,慢慢达到最高并发。负载测试帮助我们了解接口性能的变化曲线,获得最大用户数,tps峰值,资源利用率,响应耗时等重要性能参数。建议多做几次,以确保结果正确合理。之前我们提到从产品那里得到对接口性能的预估,我们可以进行对比,如果不满足,就要返回开发那里,一起定位问题,进行性能调优。调优我们稍后会涉及到。

b,接口的表现满足我们的预估后,要进一步进行压力测试,测试服务在高负载情况下长时间极限状态下服务器的表现,并针对服务器的承载能力做出评估。这个测试中我们经常遇到内存溢出,磁盘日志打满,服务宕机,网络异常等。也是我们发现问题的时候。排除问题,我们继续向下走。

c有了前面的测试,我们还要针对数据库进行容量测试,比如在测试导航算路的算法中,涉及到的用例有从1公里-2000公里,不同距离对网络,内存,磁盘读写都会形成不同的冲击,以及高并发下我们对数据库的性能表现做出判断,单点还是集群?是否需要分库分表?读写是否分离?后续都会面临调优问题。

d通常,实操同事会给业务线配给不同的并发数,那么我们就要针对不同并发数进行配置测试,确定某一配置下的性能参数,为业务线提供数据支撑。 
e当这些做完后,别着急,我们要做一次基准测试。 
基准测试是为了后续调优和系统评测提供参数支持,针对整个系统进行的基准测试。有的场景是不允许我们进行全链路测试的,比如支付场景,银行业务等。但是不妨碍我们进行基准测试。

我在做基准测试的时候,是写了一个mq的发送工具,mq打满后,启动服务,观察模块消费mq的速度,计算耗时,获得数据。每个模块逐一进行测试,最后会得到如下数据: 
例如: 
模块A (3000tps) 
模块B (5000tps) 
模块C (6000tps) 
数据库 (3500tps)

由此可知,我们系统瓶颈在模块A,和数据库。 
同时,对模块B,C,我们在下次改动后做性能测试时,就有了参照数据,性能提升了还好,下降了肯定不答应他们上线。

测试到此:允许上线。(呵呵)

==================================== 
说到性能方面,不得不说常用的监控方式和命令: 
jconsol,jvm内存实时展示;nmon,服务器端记录机器的各种参数,详细而全面。其他不一一介绍,我们是在面试,说好要点,说清楚要点是关键,这里要精不要多。 
监视内存我们可以查看有无FGC,有无内存泄漏,内存泄漏可以通过观察swap空间是否被使用能获得。 
这里准备了一些常见的参考(转载了一部分内容): 
1、处理器队列堵塞判断方法:如果Processor queue length大于2,而处理器利用率一直很低,则存在处理器堵塞。 
2、处理器瓶颈判断方法: 排除内存因素后,如果%processor time持续大于90%,并且%interrupt time的值持续大于15%,同时网卡和硬盘的值比较低,可以断定处理器负荷过重,无法满足业务增长需要,处理器是系统瓶颈点。 
3. 监视内存不足的状况,可以通过 page/sec,Available Mbytes、page read/sec、page faults/sec等计数器的指标进行监控,还可以通过使用“页面交换”的频率来衡量。“页面交换”是使用称为“页面”的单位,将固定大小的代码和数据块从RAM移动到磁盘的过程,从而释放暂时不使用的空间,这些页面文件就是操作系统用来虚拟内存的硬盘空面。操作系统对于虚拟内存主要设置两点,即内存页面文件的大小和页面文件存放的位置,内 存页面文件的大小就是设置虚拟内存最小和最大空间量,而页面位置则是设置虚拟内存使用哪个分区中的硬盘空间。频繁的页面交换将降低系统性能,如果系统“页交换”频繁,说明内存不足。通过调优配置减少页交换,将显著提高系统响应速度。 
4. 通过pages/sec指标判断是否存在内存问题,如果pages/sec持续高于几百,则有可能需要增加内存,以减少换页的需求,此时还应该进一步研究 页交换活动。如果pages/sec指标过高(几百),而硬盘数据流量不高(几百kb/s)则可确定是内存不足问题,如果pages/sec指标较高(几百),而此时硬盘数据流量也很高(几千KB /S),则可以判定是磁盘问题。 
5.通过 available mbytes来判断是否存在严重内存泄漏问题,如果该值很小(<4M),则说明计算机上总的内存可能不足,或者某个程序始终占用而没有释放内存,系统存在严重的内存泄漏问题。 
6.如果页面读取操作速率page reads/sec指标的值很低,同时%disk time和avg.disk queue length的值却很高,则确定为磁盘瓶颈,但如果Avg.sidk queue length增加的同时page reads/sec页面读取速率指标并未降低,则确定为内存不足。

上一篇:没有了     下一篇:没有了

网名:接口测试 | 博客官网

姓名:柠檬

籍贯:江苏省-南京市

现居:厦门市—思明区

职业:软件测试

填写您的邮件地址,订阅我们的精彩内容:

网站分类
接口测试教程官网

接口测试加群二维码