1. web端和app端测试的相同点和不同点的是
原文：https://blog.csdn.net/ningmengban/article/details/75454014
A：相同===>都是采用功能测试
B：不相同====>一个在web测试，一个在APP测试。
A：相同点：
不管是传统行业的web测试，还是新兴的手机app测试，都离不开测试的基础知识：
1）同样的设计测试用例方法：边界值分析法、等价类划分、错误推测法、场景法等
2）同样的测试方法：黑盒测试，验证业务功能是否正确符合用户或者设计预期；
3）都要检查UI：界面的布局、风格和按钮等是否简洁美观、是否统一等；
4）页面性能检测：测试页面载入和翻页的速度、登录时长、内存是否溢出等；
5）应用的稳定性：测试应用系统的稳定性等，不会闪退卡死等。
B：不同点
相对于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多分辨率测试，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的登录场景？
功能测试 (Function test)
输入正确的用户名和密码，点击提交按钮，验证是否能正确登录
输入错误的用户名或者密码, 验证登录会失败，是否有相应的错误提示信息
登录成功后是否跳转到正确的页面
用户名和密码，如果太短或者太长，应该怎么处理
用户名和密码，中有特殊字符，和其他非英文的情况
记住用户名和密码的功能
登陆失败后，不能记录密码的功能
用户名和密码输入时前后有空格的处理
密码是否可见，是否用星号标识
界面测试 (UI Test)
布局是否合理，2个 Testbox 和一个按钮是否对齐
Testbox和按钮的长度、高度是否复合要求
界面是否美观
图片，颜色，字体，超链接，是否都显示正确
性能测试 (performance test)
打开登录页面，需要几秒
输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒
能支持多少个用户同时登陆
安全性测试 (Security test)
登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
用户名和密码是否通过加密的方式，发送给Web服务器
用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证
用户名和密码的输入框，应该屏蔽SQL 注入攻击
用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）
错误登陆的次数限制（防止暴力破解）
可用性测试 (Usability Test)
是否可以全用键盘操作，是否有快捷键
输入用户名，密码后按回车，是否可以登陆
兼容性测试（Compatibility Test）
主流的浏览器下能否显示正常（IE/Edge, Firefox, Chrome, Safari 等）
不同的平台是否能正常工作，比如Windows, Mac
移动设备上是否正常工作，比如iPhone, Andriod
不同的分辨率
不同的浏览器大小（浏览器最大化， 和非最大化）
软件辅助性测试 （Accessibility test）
软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
比如高对比度下能否显示正常 （视力不好的人使用）
4. Push消息测试如何测试？
1、检查Push消息是否按照指定的业务规则发送。
2、检查不接收推送消息时，用户不会在接收到Push消息。
3、如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到Push。在非免打扰时间段内，用户能正常收到Push。
4、当Push消息是针对登录用户的时候，需要检查收到的Push与用户身份是否相符，没有错误的将其他人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。
5、测试Push时，在开关机、待机状态下执行推送，消息及其推送跳转的正确性。
6、push消息时，会有红点展示，推送消息阅读前后数字的变化是否正确；
7、应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转是否正确。
8、多条推送的合集的显示和跳转是否正确。
5. App的闪退通常是什么原因造成的？
1.缓存垃圾过多
由于安卓系统的特性,如果长时间不清理垃圾文件.会导致越来越卡.也会出现闪退情况.
- 运行的程序过多,导致内存不足
3.应用版本兼容问题
如果应用版本太低，会导致不兼容，造成闪退。此外，有些新版本在调试中，也会造成应用闪退。
解决方法：如果是版本太旧，更新为新版本即可；如果是新版本闪退，可能是应用在改版调试，可卸载后安装旧版。
4.. 检查APP中访问网络的地方，组件中的ImageView是否可以正常的下载并显示到app 页面上。
5.检查APP的sdk和手机的系统是否兼容。
6.在一些特定情况下的闪退,比如播放视频,在Android5.0 升级到Android6.0的时候,有些系统API老版本有,新版本没有,到时回去对象的时候失败,报空,系统就会出现闪退问题.
6. 常见的接口协议/类型是什么?
1.HTTP 类型/协议：
通过GET或POST来获取数据，在数据处理上效率比较高 == 概念
2.Webservice 类型/协议：
通过soap协议来获取数据,比起 http 来说能处理更加复杂的数据类型。本质上也是 http 协议。
7. 常见的接口请求方式是什么？
1、Get 向特定资源发出请求（请求指定页面信息，并返回实体主体）
2、Post 向指定资源提交数据进行处理请求（提交表单、上传文件），又可能导致新的资源的建立或原有资源的修改
3、Put 向指定资源位置上上传其最新内容（从客户端向服务器传送的数据取代指定文档的内容）
4、Head 与服务器索与get请求一致的相应，响应体不会返回，获取包含在小消息头中的原信息（与get请求类似，返回的响应中没有具体内容，用于获取报头）
5、Delete 请求服务器删除request-URL所标示的资源（请求服务器删除页面）
6、opions 返回服务器针对特定资源所支持的HTML请求方法 或web服务器发送测试服务器功能（允许客户端查看服务器性能）
8. 常见的状态码是什么以及都有什么意思请解释说明?
2开头的状态码
2xx表示成功处理了请求状态码
200（成功）服务器已经成功处理了请求通常；
3开头的状态码
3xx（重定向）表示要完成请求，需要进一步操作，通常这些状态码用来重定向
304（未修改）自从上次请求后，请求的网页未修改过，服务器返回此响应时不会返回网页内容；
4开头的状态码
4xx(请求错误)这些状态码表示请求可能出错，妨碍了服务器的处理
400（错误请求）服务器不理解请求的语法；
403（禁止）服务器拒绝请求
404（未找到）服务器找不到请求的网页
5开头的状态码
5xx(服务器错误)这些状态码表示服务器再尝试处理请求时发生内部错误，这些错误可能是服务器本身错误而不是请求错误
501（尚未实施）服务器不具备完成请求的功能；
例如：服务器无法识别请求方法时可能会返回此代码
500（服务器内部错误）服务器遇到错误无法完成请求
502（错误网卡）服务器做为网关或代理，从上游服务器收到无效响应
503（服务不可用）服务器目前无法使用（由于超载或者停机维护）通常这只是暂时状态
504（网关超时）服务器做为网关或代理，但是没有及时从上游服务器收到请求
505（http版本不受支持）服务器不支持请求中所用的http协议版本
9. 接口测试的原理是什么?
模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的一个过程。
10. 后台接口测试了一遍前端也测试一遍是不是重复测试?
首先要明白一个道理：永远不要相信开发能保证软件质量。
从后端角度出发：后端测试自己开发的接口，更多在于单测层面，好的开发会从接口业务调用场景出发，覆盖一些功能case，但是开发测试自己的代码，他往往觉得自己的代码已经很完美了，所以开发测试自己的代码往往是覆盖不全面的。
从前端角度出发：前端开发要和后端联调，所以前端的关注点是你接口返回给我的数据结构是不是严格按照技术方案上契约来设计的，你让我传给接口的参数是不是按照契约约定的，，所以前端开发不太关注接口逻辑对不对，只关心我只要入参给的对，返回的数据结构对就行了。
从测试角度出发：测试是保证质量最重要的一环，接口测试我们不仅仅只考虑功能层面用例，还要从非功能层面出发，比如接口性能，稳定性，安全性。我们还要结合业务场景，去思考一些反向的异常case，和其他服务相互调用过程的异常场景怎么兜底，依赖服务响应超时怎么兜底，系统异常怎么兜底等。
综上，因为前后端对同一个接口的关注点是不同的，所以不能说是重复测试。保证质量，更多依赖测试人员。三者相互协调能得到质量最优解。
11. 接口测试的流程/步骤(你的接口测试怎么做的)？
https://blog.csdn.net/weixin_39948247/article/details/111014715
12. get/post的区别？
- get请求常用在获取数据，post常用于发送数据
- get请求速度比post稍快
- get请求的数据是跟随请求地址一起发送，而post是在请求体中单独发送。
13. 如何编写接口测试用例？
功能测试：
测试这个接口的功能是否实现，并且测试这个接口是否按照接口文档来进行开发的（比如说接口文档规定了一些关键字，而开发的时候把关键字改成了其他的关键字，因为在整个项目周期，并不只有一个开发而是有多个，所以可能因为在开发过程中因为关键字不一样导致某些开发的功能异常，还有自动化脚本也会发生异常）
逻辑业务:
主要指的是一些逻辑业务依赖关系（比如支付宝提交订单的时候要保证你是在登录的情况下，如果你没有登录而提交成功了，这就是异常，可以修改请求的cookie来测试）
异常测试：
参数异常：关键字参数（应用其他的关键字替换进行测试）、参数为空、参数多少（通过添加参数增添个数），参数错误。数据异常：关键字数据（填入的数据用其他的数据语言的数据替用）、数据长度、数据为空、数据错误。
14. 性能测试都包含了哪些？（负载测试 压力测试 容量测试）
性能测试：
主要是在压力测试下收集系统的各项性能指标，与预期的指标进行对比，如关注并发用户数，cpu、内存，响应时间；
负载测试：
性能测试的一种，对系统不断增加压力，或增加一定压力下的持续时间，知道系统的性能指标达到极限，如响应时间超过预定指标，强调压力持续时间。
强度或压力测试：
通过增加系统负载，确定系统在什么条件下失效，来获得系统性能下降拐点，侧重压力大小。
容量测试：
是系统承受超额的数据容量，测试系统是否能够正常处理，通常和数据库有关。
15. 什么时候执行性能测试？
我认为一个新的项目在事先知道性能值的时候，在系统第一轮冒烟测试后就应该介入性能测试，不管功能实现中有多少bug都不影响性能测试的初步阶段，我们可以先进行简单的性能测试。尽量排除功能缺陷的干扰，尽早发现性能上的瓶颈。即时修改方案
16. 你是如何做测试分析？
1.根据需求规格提取独立的功能点，确定测试范围；
2.对独立功能进行分析，确定各独立功能的测试点；
3.对业务场景即功能组合进行分析，提供业务场景的测试点；
4.对非功能特性进行分析，了解需要测试的非功能特性；
5.针对系统级接口进行分析，了解被测试对象、测试规格。分析可测性，确定测试方法、工具。
17. 性能测试的步骤/流程？
https://www.cnblogs.com/imyalost/p/6854479.html
18. 你如何识别性能测试的瓶颈？
自己的理解，瓶颈产生在以下几方面：
1.网络瓶颈，如带宽，流量等形成的网络环境
2.应用服务瓶颈，如中间件的基本配置，CACHE等
3.系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
4.数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
5.应用程序本身瓶颈，
19. 请解释下 常用的性能测试指标的含义?
https://www.jianshu.com/p/260c36b523ab
20. 响应时间 并发用户数 吞吐量 性能计数器 TPS HPS QPS?
并发数
并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。
响应时间
响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间。
吞吐量
吞吐量是指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。
性能计数器
性能计数器是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
TPS就是我们通常说的吞吐量，也是服务端的每秒处理事务率
QPS是数据的每秒查询率
RPS是阿里提出比较重要的性能指数，是每秒处理事务率
HPS是用户每秒发起的请求率
通常关注的是tps，
tps通常可以衡量一个服务端或者系统的性能
rps反映了用户的并发施加的压力
21. 针对性能测试 负载测试 压力测试在你项目中的使用？
性能测试，压力测试，负载测试，经常听说却并没有真正的去了解区别，而且网上大部分讲的还是有点混乱，很容易让人混淆。所以根据自己的经验还有查阅软件测试书籍做了一些总结：很多时候，查阅软件测试书籍是寻找答案最好的方法。
从测试的方法与工具来说，三者都是一样的，压力测试跟负载测试都是属于性能测试的子集（软件测试书籍也是有说明这点）。
从测试的目的来说，三者又是不一样的。
性能测试：软件测试的定义：模拟用户负载来测试系统在负载情况下，系统的响应时间，吞吐量等。（这里的负载指的是用户并发数）所以它的目的是为了获取系统的指标。
负载测试：软件测试的定义：在一定的软硬件环境上，通过不断的加大负载来确定在满足性能指标情况下所能够承受的最大用户数。所以它的目的是为了获取最大用户数。一般不超过80%cpu，正常情况工作下最大用户数数据。
压力测试，也叫强度测试。软件测试的定义：在一定的软件硬件环境下，通过高负载的手段来使服务器资源处于极限的状态，测试该系统在极限状态长时间运行是否稳定。包括系统指标，服务器性能指标。
综上所述：
一般情况下我们所说的性能测试就是在服务器指标不超过80%下的测试来获取性能指标，负载测试是测试的一个方法，通过不断调试并发数获取性能瓶颈。比如80个并发，这个叫80用户负载测试。通过80—>180这样的并发数变化过程，就叫做性能测试。也就是说，性能测试是通过不同的负载测试来实现的。
压力测试，就是高负载的情况下进行的，目的不是为了获取性能指标，而是想要了解系统是否稳定。这时候服务器的指标一般不超过90%。压力测试通过长时间的运行较性能测试更能容易发现内存泄露的问题。
简单来说，负载测试是个方法，性能测试是一个过程。压力测试是个高压力下的性能测试。（个人理解）
22. 如何判断一个bug是前端bug还是后台bug?
1.先明白什么是前端，什么是后端 能够理解前端和后台，就非常好区分Bug所属位置:
前端 ： 是用户看得见摸得着的东西，主要体现在页面的视觉效果以及交互设计上
后端 ：则侧重于更深层面的东西，关于逻辑，关于数据，关于平台的稳定性与性能。后台主要负责实现具体的功能。
2.前端的bug主要分为3类：HTML CSS javascript三类问题
出现样式的问题基本都是CSS的bug;
出现文本的问题基本都是html的bug
出现交互类的问题基本都是Javascript的bug
后端的Bug如：
(1) 查看报错日志
查看报错日志，通过日志分析，需要有一定的经验，并且有一定的代码基础，才能更好地定位问题。
（2）查看数据库的数据
了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。
（3）查看缓存（如Memcache、apc、redis等缓存）是否正确
3.综合分析bug可能是前台还是后台：
（1）文本框输入不合法的内容，点击提交按钮， 如果不合法的内容提交成功， 那应该是前后台没有做校验， 前后台都有这个bug
（2）文本框输入合法的内容，点击提交按钮， 查看数据库中的数据和输入的内容不一致， 这个时候需要看前台传的数据是否正确，使用fiddler抓包， 查看请求头里面的数据是否和输入一致，如果一致就是后台的问题， 如果不一致，就是前台的bug
（3）界面展示不友好， 重复提交 这些都是前台的bug.
23. 说一说你所知道的Python 数据类型有哪些？
image.png
image.png
24. 你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解?
1、将问题提交到缺陷管理库里面进行备案。
2、要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
3、与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
4、合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
25. 给你一个网站，你如何测试?给你一个app程序你要怎么做？
26. 什么是测试用例？什么是测试脚本？两者关系？
测试用例为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
测试脚本是为了进行自动化测试而编写的脚本。
测试脚本的编写必须对应相应的测试用例
27. 简述：静态测试、动态测试、黑盒测试、白盒测试、α测试 、β测试分别是什么？
静态测试
（ui界面 业务逻辑 ）是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。
动态测试（链接数据之后 ）
是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。
黑盒测试 ：
纯功能测试 （手动测试。点点点）
功能测试：
安装/卸载测试
界面测试
易用测试
兼容性测试
逻辑功能测试
性能测试：
稳定性测试 monkey命令
压力测试
负载测试
一般性能测试 系统资源使用率
白盒测试 ： 使用编程脚本进行测试 实现自动化
α测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
β测试：是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
28. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
一条Bug记录最基本应包含：
bug编号；
bug严重级别，优先级；
bug产生的模块；
首先要有bug摘要，阐述bug大体的内容；
bug对应的版本；
bug详细现象描述，包括一些截图、录像…等等；
bug出现时的测试环境，产生的条件即对应操作步骤；
高质量的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. 如果项目周期很短，测试人力匮乏，你是怎么协调的？
-依据代码review的结果和影响范围，对测试内容进行适当的裁剪。
-借助自动化工具的支持，提高测试案例的执行效率。
-调整组内任务的优先级，进行人力协调，优先投入最紧要的项目。
-必要的情况下加班
31. 描述下你团队的测试分工？
测试技术组和业务测试组：
测试技术组主要进行工具考研、工具开发和工具维护，为业务测试效率提升和基础建设做支撑。
业务测试组主要进行具体业务测试和工具的落地使用，具体测试内容覆盖功能、性能、兼容、稳定性、接口等
32. 你做移动端的应用和web的程序应用都是如何的兼容性测试的？
移动端
1、适配系统版本：
去二手平台找到低版本的设备
image.png
2、 适配不同机型：
选择世面上的主流机型
image.png
3、适配尺寸：
image.png
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. 请讲诉移动应用的灰度是怎么做的？
灰度发布作为A/B Test的一种，一般指发布新功能到部分用户，收集反馈/改进，进而发布到全步用户的一种策略。
个人经历过以下方面：
1.新服务发布到全部服务器，但通过配置项把不同特征用户的请求打到不同的后端服务上去。比如ip是中国的用户访点击某个按钮，调用的是后端。。。/vi这个API， 而国外ip调用。。/V2
2.新功能的后端服务只发布到部分服务器，只有访问到这个服务器的用户才能用新功能。
3.同一个用户访问的平台不同，请求的服务就不同，比如app的访问V1， web的访问V2，可以通过发布app版本来实现。
另外这个实现还有很多专业的AB测试平台可以实现， 例如（云测，此处欠我广告费）。
如果涉及到写DB操作， 一般都双写。即访问新服务时，写到新服务的DB数据也要写到老服务的DB。甚至全部切换至新服务后再并行运行一段时间，才彻底切换到新服务，停写老服务。
34. 请简述移动应用在升级安装时候应该考虑的场景？
-APP有新版本时，打开APP是否有更新提示。
-当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
-当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。
-不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。
-删除老的APP，重新下载APP，能不能正常工作。
-不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。
-检查在线跨版本升级能否成功，版本过老是否提示用户重装。
-更新成功后，用户数据有没有丢失，各个配置项是否还原。
35. 如果让你来测试扫码支付，你会考虑哪些场景？
功能测试用例
--卡的类型（
一类户：借记卡、信用卡、各个开户行
二类户：虚拟账户如微信里的零钱账户、支付宝的余额宝、电子账户
二维码的商户类型（微信、支付宝、汇宜、银联）
--支付限额（单笔限额、累计限额、日累计、月累计、支付笔数）
--退款（退款入口、退款进度、退款结果）
--对账
--资金流动（我方扣款数额正确，对方收款数额正确）数额及时效
--支付结果展示、交易明细
--连续扫码支付，每天的扫码支付次数限制及数额限制
--二维码有效期
--有无相机权限
--前后置摄像头
--像素低端的手机能否扫码成功
兼容性
兼容性（不同手机厂商自带相机功能实现不一致）
安全性：
1.是否有超时超次限制
2.测试用户操作时相关信息是否写入了日志文件、是否可追踪等
3.如果使用了安全套字，需要测试加密是否正确，加密前后的信息完整性，正确性
性能
1.用户操作的响应时间
2.系统的吞吐量（TPS）
3.系统的硬件资源情况（CPU、硬盘、磁盘）
4.网络资源占用情况等。
异常场景
异常情况（卡异常、余额不足）
36. 请描述下微信朋友圈发小视频的用例设计？
功能：
入口图标的标识度
进入和退出操作简易度
取景框大小
拍景和自拍切换
视频的像素限制
视频的时长限制
发送的进度提示
性能：
发送的时间
操作是否卡顿
兼容：
不同机型分辨率
不同系统版本
不同网络情况
不同流量情况
37. 一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?
• 300个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。
• 300个用户在一个客户端上，需要更大的带宽。
• IP地址的问题，可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制。
• 所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置
38. 您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。
运用一些测试管理工具如TestDirector进行管理也是较有效的方法，同时要注意在TestDirector中对BUG有准确的描述。
在团队中建立测试人员与开发人员良好沟通中注意以下几点：
一真诚、二是团队精神、三是在专业上有共同语言、四是要对事不对人，工作至上
当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。
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(): 硬性等待，也叫线程等待，通过休眠的方式完成等待如等待5秒Thead.sleep(5000)
implicitly_wait(): 隐式等待，通过imlicitlyWait完成延时等待，这种事针对全局设置的等待，如设置超市10秒，使用imlicitlyWait后，如果第一次没有找到元素，会在10秒之内不断循环查找元素，如果超时间10秒还没有找到，则抛出异常
WebDriverWait()：显式等待，智能等待，针对指定元素定位指定等待时间，指定的范围内进行元素查找，找到元素则直接返回，超时没有找到元素则抛出异常
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：
1.IDE,俗称集成开发环境（编辑器），client
编写脚本，设置app相关的参数，形成操作指令集，将指令通过HTTp协议传输给APPium Server
2.Appium Server
提供依http协议方提供API接口服务，client通过API接口访问webdriver，发送指令，数据格式是JSON格式。
Appium Server接到指令后，交给Android系统启动的监听服务（uiautomcator2-server）
Appium Server将操作后的结果，依照JSON格式返回给客户端
3.Android/IOS
通过uiautomator2-server提供agent服务，接受来自appiumserver指令
完成指令，并返回操作结果
简化版：
Appium是C/S架构的，更像是一个proxy，连接其被测移动平台和测试脚本。
appium是基于 webdriver 协议添加对移动设备自化api扩展而成的。
区别：
selenium是web端的自动化，appium是app端的自动化，它继承了webdriver(也就是selenium 2)
52. 如果使用monkey发现了一个闪退，请问怎么使用monkey重现它？
53. Charles拦截并修改请求和返回值的步骤以及在你项目中的应用场景？
54. Charles如恶化抓取app端的htpps接口的？
55. 如何实现jenkins实现自动自动化打包发布和启动？
一、安装jenkins
二、进入jenkins
三、安装和Git，GitLab插件
四、新建item
56. 如何进行jmeter 上下游接口测试？
上下游接口有数据依赖，典型的例子就是下游接口的请求参数的数据，需要从上游接口请求以后的响应报文中获取。换一句话说，就是这么一个场景：我们需要从第一个接口请求的响应报文中，提取一些数据，作为第二个接口请求的参数值，这样，第二个接口的请求才能发送成功。如果没有先发送第一个接口的请求获取数据，第二个接口的请求就会失败。
此时如何处理？接口测试中一般会使用关联的技术来解决这个问题。如果是用Jmeter来做的话，可以使用Jmeter中的后置处理器来实现关联，比如XPath提取器，或者，正则表达式提取器等等
57. 你为什么离开上家公司？离职原因（这个会在最后问）
拖欠2个月的工资
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
- 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. 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.测试结束的标准是什么？
错误强度曲线下降到预定的水平。
单元测试退出标准
单元测试用例设计已经通过评审
核心代码100％ 经过Code Review
单元测试功能覆盖率达到100％
单元测试代码行覆盖率不低于80％
所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
不存在A、B类缺陷
C、D、E类缺陷允许存在
按照单元测试用例完成了所有规定单元的测试
软件单元功能与设计一致
集成测试退出标准
集成测试用例设计已经通过评审
所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
按照集成构件计划及增量集成策略完成了整个系统的集成测试
达到了测试计划中关于集成测试所规定的覆盖率的要求
集成工作版本满足设计定义的各项功能、性能要求
在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
A、B类BUG不能存在
C、D类BUG允许存在,但不能超过单元测试总BUG的50％。
E类BUG允许存在
系统测试退出标准
系统测试用例设计已经通过评审
按照系统测试计划完成了系统测试
系统测试的功能覆盖率达100％
系统的功能和性能满足产品需求规格说明书的要求
在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
系统测试后不存在A、B、C类缺陷
D类缺陷允许存在，不超过总缺陷的5％
E类缺陷允许存在，不超过总缺陷的10％
注：这只是一套比较理想化的退出标准，但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是100%。现在的军方标准是达到99%。对于通用软件来说就要根据公司实际情况
网友评论