2021-04-15

admin管理员组

文章数量:1530060

综合复习练习题：

1.web端和app端测试的相同点和不同点的是？
相同点
不管是传统行业的web测试，还是新兴的手机app测试，都离不开测试的基础知识：
1）同样的设计测试用例方法：边界值分析法、等价类划分、错误推测法、场景法等（若想看这些基础课视频，直接点击原文看腾讯课堂的视频，都有，且免费！）；
2）同样的测试方法：黑盒测试，验证业务功能是否正确符合用户或者设计预期；
3）都要检查UI：界面的布局、风格和按钮等是否简洁美观、是否统一等；
4）页面性能检测：测试页面载入和翻页的速度、登录时长、内存是否溢出等；
5）应用的稳定性：测试应用系统的稳定性等，不会闪退卡死等。

不同点
相对于web测试，APP测试，除了要考虑基本的功能测试、性能等，还要考虑手机本身固有的属性特征。所以APP测试过程中还需要注意如下几个方面特性：

1）手机作为通信工具，来电、去电、接收短信等操作都会对app应用程序产生影响，所以app测试第一个要考虑的属性特征是：中断测试。
中断测试有人为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证：
a.来电中断：呼叫挂断、被呼叫挂断、通话挂断、通话被挂断
b.短信中断：接收短信、查看短信
c.其他中断：蓝牙、闹钟、插拔数据线、手机锁定、手机断电、手机问题（系统死机、重启）

2）手机用户对app产品的安装卸载操作：
a.从上一个版本/上两个版本直接升级到最新版本。
b.全新安装新版本
c.新版本覆盖旧版本安装
d.卸载旧版本，安装新版本
e.卸载新版本，安装新版本

3）web自动化测试使用的工具较常用的是QTP，而android手机自动化测试工具比较常用的是monkey、monkeyrunner、appium。
————————————————

2…Ios和android测试的侧重点是？
1、手机操作系统：
Android较多，Ios较少且不能降级，只能单向升级。
2、多分辨率测试：
Android端有20多种，而Ios较少。
3、按键：Android一般有3个按键，而Ios只有一个home键。
①Android长按home键呼出应用列表和切换应用，然后右滑则终止应用。
Back键在大部分情况下和页面上的返回键功能一样，不过还要看Back键是否被重写，测试Back键的反馈是否正确，可以在应用间切换，还可以返回主屏幕。
②Ios单击home键返回主界面，双击回到单手操作模式。
4、push测试（推送测试）：
①Android：点击home键，程序后台运行时，此时接收到push，点击后唤醒应用，查看此时是否可以正常跳转。
②Ios：点击home键关闭程序；屏幕锁屏时的情况（红点的显示）。
5、安装和卸载测试：
Android的下载、安装的平台和工具，平台比较多。
Ios主要有App store，iTunes，testflight下载。
6、升级测试：
可以被升级的必要条件：新旧版本具有相同的签名、具有相同的包名、有一个标识符区分新旧版本（如版本号）。
7、分享跳转：
分享后的文案是否正确、分享后跳转是否正确、显示的消息来源是否正确。
8、触屏测试：
同时触摸不同的位置或同时进行不同的操作，查看客户端的处理情况，比如，是否会crash等。

3.如何测试一个app的登录场景？
功能性用例设计点：

1. 输入已注册的用户名和正确的密码，验证是否成功登录

2. 输入已注册的用户名和不正确的密码，验证是否成功失败，且提示信息正确

3. 输入未注册的用户名和任意密码，验证是否登录失败，且提示信息正确

4. 使用未激活账户登录，验证是否登录失败

5. 使用被停用用户登录，验证是否登录失败

6. 用户名和密码两者都为空，验证是否登录失败，且提示信息正确

7. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确

8. 如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入正确的验证码，验证是否登录成功

9. 如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入错误的验证码，验证是否登录失败，且提示信息正确
   10.用户名和密码是否大小写敏感
   11.页面上的密码框是否加密显示、或者是否需要有明暗码切换按钮
   12.后台系统创建的用户第一次登录成功时，是否提示修改密码
   13.忘记用户名和忘记密码的功能是否可用
   14.前端页面是否根据设计需求限制用户名和密码长度
   15.如果登录功能需要验证码，点击验证码图片或者点击换一张是否可以更换验证码，更换后的验证码是否可用
   16.刷新页面是否会刷新验证码
   17.如果验证码有时效性，需要分别时效性内和时效性外验证码的有效性
   18.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面
   19.不同级别的用户，比如管理员和普通用户，登录系统后权限是否正确
   20.页面默认焦点是否定位在用户输入框中
   21.快捷键Tab和Enter等，是否可以正常使用
   22.为空和输入空格字符串的校验是否一致
   23.使用中文键盘输入字母和使用英文键盘输入字母传入后端的字符长度是否一致
   24.成功登录后的session的时效设置
   25.输入栏是否设置快速删除按钮
   26.用户名和密码是否支持特殊字符和中文
   27.浏览器的前进后退按钮，是否有效
   28.成功登出后，点击浏览器回退按钮，是否可以继续操作系统
   29.需求中是否有登录时间限制，如果有验证时间限制是否有效
   30.验证不同登录方式的正确性：扫码、账号密码、第三方……
   31.若支持手机号+验证码登录，验证码是否有时间限制，移动设备是否可以直接获取验证码
   32.操作错误提示信息是否简单明了
   兼容性测试用例设计点：

10. 不同浏览器下，验证登录页面的显示以及功能正确性

11. 相同浏览器的不同版本下验证登录页面的显示以及功能正确性

12. 不同移动设备终端的不同浏览器下，验证登录页面显示以及功能的正确性

13. 不同分辨率的界面下，验证登录页面的显示以及功能正确性
    安全性测试用例设计点：

14. 用户密码后台存储是否加密

15. 用户密码在网络传输过程中是否加密

16. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码

17. 不登录的情况下，在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面

18. 密码输入框是否不支持复制粘贴

19. 密码输入框内输入的密码是否都可以在页面源码模式下被查看

20. 用户名和密码输入框分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面

21. 用户名和密码输入框分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改

22. 连续多次登录失败的情况下，系统是否会阻止后续的尝试以应对暴力破解
    10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期
    11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性
    12.是否可以记住密码，记住的密码保存是否加密，记住的密码是否有有效期，过了有效期后是否清空密码
    13.是否支持第三方登录
    14.密码的强弱性，复杂度校验
    15.异地登录校验、更换设备登录校验、登陆信息异常是否考虑账户冻结停用、是否允许第三方平台存储密码
    16.是否可以使用登录的api发送登录请求，并绕开验证码校验
    17.是否可以用抓包工具抓到的请求包直接登录
    18.截取到的token等信息，是否可以在其他终端上直接使用，绕开登录，token过期时间校验
    19.登录错误后的提示是否存在安全隐患
    性能压力测试的用例设计点：

23. 单用户登录的响应时间是否小于3秒

24. 单用户登录时，后台请求数量是否过多

25. 高并发场景下用户登录的响应时间是否小于5秒

26. 高并发场景下服务端的监控指标是否符合预期

27. 高集合点并发场景下，是否存在资源死锁和不合理资源等待

28. 长时间大量用户连续登录和登出，服务器是否存在内存泄露

29. 输入内容校验是否加入了函数防抖

4.Push消息测试如何测试？

1. push专项测试
   1.1. 覆盖的系统
   1.2. 覆盖的机型
   1.3. 到达率（即时？定时？）
   1.4. 覆盖哪些模块的push？
   IM/秘邮消息push
   应用通知的push
   1.5. 内容展示
   显示几行？
   标点符号显示？
   时间显示？
   APP icon显示是否正常
   1.6. push推送的场景
2. 手机是否设置开启消息通知栏（开启/关闭）
3. APP是否运行/锁屏，是否有推送消息/是否可点击查看
   a) App前台运行
   b) App前台运行-锁屏-亮屏
   c) App前台运行-锁屏-息屏
   d) App后台运行
   e) App后台运行-锁屏-亮屏
   f) App后台运行-锁屏-息屏
   g) APP被杀进程
4. 推送用户范围
   a) 全部用户推送
   b) 部分用户推送/分组推送
   c) 指定用户推送
   i. 已登录
   ii. 未登录
5. 收到推送，跳转测试
   a) 单个推送
   b) 折叠推送

5.App的闪退通常是什么原因造成的？
一般App闪退是由于以下几个原因造成的.

1.缓存垃圾过多
由于安卓系统的特性,如果长时间不清理垃圾文件.会导致越来越卡.也会出现闪退情况.
2. 运行的程序过多,导致内存不足
3.应用版本兼容问题，如果应用版本太低，会导致不兼容，造成闪退。此外，有些新版本在调试中，也会造成应用闪退。

4… 检查APP中访问网络的地方，组件中的ImageView是否可以正常的下载并显示到app 页面上。
5.检查APP的sdk和手机的系统是否兼容。
6.在一些特定情况下的闪退,比如播放视频,在Android5.0 升级到Android6.0的时候,有些系统API老版本有,新版本没有,到时回去对象的时候失败,报空,系统就会出现闪退问题.

6.常见的接口协议/类型是什么?

1. OPC协议：OPC（Object Linking and Embedding(OLE) for Process Control）是微软公司的对象连接和嵌入技术在过程控制方面的应用。该标准中定义了在基于PC的客户机之间进行自动化数据实时交换的方法。
2. ODBC开放数据库连接（Open Database Connectivity，ODBC）是为解决异构数据库间的数据共享而产生的，现已成为WOSA(The Windows Open System Architecture(Windows开放系统体系结构))的主要部分和基于Windows环境的一种数据库访问接口标准ODBC 为异构数据库访问提供统一接口。
3. WebService协议是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，Web Service技术，能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。
4. Http Restful协议是一种网络应用程序的设计风格和开发方式，适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。

7.常见的接口请求方式是什么？
一．接口请求的八种方式：

1、Get 向特定资源发出请求（请求指定页面信息，并返回实体主体）
2、Post 向指定资源提交数据进行处理请求（提交表单、上传文件），又可能导致新的资源的建立或原有资源的修改
3、Put 向指定资源位置上上传其最新内容（从客户端向服务器传送的数据取代指定文档的内容）
4、Head 与服务器索与get请求一致的相应，响应体不会返回，获取包含在小消息头中的原信息（与get请求类似，返回的响应中没有具体内容，用于获取报头）
5、Delete 请求服务器删除request-URL所标示的资源*（请求服务器删除页面）
6、Trace 回显服务器收到的请求，用于测试和诊断
7、opions 返回服务器针对特定资源所支持的HTML请求方法 或web服务器发送*测试服务器功能（允许客户端查看服务器性能）
8、Connect HTTP/1.1协议中能够将连接改为管道方式的代理服务器

二．get 和 post区别：
1.get请求无消息体，只能携带少量数据，且不安全
post请求有消息体，可以携带大量数据，且安全
2.携带数据的方式：
get请求将数据放在url地址中
post请求将数据放在消息体body中
3.GET方式提交的数据最多只能有1024字节，而POST则没有此限制。

三．Get和head被称为安全方法：
它们只会从服务器获取数据而不会操作数据，数据不变就不会有问题

8.常见的状态码是什么以及都有什么意思请解释说明?
2开头的状态码
2xx表示成功处理了请求状态码
200（成功）服务器已经成功处理了请求通常；

3开头的状态码
3xx（重定向）表示要完成请求，需要进一步操作，通常这些状态码用来重定向
304（未修改）自从上次请求后，请求的网页未修改过，服务器返回此响应时不会返回网页内容；

4开头的状态码
4xx(请求错误)这些状态码表示请求可能出错，妨碍了服务器的处理
400（错误请求）服务器不理解请求的语法；
403（禁止）服务器拒绝请求
404（未找到）服务器找不到请求的网页

5开头的状态码
5xx(服务器错误)这些状态码表示服务器再尝试处理请求时发生内部错误，这些错误可能是服务器本身错误而不是请求错误
501（尚未实施）服务器不具备完成请求的功能；
例如：服务器无法识别请求方法时可能会返回此代码
500（服务器内部错误）服务器遇到错误无法完成请求
502（错误网卡）服务器做为网关或代理，从上游服务器收到无效响应
503（服务不可用）服务器目前无法使用（由于超载或者停机维护）通常这只是暂时状态
504（网关超时）服务器做为网关或代理，但是没有及时从上游服务器收到请求
505（http版本不受支持）服务器不支持请求中所用的http协议版本

9.接口测试的原理是什么?
原理：模拟客户端向服务器发送请求报文，服务器接受请求报文后对相应的报文做处理并向客户端返回应答，客户端再接受应答的一个过程。
接口测试是黑盒测试。作为黑盒测试，基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑。

10.后台接口测试了一遍前端也测试一遍是不是重复测试?
1、基本功能测试：
由于是针对基本业务功能进行测试，所以这部分是两种测试重合度最高的一块，开发同学通常所指的也主要是这部分的内容。

2、边界分析测试：
在基本功能测试的基础上考虑输入输出的边界条件，这部分内容也会有重复的部分（比如业务规则的边界）。但是，前端的输入输出很多时候都是提供固守的值让用户选择（如下拉框），在这种情况下测试的边界范围就非常有限，但接口测试就不存在这方面的限制，相对来说接口可以覆盖的范围更广，同样的，接口出现问题的概率也更高。

3、性能测试：
这个比较容易区分，虽然都需要做性能测试，但关注点确大不相同。App端性能主要关注与手机相关的特性，如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别，所以这部分内容是需要分开单独进行测试的，理论上来说这也是不同的部分。

综论：
1、接口测试和app测试的活动有部分重复的内容，主要集中在业务功能测试方面。除此之外，针对各自特性的测试都不一样，需要分别进行有针对性的测试，才能确保整个产品的质量。
2、接口测试可以关注于服务器逻辑验证，而UI测试可以关注于页面展示逻辑及界面前端与服务器集成验证

11.接口测试的流程/步骤(你的接口测试怎么做的)？
1.找开发或者开发主管索要接口说明文档（API文档）。作用：是开发测试脚本的依据
2.熟悉业务，设计测试用例，准备测试数据
3.根据接口说明文档开发接口测试脚本，执行脚本

1.API文档
2.测试文档接口说明，参数，返回值，是否齐全
3.熟悉业务
4.设计测试用例，准备测试数据
5.开发接口测试脚本
6.执行脚本，调入数据
7.提交BUG
8.写报告

12.get/post的区别？

1. get是从服务器上获取数据，post是向服务器传送数据。
   get 和 post只是一种传递数据的方式，get也可以把数据传到服务器，他们的本质都是发送请求和接收结果。只是组织格式和数据量上面有差别，http协议里面有介绍
2. get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
   因为get设计成传输小数据，而且最好是不修改服务器的数据，所以浏览器一般都在地址栏里面可以看到，但post一般都用来传递大数据，或比较隐私的数据，所以在地址栏看不到，能不能看到不是协议规定，是浏览器规定的。
3. 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。
   没明白，怎么获得变量和你的服务器有关，和get或post无关，服务器都对这些请求做了封装
4. get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。
   post基本没有限制，我想大家都上传过文件，都是用post方式的。只不过要修改form里面的那个type参数
5. get安全性非常低，post安全性较高。
   如果没有加密，他们安全级别都是一样的，随便一个监听器都可以把所有的数据监听到。
   ————————————————

13.如何编写接口测试用例？
三个步骤：

初始化测试数据
调用接口，传入输入数据
对输出断言

14.性能测试都包含了哪些？（负载测试 压力测试 容量测试）
负载测试- 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。
强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。
容量测试- 核实测试用户同时使用软件程序的最大数量。

15.什么时候执行性能测试？
功能测试通过；一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。

16.你是如何做测试分析？
1、覆盖度够全
PRD、UI搞、时序图、表结构变更设计、概要设计文档、接口文档等等的参考文档上的内容在测试分析中都有体现

2、结构清晰易懂
不了解此块业务的人看到测试分析，也能快速了解业务框架结构、细节逻辑、业务间关联关系

3、维护成本低
在需求不断变化，迭代速度越来越快的情况下，如何快速找到所有需求要更新的部分，以及合理把新增

部分加入到原有的测分中且不用对原有结构做大的调整

4、隐式需求挖掘较透彻
往往需求文档写的不够细致到位，或者是为了实现新的需求的部分细节功能会和与原有的某些功能相违背
甚至是不兼容、设计的不合理，可变性降低等等

5、非功能性方面的考虑
性能能否满足、容错处理、业务层面的安全性考虑、用户体验等
————————————————

17.性能测试的步骤/流程？
一、 规范性能测试实施流程的意义

规范的性能测试实施流程能够加强测试工作流程控制，明确性能测试各阶段应完成的工作，指导测试人员正确、有序的开展性能测试工作，提高各角色在性能能测试中的工作效率。本次分享的性能测试实施流程是性能测试开展的”指导方针”，希望帮助您可以早日成为性能测试”达人”。

二、 性能测试实施流程
性能测试流程分为五个阶段，分别是【需求调研阶段】→【测试准备阶段】→【测试执行阶段】→【测试报告阶段】→【测试总结阶段】。
————————————————

18.你如何识别性能测试的瓶颈？
　1、网络瓶颈，如带宽，流量等形成的网络环境
　　2、应用服务瓶颈，如中间件的基本配置，CACHE等
　　3、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
　　4、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
　　5、应用程序本身瓶颈，这个是测试过程中最需要去关注的，需要测试人员和开发人员配合执行，然后定位
逐步细化分析，先可以监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，然后根据所测系统具体情况，进行初步问题定位，然后确定更详细的监控指标来分析。

19.请解释下 常用的性能测试指标的含义?
1、时间特性，主要指的是软件产品的事物响应时间（用户发出请求到收到应答的这段时间）

2、资源利用率，包括：cpu、内存、网络、硬盘、虚拟内存（如Java虚拟机）

3、服务器可靠性，指服务器能在相对高负载情况下持续的运行

4、可配置优化性，指服务器配置优化、业务逻辑优化、代码优化等

20. 响应时间 并发用户数 吞吐量 性能计数器 TPS HPS QPS?
常用的网站性能测试指标有：TPS、吞吐量、并发数、响应时间、性能计数器等。

并发数
并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。

响应时间
响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间。

吞吐量
吞吐量是指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。

QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。

跟吞吐量有关的几个重要是：并发数、响应时间。

QPS（TPS），并发数、响应时间它们三者之间的关系是：

QPS（TPS）= 并发数/平均响应时间

性能计数器
性能计数器是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。

Linux中可以使用 top 或者 uptime 命令看到当前系统的负载及资源利用率情况。

资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。

21.针对性能测试 负载测试 压力测试在你项目中的使用？
1）性能测试
性能测试主要评价系统或组件的性能是否和具体的性能需求一致，例如：对访问速度的性能需求或对内存使用情况的需求。特定性能测试的关注点在于组件或系统在规定的时间内和特定的条件下响应用户或系统输入的能力。
不同的性能的度量方法取决于不同的被测对象。对于一个单独软件组件，其性能可以根据CPU主频来判定。而带客户端的系统，其性能则要根据系统处理特定用户请求的响应时间来判定。对于那些由多种组件（如客户端、服务器、数据库）构成的系统，则要进行各组件之间的性能测试。

2）负载测试
负载测试是一种通过增加负载来评估组件或系统的性能的测试方法。例如：通过增加并发用户数和（或）事务数量来测量组件或系统能够承受的负载。负载测试和性能测试的主要区别在于负载测试时，系统负载是逐渐增加的，而不是一步到位，负载测试需要观察系统在各种不同的负载情况下是否都能够正常工作。

3）压力测试
压力测试是评估系统处于或超过预期负载时系统的运行情况。压力测试的关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。在压力级别逐渐增加时，系统性能应该按照预期缓慢下降，但是不应该崩溃。压力测试还可以发现系统崩溃的临界点，从而发现系统中的薄弱环节。
例如：系统最大支持的同时在线用户数是1000个，压力测试需要测试在1000个用户甚至2000个用户同时在线时系统的表现。虽然测试时负载已经超过了系统的设计能力，但是在这种情况下被测试系统也不应该发生崩溃。压力测试也可以针对系统资源进行测试，例如：在系统内存耗尽情况下，测试系统的运行情况，这种情况下被测试系统也不应该崩溃。

22.如何判断一个bug是前端bug还是后台bug?
端bug特点 1， 界面相关 2，布局相关 3，兼容性相关

后端bug特点 1，业务逻辑相关 2，性能相关 3，数据相关 4，安全性相关

1、经验法
软件测试人员应不断精进自己的技能，负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类bug了。 例如： 网页上的某个图片的分辨率不对，如果我们了解实现过程，可以想到一般情况下，是根据某个地址去服务器取图片的，数据库一般只保存地址，那么图片能正确显示，就说明后端的基本功能是满足需求的。如果具体图片分辨率有误，最可能的原因是前端显示过程出了差错。

2、查日志
当我们发现一个bug，并不确定这个bug属于前端还是后端，可以查看后端服务的日志，复现bug时，查看日志中有没有相关信息。基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析

3、查接口
这种方法常用于查看是后端返回给前端的数据有误，还是前端显示有误。 大多数浏览器都有自带的接口查看工具，如Chrome，FireFox等都可以通过F12开启抓包，在NetWork中可以看到当前页面发送的每个http请求。 我们需要对比通过后端接口拿到的数据和前端显示的数据，来确认问题出在哪里。如果数据错了，页面显示是错的，也是正常的，先从后端入手去解决。
还可以分析控制台中js是否有错误，network中状态码是否有问题，如果是500等说明服务端有问题。
比如登录页面，输入账号和密码点击登录，结果没有跳转也没有反应
可以打开控制台，看是否有js错误，如果有就是前端问题，没有且有正常post请求再看network状态码，如果是404有可能是前端参数写错或者后台接口改了，前后端都可以提，500就是后台出了问题。

23.说一说你所知道的Python 数据类型有哪些？

1. 数字类型
   Python数字类型主要包括int（整型）、long（长整型）和float（浮点型），但是在Python3中就不再有long类型了。
   int（整型）
   在32位机器上，整数的位数是32位，取值范围是-231231-1，即-2147483648214748364；在64位系统上，整数的位数为64位，取值范围为-263263-1，即92233720368547758089223372036854775807。
   long（长整型）
   Python长整型没有指定位宽，但是由于机器内存有限，使用长的长整数数值也不可能无限大。
   float（浮点型）
   浮点型也就是带有小数点的数，其精度和机器有关。
   complex（复数）
   Python还支持复数，复数由实数部分和虚数部分构成，可以用 a + bj,或者 complex(a,b) 表示， 复数的实部 a 和虚部 b 都是浮点型。
2. 字符串
   在Python中，加了引号的字符都被认为是字符串，其声明有三种方式，分别是：单引号、双引号和三引号；Python中的字符串有两种数据类型，分别是str类型和unicode类型，str类型采用的ASCII编码，无法表示中文，unicode类型采用unicode编码，能够表示任意字符，包括中文和其他语言。
3. 布尔型
   和其他编程语言一样，Python布尔类型也是用于逻辑运算，有两个值：True（真）和False（假）。
4. 列表
   列表是Python中使用最频繁的数据类型，集合中可以放任何数据类型，可对集合进行创建、查找、切片、增加、修改、删除、循环和排序操作。
5. 元组
   元组和列表一样，也是一种序列，与列表不同的是，元组是不可修改的，元组用”()”标识，内部元素用逗号隔开。
6. 字典
   字典是一种键值对的集合，是除列表以外Python之中最灵活的内置数据结构类型，列表是有序的对象集合，字典是无序的对象集合。
7. 集合
   集合是一个无序的、不重复的数据组合，它的主要作用有两个，分别是去重和关系测试。

24.你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解?
8. 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
9. 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。

25.给你一个网站，你如何测试?给你一个app程序你要怎么做？
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：
功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
② 设计测试用例：
功能性测试可以包括，但不限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。
③ 提交功能的测试。
多媒体元素是否可以正确加载和显示。
多语言支持是否能够正确显示选择的语言等。
④ 界面测试可以包括但不限于以下几个方面：
页面是否风格统一，美观；页面布局是否合理，重点内容和热点内容是否突出；控件是否正常使用；对于必须但为安装的空间，是否提供自动下载并安装的功能;文字检查
⑤ 性能测试一般从以下两个方面考虑：
压力测试；负载测试；强度测试
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
⑥ 安全性测试：
1 基本的登录功能的检查 2 是否存在溢出错误，导致系统崩溃或者权限泄露 3 相关开发语言的常见安全性问题检查，例如 SQL 注入等。4 如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
⑦ 兼容性测试，根据需求说明的内容，确定支持的平台组合：浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性
开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。

(1) 功能测试
每项开发的新功能都需要进行测试。app测试中功能测试是一个重要方面。测试人员应该要进行手动测试和后期的自动化测试维护。刚开始测试时，测试员必须把app当做"黑盒"一样进行手动测试，看看提供的功能是否正确并如设计的一样正常运作。除了经典软件测试，像点击按钮、提交订单看看会发生什么，测试员还必须执行更多功能的app测试。
除了整个手动测试过程，测试自动化对移动app也很重要。每个代码变化或新功能都可能影响现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化回归测试。现在市面上有很多自动化测试工具，有商业的也有开源的，面向各个不同平台，如Android，iPhone，WindowsPhone7，BlackBerry以及移动Webapp。根据开发策略和结构，品质管理测试专家需找出最适合他们环境的自动化工具。

(2) 客户端性能测试
一个App做的好不好，不仅仅只反应在功能上。被测的app在中低端机上的性能表现也很重要。比如：一个很好玩的游戏或应用，只能在高端机上流畅运行，在中低端机上卡的不行，也不会取得好的口碑。
关于App的性能测试，我们比较关注的参数有：CPU，内存，耗电量，流量，FPS。同时也需关注一下App的安装耗时和启动耗时。
目前大家可能比较困惑的一个问题，多高的CPU，内存，耗电量，流量，FPS才算是符合发布的值呢？这里可以告诉大家，可以参考精品游戏的一些数值，将自己研发的app与业内精品的app数据做对比。

(3) 适配兼容测试
App在经过功能测试后，也需对其进行适配兼容测试需要检查的项主要有以下几点：
(a) 在不同平牌的机型上的安装、拉起、点击和卸载是否正常；
(b) 在不同的操作系统上的安装、拉起、点击和卸载是否正常；
我们在实际测试中，常常会遇到下列问题：
(a) 在某个平牌某个系统上，app安装不上；
(b) 在某个平牌某个系统上，app无法拉起；
© 在某个平牌某个系统上，app拉起后无响应或拉起后黑屏、花屏；
(d) 在某个平牌某个系统上，app无法顺利卸载；
(4) 安全测试
App在上线前，都需要做详细的安全测试。安全测试主要为了检测应用是否容易被外界破解；是否存在被恶意代码注入的风险；上线后外挂的风险高不高等。
(5) 服务器性能测试

服务器性能测试，主要包含单机容量测试和24小时稳定性测试。单机容量测试，可以检测到单机服务器在90%的响应时间和成功率都达标的前提下，能够承载多少用户量。使用特定游戏模型压测24小时，服务无重启，内存无泄漏，并且各事务成功率达标。

26.什么是测试用例？什么是测试脚本？两者关系？
测试用例为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
测试脚本是为了进行自动化测试而编写的脚本。
测试脚本的编写必须对应相应的测试用例

27.简述：静态测试、动态测试、黑盒测试、白盒测试、α测试 、β测试分别是什么？
静态测试、动态测试相对。根据动态测试在软件开发过程中所处的阶段和作用分为单元测试、集成测试、组装测试、确认测试和系统测试。单元测试就是白盒测试。系统测试是黑盒测试。

静态测试是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处。

动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。

白盒测试也称为结构测试，主要用于检测软件编码过程中的错误。程序员的编程经验、对编程软件的掌握程度、工作状态等因素都会影响到编程质量，导致代码错误。

黑盒测试又称为功能测试，主要检测软件的每一个功能是否能够正常使用。在测试过程中，将程序看成不能打开的黑盒子，不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。

28.在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
1.和BUG对应的软件版本
2.开发的借口人员，测试人员
3.BUG的优先级
4.BUG的严重程度
5.BUG可能属于的模块
6.BUG的标题
7.BUG的描述
8.BUG的截图
9.BUG的状态
10.BUG的错误类型（数据，界面。。。。）

一篇高质量的软件缺陷记录应该考虑一下方面：

1. 通用ui要统一、准确
   缺陷报告的ui要与测试的软件ui保持一致，便于查找定位。
2. 尽量使用业界惯用的表达术语和表达方法
   使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
3. 每条缺陷报告只包括一个缺陷
   每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
4. 不可重现的缺陷也要报告
   首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
5. 明确指明缺陷类型
   根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
6. 明确指明缺陷严重等级和优先等级
   时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
7. 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
   描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（ui）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
8. 短行之间使用自动数字序号，使用相同的字体、字号、行间距
   短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
9. 每一个步骤尽量只记录一个操作
   保证简洁、条理井然，容易重复操作步骤。
10. 确认步骤完整，准确，简短
    保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
11. 根据缺陷，可选择是否进行图象捕捉
    为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。
     附加必要的特殊文档和个人建议和注解
    如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
12. 检查拼写和语法缺陷
    在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
13. 尽量使用短语和短句，避免复杂句型句式
    软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。
    以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。
14. 缺陷描述内容
    缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。

29.在你的项目中详细的描述一个测试活动完整的过程？
项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪
开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
测试用例完成后，测试和开发需要进行评审。
测试人员搭建环境
开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。
开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。
重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。
如果有客户反馈的问题，需要测试人员协助重现并重新测试。
————————————————

30.如果项目周期很短，测试人力匮乏，你是怎么协调的？

1. 首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来；
2. 提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，
   然后再编写测试用例，再评审，评审通过后，再进行后续的测试。

31.描述下你团队的测试分工？
10人为例 2个前端 2个 后台 5个移动 2个测试 1个产品 1个项目经理

32.你做移动端的应用和web的程序应用都是如何的兼容性测试？

https://blog.csdn/weixin_46183674/article/details/113914319移动端
1、适配系统版本：去二手平台找到低版本的设备
2、 适配不同机型：选择世面上的主流机型
3、适配尺寸：
4、适配分辨率：分辨率常见的720p(720×1280),1080p(1080×1920),2k(2560×1440)
5、适配网络：三大运营商 、信号：2G、3G、4G、5G、WiFi
6、适配异形屏现在手机花里胡哨的，全面屏、曲面屏、3D屏、刘海屏、挖孔屏、越来越多，所以我们也需要测试一下系统状态栏
7、涉及到蓝牙、耳机，看对应功能需要了web端1.操作系统兼容性市场上有很多不同的操作系统，Windows 、Mac、Linux等操作系统。同一个应用在不同的操作系统下，可能会有兼容性问题，可能有些系统正常，有些系统不正常。2.浏览器兼容性国内主流的浏览器内核主要有3种：IE内核、Firefox内核和Chrome内核；
（1）IE内核常见的浏览器有：360安全浏览器（兼容模式）、360极速浏览器（兼容模式）、搜狗浏览器（兼容模式）、QQ浏览器；
（2）Firefox内核常见的浏览器即火狐浏览器（Firefox）；
（3）Chrome内核常见的浏览器有
3.分辨率兼容性同一个页面在不同分辨率下，显示的样式可能会不一样。可以通过对浏览器的缩放的比例进行不同分辨率的测试。台式机分辨率：：1024×768、1280×1024、1440×900笔记本电脑分辨率：1024X768 、1280X800、1440X900、 1600X90004.网速测试项目在不同的网络环境中是否正常的运行，通过Charles、Fiddler等工具进行弱网测试。

33.移动应用的灰度是怎么做的？
1.开黑白名单（白名单的人下载后可使用，黑名单的人及时可下载但也不可使用）
2.开灰度环境（直接在后台控制，可有一级灰度发布、二级灰度发布、三级灰度发布、全量发布等，每个灰度针对不同的人群）
3.iOS版本可以使用testflight灰度发布，让加入的人群提前体验
4.Android可以使用第三方平台（如：蒲公英，可设置下载密码，提供给特定的人群体验）。或者生成下载连接发给对应的人

34.移动应用在升级安装时候应该考虑的场景？
1.APP有新版本时，打开APP是否有更新提示。
2.当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
3.当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。
4.不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。
5.删除老的APP，重新下载APP，能不能正常工作。
6.不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。
7.检查在线跨版本升级能否成功，版本过老是否提示用户重装。
8.更新成功后，用户数据有没有丢失，各个配置项是否还原。

35.如果让你来测试扫码支付，你会考虑哪些场景？
功能测试用例卡的类型（一类户：借记卡、信用卡、各个开户行二类户：虚拟账户如微信里的零钱账户、支付宝的余额宝、电子账户二维码的商户类型（微信、支付宝、汇宜、银联）支付限额（单笔限额、累计限额、日累计、月累计、支付笔数）退款（退款入口、退款进度、退款结果）对账资金流动（我方扣款数额正确，对方收款数额正确）数额及时效支付结果展示、交易明细连续扫码支付，每天的扫码支付次数限制及数额限制二维码有效期有无相机权限前后置摄像头像素低端的手机能否扫码成功兼容性兼容性（不同手机厂商自带相机功能实现不一致）
安全性：
1.是否有超时超次限制
2.测试用户操作时相关信息是否写入了日志文件、是否可追踪等
3.如果使用了安全套字，需要测试加密是否正确，加密前后的信息完整性，
正确性性能
1.用户操作的响应时间
2.系统的吞吐量（TPS）
3.系统的硬件资源情况（CPU、硬盘、磁盘）
4.网络资源占用情况等。异常场景异常情况（卡异常、余额不足）

36.一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?

1.)300个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。2.)300个用户在一个客户端上，需要更大的带宽。
3.)IP地址的问题，可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制。所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。

37.测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。运用一些测试管理工具如TestDirector进行管理也是较有效的方法，同时要注意在TestDirector中对BUG有准确的描述。在团队中建立测试人员与开发人员良好沟通中注意以下几点：一真诚、二是团队精神、三是在专业上有共同语言、四是要对事不对人，工作至上当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。

38.简述你在以前的工作中做过哪些事情，比较熟悉什么？
在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。在测试中，我感觉对用户需求的完全准确的理解非常重要。另外，就是对BUG的管理，要以需求为依据，并不是所有BUG均需要修改。测试工作需要耐心和细致，因为在新版本中，虽然多数原来发现的BUG得到了修复，但原来正确的功能也可能变得不正确。因此要注重迭代测试和回归测试。

39.请说出这些测试最好由那些人员完成，测试的是什么？
代码、函数级测试一般由白盒测试人员完成，他们针对每段代码或函数进行正确性检验，检查其是否正确的实现了规定的功能。模块、组件级测试主要依据是程序结构设计测试模块间的集成和调用关系，一般由测试人员完成。系统测试在于模块测试与单元测试的基础上进行测试。了解系统功能与性能，根据测试用例进行全面的测试。

40.在windows下保存一个文本文件时会弹出保存对话框，如果为文件名建立测试用例，等价类应该怎样划分？
10. 单字节，如A；
11. 双字节， AA、我我；
12. 特殊字符 /‘。‘；、=-等；
13. 保留字，如com；
14. 文件格式为8.3格式的；
15. 文件名格式为非8.3格式的；
16. /,,等九个特殊字符。
17. 空字符串；
18. 数字字母组合；
19. 单字节双字节组合；
20. 字符与特殊字符组合41.假设有一个文本框要求输入10个字符的邮政编码，对于该文本框应该怎样划分等价类？特殊字符，如10个或￥；英文字母，如ABCDefghik；小于十个字符，如123；大于十个字符，如11111111111；数字和其他混合，如123AAAAAAA；空字符；保留字符

42.您以往的工作中是否曾开展过测试用例的评审工作?如果有，请描述测试用例评审的过程和评审的内容。？
评审计划->预审->评审;评审内容主要是测试用例对软件需求的覆盖程度，对于相关边界是否考虑，是否针对复杂流程准备多套测试数据，是否有专门针对非功能性需求的测试。

43.在你测试的过程中如果发生时间上不允许进行全部测试，你应该怎么做？
软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷”发布。实际上完全测试是不可能的。主要有以下一个原因：-完全测试比较耗时，时间上不允许；-完全测试通常意味着较多资源投入，这在现实中往往是行不通的-输入量太大，不能一一进行测试；-输出结果太多，只能分类进行验证；-软件实现途径太多；-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；因此测试的程度要根据实际情况确定。

44.列举web自动化中常见的元素定位方式是？
1）通过class属性定位driver.findElement(By.className(“spread”)).sendKeys(“你好”);2）通过id属性定位driver.findElement(By.id(“username”)).sendKeys(“你好”);3）通过name属性定位driver.findElement(By.name(“username”)).sendKeys(“你好”);4）通过link属性定位driver.findElement(By.linkText(“海贼王”)).click();5）通过partialLink定位driver.findElement(By.partialLinkText(“贼”)).click();6）通过标签tabname定位driver.findElement(By.tagName(“a”)).click();7）通过css定位driver.findElement(By.cssSelector(“input[type=‘button‘]”)).click();8）通过xapth定位driver.findElement(By.xpath("/html/body/div[1]/input[2]")).click();//通过xpath绝对路径的方式定位driver.findElement(By.xpath("//input[@value=‘查询‘]")).click();//通过相对路径的方式定位driver.findElement(By.xpath("//a[text()=‘百度一下‘]")).click();//相对路径方式，元素是可点击的链接文字

45.简述你知道的延时等待的方式?
硬性等待，也叫线程等待，通过休眠的方式完成等待如等待5秒Thead.sleep(5000)隐式等待，通过imlicitlyWait完成延时等待，这种事针对全局设置的等待，如设置超市10秒，使用imlicitlyWait后，如果第一次没有找到元素，会在10秒之内不断循环查找元素，如果超时间10秒还没有找到，则抛出异常显式等待，智能等待，针对指定元素定位指定等待时间，指定的范围内进行元素查找，找到元素则直接返回，超时没有找到元素则抛出异常

46.完整运行一次自动化用例需要多久时间？
主要跑的是业务流，所以跑一次需要半个小时左右

47.什么是分层自动化？
金字塔结构， 最底层UnitTest，往上接口API/集成起来的service， 最上面UI自动化

48.你的测试数据是怎么准备的？
小型系统的测试，业务数据一般可以直接获取以前版本的数据，通过SQL数据或某些命令操作，取得当前需要使用的数据。 对于复杂系统，测试数据准备可能需要封装一系列的API函数，例如一种策略就是先封装出一个完全API调用函数，里面有各种常规默认值，然后再这个基础上针对业务进行封装，面向该操作只需要设定某个特定值的，可以调用该特定封装函数。极个别的，可以直接调原始的完全封装。当然，考虑到一些大公司的情况，可能还需要考虑跨平台测试架构的情况，有些人提出进一步封装，提供RestFul的调用接口来屏蔽开发工具特性。其实，都只有一个目的，尽量把测试数据和产生方法隔离，而只侧重测试的业务属性。 大量需要业务累积才能形成的测试数据，一般只有一个办法，就是通过大量实际数据脱敏。但如果涉及面向公众业务或国防业务之类，考虑到安全策略限制，就只能用笨办法就通过自动化操作来逐步实施模拟，但是这个方法就是太慢，并且不见得好用。 对测试数据准备都需要有专人专责的一段时间来做的，就是很大系统很大业务了，这时很有必要对测试数据采取严格的版本管理和配置部署管理。用户需要首先注册数据，注明对应版本。测试运行时，平台会有统一生成的脚手架，对应脚本需要使用的数据必须标明版本。 而考虑到自动化和灵活性，一般比较通用的方法还是先考虑实际数据脱敏，然后通过SQL脚本为基础，结合API调用，需要灵活配置的部分放到配置文件中，再加上配置管理来保证。这一般只在大型网站、大型系统有这个必要。 实际测试时，针对测试数据，可能有以下一些策略：1、检索：只允许从现在系统中或已使用的数据中检索，没有的话直接生成数据失败；2、新创建：有些时候需要全新创建数据；3、智能：无所谓，只要有符合要求 ；4、out-of-box：使用缓冲池预先准备的数据。

49.请简述Appium和selenium的原理？
selenium的原理我们使用Selenium实现自动化测试，主要需要3个东西1.测试脚本，可以是python，java编写的脚本程序（也可以叫做client端）2.浏览器驱动, 这个驱动是根据不同的浏览器开发的，不同的浏览器使用不同的webdriver驱动程序且需要对应相应的浏览器版本，比如：geckodriver.exe(chrome)3.浏览器，目前selenium支持市面上大多数浏览器，如：火狐，谷歌，IE等appium工作原理当开启appium服务器的同时就开启了监听端口；我们运行脚本的时候，调用任何的appiumAPI，都会向Appium Server端post一条HTTP请求，请求内容就是根据webdriver wire protocol协议规定的一条JSON格式的数据；Appium Server端接收到请求后，解析出JSON数据并发送到手机端；手机端上已经由BootStrap.jar(iOS为BootStrip.js)开启的socket服务器监听相应的端口，BootStrap.jar在appium每个session第一次访问手机端的时候会自动安装；手机端接收到对应的请求后，通过BootStrap.jar翻译成UIAutomator能执行的命令，然后通过UIAutomator处理并操作APP完成测试。

50.Charles如恶化抓取app端的htpps接口的？
1，下载charleshttps://www.charlesproxy/download/2.跟着提示一直下一步安装即可3.启动charles安装证书 点击charles中的help­>SSL Proxying­>install charles Root certificate 安装时注意 选择将所有证书存储到第三方根证书颁发机构 最后点击证书路径 看证书状态 显示改证书没有问题即可4.手机端配置网络代理 需要和电脑端在同一个局域网win+R 输入cmd 输入ipconfig查看ip地址点击Proxy -》Proxy Settings查看端口号 5.苹果手机 在safari浏览器中输入： http://chls.pro/ssl　安卓手机 在自带的浏览器中输入 http://chls.pro/ssl　会自动提示下载 安装证书后 有弹窗选择Allow6.如果浏览器输入http://chls.pro/ssl 没有网络 需要在pc端设置下网络防火墙允许charles应用通过7.此时抓包charles会显示unknown 需要配置抓取https请求 点击Proxy -> SSL Proxying Settings Host输入框输入* Port输入框输入*8.以上就配置好了 如果不行请重启charles51.如何实现jenkins实现自动自动化打包发布和启动？1.下载jenkins安装包并安装本例使用jenkins-2.86的windows版本2.安装常用插件如PUBLISH OVER SSH、Subversion Plug-in、Credentials Binding Plugin、Maven Integration plugin3.配置svn账号，用于拉取源码4.配置maven、JDK5.配置SSH服务器6.构建一个maven工程7.构建完成后把war包发布到远程tomcat，并执行脚本重启tomcat8.需要修改脚本为可执行脚本，否则jenkins权限不够执行shell脚本9.jenkins控制台乱码

52.请写出冒泡排序
public static int[] buddleSort(int[] arr){
for(int i=1;i<arr.length;i++){
for(int j=0; j<arr.length-i; j++){
if(arr[j] < arr[j+1]){
int temp = arr[j];
arr[j] = arr[j+1];
arr[j+1] = temp;
}
}
}
return arr;
}

53.数据库的中的左连接右连接和全连接内连接的区别？
1、内联接（典型的联接运算，使用像 = 或 <> 之类的比较运算符）。包括相等联接和自然联接。内联接使用比较运算符根据每个表共有的列的值匹配两个表中的行。例如，检索 students和courses表中学生标识号相同的所有行。
2、外联接。外联接可以是左向外联接、右向外联接或完整外部联接。在 FROM子句中指定外联接时，可以由下列几组关键字中的一组指定：
1）LEFT JOIN或LEFT OUTER JOIN左向外联接的结果集包括 LEFT OUTER子句中指定的左表的所有行，而不仅仅是联接列所匹配的行。如果左表的某行在右表中没有匹配行，则在相关联的结果集行中右表的所有选择列表列均为空值。
2）RIGHT JOIN 或 RIGHT OUTER JOIN右向外联接是左向外联接的反向联接。将返回右表的所有行。如果右表的某行在左表中没有匹配行，则将为左表返回空值。
3）FULL JOIN 或 FULL OUTER JOIN完整外部联接返回左表和右表中的所有行。当某行在另一个表中没有匹配行时，则另一个表的选择列表列包含空值。如果表之间有匹配行，则整个结果集行包含基表的数据值。

54.测试结束的标准是什么？
单元测试退出标准

1. 单元测试用例设计已经通过评审
2. 核心代码100％ 经过Code Review
3. 单元测试功能覆盖率达到100％
4. 单元测试代码行覆盖率不低于80％
5. 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
6. 不存在A、B类缺陷
7. C、D、E类缺陷允许存在
8. 按照单元测试用例完成了所有规定单元的测试
9. 软件单元功能与设计一致集成测试退出标准1) 集成测试用例设计已经通过评审2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试4) 达到了测试计划中关于集成测试所规定的覆盖率的要求5) 集成工作版本满足设计定义的各项功能、性能要求6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准7) A、B类BUG不能存在8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％。9) E类BUG允许存在系统测试退出标准1) 系统测试用例设计已经通过评审2) 按照系统测试计划完成了系统测试3) 系统测试的功能覆盖率达100％4) 系统的功能和性能满足产品需求规格说明书的要求5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准6) 系统测试后不存在A、B、C类缺陷7) D类缺陷允许存在，不超过总缺陷的5％8) E类缺陷允许存在，不超过总缺陷的10％

本文标签：