1.web端和app端测试的相同点和不同点的是

基础行业的web测试，和手机app测试又有什么的相同点与不同之处呢？

1、相同点
不管是传统行业的web测试，还是新兴的手机app测试，都离不开测试的基础知识，即是不管怎么变，测试的原理依然会融入在这两者当中。
1）设计测试用例时，依然都是依据边界值分析法、等价类划分等；
2）多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用；
3）需要检查界面的布局、风格和按钮等是否简洁美观、是否统一等；
4）测试页面载入和翻页的速度、登录时长、内存是否溢出等；
5）测试应用系统的稳定性等。

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

2）手机用户对app产品的安装卸载操作：从上一个版本/上两个版本直接升级到最新版本。
全新安装新版本
新版本覆盖旧版本安装
卸载旧版本，安装新版本
卸载新版本，安装新版本
3）web自动化测试使用的工具较常用的是QTP，而android手机自动化测试工具比较常用的是monkey、monkeyrunner。
web测试与终端app测试本质上没有什么区别，性质都一样！但是实际的测试工作中要考虑的因素有很大的差异性。
web更多的是考虑自身功能的实现与浏览器的兼用；
终端App除了要考虑自身功能实现与否外，还得考虑很多外在因素；如：wifi网络、个硬件按键、不同分辨率设备适配、兼容性、来电、没电等因素。 web测试和app测试大部分都是手工测试为主；偶尔也会使用自动化测试工具进行简单的测试工作

2.Ios和android测试的侧重 点是？

1、Android多分辨率测试，20多种，IOS较少。
2、Android手机操作系统较多，IOS较少且不能降级，只能单向升级；新的IOS系统中的资源库不能完全兼容低版本中的IOS系统的应用，低版本IOS系统中的应用调用新的资源库，会直接导致闪退。
3、Android操作习惯，Back键是否被重写，应用数据从内存移动到SD卡能否正常运行。
4、安装卸载测试：Android的下载和安装平台较多，IOS主要是AppStore，iTunes，TestFlight。
5、Push测试：Android点击home键，程序后台运行，此时点击Push消息，唤醒后台应用；iOS点击home键关闭程序和屏幕锁屏的情况。
6、单条item的操作：Android中分为点击和长按，点击一般进入一个新的页面，长按进入编辑模式。IOS中分为点击和滑动，点击一般进入一个新的页面，滑动会出现对item的常用操作。
7、悬浮窗：Android中可以有各种悬浮窗，IOS并不支持。

3.如何测试一个app的登录场景？

1、页面基本元素的操作。
2、大量字符，特殊字符，边界值，必填项校验。
3、注册手机号的特殊性验证，注册邮箱的格式验证。
4、密码大小写是否敏感，密码是否加密展示，密码是否有可见按钮功能，密码框能否使用复制粘贴。
5、验证码校验：必填项，过期，错误，无网络时获取验证码，多次获取，超过获取次数，输入验证码后，修改手机号。
6、登陆时与系统的交互：锁屏，蓝牙，home，后退，横竖屏，修改字体字号。
7、逆向思维：已注册账号注册，未注册账号忘记密码，未注册账号登陆，注册过程中退出再次注册。
8、输入法交互，切换输入法，切换输入输入模式，手写/九宫格。
9、登陆账号的多样性：多个账号轮流登陆，同一个账号多角色登陆。
10、第三方登录验证：账号授权，信息正确，取消授权。
11、登陆页面跳转，返回，登陆成功及其他页面跳转。
12、手机兼容性测试：分辨率兼容，系统兼容，系统版本兼容，App版本兼容。
13、网络切换，网络断开，弱网。

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

检查 Push 消息是否按照指定的业务规则发送；
检查不接收推送消息时，用户不会再接收到 Push 消息；
如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到 Push。在非免打扰时间段内，用户能正常收到 Push；
当 Push 消息是针对登录用户的时候，需要检查收到的 Push 与用户身份是否相符，没有错误的将其他人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送；
测试 Push 时，在开关机、待机状态下执行推送，消息及其推送跳转的正确性；
push 消息时，会有红点展示，推送消息阅读前后数字的变化是否正确；
应用在开发、未打开状态、应用启动且在后台运行的情况下是 push 显示和跳转否正确；
多条推送的合集的显示和跳转是否正确。

5.App的闪退通常是什么原因造成的？

缓存垃圾太多，Android 系统的特性，如果长时间不清理垃圾文件，会导致越来越卡，甚至闪退；
运行程序太多，导致内存不足；
应用版本兼容问题，分辨率兼容问题；
APP中访问网络的地方，组件能否正常下载并显示；
APP的 SDK 与手机系统不兼容；
系统升级后，新版本不兼容老版本的 API，返回对象失败，报空指针；
软件权限未开放。

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

HTTP接口
通过http协议传输的接口，可以传输文本表单数据，也可以传输json类型的对象数据或XML类型的数据
RPC
RPC：远程方法调用，随着分布式系统的出现，当你需要调用部署到其他服务器上的方法时，需要用到RPC。RPC只是提出了这样一个问题，有很多种解决方案，比如webservice(基于SOAP协议)，REST(基于HTTP协议)
web service
基于SOAP协议的一种RPC实现方案。相比传统的HTTP接口只传输文本请求和文本响应，通过web service可以直接拿到远程的一个对象，并能够直接调用该对象的属性和方法，比HTTP更高级
REST/RESTful API
REST，表述性状态转移。一种http接口的设计风格，将一切接口视为资源，要求接口路径统一管理，分版本管理，规定了GET/POST等请求以及HTTP状态码的使用规范，默认使用JSON格式传输。RESTful API即满足REST风格即设计规范的API接口

7.常见的接口请求方式是什么？

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

8.常见的状态码是什么以及都有什么意思请解释说明?

1.200：请求成功，浏览器会把响应体内容（通常是html）显示在浏览器中；
2.404：(客户端问题)请求的资源没有找到，说明客户端错误的请求了不存在的资源；
3.500：(服务端问题)请求资源找到了，但服务器内部发生了不可预期的错误；
4.301/302/303：(网站搬家了，跳转)重定向
5.304: Not Modified,代表上次的文档已经被缓存了,还可以继续使用。如果你不想使用本地缓存可以用Ctrl+F5 强制刷新页面

9.接口测试的原理是什么?

1.接口测试的原理主要是模拟客户端向服务端发送请求，服务器接收请求后进行相应的业务处理，并向客户端返回响应数据，检查响应数据是否符合预期。

10.后台接口测试了一遍前端也测试一遍是不是重复测试?

1.从后端角度出发：后端测试自己开发的接口，更多在于单测层面，好的开发会从接口业务调用场景出发，覆盖一些功能case，但是开发测试自己的代码，他往往觉得自己的代码已经很完美了，所以开发测试自己的代码往往是覆盖不全面的。
2.从前端角度出发：前端开发要和后端联调，所以前端的关注点是你接口返回给我的数据结构是不是严格按照技术方案上契约来设计的，你让我传给接口的参数是不是按照契约约定的，，所以前端开发不太关注接口逻辑对不对，只关心我只要入参给的对，返回的数据结构对就行了。
3.从测试角度出发：测试是保证质量最重要的一环，接口测试我们不仅仅只考虑功能层面用例，还要从非功能层面出发，比如接口性能，稳定性，安全性。我们还要结合业务场景，去思考一些反向的异常case，和其他服务相互调用过程的异常场景怎么兜底，依赖服务响应超时怎么兜底，系统异常怎么兜底等。

11.接口测试的流程/步骤(你的接口测试怎么做的)？

1.需求分析和设计评审
2.测试框架和技术选型
3.测试计划制定
4.测试环境搭建
5.测试用例设计和评审
6.测试实现和执行
7.持续集成

12.get/post的区别？

1.get是获取数据的，而post是提交数据的
2.GET 用于获取信息，是无副作用的，是幂等的，且可缓存， 而POST 用于修改服务器上的数据，有副作用，非幂等，不可缓存。

13.如何编写接口测试用例？

1.用例编号
2.所属模块
3.用例标题
4.优先级
5.前置条件
6.操作步骤
7.请求方法
8.参数名
9.参数类型
10测试数据
11.预期结果
12.实际结果
13.通过否
14.bugid
15.编写人员
16.编写时间
17.测试人员
18.测试时间
19.备注

14.性能测试都包含了哪些？（负载测试 压力测试 容量测试）

1.压力测试
2.负载测试
3.容量测试

15.什么时候执行性能测试？

1.一般在系统功能稳定没有大的缺陷之后开始执行。但前期准备工作可以从系统需求分析时就开始：性能目标制定、场景获取、环境申请等。

16.你是如何做测试分析？

1.根据需求规格提取独立的功能点，确定测试范围
2.对独立功能进行分析，确定各独立功能的测试点
3.对业务场景即功能组合进行分析，提供业务场景的测试点
4.对非功能特性进行分析，了解需要测试的非功能特性
5.针对系统级接口进行分析，了解被测试对象、测试规格。分析可测性，确定测试方法、工具。

17.性能测试的步骤/流程？

1.测试准备
2.搭建环境
3.测试脚本开发
4.测试数据准备
5.测试执行
6.结果分析与调优
7.测试后续跟踪

18.你如何识别性能测试的瓶颈？

1.查看系统日志，如果日志记录的全面，很容易通过日志发现问题。比如，系统宕机时，系统日志打印了某方法执行是抛出out of memory的错误，很快定位到导致内存溢出的问题在哪里。
2.利用性能监控工具，比如：linux系统环境下通过nmon来监控系统性能。
3.设计合理的性能测试场景，好的测试场景能更加快速的发现瓶颈。
4.了解系统参数配置，可以进行后期的性能调优

19.请解释下 常用的性能测试指标的含义?

1.TPS
TPS的含义是每秒事务数。
2.并发
多个线程模拟多个虚拟用户(virtual user)
3.RT
response time；90%用户的响应时间，就是这个意思，比如一个小时内90%的响应时间为500ms，表示是这个小时内所有请求该页面的响应时间中，有90%的请求响应时间小于或等于500ms
4.吞吐量

20. 响应时间 并发用户数 吞吐量 性能计数器 TPS HPS QPS?

响应时间(RT)
　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
　　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

并发用户数
　　并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

QPS每秒查询率(Query Per Second)
　　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）
　　1、TPS：Trasaction per second也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分，测试软件就是利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分。一般来说系统的TPS取决于系统事务最低处理能力的模块的TPS，经验值10-100
2、HPS:Hit per second也就是点击数/秒，指的是一秒钟的时间内用户对WEB页面的链接、提交按钮等点击的总和。一般与TPS成正比关系，是衡量B/S系统的一个主要指标

21.针对性能测试 负载测试 压力测试在你项目中的使用？

22.如何判断一个bug是前端bug还是后台bug?

通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口，传参，响应。
1.请求接口url是否正确
2.传参是否正确
3.请求接口url和传参都正确，查看响应是否正确
4.也可以在浏览器控制台输入js代码调试进行分析

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

1.数字类型
int（整型）、long（长整型）、float（浮点型）
2.字符串
3.布尔型
4.列表
5.元组
6.字典
7.集合

24.你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解?

首先，将问题提交到缺陷管理库里面进行备案。
然后，要获取判断的依据和标准：
• 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
• 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
• 根据用户的一般使用习惯，来确认是否是缺陷；
• 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

25.给你一个网站，你如何测试?给你一个app程序你要怎么做？

网站测试分以下几方面内容:
性能测试
（1）连接速度测试：用户连接到电子商务网的速度与上网方式有关，他们或许是电话拨号，或是宽带上网，打开速度越快的网站，越受用户喜爱。
（2）负载测试：负载测试是在某一负载级别下，检测电子商务系统的实际性能。允许多少个用户同时在线，可以通过相应的软件在一台客户机上模拟多个用户来测试负载。
（3）压力测试：压力测试是测试系统的限制和故障恢复能力，也就是测试电子商务系统会不会崩溃。
安全性测试
对网站的安全性（服务器安全，脚本安全）可能有的漏洞测试，攻击性测试，错误性测试。对电子商务的客户服务器应用程序、数据、服务器、网络、防火墙等进行测试。用相对应的软件进行测试。
基本测试
包括色彩的搭配，连接的正确性，导航的方便和正确，CSS应用的统一性。
网站优化测试
（1）引擎优化测试：好的网站是看它是否经过搜索引擎优化了，网站的架构、网页的栏目与静态情况等。
（2）用户优化测试：用户来到网站能能够在3-5次，找到其需要的内容。方便用户的网站倍受用户的亲昵。
功能实现：网站现有版本，需求是否完全实现。满足需求的网站才是有用的网站。

app测试
(1) 功能测试
每项开发的新功能都需要进行测试。app测试中功能测试是一个重要方面。测试人员应该要进行手动测试和后期的自动化测试维护。刚开始测试时，测试员必须把app当做"黑盒"一样进行手动测试，看看提供的功能是否正确并如设计的一样正常运作。除了经典软件测试，像点击按钮、提交订单看看会发生什么，测试员还必须执行更多功能的app测试。
除了整个手动测试过程，测试自动化对移动app也很重要。每个代码变化或新功能都可能影响现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化回归测试。现在市面上有很多自动化测试工具，有商业的也有开源的，面向各个不同平台，如Android，iPhone，WindowsPhone7，BlackBerry以及移动Webapp。根据开发策略和结构，品质管理测试专家需找出最适合他们环境的自动化工具。
(2) 客户端性能测试
一个App做的好不好，不仅仅只反应在功能上。被测的app在中低端机上的性能表现也很重要。比如：一个很好玩的游戏或应用，只能在高端机上流畅运行，在中低端机上卡的不行，也不会取得好的口碑。
关于App的性能测试，我们比较关注的参数有：CPU，内存，耗电量，流量，FPS。同时也需关注一下App的安装耗时和启动耗时。
(3) 适配兼容测试
App在经过功能测试后，也需对其进行适配兼容测试需要检查的项主要有以下几点：
(a) 在不同平牌的机型上的安装、拉起、点击和卸载是否正常；
(b) 在不同的操作系统上的安装、拉起、点击和卸载是否正常；
我们在实际测试中，常常会遇到下列问题：
(a) 在某个品牌某个系统上，app安装不上；
(b) 在某个品牌某个系统上，app无法拉起；
© 在某个品牌某个系统上，app拉起后无响应或拉起后黑屏、花屏；
(d) 在某个品牌某个系统上，app无法顺利卸载；
(4) 安全测试
App在上线前，都需要做详细的安全测试。安全测试主要为了检测应用是否容易被外界破解；是否存在被恶意代码注入的风险；上线后外挂的风险高不高等。
(5) 服务器性能测试
服务器性能测试，主要包含单机容量测试和24小时稳定性测试。单机容量测试，可以检测到单机服务器在90%的响应时间和成功率都达标的前提下，能够承载多少用户量。使用特定游戏模型压测24小时，服务无重启，内存无泄漏，并且各事务成功率达标。

26.什么是测试用例？什么是测试脚本？两者关系？

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

27.简述：静态测试、动态测试、黑盒测试、白盒测试、α测试 、β测试分别是什么？

1.静态测试（ui界面 业务逻辑 ）是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。
2.动态测试（链接数据之后 ）是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。
3.黑盒测试 ：纯功能测试
4.白盒测试 ：使用编程脚本进行测试 实现自动化
5.α测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
6.β测试：是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

28.在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

一条Bug记录最基本应包含：
bug编号；
bug严重级别，优先级；
bug产生的模块；
首先要有bug摘要，阐述bug大体的内容；
bug对应的版本；
bug详细现象描述，包括一些截图、录像…等等；
bug出现时的测试环境，产生的条件即对应操作步骤；
高质量的Bug记录：

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

29.在你的项目中详细的描述一个测试活动完整的过程？

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

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

1.依据代码review的结果和影响范围，对测试内容进行适当的裁剪。
2.借助自动化工具的支持，提高测试案例的执行效率。
3.调整组内任务的优先级，进行人力协调，优先投入最紧要的项目。
4.必要的情况下加班

31.描述下你团队的测试分工？

一个测试经理，3个测试组长，每个组有5个测试人员：包括自动化测试、，功能测试、性能测试等的测试工程师。
我们往往都是根据接到的项目来组成测试团队。当然人手不够的时候，可以请几位开发人员参与到测试工作中。

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

移动端
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、 1600X9000

4.网速测试
项目在不同的网络环境中是否正常的运行，通过Charles、Fiddler等工具进行弱网测试。

33.请讲诉移动应用的灰度是怎么做的？

1.内部二维码下载
2.白名单用户方式
3.国内小市场先上，国外用 Google Play的 β版，默认开放5%
4.后台控制的方式，开放给一定比例的用户

34.请简述移动应用在升级安装时候应该考虑的场景？

35.如果让你来测试扫码支付，你会考虑哪些场景？

大概的思路：金额（对、错、空等），支付流程，使用设备，绕过前端直接调取接口支付，支付失败处理：补单、退款等，网络导致的失败等待，在设计测试用例尽量落实在每一个数据核对
财务人员有句老话叫：财务无小事。因为，首先，任何涉及到财务的问题，不论金额有多么的小，它在性质上也是严重事件；其次，在各种金融支付功能已深入老百姓生活的方方面面的今天，一个程序中，哪怕仅有一个小小的支付问题，那么，最后引起的也可能是涉及成百上千乃至上亿元金额和大量用户的大问题。
因此，专业的测试人员，在对待带有支付功能的产品时，都会格外的小心谨慎，将边界值分析、等价类划分、错误推测、因果图等各种测试方法进行结合，整理出尽可能全面的测试案例，对该支付功能及其相关功能进行测试，以确保整个支付流程以及涉及到支付流程的其他流程在任何情况下都能正常进行。
简单总结一下测试的思路：
从金额上：包括正常金额的支付，最小值的支付，最大值的支付，错误金额的输入（包括超限的金额、格式错误的金额、不允许使用的货币等等）；
从流程上：包括正常完成支付的流程，支付中断后继续支付的流程，支付中断后结束支付的流程，支付中断结束支付后再次支付的流程，单订单支付的流程，多订单合并支付的流程等等；
从使用的设备上：包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
从支付接口上：包括POSE终端机支付、银行卡网银支付、支付宝支付、微信支付、手机支付等；
从产品容错性上：包括支付失败后如何补单或者退单、如何退款等；
从后台的账务处理上：成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。
还有其他需要考虑的问题这里就不再赘述了，总之，在测试过程中，测试人员要将以上各种情况都综合考虑到，根据这些情况来编写最少量但尽可能发现最多问题的测试案例，并且严格按照案例来执行测试，只有经过最严谨的测试的支付功能，才能够尽可能的避免上线后出现生产问题。

36.请描述下微信朋友圈发小视频的用例设计？

对于一个待测试的对象，我们通常通过以下几个方面来进行测试：功能测试、可靠性测试、易用性测试、效率、可维护性、可移植性、安全性测试、界面测试等。

本文将其分成两个方面来看：
（1）站在测试人员的技术测试角度（功能测试、可靠性测试、兼容性、可维护性、效率、可移植性、安全性测试、可维护性）

（2）站在用户的角度（功能测试、易用性测试）

站在测试人员的技术测试角度：
1.功能测试

功能测试是软件测试中最基本的测试，功能实现不满足要求，软件就不能发布测试。要进行功能测试，首先就需要了解朋友圈的各个功能，那么如何了解朋友圈的功能呢？——需求文档。因为所有的开发设计、测试设计等，都是以需求文档来进行的。需求文档中规定了必须有哪些功能，那么我们在测试的时候就可以对比知道哪些功能实现了，还有哪些功能未实现（需要说明的是：开发计划明确说明当前版本暂不实现的功能，不能算作bug）。

相信玩过微信朋友圈的人都能知道微信朋友圈大概有以下基础功能：
1）发朋友圈、删除朋友圈，看朋友圈；
2）朋友圈的类型（图、文、混合）；
3）评论朋友圈；
4）朋友圈的对外接口（例如，王者荣耀，把战绩分享至朋友圈等）；
5）屏蔽与被屏蔽，不能查看对应好友的朋友圈；
我们做基础功能测试，就需要对朋友圈具有的所有功能进行测试。
发朋友圈：我们可以通过短按或者常按朋友圈中的照相机图标，分别发起图片版或文字版的朋友圈操作，在此过程中，我们需要关注进行发起操作的响应时间是否符合需求。然后就需要对发朋友圈进行全面的测试了，其中包括，正常发朋友圈，取消发朋友圈，多次发朋友圈等。如果需求中对朋友圈的内容有限定，例如不允许出现敏感字眼等。

2.可靠性测试

先来说一下软件可靠性的概念：软件可靠性（software reliability）是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。

规定的条件是直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件，或统称为软件运行时的外部输入条件；

规定的时间是指软件的实际运行时间区间；
规定的功能是指提供给定的服务，软件产品所必须具备的功能。
软件可靠性不但与软件存在的缺陷（或）差错有关，而且与系统输入和系统使用有关。软件可靠性的概率度量程为软件可靠度。
这里举几个朋友圈的可靠性例子：
1）短时间内频繁进行发送、取消、以及删除朋友圈的组合测试，看朋友圈相关功能是否正常；
2）微信打开后，手机锁屏或切换到主界面，微信在后台是否会失效出现bug，并且朋友圈的功能是否会失效。

3.性能测试

性能测试主要对服务器的性能进行测试的。在App上，性能测试分为客户端性能、服务器性能。
对客户端性能我们主要关注的指标有：CPU占用率、内存占用率、流量耗用量等。举个例子，如果发起朋友圈操作之前，手机的CPU使用率为30%，发起操作之后，忽然涨到了80%，不关闭朋友圈的相关操作，CPU使用率降不下来，那么对于整个朋友圈的性能问题就得需要我们去好好找原因了。
对提供朋友圈服务的服务器进行性能测试时，我们需要进行压力测试、负载测试、稳定性测试。常用的工具就是Loadrunner了，主要关注的指标有：CPU、内存、响应时间等。

4.其他测试

例如：
1）在弱信号的情况，进行发朋友圈、看朋友圈等操作，测试其是否会产生其它未知故障。（例如对WiFi信号进行限速）
2）在不同的客户端的兼容性测试，使用不同平台的客户端进行朋友圈的功能测试。（例如使用不同厂商的手机、平板）
3）安全性测试（例如在朋友圈儿中输入一些脚本程序代码什么的，测试是否会将微信客户端搞崩溃什么的。

站在用户的角度
站来用户角度来说，易用性是其评价软件好坏最主要的一点，功能操作是否简单明了，给出的提示是否清楚明白无二意，还有就是界面布局否美观合理。
除此之外，我们还要模拟不同的用户场景下的使用。把自己想象为不同的用户（小白用户，资深用户），因为不同的用户有不同的使用习惯，这也类似于发散测试，因人而异。

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

一个客户端，三百个用户
只有一个客户端，三百个用户肯定不能同时进行操作，假设每次一人操作客户端对服务器施压，服务器承受的压力小但持续时间长
三百个客户端，三百个用户
假设三百个客户端同时进行操作对服务器施压，就要求服务器带宽能够承受三百人同时在线操作，且服务器短时间内承受压力大但持续时间短

38.您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

1、要耐心和细心
细心是测试工程师的一个基本素质，测试工程师是对质量负责的人，涉及到质量问题，就不能含糊，因此一定要细心，细心对待每一个可能的BUG、细心对待每一 段 被你检查的代码，细心对待每一个你撰写的BUG报告，细心对待你发出的每一封邮件。细心是一种态度，你的态度迟早会感染和你合作的开发人员，而这往往是合作愉快的基础。
至于说到耐心，在我的工作经历中，不厌其烦地向开发人员解释一个BUG，让他认识到BUG的重要性是经常的事情，其实想想也很正常，对任何人来说，被人指 出自己的缺点和不足都不是让人舒服的事情，因此，一点不耐烦的情绪就可能引起对方很大的反感，给自己的工作带来不必要的麻烦。

2、要懂得尊重对方
开发是一件需要全面和综合考虑的工作，开发工作中，由于各种原因导致程序中出现问题是很正常的现象，作为测试工程师，发现了这些问题并不值得你夸耀，也不能 说明你比开发工程师聪明。一个好的测试工程师一定是懂得尊重开发工程师的人，尊重对方的技术水平，尊重对方的代码。我接触过的开发人员都是挺和善的，一般 来说，对他们最大的尊重就是承认他的专业水平，承认他的代码。对他们来说，代码就像是自己的孩子一样：）因此，记得在合适的时候表达你对他的尊重，赞扬一下他代码的精妙之处。

3、要能设身处地为对方着想
开发工程师一般都处在较大的工作压力下，他的上司直接考核他们的指标很大程度上是已完成的代码，所以在工作任务紧张的时候，对于测试工程师报上来的BUG 会 拖延解决甚至是推脱，给测试工程师的感觉就是很不合作。那么在这个时候，就需要设身处地的为对方着想了，每个人都会为自己的工作在内心排定优先级，如果他认为解决你发现的BUG不是重要的事情，那么最大的可能就是你并没有向他解释清楚这个BUG的严重程度。
发现BUG是我们的责任，敦促BUG得到解决是我们更重要的责任，因此，我们可以心平气和地和开发人员坐下来讨论一下BUG的严重程度，和他一起排定BUG的优先级别并确定解决的时间。

4、要有原则
不要忘记，测试工程师需要对产品的质量负责，在这一点上一定要有原则。测试工程师可以和开发工程师建立良好的个人关系，但在具体的事情上，一定要按照公司的 相关流程来处理。当然，在坚持原则的同时，可以采用一些委婉的表达方式，可以在允许的情况下尽量体谅开发工程师，但请记住，一个有原则的测试工程师才能真 正帮助开发工程师，才能赢得开发工程师的尊重。

5、要主动承担
如果开发工程师要求你承担部分不属于你的责任，比如，定位你发现的BUG到代码一级，或者是帮助他编写部分文档和代码（不要不相信，真的有这样的事情），那 么你会怎么做呢？在我的测试经历中，这些事情都遇到过，我的原则是在可能的情况下尽量多承担。其实都是工作上的事情，有能力的话，多做一点也无妨。当然， 肯定有人不同意我的意见，在这里我也不想争辩，个人意见而已，仅供参考：）
在我的测试经历中，我会根据自己的进度和时间安排尽可能地提供更多的关于BUG的参考意见，甚至是定位到代码一级，这种方式不是正规的方式，但对于提高自己被信任的程度是非常有益的。但在主动承担时，一定要明确是在自己确有余力的情况下才能去承担，否则，婉拒是最好的对策。

【五不要】

1、不要嘲笑
不要嘲笑你所发现的BUG，即使是非常愚蠢的错误也绝对不要嘲笑，说不定那个错误是因为开发工程师联系加班24小时犯下的，对别人的工作始终应该尊重。如 果 你觉得有必要提醒他不再犯一些经常犯的错误，可以采用这样的方式：编写一份测试过程中发现的开发人员常犯错误的文档（记住，千万不要写上谁犯了这些错误），用轻松的口气调侃一下，发送给开发人员。这种方法我采用过，开发人员都能很快接受。

2、不要在背后评论开发工程师
永远不要在背后评论开发工程师的技术能力，这个绝对是非常忌讳的事情，一时的口舌之快或许会使你永远不再能同他良好地合作，要知道，开发工程师最在意地就是别人对他的技术能力的评价。其实这个不仅仅是作为测试工程师的准则，也应该是做人的准则。

3、不要动辄用上层来压制对方
在出现和对方的意见分歧的时候，应该采用什么方式说服对方呢？直接向上层求助当然是一个办法，但这种办法带来的负面左右也是很明显的，首先是作为上层的处理 结果可能不一定符合你的愿望（在很多公司，开发工程师的地位高于测试工程师的地位，这种地位的不平等导致上层在处理分歧时会有一定的偏向性）；其次是动辄 拿出上层来压制对方只能给他人留下无用的印象。所以在出现分歧时，尽量尝试通过沟通解决吧，实在不行，再动用最后的手段。

4、和开发人员的沟通不要只有BUG
除了在BUG记录单上，在其他的地方也让和你合作的开发工程师接触到你吧：），午餐或是集体活动的时候多和对方聊聊天，一方面可以增进彼此的感情，混个脸熟，打交道的时候也方便；另一方面，从他那里了解业务的知识和他负责模块的方方面面，对自己也是提升。我个人就很喜欢和开发工程师沟通，开发工程师其实一 般都是比较健谈的，尤其是对自己程序的精妙之处，多了解一些，多接触一些，对自己总是有益的。

5、不要对开发人员的技能进行主观比较
有时候某开发人员迟迟难以解决某深度bug，测试人员为了推动bug的修复，也许会建议他找其他更牛的开发人员来帮助解决这个bug。这是对开发人员最大的鄙视，对方即便不与你翻脸，也会非常得懊恼，不良的情绪会让其代码质量更差，解决问题的方法需要自己去寻找。
没有人天生是牛人，也没有人从不出错，开发人员更需要你的肯定与鼓励。

写了这么多，其实关键的就是两点：多从别人的角度去想想，所谓"换位思考"，多尊重对方就一定能得到对方的尊重与配合；其次是加强和开发工程师的沟通，让他清楚地认识到你的工作对他的价值，你发现的每一个BUG的重要性。
我一直认为，一个好的测试工程师一定是在公司里被所有人尊重的快乐分子，而不应该是一个"铁面判官"：）当然，作为我个人来说，绝对不敢说自己做的已经很好了，不过，我经常都记得提醒自己：尊重对方。

39.简述你在以前的工作中做过哪些事情，比较熟悉什么？

我过去的主要工作是系统测试和自动化测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。

在测试中，我感觉对用户需求的完全准确的理解非常重要。另外，就是对BUG的管理，要以需求为依据，并不是所有BUG均需要修改。

测试工作需要耐心和细致，因为在新版本中，虽然多数原来发现的BUG得到了修复，但原来正确的功能也可能变得不正确。因此要注重迭代测试和回归测试。

40.请说出这些测试最好由那些人员完成，测试的是什么？

代码、函数级测试一般由白盒测试人员完成，他们针对每段代码或函数进行正确性检验，检查其是否正确的实现了规定的功能。

模块、组件级测试主要依据是程序结构设计测试模块间的集成和调用关系，一般由测试人员完成。

系统测试在于模块测试与单元测试的基础上进行测试。了解系统功能与性能，根据测试用例进行全面的测试

41.在windows下保存一个文本文件时会弹出保存对话框，如果为文件名建立测试用例，等价类应该怎样划分？

单字节，如A;双字节， AA、我我;特殊字符 /‘。‘;、=-等;保留字，如com;文件格式为8.3格式的;文件名格式为非8.3格式的;/,*等九个特殊字符。

42.假设有一个文本框要求输入10个字符的邮政编码，对于该文本框应该怎样划分等价类？

特殊字符，如10个*或￥;英文字母，如ABCDefghik;小于十个字符，如123;大于十个字符，如11111111111;数字和其他混合，如123AAAAAAA;空字符;保留字符

43.您以往的工作中是否曾开展过测试用例的评审工作?如果有，请描述测试用例评审的过程和评审的内容。？

44.在你测试的过程中如果发生时间上不允许进行全部测试，你应该怎么做？

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

45.列举web自动化中常见的元素定位方式是？

通过class属性定位
通过id属性定位
通过name属性定位
通过link属性定位
通过partialLink定位
通过标签tagname定位
通过css定位
通过xapth定位

46.简述你知道的延时等待的方式?

sleep()： 强制等待，设置固定休眠时间。后脚本的执行过程中执行 sleep()后线程休眠，而另外两种线程不休眠。
implicitly_wait()：隐式等待，是设置的全局等待。设置等待时间，是对页面中的所有元素设置加载时间，如果超出了设置时间的则抛出异常。隐式等待可以理解成在规定的时间范围内，浏览器在不停的刷新页面，直到找到相关元素或者时间结束。
WebDriverWait()：显示等待，是针对于某个特定的元素设置的等待时间，在设置时间内，默认每隔一段时间检测一次当前页面某个元素是否存在，如果在规定的时间内找到了元素，则直接执行，即找到元素就执行相关操作，如果超过设置时间检测不到则抛出异常。默认检测频率为0.5s，默认抛出异常为：NoSuchElementException。

47.自动化测试用例的覆盖率多少？

40％左右

48.完整运行一次自动化用例需要多久时间？

主要跑的是业务流，所以跑一次需要半个小时左右

49.什么是分层自动化？

金字塔结构， 最底层UnitTest，往上接口API/集成起来的service， 最上面UI自动化

50.你的测试数据是怎么准备的？

提前准备好，在代码里的yaml文件

51.请简述Appium和selenium的原理？

selenium：
IDE,俗称集成开发环境（编辑器），client（1.编写脚本，形成操作指令集，并运行时，会启动webdriver。2.webdriver启动后，绑定ip和端口，向发送来的请求的链接创建session（首次）。webdriver提供的http服务，client通过API接口访问webdriver，发送指令，webdriver接到指令后，按照自己封装的原生的浏览器API，对浏览器进行操作。webdriver将操作完成结果返回给客户端）
简化版：
1.IDE,俗称集成开发环境（编辑器），client（1.编写脚本，形成操作指令集，并运行时，会启动webdriver。通过HTTP协议传输给Webdriver
2.webdriver启动后，绑定ip和端口，向发送来的请求的链接创建session（首次）。webdriver提供的依http协议方式提供API接口服务，client通过API接口访问webdriver，发送指令，数据格式是JSON格式。webdriver接到指令后，按照自己封装的原生的浏览器API，对浏览器进行操作。webdriver将操作完成结果依照JSON格式返回给客户端
appium：
Appium是C/S架构的，更像是一个proxy，连接其被测移动平台和测试脚本。
appium是基于 webdriver 协议添加对移动设备自化api扩展而成的。

52. 如果使用monkey发现了一个闪退，请问怎么使用monkey重现它？

53.Charles拦截并修改请求和返回值的步骤以及在你项目中的应用场景？

54.Charles如恶化抓取app端的htpps接口的？

首先charles可以抓包http
https = http+ssl
1 ssl需要指定的手机安装CA证书
2 设置charles配置
安装好即可抓包
步骤：查看CA下载地址，弹出框中粘贴地址到手机的浏览器，此时页面打开直接是一个证书的下载地址

步骤2：CA证书如下所示

步骤3：

配置charles代理中的ssl配置可以抓包所有的地址*

55.如何实现jenkins实现自动自动化打包发布和启动？

一、安装jenkins
二、进入jenkins
三、安装和Git，GitLab插件
四、新建item

56.如何进行jmeter 上下游接口测试？

上下游接口有数据依赖，典型的例子就是下游接口的请求参数的数据，需要从上游接口请求以后的响应报文中获取。换一句话说，就是这么一个场景：我们需要从第一个接口请求的响应报文中，提取一些数据，作为第二个接口请求的参数值，这样，第二个接口的请求才能发送成功。如果没有先发送第一个接口的请求获取数据，第二个接口的请求就会失败。
此时如何处理？接口测试中一般会使用关联的技术来解决这个问题。如果是用Jmeter来做的话，可以使用Jmeter中的后置处理器来实现关联，比如XPath提取器，或者，正则表达式提取器等等

57.你为什么离开上家公司？离职原因（这个会在最后问）

不发工资

58.请写出冒泡排序

def bubbleSort(array):
maxindex = len(array)-1
maxValue = array[maxindex]
k=0
while maxindex:
for i in range(1,maxindex):
if array[i-1]>array[i]:
temp = array[i]
array[i] = array[i-1]
array[i-1] = temp
k+=1
maxindex -=1
print(k)
return array

59.1~9999数列中数字3出现的次数。用递推方法解出。

def count_digit(number):
return len(str(number))
def countThree(digit):
if not isinstance(digit,int):
raise TypeError(‘number is not int’)

digit = len(str(number))

if(digit <=0):
return 0
if(digit ==1):
return 1
return 10*countThree(digit-1) + 10 **(digit-1)
print(countThree(count_digit(9999)))

60.从一个数组中找出前4个最大的数，用最优解。

#快速排序：最快的n*logN
def qiuckSort(list):
if len(list)<2:
return list
mid = list[0]
left = [i for i in list[1:] if i <= mid]
right = [i for i in list[1:] if i > mid]
finallyList = qiuckSort(left)+[mid] + qiuckSort(right)
return finallyList
array = [3, 0, 1, 832,23,45, 5, 5, 6,46, 9, 56, 897]
print(qiuckSort(array)[-4:])

61.写一段程序，删除字符串a中包含的字符串b，举例 输入a = “asdw”,b = “sd” 返回 字符串 “aw”，并且测试这个程序。

def delBString(a,b):
if not isinstance(a,str):
raise TypeError(“a is not str”)
if not isinstance(b,str):
raise TypeError(“b is not str”)
if len(a) < len(b):
raise Exception(‘a length must large to b length’)
result = []
flag = False
i=0
la = len(a)
lb = len(b)
while i <la:
j = 0
while j < lb:
if i+j < la and a[i+j] == b[j]:
j += 1
else :
j += 1
flag = False
break
flag = True
if flag:
i += lb
else:
result.append(a[i])
i += 1
return “”.join(result)

62. 写一个方法把字符串转为数字，比如 str=“1234”，变成 int 1234。并且测试这个程序

def StrToInt(a):
res ,mult,flag = 0,1,1
if not isinstance(a,str):
raise TypeError(“a is not str”)
if a[0] ==’-’ or a[0] == ‘+’:
if a[0] == ‘-’:
flag = -1
a = a[1:]
for i in range(len(a)-1,-1,-1):
if ‘9’ >=a[i] >= ‘0’:
res +=(ord(a[i]) -48) * mult
mult = mult *10
else :
return 0
return res * flag
def test_strToInt2(self):
with pytest.raises(TypeError):
StrToInt(34)

63.数据库的中的左连接右连接和全连接内连接的区别？

比如有两张表 A，B。左连接是把符合条件的所有A表的内容列出来，B表如果没有内容匹配用NULL代替。
右连接是符合条件的所有B表的内容列出来，A表如果没有内容匹配用NULL代替

64.测试结束的标准是什么？

错误强度曲线下降到bai预du定的水平。

数据库：

1.计算每个人的总成绩并排名(要求显示字段：姓名，总成绩)
select name,sum(score) from stuscore group BY name ORDER BY score desc
2.计算每个人的总成绩并排名(要求显示字段: 学号，姓名，总成绩)
select name,sum(score),stid from stuscore group BY name ORDER BY score desc
3.计算每个人单科的最高成绩(要求显示字段: 学号，姓名，课程，最高成绩)
select t1.stid,t1.name,t1.subject,t1.score from stuscore t1,
(select stid,max(score) as maxscore from stuscore group by stid) t2
where t1.stid=t2.stid and t1.score=t2.maxscore
4.计算每个人的平均成绩（要求显示字段: 学号，姓名，平均成绩）
select name,stid,avg(score) from stuscore group BY stid, name
5.列出各门课程成绩最好的学生(要求显示字段: 学号，姓名,科目，成绩)
select t1.stid,t1.name,t1.subject,t1.score from stuscore t1,(
select subject,MAX(score) as maxscore from stuscore group by subject)t2
where t1.subject = t2.subject and t1.score = t2.maxscore
6.列出各门课程成绩最好的两位学生(要求显示字段: 学号，姓名,科目，成绩)
select t1.name,t1.subject,t1.score from stuscore t1 where (select count(1) from stuscore t2 where t1.subject = t2.subject and t2.score >=t2.score)<=2 ORDER BY t1.subject,t1.score desc

select stid,name ,sum(case when subject=‘语文’ then score else 0 end ),
sum(case when subject=‘数学’ then score else 0 end ),
sum(case when subject=‘英语’ then score else 0 end ),
SUM(score),avg(score) from stuscore
group by stid,name order by score

8.列出各门课程的平均成绩（要求显示字段：课程，平均成绩）
select subject,AVG(score)平均成绩 from stuscore
group by subject
9.列出数学成绩的排名（要求显示字段：学号，姓名，成绩，排名）
select stid,name,score,
(select count() from stuscore t1 where subject =‘数学’ and t1.score > t2.score)+1 from stuscore t2
where subject=‘数学’ order by score desc
10.列出数学成绩在2-3名的学生（要求显示字段：学号，姓名,科目，成绩）
select t3. from (
select stid,name,subject,score,
(select count() from stuscore t1 where subject =‘数学’ and t1.score > t2.score)+1 as 名次 from
stuscore t2 where subject=‘数学’) t3
where t3.名次 between 2 and 3 order by t3.score desc
11．求出李四的数学成绩的排名
select stid,name,subject,score,(select count() from stuscore t1 where subject =‘数学’ and t1.score > t2.score)+1 as 名次
from stuscore t2 where subject=‘数学’ and name = ‘李四’ order by score desc

select subject ,sum(case when score between 0 and 59 then 1 else 0 end) as 不及格,
sum(case when score between 60 and 80 then 1 else 0 end) as 良,
sum(case when score between 81 and 100 then 1 else 0 end) as 优秀 from stuscore
group by subject

declare @s varchar(1000)
set @s=’’
select @s =@s+’,’+name+’(’+convert(varchar(10),score)+‘分)’ from stuscore where subject=‘数学’
set @s=stuff(@s,1,1,’’)
print’数学:’+@s