1.软件的生命周期（prdctrm）
计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne）
2、问：给你一个网站，你如何测试？
首先，查找需求说明、网站设计等相关文档，分析测试需求。
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
3.在搜索引擎中输入汉字就可以解析到对应的域名，请问如何用LoadRunner进行测试。
录制测试脚本.设置测试场景：针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标；针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃；执行测试，获取测试结果，分析测试结果
4.一个客户端有三百个用户与三百个客户端有三百个用户对服务器施压，有什么区别？
一个客户端，三百个用户
只有一个客户端，三百个用户肯定不能同时进行操作，假设每次一人操作客户端对服务器施压，服务器承受的压力小但持续时间长
三百个客户端，三百个用户
假设三百个客户端同时进行操作对服务器施压，就要求服务器带宽能够承受三百人同时在线操作，且服务器短时间内承受压力大但持续时间短
300个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。
300个用户在一个客户端上，需要更大的带宽。
IP地址的问题，可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制。
所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。
5.你这个项目做过几次回归测试,做了几次迭代,写了多少条用例,覆盖了多少条测试点
2次回归 4次迭代
这个问题就是坑，因为没有固定的要去写多少多少，不要回答几十条，上百条。这个问题没有确定的答案
你应该看你当前负责的模块功能的复杂度，直接回答没留意过具体每天具体多少条。一般我 2、3 天写一个模块，一个模块的测试用例大概在 150 条左右。以具体的功能为准
6.什么是软件质量？
正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）
7.目前主要的测试用例设计方法是什么？
白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖
黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法
8.软件的安全性应从哪几个方面去测试？
软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
用户登陆密码是否是可见、可复制 、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）
9.什么是测试用例 什么是测试脚本 两者的关系是什么？
测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
测试脚本是为了进行自动化测试而编写的脚本。
测试脚本的编写必须对应相应的测试用例
10.简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试
静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。
动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异
黑盒测试一般用来确认软件功能的正确性和可操作性
白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
11.软件产品质量特性是什么?
功能性：适应性、准确性、互操作性、依从性、安全性。
可靠性：成熟性、容错性、易恢复性。
可使用性：易理解性、易学习性、易操作性。
效率：时间特性、资源特性。
可维护性：易分析性、易变更性、稳定性、易测试性。
可移植性： 适应性、易安装性、遵循性、易替换性
12.软件测试分为几个阶段?
单元测试、集成测试、系统测试、验收测试
13.测试人员在软件开发过程中的任务是什么？
1、尽可能早的找出系统中的Bug；
2、避免软件开发过程中缺陷的出现；
3、衡量软件的品质，保证系统的质量；
4、关注用户的需求，并保证系统符合用户需求。
总的目标是：确保软件的质量。
14.在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
一条Bug记录最基本应包含：
bug编号；
bug严重级别，优先级；
bug产生的模块；
首先要有bug摘要，阐述bug大体的内容；
bug对应的版本；
bug详细现象描述，包括一些截图、录像…等等；
bug出现时的测试环境，产生的条件即对应操作步骤；
15.黑盒测试和白盒测试是软件测试的两种基本方法，请分别说明各自的优点和缺点！
黑盒测试的优点有：比较简单，不需要了解程序内部的代码及实现；与软件的内部实现无关；
黑盒测试的缺点有：不可能覆盖所有的代码，覆盖率较低
白盒测试的优点有：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐 藏的问题。
白盒测试的缺点有：程序运行会有很多不同的路径，不可能测试所有的运行路径；而且会漏掉一些功能需求
16.测试计划编写6要素（5W1H）
why——为什么要进行这些测试；
what—测试哪些方面，不同阶段的工作内容；
when—测试不同阶段的起止时间；
where—相应文档，缺陷的存放位置，测试环境等；
who—项目有关人员组成，安排哪些测试人员进行测试；
how—如何去做，使用哪些测试工具以及测试方法进行测试
17.软件测试的基本流程
需求分析-编写测试计划-编写测试用例-评审-执行用例(先执行冒烟测试，然后进行系统测试)-出测试报告-验收阶段-文档归档-上线，关注线上功能和线上bug跟踪
18.你对测试最大的兴趣在哪里？为什么？
回答这个面试题，没有固定统一的答案，但可能是许多企业都会问到的。提供以下答案供考：
最大的兴趣，感觉这是一个有挑战性的工作；
测试是一个经验行业，工作越久越能感觉到做好测试的难度和乐趣
通过自己的工作，能使软件产品越来越完善，从中体会到乐趣
19.简述你在以前的工作中做过哪些事情，比较熟悉什么。参考答案如下。
我过去的主要工作是系统测试和自动化测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。
在测试中，我感觉对用户需求的完全准确的理解非常重要。另外，就是对BUG的管理，要以需求为依据，并不是所有BUG均需要修改。
测试工作需要耐心和细致，因为在新版本中，虽然多数原来发现的BUG得到了修复，但原来正确的功能也可能变得不正确。因此要注重迭代测试和回归测试。
20.Internet采用哪种网络协议？该协议的主要层次结构？Internet物理地址和IP地址转换采用什么协议？
TCP/IP协议主要层次结构为： 应用层/传输层/网络层/数据链路层。
ARP (Address Resolution Protocol)（地据址解析协议）
21.软件验收测试包括
正式验收测试、alpha测试、beta测试三种测试
22.什么是回归测试?
回归测试: (regression testing): 回归测试有两类：用例回归和错误回归；用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试，看看会重新发现问题。错误回归，就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试的方法。
23.你所了解的的软件测试类型都有哪些，简单介绍一下。
按测试策略分类：1、静态与动态测试2、黑盒与白盒测试 3、手工和自动测试 4、冒烟测试 5、回归测试；
按测试阶段分类：单元测试、集成测试、系统测试；
其他常见测试方法：1、功能测试 2、性能测试 3、压力测试 4、负载测试 5、易用性测试 6、安装测试 7、界面测试 8、配置测试 9、文档测试 10、兼容性测试 11、安全性测试 12、恢复测试
24.测试结束的标准是什么？
从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行72小时，目前Bug Tracking System中，本版本中没有一般严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本Release。
25.LoadRunner分为哪三个模块？请简述各模块的主要功能。
Virtual User Generator：用于录制脚步
Mercury LoadRunner Controller：用于创建、运行和监控场景
Mercury LoadRunner Analysis：用于分析测试结果
26.主键、外键的作用，索引的优点与不足?
答：主键：是表中的唯一标示键。作用：保证实体的完整性;加快数据库的操作速度;增加新的表记录时，数据库会自动检索新记录的主键值，不允许该值与其他表中记录的主键重复;数据库会按主键值的顺序显示记录，如果没有设定主键，则按输入的顺序显示记录。
外键：是主键的从属，表示了两个表之间的联系。作用：使用外键可以避免冗余。
索引的优点： 1、通过创建唯一性的索引，可以保证表中数据的唯一性; 2、加速数据的检索速度; 3、加快表与表之间的连接; 4、在使用分组与排序数据检索时，可以显著检索分组与排序的时间; 5、在查询的过程中使用优化隐藏器，提供系统性能。
缺点： 1、创建索引需要时间，且随着数据量的增加而增加; 2、索引需要占用物理空间;
27.性能测试的流程?
1.测试需求分析2.测试计划制定与评审3.测试用例设计与开发4.测试执行与监控5.分析测试结果6.编写性能测试报告7.测试经验总结
28.您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
关键是测试脚本的录制，测试时候测试环境的干净。
29.上线标准!
.功能测试在 beta 版本对外的上线标准是什么？
功能上线标准每个公司不一样，大致如下：
1.所有功能点(需求)都被用例覆盖到了
2.所有用例执行过至少一遍
3.所有发现的bug被修复并验证，做过regression了。
4.不能修复的记录了/关闭了/known issue了。
5.bug曲线区域平稳了
功能指标：
Bug通过率 >＝95%
严重级别bug通过率＝100%
case通过率 >＝95%
p0和p1级别case通过率100%
自动化工具通过率达到标准
接口、安全、兼容、性能、稳定性达到要求
产品验收通过
30.上线频率?(多久上线,多久发版一次)
看一个版本的内容有多少，现在外面好多走敏捷开发，一般两周一个版本
31.SQL 约束有哪几种？
六大约束
NOT NULL 非空，用于保证该字段的值不能为空
DEFAULT 默认 ， 用于保证该字段有默认值
PRIMARY KEY 主键， 用于保证该字段的值具有唯一性，并且非空
UNIQUE 唯一， 用于保证该字段的值具有唯一性，可以为空
auto_increment 自增约束
FOREIGN KEY 外键
32.六种关联查询
交叉连接（CROSS JOIN）
内连接（INNER JOIN）
外连接（LEFT JOIN/RIGHT JOIN）
联合查询（UNION与UNION ALL）
全连接（FULL JOIN）
交叉连接（CROSS JOIN）
33.数据库的查删增改?
查 show databases;
删 Drop database 数据库名称;
增 create database 数据库名称;
34.数据库里表的查删增改?
查 desc 表名;
删 drop table 表名;
增 create table 表名();
35.数据的查删增改?
查 select * from表名;
删 delete from 表名 where 条件;
增 Insert into 表名 values(列值1,列值2,列值3,........列值n);
改 update 表名 set 列名1=该列新值,列名2=该列新值,...........列名n=该列新值 where 条件;
36.如何提高数据库查询速度?
1.恰当地使用索引
2.字段冗余，减少跨库查询和大表连接操作
3.避免全表扫描的情况
4.尽可能的使用 varchar代替 char
5.不要写一些没有意义的查询,如需要生成一个空表结构
37.数据库的索引是什么?
索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。
缺点是它减慢了数据录入的速度，同时也增加了数据库的尺寸大小。
38.mysql优化?
1.定期分析检查表
2.定期优化表
39.什么样的字段适合建索引
唯一、不为空、经常被查询的字段
40.sql的脚本注入?
可以将输入的sql语句写成一个一句话木马通过访问网站将一句话木马写入到后端文件中，进而通过中国菜刀(post代表连接的菜刀)进行进一步控制
41.Linux的基本组件是什么？
1.linux内核
2.shell
3.应用程序
42.linux常用命令?
shutdown –h now：立刻进行关机
shutdown –r now：现在重新启动计算机
cat 文件名 | head -n 10 :查看前10行
kill 杀死进程
ps 看进程
uptime 查询系统当前负载信息
43.常用的两种接口：webservice接口和http api接口
webService接口是走soap协议通过http传输，请求报文和返回报文都是xml格式的，可以用soupui、jmeter等工具进行测试。
http api接口是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，可以用postman、jmeter等工具进行测试。
44.接口测试的必要性
可以发现很多页面上操作发现不了的bug；
检查系统的异常处理能力；
检查系统的安全性、稳定性
可以修改请求参数，突破前端页面输入限制（如金额）
45.接口测试流程
需求评审，熟悉业务和需求 → 开发提供接口文档 → 编写接口测试用例 → 用例评审 → 提测后开始测试 → 提交测试报告
46.接口规范文档
接口文档至少包括：
（1）接口说明
（2）调用url
（3）请求方法（getpost）
（4）请求参数、参数类型、请求参数说明
（5）返回参数说明
47.GET和POST请求
如果是get请求的话，直接在浏览器里输入就行了，只要在浏览器里面直接能请求到的，都是get请求，如果是post的请求的话，就不行了，就得借助工具来发送。
GET请求和POST请求的区别：
（1）GET使用URL或Cookie传参。而POST将数据放在BODY中。
（2）GET的URL会有长度上的限制，则POST的数据则可以非常大。
（3）POST比GET安全，因为数据在地址栏上不可见。
（4）一般get请求用来获取数据，post请求用来发送数据。
( 5 )最大的区别就是get请求只能通过url传参
其实上面这几点，只有最后一点说的是比较靠谱的，第一点post请求也可以把数据放到url里面，get请求其实也没长度限制，post请求看起来参数是隐式的，稍微安全那么一些些，但是那只是对于小白用户来说的，就算post请求，你通过抓包也是可以抓到参数的。所以上面这些面试的时候你说出来就行了。
48.http状态码
（1）200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。
（2）300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了。
（3）400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面。
（4）500 5开头的代表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果。
49.APP专项测试
①内存占用
②CPU占用
③电量消耗
④流量消耗
⑤帧数
50.什么是接口测试？
：是测试系统组件间接口的一种测试方法
：检查数据的交换，数据传递的正确性，以及接口间的逻辑依赖关系
：在软件开发的同时实现并行测试，减少页面层测试的深度，缩短整个项目的测试周期
51.接口自动化测试的流程？
基本的接口功能自动化测试流程为：需求分析-->用例设计-->脚本开发-->测试执行-->结果分析
52.如何从上一个接口获取相关的响应数据传递到下一个接口？
先从上一个接口中的响应数据获取对应的返回值，然后使用正则表达式or使用JSON解析来提取需要获取的值，然后存储在一个变量中，最后在下一个接口中直接引用该变量即可
53.接口测试用例的编写要点有哪些？
1）必填字段：请求参数必填项、可选项
2）合法性：输入输出合法、非法参数
3）边界：请求参数边界值等
4）容错能力：大容量数据、频繁请求、重复请求（如：订单）、异常网络等的处理
5）响应数据校验：断言、数据提取传递到下一级接口...
6）逻辑校验：如两个请求的接口有严格的先后顺序，需要测试调转顺序的情况
7）性能：对接口模拟并发测试，逐步加压，分析瓶颈点
8）安全性：构造恶意的字符请求，如：SQL注入、XSS、敏感信息、业务逻辑（如：跳过某些关键步骤；未经验证操纵敏感数据）
54.接口测试中依赖登录状态的接口如何测试？(重点 token)
依赖登最状态的接口，本质上是在每次发送请求时需要带上存储有账户有效信息的Session或Cookie才能发送成功，在构建POST请求时添加必要的Session或Cookie
55.平常你是怎么测试接口的？
1、绕过验证
2、绕过身份授权
3、参数是否加密
4、密码安全规则，密码的复杂程度校验
4、所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。
56.在手工接口测试或者自动化接口测试的过程中，上下游接口有数据依赖如何处理？
用一个全局变量来处理依赖的数据，比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参数
57.依赖于第三方数据的接口如何进行测试？
mock
mock除了用在单元测试过程中，还有一个用途，当前端开发在开发页面的时候，需要服务端提供API接口
此时服务端没开发完成，或者说没搭建测试环境，这个时候前端开发会自己mock一个api服务端，自己给自己提供调用接口的返回数据
mock-server用途就是开发在开发的过程中，需要依赖一部分的接口，但是对方没有提供或者环境等等情况
58.当一个接口出现异常时候，你是如何分析异常的？
1.抓包，用fiddler工具抓包，或者浏览器上f12,app上的话，那就用fiddler设置代理，去看请求报文和返回报文了
2.查看后端日志，xhell连上服务器，查看日志
59.APP.如何模拟弱网测试?
fiddler和charles都可以模拟弱网测试，平常说的模拟丢包，也是模拟弱网测试
首先选择手动代理，并输入PC端网络代理,打开Rules—》customer rules
Ctrl+F组合键调出搜索对话框，键入m_Simulate进行搜索，找到如下代码框
upload代表 上传速度
download代表下载速度
bad-->下载：8kb/s 上传：3Kb/s
2G---->下载：16kb/s 上传：7kd/s
3G---->下载：168kb/s 上传：20kb/s
4G---->下载：1432kb/s 上传：140kb/s
60.哪些场景需要用到弱网测试?
1.聊天 2.支付成功 3.提交 4.视频
61.如何分析一个bug是前端还是后端的？
平常提bug的时候，前端开发和后端开发总是扯皮，不承认是对方的bug
这种情况很容易判断，先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对
请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题咯
62.token的提取?
接口调用地址后面的tocken=后面的那串英文就是我们要用的token 或者在cookie里面
然后在相关网站进行解析
1.首先新建一个线程，取名为获取token,且增加一个http requests请求，可引用变量中的用户名、密码，至于如何设置自定义变量，前面已经讲过。这里就不再多说，具体如下图所示：设置好这些就添加结果树，运行查看结果，看token的规则及设置检查点，验证返回结果中是否存在token
2.然后设置正则表达示，提取token：如果想将这个获得的token值应用到其他的线程中，必须将其设为全局变量
设置完之后，其他的线程都可以引用这个token，我的是http 协议头中包含token， 组成的方式是 Bearer+token
63.APP端和PC端的交互?
一、准备工作：
1.调研PC端的接口：利用（google，firefox）f12开发者模式，抓取pc端请求信息（url，请求参数）
2.本地后台构建相应的实体，以及对接pc端接口的方法；
二、pc端接口信息获取及处理
1.使用spring的RestTemplate中的postForEntity()方法来对接pc端接口
2.使用spring的RestTemplate中的 exchange() 方法来对接pc端接口
参数处理，将实体转为map集合
3. 参数详解：strUrl为pc端请求路径，method：pc端请求的类型，params是请求参数，String.class：响应数据的反射类型
4.获取请求cookie里面的值，jsoup（）方法
json转实体、集合
64. App测试点
2.1安全测试
2.1.1软件权限
1）扣费风险：包括发送短信、拨打电话、连接网络等
2）隐私泄露风险：包括访问手机信息、访问联系人信息等
3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测
4）限制/允许使用手机功能接入互联网
5）限制/允许使用手机发送接受信息功能
6）限制/允许应用程序来注册自动启动应用程序
7）限制或使用本地连接
8）限制/允许使用手机拍照或录音
9）限制/允许使用手机读取用户数据
10) 限制/允许使用手机写人用户数据
11) 检测App的用户授权级别、数据泄漏、非法授权访问等
2.1.2安装与卸载安全性
1）应用程序应能正确安装到设备驱动程序上
2）能够在安装设备驱动程序上找到应用程序的相应图标
3）是否包含数字签名信息
4）JAD文件和JAR包中包含的所有托管属性及其值必需是正确的
5）JAD文件显示的资料内容与应用程序显示的资料内容应一致
6）安装路径应能指定
7）没有用户的允许, 应用程序不能预先设定自动启动
8）卸载是否安全, 其安装进去的文件是否全部卸载
9）卸载用户使用过程中产生的文件是否有提示
10）其修改的配置信息是否复原
11）卸载是否影响其他软件的功能
12）卸载应该移除所有的文件
2.1.3数据安全性
1）当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码
2）输人的密码将不以明文形式进行显示
3）密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上
4）不同的应用程序的个人身份证或密码长度必需至少在4一8 个数字长度之间
5）当应用程序处理信用卡明细, 或其他的敏感数据时, 不以明文形式将数据写到其它单独的文件或者临时文件中。以6）防止应用程序异常终止而又没有侧除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息。
7）当将敏感数据输人到应用程序时, 其不会被储存在设备中
8）备份应该加密, 恢复数据应考虑恢复过程的异常?通讯中断等, 数据恢复后再使用前应该经过校验
9）应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告
10）应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告, 更不能在安全警告显示前,，利用显示误导信息欺骗用户，应用程序不应该模拟进行安全警告误导用户
11）在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作
12）“ 取消” 命令操作能够按照设计要求实现其功能
13）应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况
14）当进行读或写用户信息操作时, 应用程序将会向用户发送一个操作错误的提示信息
15）在没有用户明确许可的前提下不损坏侧除个人信息管理应用程序中的任何内容Μ
16）应用程序读和写数据正确。
17）应用程序应当有异常保护。
18）如果数据库中重要的数据正要被重写, 应及时告知用户
19）能合理地处理出现的错误
20）意外情况下应提示用户
2.1.4通讯安全性
1）在运行其软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否能暂停程序，优先处理通信, 并在处理完毕后能正常恢复软件, 继续其原来的功能
2）当创立连接时, 应用程序能够处理因为网络连接中断, 进而告诉用户连接中断的情况
3）应能处理通讯延时或中断
4）应用程序将保持工作到通讯超时, 进而发送给用户一个错误信息指示有连接错误
5）应能处理网络异常和及时将异常情况通报用户
6）应用程序关闭或网络连接不再使用时应及时关闭) 断开
7) HTTP、HTTPS覆盖测试
--App和后台服务一般都是通过HTTP来交互的，验证HTTP环境下是否正常；
--公共免费网络环境中（如：麦当劳、星巴克等）都要输入用户名和密码，通过SSL认证来访问网络，需要对使用HTTP Client的library异常作捕获处理。
2.1.5人机接口安全性
1）返回菜单总保持可用
2）命令有优先权顺序
3）声音的设置不影响应用程序的功能
4）应用程序必需利用目标设备适用的全屏尺寸来显示上述内容
5）应用程序必需能够处理不可预知的用户操作, 例如错误的操作和同时按下多个键
2.2安装、卸载测试
验证App是否能正确安装、运行、卸载�以及操作过程和操作前后对系统资源的使用情况
2.2.1安装
1）软件在不同操作系统（Palm OS、Symbian、Linux、Android、iOS、Black BerryOS 6.0、Windows Phone 7）下安装是否正常。
2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。
3）软件安装各个选项的组合是否符合概要设计说明
4)）软件安装向导的UI测试
5）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理
6）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
7）安装空间不足时是否有相应提示
8）安装后没有生成多余的目录结构和文件
9）对于需要通过网络验证之类的安装，在断网情况下尝试一下
10）还需要对安装手册进行测试，依照安装手册是否能顺利安装
2.2.2卸载
1）直接删除安装文件夹卸载是否有提示信息。
2）测试系统直接卸载程序是否有提示信息。
3）测试卸载后文件是否全部删除所有的安装文件夹。
4）卸载过程中出现的意外情况的测试（如死机、断电、重启）。
5）卸载是否支持取消功能，单击取消后软件卸载的情况 。
6）系统直接卸载UI测试，是否有卸载状态进度条提示 。
2.3 UI测试
测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
2.3.1导航测试
1）按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航
2）是否易于导航，导航是否直观
3）是否需要搜索引擎
4）导航帮助是否准确直观
5）导航与页面结构、菜单、连接页面的风格是否一致
2.3.2图形测试
1）横向比较。各控件操作方式统一
2）自适应界面设计，内容根据窗口大小自适应
3）页面标签风格是否统一
4）页面是否美观
5）页面的图片应有其实际意义而要求整体有序美观
6）图片质量要高且图片尺寸在设计符合要求的情况下应尽量小
7）界面整体使用的颜色不宜过多
2.3.3内容测试
1）输入框说明文字的内容与系统功能是否一致
2）文字长度是否加以限制
3）文字内容是否表意不明
4）是否有错别字
5）信息是否为中文显示
6）是否有敏感性词汇、关键词
7）是否有敏感性图片，如：涉及版权、专利、隐私等图片
2.4功能测试
根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程：
1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。
2)根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如；涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。
3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。
2.4.1运行
1）App安装完成后的试运行，可正常打开软件。
2）App打开测试，是否有加载状态进度提示。
3）App打开速度测试，速度是否可观。
4）App页面间的切换是否流畅，逻辑是否正确
5）注册
--同表单编辑页面
--用户名密码长度
--注册后的提示页面
--前台注册页面和后台的管理页面数据是否一致
--注册后，在后台管理中页面提示
6）登录
--使用合法的用户登录系统。
--系统是否允许多次非法的登陆，是否有次数限制。
--使用已经登陆的账号登陆系统是否正确处理。
--使用禁用的账号登陆系统是否正确处理。
--用户名、口令（密码）错误或漏填时能否登陆。
--删除或修改后的用户，原用户登陆。
--不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。
--登陆后，页面中登陆信息。
--页面中有注销按钮。
--登陆超时的处理。
7）注销
--注销原模块，新的模块系统能否正确处理。
--终止注销能否返回原模块，原用户。
--注销原用户，新用户系统能否正确处理。
--使用错误的账号、口令、无权限的被禁用的账号进行注销
2.4.2应用的前后台切换
1) APP切换到后台，再回到app，检查是否停留在上一次操作界面。
2) APP切换到后台，再回到app，检查功能及应用状态是否正常，IOS4和IOS5的版本的处理机制有的不一样。
3) app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
4) 手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
5) 当App使用过程中有电话进来中断后再切换到app，功能状态是否正常
6) 当杀掉app进程后，再开启app，app能否正常启动。
7) 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。
8) 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。
2.4.3免登录
很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来使用app.
1) app有免登录功能时，需要考虑IOS版本差异。
2) 考虑无网络情况时能否正常进入免登录状态。
3) 切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。
4) 根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。
5) app切换到后台，再切回前台的校验
6) 切换到后台，再切换回前台的测试
7) 密码更换后，检查有数据交换时是否进行了有效身份的校验
8) 支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误。
9) 检查用户主动退出登录后，下次启动app，应停留在登录界面
2.4.4数据更新
根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。
1) 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新。
2) 确定哪些地方从后台切换回前台时需要进行数据更新。
3) 根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。
4) 确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试。
5) 检查有数据交换的地方，均有相应的异常处理。
2.4.5离线浏览
很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。
1) 在无网络情况可以浏览本地数据
2) 退出app再开启app时能正常浏览
3) 切换到后台再切回前台可以正常浏览
4) 锁屏后再解屏回到应用前台可以正常浏览
5) 在对服务端的数据有更新时会给予离线的相应提示
2.4.6 App更新
1) 当客户端有新版本时，有更新提示。
2) 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
3) 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。
4) 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。
5) 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。
6) 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。
2.4.7定位、照相机服务
1) App有用到相机，定位服务时，需要注意系统版本差异
2) 有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。
3) 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。
4) 测试定位、照相机服务时，需要采用真机进行测试。
2.4.8时间测试
客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响。
--中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东8区时间时，再查看则显示为10：00。
2.4.9 PUSH测试
1) 检查push消息是否按照指定的业务规则发送
2) 检查不接受推送消息时，检查用户不会再接收到push.
3) 如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。
在非免打扰时间段，用户能正常收到push。
4) 当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。
5) 测试push时，需要采用真机进行测试。
2.5性能测试
评估App的时间和空间特性 ：
1)极限测试：在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。
--内存满时安装App
--运行App时手机断电
--运行App时断掉网络
2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求 。
--App安装、卸载的响应时间
--App各类功能性操作的影响时间
3)压力测试：反复/长期操作下、系统资源是否占用异常。
--App反复进行安装卸载，查看系统资源是否正常
--其他功能反复进行操作，查看系统资源是否正常
4)性能评估：评估典型用户应用场景下，系统资源的使用情况。
5)Benchmark测试（基线测试）：与竞争产品的Benchmarking, 产品演变对比测试等。
2.6交叉事件测试
针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。如；App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。交叉事件测试非常重要，能发现很多应用中潜在的性能问题。
1） 多个App同时运行是否影响正常功能
2） App运行时前/后台切换是否影响正常功能
3） App运行时拨打/接听电话
4） App运行时发送/接收信息
5） App运行时发送/收取邮件
6） App运行时切换网络（2G、3G、wifi）
7） App运行时浏览网络
8） App运行时使用蓝牙传送/接收数据
9） App运行时使用相机、计算器等手机自带设备
2.7兼容测试
主要测试内部和外部兼容性
1）与本地及主流App是否兼容
2）基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确
3）与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致
--不同操作系统的兼容性，是否适配
--不同手机屏幕分辨率的兼容性
--不同手机品牌的兼容性
2.8回归测试
1）Bug修复后且在新版本发布后需要进行回归测试。
2）Bug修复后的回归测试在交付前、要进行全量用例的回归测试。
2.9升级、更新测试
新版版发布后，配合不同网络环境的自劢更新提示及下载、安装、更新、启劢、运行的验证测试。
1）测试升级后的功能是否与需求说明一样
2）测试与升级模块相关的模块的功能是否与需求一致
3）升级安装意外情况的测试（如死机、断电、重启）
4）升级界面的UI测试
5）不同操作系统间的升级测试
2.10用户体验测试
以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。 通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性�提出修改意见提升产品的潜在客户满意度。
1）是否有空数据界面设计，引导用户去执行操作。
2）是否滥用用户引导。
3）是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导
4）菜单层次是否太深
65.性能测试三大组件
1.虚拟用户脚本生成器（virtual user Generator）VUG
功能：录制脚本，编辑测试脚本
2.压力调度控制台（controller）
功能：创建场景，运行场景，监控场景，收集测试数据
3.压力结果分析器（Analysis）
66.性能测试参数?
【一】并发
【二】并发用户数量
【三】请求响应时间
【四】事物响应时间
【五】吞吐量
【六】吞吐率TPS
【七】点击率
【八】资源利用率
67.什么时候可以开始执行性能测试？
在产品相对比较稳定，功能测试结束后。灵活性比较强。
68.性能测试怎么关联?
1） 录制测试脚本回放一次
2） 根据两个快照进行对比确定插入关联的位置
3） 根据业务找到web_submit_data或web_submit_form或 web_custom_request里面关键数据，来确定关联数据个数
4） 在view script中使用web_reg_save_param函数手动建立关联
5） 将脚本中有用到关联的数据，用参数替换
6） 验证关联的正确性
69.你如何设计负载？标准是什么？
负载测试计划多少用户数量、使用什么类型的机器、以及在什么环境下进行。主要基于两个重要的文档，任务分布图和事务信息，任务分布图告诉我们在负载时间段内，某一个事务使用的用户数，高峰使用率及低峰使用率均来自该文档；事务信息告诉我们事务名及优先级，在设计场景时可以参考。
70.你如何识别性能瓶颈？
RBI方法
重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。RBI方法
按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能
71.接口自动化流程?
接口自动化大致步骤：
1、发送请求
2、解析结果
3、验证结果
定义三个和业务相关的类
1、一个用来封装HTTPclient，用来发送请求
2、解析结果xml的类
3、一个用于比较测试结果和期望值的类，用于验证
4、自动生成报告的类：自动发送报告之类的
72、深拷贝和浅拷贝的区别是什么？
深拷贝是将对象本身复制给另一个对象。这意味着如果对对象的副本进行更改时不会影响原对象。
浅拷贝是将对象的引用复制给另一个对象。因此，如果我们在副本中进行更改，则会影响原对象。
73、能否解释一下 *args 和 kwargs?
如果我们不知道将多少个参数传递给函数，比如当我们想传递一个列表或一个元组值时，就可以使用*args。
当我们不知道将会传入多少关键字参数时，使用**kwargs 会收集关键字参数。
74、arg和 *kwarg作用？
万能参数，解决了函数参数不固定的问题
*arg：会把位置参数转化为tuple（非键值对的参数组）
**kwarg：会把关键字参数转化为dict（键值对参数组）