最近的面试整理

这是第二个星期出去面试了,这里就整理一下遇到的面试题~ 

一、数据库题

表名:字段 

users:  id
trace: user_id(用户id)    payment(消费金额)    pay_time(消费时间)
 
1、查询id为1的用户在2018.10.01-2018.10.02期间消费的总金额
2、分别查询 id 在 1-10 的用户当天消费的金额
 
答:1、select sum(payment) from users join trace on users.id = trace.user_id and pay_time between "2018-10-01" and "2018-10-02" and users.id = 1;
 
2、select id,sum(payment) from users join trace on users.id = trace.user_id and users.id between 1 and 10 and pat_time = curdate() group by users.id;

二 、WEB测试与APP测试的区别?

1⃣️WEB是B/S架构,基于浏览器的,而APP功能测试则是C/S的,必须要有客户端。

2⃣️从系统架构来看,web测试只要是更新了服务端,客户端就会同步更新,而且客户端是可以保证每个用户的客户端是完全一致的。APP端则不能保证完全一致,除非用户更新客户端,因此APP下修改了服务端,意味着需要对用户使用的核心版本进行回归测试。

3⃣️ 性能方面,web页面只关注响应时间,而APP则还需要关注流量、电量、CPU、GPU、Memory等

4⃣️ 兼容性方面,WEB是基于浏览器的,所以更倾向于浏览器和电脑硬件,操作系统的方向的兼容,选择不同浏览器内核进行测试,如IE、Firefox、Chrome、Safari、Opera等。APP测试则必须依赖phone或者是pad,不仅要看分辨率、屏幕尺寸、还要看设备系统。

5⃣️app端还多了一些专项测试,如一些异常场景的考虑以及弱网测试,异常场景中断的考虑包括:中断、来电、信息、关机、重启等

6⃣️ 弱网的测试:包含弱网和网络切换测试,需要考虑测试网络所造成的用户体验,重点要考虑回退和刷新是否会造成二次提交,需要测试丢包、延时的处理机制,避免用户的流失

7⃣️APP是客户端的,则必须要进行安装、卸载、更新测试,此外,还要考虑异常场景,包括安装时的中断、弱网、安装后删除安装文件,更新的强制更新与非强制更新、增量包更新、断点续传、弱网、卸载后删除APP相关的文件等等

8⃣️ 现在APP产品的用户都是使用触屏手机,所以测试的时候要关注手势、横竖屏切换、多点触控、时间触发区域等测试

三、进行简单JMeter压力测试需要配置什么?都关注哪些指标?

需要配置:

1、线程组

2、取样器(HTTP请求、TCP请求等)

3、前置处理器(用户参数)

4、配置元件(CSV数据文件、HTTP Cookie管理器等)

5、监听器(查看结果树、聚合报告、图形结果等)

6、断言(响应断言、JSON断言、XPath断言等)

需要关注的指标有:

1、throughput(吞吐量) 

系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间

QPS(TPS):每秒钟request/事物 数量

并发数:系统同时处理的 request/事物数 

响应时间:一般取平均响应时间 

能推算出三者间的关系: 

QPS(TPS) = 并发数/平均响应时间

并发数=QPS(TSP)*平均响应时间 

2、Error%(错误率)

当表格中Error%不等于0%时系统出现瓶颈,这是通过查看结果树,响应时间,服务器资源使用情况判断出系统哪里出现了瓶颈。

3、response time(响应时间)

响应时间:对请求作出响应所需要的时间

网络传输时间为 t1(发送)+t2(返回)

应用服务器处理时间:t3

 数据库服务器处理时间:t4

响应时间=t1+t2+t3+t4 

4、系统资源使用率(CPU和内存)

远程连接服务器后使用 top 等命令监控系统资源使用情况

使用free -m  查看内存使用情况。 

四、测试一个APP时出现一个错误,怎么判断该错误是后端的问题还是APP请求的问题?怎么做?

先使用抓包工具确定服务器接口返回的数据是否正确,这样就可以排除是否是服务器原因

如果返回的是服务器报错那麼就是服务器原因, 如果反回的数据与接口文档不符那麼就是接口问题,

最後就是APP客户端问题。

一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试。

测试用例的定义
      测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。

测试用例的特征
  1.最有可能抓住错误的;
  2.不是重复的、多余的;
  3.一组相似测试用例中最有效的;
  4.既不是太简单,也不是太复杂。

测试用例组成元素
  1.用例ID;
  2.用例名称;
  3.测试目的;
  4.测试级别;
  5.参考信息;
  6.测试环境;
  7.前提条件;
  8.测试步骤;
  9.预期结果;
  10.设计人员。

测试用例设计原则
  1.测试用例的代表性:能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
  2.测试结果的可判定性:即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。
  3.测试结果的可再现性:即对同样的测试用例,系统的执行结果应当是相同的。

2020-12-17面试纪要:

1、进行压测时,生产环境与测试环境机器不一致,怎么判断在测试环境的测试结果通过与否

2、接到一个需求后,怎么去评估工时,依据是什么

3、如果你作为一个小组长,接到一个新需求,你怎么去分配工作给组员

4、自动化测试python + unittest + requests 的断言

5、lambda函数:lambda和普通的函数相比,就是省去了函数名称而已,同时这样的匿名函数,又不能共享在别的地方调用。 

    lambda语句中,冒号前是参数,可以有多个,用逗号隔开,冒号右边的返回值。lambda语句构建的其实是一个函数对象,见证一下:

    >>> foo = [2, 18, 9, 22, 17, 24, 8, 12, 27]
    >>> print filter(lambda x: x % 3 == 0, foo)
    [18, 9, 24, 12, 27]
    >>> print map(lambda x: x * 2 + 10, foo)
    [14, 46, 28, 54, 44, 58, 26, 34, 64]

    >>> print reduce(lambda x, y: x + y, foo)

    139

原文地址:https://www.cnblogs.com/DeryKong/p/10715758.html