面试测试总结

Posted 2021-01-09 jingsiqing

1、给你一个APP，你该如何进行测试？

　　（1）功能测试-----主要测试APP的流程和业务要求是否达标（手动和自动化结合测试）

　　（2）性能测试------关注APP的性能参数：CPU、FPS、内存、耗电量、流量，同时关注APP的安装和启动耗时

　　（3）接口测试------关注数据的传送，数据的安全加密

　　（4）安全测试------APP内涉及到用户的信息是否加密，XSS攻击、sql注入来测试

　　（5）兼容测试------平台/系统（ios、android）、不同机型、相同机型的不同系统版本、分辨率、版本之间的兼容等

 

2、Appium 的工作原理？

Appium启动时会创建一个http：127.0.0.1:4723/wd/hub服务端（相当于一个中转站），脚本会告诉服务器我要做什么，服务端再去跟设备打交道，服务端完成了脚本交给他的任务之后

服务端和设备如何通讯？

服务端和设备默认使用4723端口进行通讯的，底层调用uiautomator工具，在测试的时候服务端会给设备扔一个jar包就是appiumbootstrap.jar，会启动这个包，启动之后会在手机上创建一个socket服务，暴露的就是4723的端口；相对于socket服务来说，appium服务端又是一个客户端；

服务端的4723可以修改，设备上的不可以；服务端收到脚本传递过来的命令之后，通过电脑上的4723端口，想设备上的4723端口发送指令，appiumbootstrap.jar收到指令后回去完成点击，滑动其他的操作，完成之后再通过服务给服务端一个相应。服务端收到之后再去相应脚本

--------------------- 本文来自 jffhy2017 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/jffhy2017/article/details/69220719?utm_source=copy 

 

　　

Appium工作原理

2.1 Android

在Android端，appium基于WebDriver协议，利用Bootstrap.jar，最后通过调?用UiAutomator的命令，实现App的自动化测试。

UiAutomator测试框架是Android SDK自带的App UI自动化测试Java库。

另外由于UiAutomator对H5的支持有限，appium引入了chromedriver以及safaridriver等来实现基于H5的自动化。

appium 在android端工作流

1. client端也就是我们 test script是我们的webdriver测试脚本。

2. 中间是起的Appium的服务，Appium在服务端起了一个Server（4723端口），跟seleniumWebdriver测试框架类似， Appium?持标准的WebDriverJSONWireProtocol。在这里提供它提供了一套REST的接口,Appium Server接收web driverclient标准rest请求，解析请求内容，调?用对应的框架响应操作。

3. appium server会把请求转发给中间件Bootstrap.jar，它是用java写的，安装在手机上.Bootstrap监听4724端口并接收appium的命令，最终通过调?用UiAutomator的命令来实现。

4. 最后Bootstrap将执行的结果返回给appium server。

5. appium server再将结果返回给 appium client。

2.2 ios

在IOS端，appium同样使?WebDriver的一套协议。

与Android端测试框架不同的是，appium ios封装了apple的Instruments框架，主要用了Instrument里的UIAutomation（Apple的?自动化测试框架），然后在设备中注?入bootstrap.js进?行监听。

appium 在ios端工作流

1. client端 依然是 test script是我们的webdriver测试脚本。

2. 中间是起的Appium的服务，Appium在服务端起了一个Server（4723端口），跟seleniumWebdriver测试框架类似， Appium?持标准的WebDriverJSONWireProtocol。在这里提供它提供了一套REST的接口,Appium Server接收web driverclient标准rest请求，解析请求内容，调?用对应的框架响应操作。

3. appium server调用instruments.js 启动?一个socketserver，同时分出一个?子进程运?instruments.app，将bootstrap.js（一个UIAutomation脚本）注?入到device?于和外界进行交互

4. 最后Bootstrap.js将执行的结果返回给appium server

5. appium server再将结果返回给 appium client。

所以我们可以看到android与ios区别在于appium将请求转发到bootstrap.js或者bootstrap.jar.然后由bootstrap驱动UIAutomation和UiAutomator去devices上完成具体的动作。 

3、接口测试用例的设计？

　　　1)   优先级--针对所有接口

　　　　1、暴露在外面的接口，因为通常该接口会给第三方调用；

　　　　2、供系统内部调用的核心功能接口；

　　　　3、供系统内部调用非核心功能接口；

　　　2)   优先级--针对单个接口

　　　　1、正向用例优先测试,逆向用例次之(通常情况，非绝对)；

　　　　2、是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制

　  　 　3、无网络，接口的响应时间和返回值

 

4、接口测试用例过多时，如何简化用例？

　　（1）根据接口的使用对象(外部，系统内部)，有选择的去、留部分用例

      （2）根据接口的是否核心接口，有选择的去、留部分用例

      （3）根据参数说明，及实际情况，有选择的去、留部分用例

 

5、接口测试的输入值如何考虑设计？

　　（1）覆盖所有的必选参数

　　（2）组合可选参数

　　（3）参数有、无或为null

　　（4）参数的顺序、个数、类型

　　（5）参数类型的数值大小，输入的数值的范围

　　（6）参数字符串的长短

　　（7）参数包含特殊字符

 

6、接口测试质量评估标准：

　　a) 业务功能覆盖是否完整

　　b) 业务规则覆盖是否完整

　　c) 参数验证是否达到要求（边界、业务规则）

　　d) 接口异常场景覆盖是否完整

　　e) 接口覆盖率是否达到要求

　　f)  代码覆盖率是否达到要求

　　g) 性能指标是否满足要求

　　h) 安全指标是否满足要求

 

7、软件测试用例设计

　　推荐一篇博客，学习链接：https://www.cnblogs.com/sunshine2016/category/840159.html

 

8、接口测试一遍，功能测试一遍，是不是测试重复了？

　　不会，可以设置2个测试的关注点不同，推荐一篇博客，学习链接：http://www.cnblogs.com/puresoul/p/5388586.html

 

9、http和https的区别？

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

--------------------- 本文来自 xh15 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/xionghuixionghui/article/details/68569282?utm_source=copy 

 

10、请求方式是否有所了解？分别说明

　　GET：发送请求来获得服务器上的资源，请求体中不会包含请求数据，请求数据放在协议头中。另外get支持快取、缓存、可保留书签等。幂等

　　POST：和get一样很常见，向服务器提交资源让服务器处理，比如提交表单、上传文件等，可能导致建立新的资源或者对原有资源的修改。提交的资源放在请求体中。不支持快取。非幂等

　　HEAD：本质和get一样，但是响应中没有呈现数据，而是http的头信息，主要用来检查资源或超链接的有效性或是否可以可达、检查网页是否被串改或更新，获取头信息等，特别适用在有限的速度和带宽下。

　　PUT：和post类似，html表单不支持，发送资源与服务器，并存储在服务器指定位置，要求客户端事先知道该位置；比如post是在一个集合上（/province），而put是具体某一个资源上（/province/123）。所以put是安全的，无论请求多少次，都是在123上更改，而post可能请求几次创建了几次资源。幂等

　　DELETE：请求服务器删除某资源。和put都具有破坏性，可能被防火墙拦截。如果是https协议，则无需担心。幂等

　　CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。就是把服务器作为跳板，去访问其他网页然后把数据返回回来，连接成功后，就可以正常的get、post了。

　　OPTIONS：获取http服务器支持的http请求方法，允许客户端查看服务器的性能，比如ajax跨域时的预检等。

　　TRACE：回显服务器收到的请求，主要用于测试或诊断。一般禁用，防止被恶意攻击或盗取信息。

11、get请求和post请求的区别？

　　

 

	GET	POST
点击返回/刷新按钮	没有影响	数据会重新提交
缓存/添加书签	可以	不可以
历史记录	有	没有
编码类型	application/x-www-form-urlencoded	application/x-www-form-urlencoded  或 multipart/form-data。为二进制数据使用 多重编码
是否幂等	幂等	非幂等
长度限制	http协议没有限制，但是实际浏览器或服务 器有(最大2048)	理论上没有，可能会收到服务器配置或内存限制
数据类型限制	只能ASCII，非ascii都要编码传输	没有限制，允许二进制数据
安全性	数据全部展示在url中，不安全	相比get，通过request body传递数据，比较安全
可见效	可见	不可见

 

注意：以上只是一种规范，如果非要给get加上request body，或者给post的url上带上参数，技术上没有任何问题。

12、如何确定性能测试的指标？标准如何定？如何推动性能的优化？

　　（1）基于现有的业务确定

　　（2）现有的行业标准

　　（3）个人之前的工作经验等

　　性能的优化：

　　　　内存使用优化，程序架构优化，降低模块间耦合，要不就是网络性能优化咯

 

一、开发不认可你的bug怎么办？

　　

1、可以先分析哪些类型的bug会出现这个情况，然后根据每种情况进行针对性说明，分别从bug本身、环境因素、人等方面回答，这样可以体现自己的分析能力和处事方式

2、开发不认同的bug一般是：数据问题导致的bug、环境问题导致（偶发）、优化体验类的bug

3、如果是应聘钢，也可以回答说出这个情况的“人”的原因，比如一种可能是测试人员和开发人员之间有矛盾等导致

4、工作中遇到这个情况后，不要轻易认同开发给的笼统模糊的观点，多纬度验证（排查法），明确bug出现的条件，定位bug的真正原因，测试实际上就是提供信息，比如app出现闪退的问题，我们就同一手机上验证不同的版本，或者不同手机验证同一个版本，或同一款手机，不同的操作系统版本上，验证同一个app版本。

 

二、给的测试时间特别短，怎么安排写用例和执行测试的时间？

 

　　考察做事时是否灵活，是否会注意区分轻重缓急，以及解决问题的能力，（面试官往往通过应聘者表现出来的分析能力，归纳总结能力来判断其解决问题的能力），回答时可以根据具体的情况具体分析，然后结合具体的实例：

思考范围：

     是否为新需求/旧某块的变更优化、此次变更影响的模块范围、此次任务的优先级、此次变更的总开发周期、当前的测试人员数量、当前的测试人员其他任务的排期、项目经理是否存在对此次变更的排期不合理、根据实际情况考虑后，与项目经理等人沟通排期时间，

说白了就是质量和时间的问题，这个时间我可以完成，但不保证质量，质量保证的情况下一定的时间是不可以被忽略的，鱼和熊掌不能兼得

　　1、是否需要写很多的用例？或者是否需要做大量的测试分析？这是不一定的，比如bug修复对应的回归时间都是不能明确给出时间的。

　　2、用例是否可以从用例库中筛选？

　　3、是需求，没有用例的情况下，考虑用xmind

　　4、加班可以追赶进度的话，适当的加班追赶（但这不是长久之计）

　　5、管理层对项目质量的态度（这个基本上都是不用 说的）

　　6、如果是面试管理岗，需要考虑到：i比如用什么样的人来执行这样的任务比较合适？要考虑这个现象是暂时还是常态，是否需要/可以优化？