1.web端和app端测试的相同点和不同点的是
相同点：
1、设计测试用例时，依然都是依据边界值分析法、等价类划分法等；
2、多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用；
3、需要检查页面的布局，风格和按钮等是否简洁美观、是否统一等；
4、测试页面载入和翻页的速度、登录时长、内存是否溢出等；
5、测试应用系统的稳定性等。
不同点：
1、手机作为通信工具，来电、去电、接收短信等操作都会对app应用程序产生影响，所以app测试第一个要考虑的属性特征是：中断测试。
中断测试有人为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证：
a：来电中断：呼叫挂断、被呼叫挂断、通话挂断、通话被挂断
b：短信中断：接收短信、查看短信
c：其他中断：蓝牙、闹钟、插拔数据线、手机锁定、手机断电、手机问题（手机死机、重启）
2、手机用户对app产品的安卓卸载操作：从上一个版本/上两个版本直接升级到最新版本。
全新安装新版本
新版本覆盖旧版本安装
卸载旧版本，安装新版本
卸载新版本，安装旧版本
3、web自动化测试使用的工具较常用的QTP和Selenium，而Android手机自动化测试工具比较常用的是monkey、monkeyrunner。
2、android与ios的app测试的区别？
1、 并发（中断）测试：闹铃弹出框提示，另一个应用的启动、视频音频的播放，来电、用户正在输入等，语音、录音等的播放时强制其他正在播放的要暂停；
2、 数据来源的测试：输入，选择、复制、语音输入，安装不同输入法输入等；
3、 push（推送）测试：在开关机、待机状态下执行推送，消息先死及其推送跳转的正确性；应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转否正确；推送消息阅读前后数字的变化是否正确；多条推送的合集的显示和跳转是否正确；
4、 分享跳转：分享后的文案是否正确；分享后跳转是否正确，显示的消息来源是否正确；
5、 触屏测试：同时触摸不同的位置或者同时进行不同操作，查看客户端的处理情况，是否会crash等。
3、如何测试一个app的登录场景
功能性用例设计点：
输入已注册的用户名和正确的密码，验证是否成功登录
输入已注册的用户名和不正确的密码，验证是否成功失败，且提示信息正确
输入未注册的用户名和任意密码，验证是否登录失败，且提示信息正确
使用未激活账户登录，验证是否登录失败
使用被停用用户登录，验证是否登录失败
用户名和密码两者都为空，验证是否登录失败，且提示信息正确
用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确
如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入正确的验证码，验证是否登录成功
如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入错误的验证码，验证是否登录失败，且提示信息正确
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.操作错误提示信息是否简单明了
兼容性测试用例设计点：
不同浏览器下，验证登录页面的显示以及功能正确性
相同浏览器的不同版本下验证登录页面的显示以及功能正确性
不同移动设备终端的不同浏览器下，验证登录页面显示以及功能的正确性
不同分辨率的界面下，验证登录页面的显示以及功能正确性
安全性测试用例设计点：
用户密码后台存储是否加密
用户密码在网络传输过程中是否加密
密码是否具有有效期，密码有效期到期后，是否提示需要修改密码
不登录的情况下，在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面
密码输入框是否不支持复制粘贴
密码输入框内输入的密码是否都可以在页面源码模式下被查看
用户名和密码输入框分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面
用户名和密码输入框分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改
连续多次登录失败的情况下，系统是否会阻止后续的尝试以应对暴力破解
10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期
11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性
12.是否可以记住密码，记住的密码保存是否加密，记住的密码是否有有效期，过了有效期后是否清空密码
13.是否支持第三方登录
14.密码的强弱性，复杂度校验
15.异地登录校验、更换设备登录校验、登陆信息异常是否考虑账户冻结停用、是否允许第三方平台存储密码
16.是否可以使用登录的api发送登录请求，并绕开验证码校验
17.是否可以用抓包工具抓到的请求包直接登录
18.截取到的token等信息，是否可以在其他终端上直接使用，绕开登录，token过期时间校验
19.登录错误后的提示是否存在安全隐患
性能压力测试的用例设计点：
单用户登录的响应时间是否小于3秒
单用户登录时，后台请求数量是否过多
高并发场景下用户登录的响应时间是否小于5秒
高并发场景下服务端的监控指标是否符合预期
高集合点并发场景下，是否存在资源死锁和不合理资源等待
长时间大量用户连续登录和登出，服务器是否存在内存泄露
输入内容校验是否加入了函数防抖
4、Push消息测试图和测试？
消息推送对象
消息推送一般可以自定义推送对象，有全部推送，精确推送，及安卓和IOS渠道推送，注意推送对象是否正确，推送之前确认自己是否在测试环境操作，以免造成生产问题。
消息简介
客户端收到消息推送有两种形式，客户端后台运行一般推送显示在通知栏，客户端前台运行一般弹出弹框，简介内容注意字数过多溢出情况。
消息详情
注意详情所支持的内容，包括文字、图片、表情包、换行以及链接跳转。
消息推送场景（支持定时推送）
（1）消息推送时间：
a)设置过去时间
b)未推送之前修改消息内容
c)删除消息，查看是否还会推送
（2）客户端运行状态
a)前台运行
b)后台运行
c)进程关闭状态
（2）特殊场景
a)多个提醒冲突
b)当天设置当天推送
c)当天设置隔几天起效
5、App的闪退通常是什么原因造成的？
闪退的原因和处理方法
1、缓存垃圾过多
平时在使用软件的过程中，会产生一些垃圾文件，如果长时间不清理会导致手机越来越卡，也会出现闪退状况。
进入设置–应用程序——全部——找到有问题的应用程序，清除数据或者缓存。(注：清除数据，会清除掉应用的个人设置、账户信息等。)
2、运行程序过多
如果不进行设置，很多软件都会自己运行，而手机后台程序过多会造成内存不足，从而造成应用闪退。如出现软件闪退，可先清理内存后再试试。
3、手机杀毒软件
部分手机软件存在着恶意代码，会被杀毒软件拦截因而不能正常进入，应该通过绿色下载平台或者使用软件商店来下载安全系数较高的游戏。
(注：以上三个原因都现在都可以通过安全软件清理，轻松解决。但需要注意在删除一些大型文件时请谨慎。)
4、应用版本问题
如果应用的版本较低，会导致应用软件不兼容，造成闪退。如果是版本太旧，更新为新版本即可。
如新版本如果出现闪退，是应用改版本还在调试中，无需担心，会很快修复。
5、网速问题
部分软件需要一个稳定的网络，使用的是2G/3G网络，造成闪退的可能性比较大，建议在有WiFi的情况下玩比较好。
6、缺少数据包
一些大型游戏需要数据包才能运行。所以要先安装好数据包才能使用。
7、系统不兼容
部分软件对版本有一定的要求，如果系统版本过低，软件是不能支持的，所以会闪退。
8、分辨率不兼容
一些软件对手机分辨率有一定的要求，如果手机分辨率不兼容，有部分软件就容易出现闪退或其它错误。
6、常见的接口协议/类型是什么？
webService接口：是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测
试。可以使用的工具有SoapUI、jmeter、loadrunner等；
http api接口：是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等
方法，这也是最常用的两种请求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；
7、常见的接口请求方式是什么？
1、Get 向特定资源发出请求（请求指定页面信息，并返回实体主体）
2、Post 向指定资源提交数据进行处理请求（提交表单、上传文件），又可能导致新的资源的建立或原有资源的修改
3、Put 向指定资源位置上上传其最新内容（从客户端向服务器传送的数据取代指定文档的内容）
4、Head 与服务器索与get请求一致的相应，响应体不会返回，获取包含在小消息头中的原信息（与get请求类似，返回的响应中没有具体内容，用于获取报头）
5、Delete 请求服务器删除request-URL所标示的资源（请求服务器删除页面）
6、opions 返回服务器针对特定资源所支持的HTML请求方法 或web服务器发送测试服务器功能（允许客户端查看服务器性能）
8、常见的状态码是什么以及都有什么意思请解释说明？
200 OK
请求正常处理完毕
204 No Content
请求成功处理，没有实体的主体返回
206 Partial Content
GET范围请求已成功处理
301 Moved Permanently
永久重定向，资源已永久分配新URI
302 Found
临时重定向，资源已临时分配新URI
303 See Other
临时重定向，期望使用GET定向获取
304 Not Modified
发送的附带条件请求未满足
307 Temporary Redirect
临时重定向，POST不会变成GET
400 Bad Request
请求报文语法错误或参数错误
401 Unauthorized
需要通过HTTP认证，或认证失败
403 Forbidden
请求资源被拒绝
404 Not Found
无法找到请求资源（服务器无理由拒绝）
500 Internal Server Error
服务器故障或Web应用故障
503 Service Unavailable
服务器超负载或停机维护
9、接口测试的原理是什么？
通过测试程序或工具，模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理，然后再把应答报文发送给客户端，客户端接收应答报文这一个过程。
10、后台接口测试了一遍前端也测试一遍是不是重复测试？
1、相同处：都有功能测试，即针对基本业务功能进行测试
2、不同处：
1）边界分析测试
前端的边界测试都是基于固定的输入（如下拉框），在这种情况下测试的边界范围就非常有限；但接口测试就不存在这方面的限制，相对来说接口可以覆盖的范围更广，同样的，接口出现问题的概率也更高。
2）性能测试
前端的性能测试关注点在与手机相关的特性，如手机cpu、内存、流量、fps等；接口性能主要关注接口响应时间、并发、服务端资源的使用情况等
11、接口测试流程/步骤（你的接口测试怎么做的）？
接口测试流程：
1.测试尽早找开发拿接口文档（需求文档）
2.根据接口文档编写测（用例编可以按照以往的规则写，比如说等价类划分，边界值，场景法等）
执行测试，查看不同的参数请求，接口返回的数据是否达到预期
接口测试怎么测的：
通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
接口安全：
1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
4、密码安全规则，密码的复杂程度校验
异常验证：
所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
性能测试
接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单
接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别。
12、get/post的区别？
get请求常用在获取数据，post常用于发送数据
get请求速度比post稍快
get请求的数据是跟随请求地址一起发送，而post是在请求体中单独发送。
13、如何编写接口测试用例？
主要从四个方面来设计接口用例：功能，业务逻辑，异常，安全
功能：
1）功能是否正常；
2）功能是否按照接口文档实现
举例：比如博客园添加随笔，需要登录才能添加。也就是业务要求不支持游客添加随笔功能，如果设计一个没有登录的用户，然后去测试添加随笔接口，结果接口能添加到随笔，说明功能不正常，不符合需求和接口文档描述。
业务逻辑：是否依赖业务；
举例：该接口调用之前，需要调用登录接口，如果不登录也能请求数据，不符合业务逻辑。
异常：参数异常和数据异常
1）参数异常：关键字参数，参数为空，多，少参数，错误参数
2）数据异常：关键字数据，数据为空，长度不一致，错误数据
举例：不管数据异常还是参数异常，测试点差不多，一个参数有key和value，key表示参数，value表示数据。第一，看看参数和数据能不能支持关键字，例如Java中的保留关键字等等。第二个就是参数和数据都为空，看看是否做了判断。第三个，参数多和少，例如有两个参数的接口，你需要设计一个三个参数的用例，一个只有一个参数的用例。数据那边长度不一致，例如设计很长的字符串是否支持，因为数据库创建表过程都设置好了每个字段的长度。输入错误的参数和数据，例如故意输出单词等等。
安全测试用例设计：
1)cookie：有cookie才能获取数据，如果不带cookie还有信息返回，说明有问题
2)header：正常接口带header信息，删除header看是否能够返回数据。
3)唯一识别码：app手机识别码，一般是唯一的。
安全测试主要从上面三点检查。第三个是唯一识别码，主要是指app上手机的识别码，一般很少用到，除非很严格的接口测试，例如银行app登录，需要指纹，而指纹来源手机，一般有一个手机识别码判断过程。
14、性能测试都包含了哪些？（负载测试 压力测试 容量测试）
性能测试：主要是在压力测试下收集系统的各项性能指标，与预期的指标进行对比，如关注并发用户数，cpu、内存，响应时间；
负载测试：性能测试的一种，对系统不断增加压力，或增加一定压力下的持续时间，知道系统的性能指标达到极限，如响应时间超过预定指标，强调压力持续时间。
压力测试：通过增加系统负载，确定系统在什么条件下失效，来获得系统性能下降拐点，侧重压力大小。
容量测试：是系统承受超额的数据容量，测试系统是否能够正常处理，通常和数据库有关。
15、什么时候执行性能测试？
功能测试通过；一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。
16、你是如何做测试分析？
1.明确需求
需求文档分析，是否有需求遗漏、需求模糊、需求错误等项目，发现问题及时和产品沟通
2.回忆成年老坑
一个需求过来，有些模块或者部分内容和之前的一致，而在之前的版本中出现过事故、特殊规则、注意事项等等内容，及时和开发回顾和讨论解决方案（尤其是新手开发上手的时候）
3.确定开发提测日期
没什么好说的，为了版本上线顺利，工作时间能均匀分配（别每次都是前几天闲死，后几天忙成狗）
4.拆解模块
根据需求内容和开发大概的系统分析，拆解各个模块
5.编写测试用例
先按各模块级别，最后集成
6.提测版本测试
7.执行测试、疯狂提 bug、bug 修复验证
8.根据开发人员水平，需求复杂度等等等 重复 6-7 N 次
9.最后回归，测试开发产品三方验收
17、性能测试的步骤/流程？
熟悉性能测试需求，确定性能测试点和测试指标；
开发性能测试脚本并调优；
准备性能测试环境，性能测试数据，设计性能测试场景；
监控性能测试环境；
运行性能测试；
分析性能测试结果，提交性能测试bug单，跟踪问题单直到问题被解决；
输出性能测试报告。
18、你如何识别性能测试的瓶颈？
1、网络瓶颈，如带宽，流量等形成的网络环境
2、应用服务瓶颈，如中间件的基本配置，CACHE等
3、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
4、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
5、应用程序本身瓶颈，
19、请解释下 常用的性能测试指标的含义？
1、事务成功率
2、事务平均响应时间和90%的事务响应时间
3、吞吐量（TPS）
4、CPU，内存，IO使用率
20、响应时间 并发用户数 吞吐量 性能计算器 TPS HPS QPS?
1. 响应时间(RT)
是指系统对请求作出响应的时间。这个指标与人对软件性能的主观感受是一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
注意: 在性能测试中, 响应时间要做更细致划分
2.并发数
并发数（并发度）：指系统同时能处理的请求数量，同样反应了系统的负载能力。这个数值可以分析机器1s内的访问日志数量来得到
2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量，TPS、QPS都是吞吐量的常用量化指标。
3. TPS(Transactions Per Second,每秒事务数)
TPS是单位时间内处理事务的数量,从代码角度来说,一段代码或多段代码可以组成一个事务.单位时间内完成的事务数越多,服务器的性能越好
4.HPS：Hits per Second 每秒点击次数
是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和。 它一般和TPS成正比关系，是B/S系统中非常重要的性能指标之一。
5.QPS(Query Per Second,每秒查询数)
QPS是单位时间内处理请求的数量,比TPS划分的更细致一些,因为一个事务可能会包含多个请求. 在一个事务当中, 假如只包含一个请求,
那么 QPS 就是指该请求过程中, 发起的数据查询总次数. 注意: 在 JMeter 当中, 把 TPS 和 QPS 简单的认为是同一个指标, 用来考察服务器性能好坏
6.性能计数器：
直接win+R运行 perfmon.exe 即可打开。可以在以下场景下使用：
如果发现有内存泄露，性能计数器可以被用来检查托管还是本地内存分配的问题。Process\Private Bytes可以查看所有进程分配的private内存（包括GC堆）和.NET CLR Memory\# Bytes in All Heaps可以查看托管内存。
如果ASP.NET程序有反常的行为，在ASP.NET目录下可以看详细信息，比如请求时间, 请求超时时间， 请求等待时间, 请求执行时间等计数器可以确认负载情况。Errors Total/Sec可以查看程序非正常的异常计数，各种cache可以查看缓存是否有效利用。
如果WCF中严重依赖数据库并且分布式事务处理失败的话，ServiceModelService目录可以查明问题。Calls Outstanding, Calls Per Second, and Calls Failed Per Second等计数器可以定位负载，Transactions Flowed Per Second计数器报告事务数量，SQL SERVER目录的MSSQL$INSTANCENAME:Transactions 和MSSQL$INSTANCENAME:Locks可以看出事务执行的问题，比如过多的锁，以及死锁。
21、针对性能测试 负载测试 压力测试在你项目中的使用？
性能测试的目的是找到系统在某种条件下的瓶颈，前提是这种条件在软件或服务的实际应用中可能发生。例如百度主页会同时有10万人访问，这是可能的。因此测试10万个Vuser同时Hit是有意义的，但是会不会有10亿人同时访问?显然不会，至少在当今不会，因此测试的数据量定在10亿个Vuser是无意义的，这种行为不靠谱。因此，在这一点上我们可以得出结论，具有清晰的、有意义的并且意义确定的预期值是进行一次性能测试的关键要素。
所以，我们在进行性能测试之前，首先要明确两个值：一个是系统负载预期值，一个是系统响应时间的预期值。有了这两个目标，才可以使用对系统持续增加负载的方法来观察系统的瓶颈所在。
那么性能测试就是简单的添加负载测试吗？显然不是。前面说过，性能测试的目的是要找出系统的瓶颈所在，而系统的瓶颈可能存在于各种方面。在代码方面，比较差的算法、硬代码多的模块等低效率的代码可能产生瓶颈；在数据库方面，冗余或者复杂的数据可能产生瓶颈；操作系统方面，CPU、磁盘、I/O系统、总线及兼容性等方面可能产生瓶颈；而在通信传输层面上，交换（路由）的转发效率、网络硬件质量等都可能引发系统瓶颈。对于以上这些可能引发瓶颈的原因，我们可以进行所谓白盒测试来找到问题的关键。各种层面上的问题，都有相应的测试工具或测试设备的支持，如果没有合适的工具，也可以自己进行设计。例如一些CPU监控工具、代码检测、数据库事件探查器、Chariot等，以及网络分析仪、数据分析仪等通信分析仪器。这些都是性能测试的利器。
我们在性能测试出现瓶颈时，需要及时的调试对应的系统问题，但是如果在调试完成之后，系统表现好了一些，但是仍然没有达到预期目标，这个时候我们就应该把目光放在系统的其他层面上。由于一个系统是由多个子系统协作的，因此各个子系统之间有着密切的关联性。以WEB系统为例，当代码层以及数据库层都进行清洗之后，还可以通过其他途径提高系统的性能，以突破瓶颈，达到预期目标。
性能测试的另外一个目的是要建立一组被测系统的基准数据，系统在同样的测试环境与测试条件下，表现应当符合或优于基准数据的要求，否则测试不通过。另外，基准数据也可以为其他类似的系统提供预期数据及预期返回时间的数值参考。
本文出自alitester的51Testing软件测试博客：http://www.51testing.com/?271947
二、负载测试
负载测试的范围个人认为比性能测试要狭窄一些，负载测试通常定义为给被测系统加上它所能操作的最大任务数的过程。负载测试考验系统的两个指标，一个是系统的容量，一个是系统的耐久性。
测试系统容量是指给系统添加大数据量的文件或者数据，让系统进行处理并实时观察系统的表现情况。例如大数据量文件输入让系统处理（我们很熟悉的操作，亲们知道是啥意思吧？），大访问量的输入处理等。目的是找到系统能添加负载的最大量。而测试系统耐久性则指的是给出数量巨大的任务，让系统始终处于高负荷量的运行状态，并观察记录系统表现情况的测试方式。目的是找到系统所谓的“疲劳点”。例如运行多少时间之后系统返回时间开始变大，系统什么时候处理时间变得缓慢等都是考察的内容。
负载测试实现的前提是要先准备巨大的数据量，例如上百兆的文件、上万的用户等。负载测试不会以使系统崩溃为目的，因此负载测试的期望值一般以满足使用需求为主，不需要太夸张的数值。
三、压力测试
任何能使系统崩溃的测试都可以称之为压力测试。这一点我在会上已经多次说过了。比如给出超出系统期望值两倍（一般业内共识是两倍）的数据量让系统处理，或者突然断开与数据库的连接然后再恢复，甚至是在服务器上运行消耗CPU、磁盘等资源的任务，总而言之，压力测试就是要想方设法的给系统添加压力，让系统出现故障，然后观察系统在出现故障时的反应以及故障恢复的能力。例如系统是缓慢死亡的还是猝死的，是不是保存了崩溃前的数据，故障恢复的时间有多久，恢复之后能不能返回原先的工作状态等等，只要是有利于提高系统在大压力情况下的表现的，都是考察的内容。
22、如何判断一个bug是前段还是后台bug？
首先需要了解一个页面的请求过程：以http请求为例： 1、用户在前端页面操作，如点击某个提交按钮 2、页面携带数据进行请求，访问具体功能接口 3、由后端服务执行相应的业务逻辑，如涉及数据，再去请求并组装数据返给前端 4、前端页面进行渲染和展示对应的页面和数据 前后端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 数据类型有哪些？
整数 int
浮点数 float
布尔属性 bool
字符串类型 str
列 表 list
元组 tuple
字典 dict
集合 set
24、你在测试中发现一个bug，但是开发经理认为这不是一个bug，你应该怎样解？
先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
25、给你一个网站，你如何测试？给你一个app程序你要怎么做 ？
首先，查找需求说明、网站设计等相关文档，分析测试需求。
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
设计测试用例：
功能性测试可以包括，但不限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
提交功能的测试。
多媒体元素是否可以正确加载和显示。
多语言支持是否能够正确显示选择的语言等。
界面测试可以包括但不限于一下几个方面：
页面是否风格统一，美观
页面布局是否合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但未安装的控件，是否提供自动下载并安装的功能
文字检查
性能测试一般从以下三个方面考虑：
压力测试；负载测试；强度测试
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
安全性测试：
基本的登录功能的检查
是否存在溢出错误，导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如SQL注入等
如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
兼容性测试，根据需求说明的内容，确定支持的平台组合：
浏览器的兼容性；
操作系统的兼容性；
软件平台的兼容性；
数据库的兼容性
开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
定期评审，对测试进行评估和总结，调整测试的内容。
26、什么是测试用例？什么是测试脚本？两者关系？
测试用例：为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
测试脚本是为了进行自动化测试而编写的脚本。
两者的关系： 测试脚本的编写必须对应相应的测试用例
27、简述：静态测试、动态测试、黑盒测试、白盒测试、α测试、β测试分别是什么？
静态测试：静态测试是指不运行被测程序本身，通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性
动态测试：通过运行被测程序来检查运行结果与预期结果的差异，并分析运行效率和健壮性等指标；这种方法包括三部分：构造测试用例、执行程序、分析程序的输出结果。
白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
a测试：公司组织的内部人员进行的测试
ß测试：公司组织的典型客户在实际生活中使用
28、在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
1.和BUG对应的软件版本
2.开发的借口人员，测试人员
3.BUG的优先级
4.BUG的严重程度
5.BUG可能属于的模块
6.BUG的标题
7.BUG的描述
8.BUG的截图
9.BUG的状态
10.BUG的错误类型（数据，界面）
29、在你的项目中详细的描述一个测试活动完整的过程？
1-项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪
2-开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
3-测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4-测试用例完成后，测试和开发需要进行评审。
5-测试人员搭建环境
6-开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。
7-开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。
8-重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。
9-如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
30、如果项目周期很短，测试人力匮乏，你是怎么协调的？
1. 测试有压力，开发必然有压力，和开发一起砍需求
2. 系分和测分增加投入，做更精准的测试
3. 测试提前进入
4. 加强开发自测，拉取开发交付用例
5. 加班
31、描述下你团队的测试分工？
按项目模块划分 这样人员利用率高，不同的人员负责的功能不一样。工作就不会存在交叉与重复
32、你做移动端的应用和web的程序应用都是如何的兼容性测试的？
web端：一般都是主要使用一种浏览器，待系统基本稳定的时候，再去专门测试浏览器的兼容性。
移动端：移动端主要分为安卓和IOS，而这两端出现的问题一般是不一致的，
一致的问题主要是数据问题，这时候是需要后台处理的，需要两端都重点测试，而不会出现先着重测试某一端的问题。
注：一般方式是在测试一端时，出现问题则立马查看另一端是否也有这个问题。
33、请讲述移动应用的灰度是怎么做的？
Android上比较容易灰度发布的。
一、发布版本号较低的灰度测试版本，如beta版本号为3.1.0.1，正式发布时为3.1.1.0。
发送的形式主要有：
1、在单独的下载点/下载渠道发布灰度测试版本，比如在网页上开一个测试版下载的口子。
2、通过APP内置的更新通知进行一定比例的发布，推送更新的机制在服务端需要处理好，比如APP
启动时获取机器特征上传到服务器，然后对应下发版本更新通知，或者直接按百分比下发。
这种实现较为复杂但可参考意义最大，一些PC软件也采用这种方法，比如我知道360、tencent。
二、正式版本发布时再进行高版本推送，之前灰度发布的测试版通过对比版本号会提醒更新到最新版本。
iOS上只能好好测试了，或者发布越狱版本（但越狱版本有时候本身也是一种问题）
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、只发送视频
1、本地相册选择/拍摄
2、视频秒数验证：1-10s，超出10s
3、视频个数验证：1个，超出1个
4、视频格式验证：支持的视频格式，例mp4、不支持的视频格式
5、视频大小验证：苹果400kb以内、Android200-300kb（此为百度数据）、超出规定大小
6、视频预览增删改操作
7、为空验证
2、发送文本+视频：输入满足要求的文本、视频进行一次验证
3、发送图片+视频：不支持发送
4、朋友圈发送内容是否有限制，例如涉及黄赌毒等敏感字
5、所在位置
1、不显示位置：发送到朋友圈动态不显示位置
2、选择对应位置：搜索支持、自动定位、手动编辑
3、点击取消，返回上一级页面
6、谁可以看
1、设置公开：所有朋友可见
2、设置私密（仅自己可见）：自己查看朋友圈-可见、好友查看朋友圈-不可见
3、设置部分可见（部分朋友可见）：选择的部分好友-可见、不被选择的好友-不可见、是否有人数上限
4、设置不给谁看（选中的朋友不可见）：不被选中的朋友-可见、被选中的朋友-不可见、是否有人数上限
5、点击取消，返回发送页面
7、提醒谁看
1、提醒单人/提醒多人：被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒
2、是否有人数上限
3、点击取消，返回发送页面
8、同步QQ空间：默认不同步、同步到QQ空间
9、取消发送朋友圈操作
1、选择相机，点击取消，返回朋友圈页面
2、进入朋友圈发送页面，选择文本图片，点击取消
10、朋友圈当天发送次数是否有上限限制
37、一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别？
一个客户端，三百个客户：
只有一个客户端，三百个用户肯定不能同时进行操作，假设每次一人操作客户端对服务器施压，服务器承受的压力小但持续时间长
三百个客户端，三百个客户：
假设三百个客户端同时进行操作对服务器施压，就要求服务器带宽能够承受三百人同时在线操作，且服务器短时间内承受压力大但持续时间短
38、你认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？
维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。
在团队中建立测试人员与开发人员良好沟通中注意以下几点：
一真诚、二是团队精神、三是在专业上有共同语言、四是要对事不对人，工作至上
39、简述你在以前的工作中做过哪些事情，比较熟悉什么？
我过去的主要工作是系统测试和自动化测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。
在测试中，我感觉对用户需求的完全准确的理解非常重要。另外，就是对BUG的管理，要以需求为依据，并不是所有BUG均需要修改。
测试工作需要耐心和细致，因为在新版本中，虽然多数原来发现的BUG得到了修复，但原来正确的功能也可能变得不正确。因此要注重迭代测试和回归测试。
40、请说出这些测试最好由哪些人员完成，测试的是什么？
代码、函数级测试一般由白盒测试人员完成，他们针对每段代码或函数进行正确性检验，检查其是否正确的实现了规定的功能。
模块、组件级测试主要依据是程序结构设计测试模块间的集成和调用关系，一般由测试人员完成。
系统测试在于模块测试与单元测试的基础上进行测试。了解系统功能与性能，根据测试用例进行全面的测试。
41、在Windows下保存一个文本文件时会弹出保存对话框，如果为文件名建立测试用例，等价类应该怎样划分？
单字节，如A；双字节， AA、我我；特殊字符 /‘。‘；、=-等；保留字，如com；文件格式为8.3格式的；文件名格式为非8.3格式的；/,,*等九个特殊字符。