同乐学堂声明：禁止转载
前言
笔试只是辅助，成功与否在于面试环节，决定你去留的是测试主管或测试经理！
时刻保持高素质，每一个眼神， 每一个动作，每一个称呼，每一句专业的话语。都是决定你成功与否的因素。
不要把自己当成垃圾，随意看着，随意站着，随意坐着，随意行走，随意准备简历，随意会害了你，自律的态度会赢得成功的鲜花和掌声。
总结一句名言：业精于勤荒于嬉，行成于思毁于随！
企业的招聘目标: 问对的问题，招对的人！
通常情况下，保证应聘者讲的话，比面试官多，在最短的时间内，取得她的信任，面试官想要听到你之前遇到的难题，你是怎么解决的，和你action之后所带来的结果。
一定要通过讲述真实的故事（体现出当时的场景，时间，地点，数字的描述、技术细节），直接要害的凸显出，应聘公司所欠缺的资质和能力。
决定面试是否成功的第一要素不是华丽的简历也不是一些小技巧。而是你内在散发出来的气质。
如今你的气质里，藏着你走过的路，读过的书和爱过的人。 ——《卡萨布兰卡》
一、基本考察点
1、测试理论、测试用例设计能力
2、通用技能（SQL+Linux+各端的调试命令+网络基础+编程基础数据结构、算法）
3、简历中项目的介绍（流畅、清晰，具有条理性）、
4、智力逻辑题
5、开放式问题
6、热爱测试
二、面试题
1、测试用例（银行ATM，电梯，笔，水杯，自动售卖机，三角形、注册、登陆、百度首页面、app电影票、红包、语音测试、视频测试（离线、直播）、语音识别，QQ文件传输等、微信朋友圈等，一般为面试官比较熟悉的也认为你比较熟悉的互联网产品）
答题套路：
1、基本功能测试（产品的主要核心功能的测试）
2、UI界面测试（跟产品一切相关文字，布局，颜色是否符合标准，是否准确）
3、兼容性测试 （在各个环境下，场景下能基本功能是否正常使用）
4、安全性测试 （有哪些功能是否能影响人的生命和财产）
5、稳定性测试 （长时间使用，功能还能正常继续使用，不会发生任何异常）
6、易用性测试 （使用方便，操作简单）
7、性能（性价比，跟其他相关产品，便宜，功能强大，效率高）、
8、容错性 （不按正常流程操作，基本功是否还能正常使用。）
9、安装、卸载、升级
10、可移植性（将系统或者物品，在不同环境下移动时的难易程度）
11、探索性、随机性测试（注重用户体验，细节的验证）
2、post 与get区别
1) get参数通过url传递，post放在request body中。
2) get请求在url中传递的参数是有长度限制的，而post没有。
3) get比post更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息。
4) get请求只能进行url编码，而post支持多种编码方式
5) get请求会让浏览器主动cache，而post不会，除非手动设置，才会进行缓存。
6) get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留。
3、HTTP与HTTPS区别
http通信使用明文不加密，内容可能被窃听,
HTTPS协议需要花钱买证书。
因为他们的链接方式不一样，所以http的端口是80，https是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
4、HTTP有几种请求方式
HTTP的请求方式常用有3种，分别是：POST、GET、HEAD
POST和GET方法是用于数据发送的。
Get方式是从服务器上获取数据；在做数据查询时，建议用Get方式；
如：商品信息接口、搜索接口、博客访客接口等。
Post方式是向服务器传送数据 ；在做数据添加、修改或删除时，建议用Post方式 ；
如：微博图片上传图片接口、登录注册接口等。
|
序号
|
方法
|
描述
|
|
1
|
GET
|
请求指定的页面信息，并返回实体主体。
|
|
2
|
HEAD
|
类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
|
| 3 |
POST
|
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
|
|
4
|
PUT
|
从客户端向服务器传送的数据取代指定的文档的内容。
|
|
5
|
DELETE
|
请求服务器删除指定的页面
|
|
6
|
CONNECT
|
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
|
|
7
|
OPTIONS
|
允许客户端查看服务器的性能。
|
|
8
|
TRACE
|
回显服务器收到的请求，主要用于测试或诊断。
|
5、cookie与session 区别
1、Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。
2、Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。
3、Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。
4、Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力
6、HTTP常见状态码
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
|
状态码
|
含义
|
|
100
|
继续请求
|
| 101 |
切换协议
|
|
200
|
请求成功
|
|
201
|
创建新资源 |
|
202
|
未处理完成
|
|
203
|
非授权信息。（返回副本内容）。
|
|
204
|
无内容
|
|
205
|
重置内容（清除浏览器的表单）
|
|
206
|
处理了部分get请求
|
|
300
|
多种选择（针对请求，服务器可执行多种操作）
|
|
301
|
永久移动（ 请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替）
|
|
302
|
临时移动（ 301类似。但资源只是临时被移动。客户端应继续使用原有URI）
|
|
303
|
查看其他位置
|
|
304
|
未修改
|
|
305
|
使用代理
|
|
307
|
临时重定向*（临时重定向。与302类似。使用GET请求重定向）
|
|
400
|
客户端语法错误
|
|
401
|
请求要求用户的身份认证
|
|
402
|
将来的需求而预留
|
|
403
|
服务器理解请求客户端的请求，拒绝执行此请求
|
|
404
|
资源未找到
|
|
405
|
客户端的请求中的方法被禁止
|
|
406
|
服务器无法根据客户端请求的内容特性完成请求。（ 请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。）
|
|
407
|
请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
|
|
408
|
服务器等待客户端发送的请求时间过长，超时
|
|
409
|
由于和被请求的资源的当前状态之间存在冲突，请求无法完成
|
|
410
|
客户端请求的资源已经不存在。（说明以前有，跟404略有区别，404压根就没有）
|
|
411
|
请求没带 带Content-Length的请求信息
|
|
412
|
客户端请求信息的先决条件错误
|
|
413
|
请求数据过大，服务器拒绝处理
|
|
414
|
URI过长，服务器解析不了
|
|
415
|
不支持的媒体类型
|
|
416
|
请求的范围无效
|
|
417
|
服务器无法满足Expect的请求头信息
|
|
421
|
连接数超过了服务器许可的最大范围。
|
|
422
|
语义错误
|
|
423
|
当前资源被锁定
|
|
424
|
由于之前的某个请求错误，导致当前错误
|
|
500
|
服务器内部错误，无法完成请求
|
|
501
|
服务器不支持请求的功能，无法完成请求
|
|
502
|
错误的网关，无效的响应
|
|
503
|
服务器超载或维护
|
|
504
|
网关超时
|
7、HTTP 常见HEADER信息
a、通用首部字段（请求报文与响应报文都会使用的首部字段
Date：创建报文时间
Connection：连接的管理
Cache-Control：缓存的控制
Transfer-Encoding：报文主体的传输编码方式
b、请求首部字段（请求报文会使用的首部字段）
Host：请求资源所在服务器
Accept：可处理的媒体类型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的内容编码
Accept-Language：可接受的自然语言
c、响应首部字段（响应报文会使用的首部字段）
Accept-Ranges：可接受的字节范围。体现一个html页面，返回了多少字节，
Location：令客户端重新定向到的URI。 证明这个请求是重定向。
Server：HTTP服务器的安装信息
d、实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）
Allow：资源可支持的HTTP方法
Content-Type：实体主类的类型
Content-Encoding：实体主体适用的编码方式
Content-Language：实体主体的自然语言
Content-Length：实体主体的的字节数
Content-Range：实体主体的位置范围，一般用于发出部分请求时使用
8、TCP三次握手
因为不存在完全可靠的通信协议.所以要通过客户端和服务端多次确认和链接之后，才进行数据的传输。
一句话总结：请求---》应答---》再次确认
详细
第一次握手：建立连接，客户端发送同步序列编号J（syn包）到服务器，并进入请求链接状态（syn_sent）.
第二次握手：服务器收到同步序列编号 j(syn包)，然后通过同步序列编号j+1 生成确认字符（ack包=j+1），进行确认上一次链接的同步序列编号（syn包）。同时服务器也生成一个同步序列编号 k (syn=k)并把同步序列编号k加ack包发送给客户端，并进入一个等待客户端返回确认字符ack包的状态（syn_recv状态）。
如果服务器上出现大量的SYN_RCVD状态的TCP连接说明这些连接一直没有收到ACK包，这主要有两种可能，一种是对方（请求方或客户端）没有收到服务器发送的[SYN,ACK]包，另一种可能是对方收到了[SYN,ACK]包却没有ACK。
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
9、TCP四次挥手
一句话总结：确保数据能够完整传输，所以搞了四次之后才终止 TCP链接。
是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。
（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
10、网络OSI七层模型
1、应用层，
2、表示层（数据处理），
3、会话层（管理会话），
4、传输层（管理链接），
5、网络层（IP选址路由选择），
6、数据链路层（链路管理），
7、物理层
巧记：应表会传网数物
TCP/IP 的四层结构图：应用层;传输层;互联层;链路层
11、软件测试基础理论
测试用例：描写规范的测试过程，目的避免漏测，重复性使用，测试确认，对象有程序，数据和文档，目的是审核产品的完成是否符合用户需求，提高用户体验，避免因为bug带来巨额损失。
测试用例要素（字段）：
1、用例ID、
2、模块名称
3、Case名称、
4、前提条件
5、测试步骤
6、期望结果、
7、用例版本
8、作者、
9、优先级、
10、实际结果、
11、备注。
测试分类：
按测试等级：单元测试、集成测试、接口测试、系统测试、验收测试
按测试方法：动态测试、静态测试、黑盒测试、白盒测试、灰盒测试
按测试类型：
1、安装测试
2、兼容性测试
3、冒烟与完整性测试
4、回归测试
5、验收测试
6、阿尔法α 测试
7、贝塔β测试
8、功能测试与非功能测试
9、持续性测试
10、破坏性测试
11、性能测试
12、可用性测试
13、可访问性测试
14、安全测试
15、国际化和本地测试
16、开发测试
17、A/B测试
18、并发测试
19、一致性或类型测试
重点：（黑白，冒烟，回归，兼容性、阿尔法α，贝塔β，测试用例的设计方法）
白盒：语句覆盖、判定逻辑覆盖，条件逻辑覆盖，判定逻辑条件覆盖、条件组合覆盖、路径覆盖
测试用例设计方法：等、边、错，因，判定(决策)、正交（过滤）、场景法（流程）、功能图
冒烟：类似一根烟的功夫就把软件的基本功能快速的测试了一遍，保证基本功能没问题！
回归：修改了旧代码，重新进行测试来确认是否引进新的bug。
阿尔法：用户在开发环境下进行的测试。
贝塔： 是一种验收测试，在最终用户的使用的复杂场景，进行测试。
12、你以前工作时的测试流程
我们的测试流程，一般有大的版本改动和新增模块时，会按照流程走。
1、需求梳理和功能清单的确认
2、需求评审是否有遗漏，模糊，错误等项目，发现问题及时和产品进行沟通
3、如果有历史Bug，讨论在新模块中是否有影响，是否要上新模块之前对历史Bug进行修复。
4、根据开发的排期，来安排测试的周期
5、对技术架构，方案，开发文档、UI设计进行评审，对开发的代码逻辑，整体效果，以及整体技术架构方案的优缺点进行深层次分析，降低风险。
6、写测试用例
7、进行测试用例评审
8、开发进行提交测试申请
9、执行测试
10、进行缺陷管理
11、输出测试报告，确认是否可以上线。
13、测试计划包含哪些内容
1、项目名称
2、编写人
3、编写时间
4、项目背景
5、编写目的
6、测试资源(软件 硬件 人力)
7、测试范围 （新增需求+全功能回归）
8、人员分工
9、测试目标
10、提测标准
11、测试结束标准
12、风险及预估
13、测试进度
14、测试策略
15、报告提交文档
14、Bug缺陷要素
1、bug 编号
2、bug标题
3、详细描述
4、测试模块
5、Bug优先级
6、出现范围和频率
7、测试人员
8、开发人员
9、测试时间
10、重现步骤
11、预期结果
12、测试结果
13、备注
14、log路径
15、测试资源
15、BUG的生命周期
1.New 新建
2. Open 打开
3. Assign 指派
4. Test 测试
5. Verified 确认
6. Deferred 延期
7. Reopened 重新打开
8. Duplicate 重复
9. Rejected 拒绝
10. Closed 关闭
1.新建：当缺陷被第一次递交的时候，它的状态即为“新建”。这也就是说缺陷未被确认其是否真正是一个缺陷。
2.打开：在测试者提交一个缺陷后，测试组长确认其确实为一个缺陷的时候他会把状态置为“打开”
3.分配：一旦缺陷被测试经理置为“打开”，他会把缺陷交给相应的开发人员或者开发组。这时缺陷状态变更为“分配”。
4.测试：当开发人员修复缺陷后，他会吧缺陷提交给测试组进行新一轮的测试。在开发人员公布已修复缺陷的程序之前，他会把缺陷状态置为“测试”。这时表明缺陷已经修复并且已经交给了测试组。
5.已核实：一但缺陷被修复它就会被置为“测试”，测试员会执行测试。如果缺陷不再出现，这就证明缺陷被修复了同时其状态被置为“已核实”。
6.延迟的：缺陷状态被置为“延迟的”意味着缺陷将会在下一个版本中被修复。将缺陷置为“延迟的”原因有许多种。有些由于缺陷优先级不高，有些由于时间紧，有些是因为缺陷对软件不会造成太大影响。
7.再次打开：如果缺陷被开发人员修复后仍然存在，测试人员会把缺陷状态置为“再次打开”。缺陷即将再次穿越其生命周期。
8.重复提交：如果同一个缺陷被重复提交或者两个缺陷表明的意思相同，那么这个缺陷状态会被置为“重复提交”
9.不接受的：如果开发人员不认为其是一个缺陷，他会不接受。他会吧缺陷状态置为“不接受的”
10.关闭：一但缺陷被修复，测试人员会对其进行测试。如果测试人员认为缺陷不存在了，他会把缺陷状态置为“关闭”。这个状态意味着缺陷被修复，通过了测试并且核实确实如此。
16、测试报告
1、项目背景、
2、测试环境
3、测试内容、
4、测试范围、
5、测试版本记录、
6、BUG统计、
7、测试通过标准、
8、测试评估、
9、测试需求覆盖率、
10、测试总结。
17、app的测试点
1、安装
2、卸载
3、启动
4、升级
5、功能点（写测试用例之前，要对一个产品的所有功能点进行梳理）
6、业务逻辑
9、性能 (APP冷启动打开比较慢超过5分钟，用户就会卸载他。不会用了。)
10、各种网络状态下的测试 （我们要测试2G，3G，4G，wifi，低速网络，不稳定网络，各种制式联通，移动的网络下软件是否能正常稳定运行。）
11、服务端接口测试 （特别重要，因为现在的互联网项目，前后端都是靠接口交互和传输数据的。）
12、数据对比测试。
13、中断测试 （中断测试，来电了不中断程序运行，只有提示才是正确的，如果来个电话就中断了我们的程序就是有bug的。）
14、app切换测试 （如果切换过程中app打不开了，崩溃，闪退了，就是bug，也是不允许的）
15、关机、待机查看app的状态（不停的关机，和待机，来查看APP的状态是否正常初始化，不产生任何异常，）
16、兼容性测试 *（构造不同手机设备，小米的，华为的，xxx，不同的手机系统版本，安卓系统班，从4.4到8.2,）还得构造不同容量，手机有运行内存，空间大小。
去购买市场上，销量前20的品牌手机，或者从公司同事手里协调，去使用云平台（百度MTC,阿里testin）。
17、app在清空数据，或者强制退出是否还能正常运行
18、app对资源的占用 。（app的大小，app安装之后，对运存的占用，如果一个app就占用了一个手机的一半内存，就是有bug的，）
app安装包大于200MB，app一运行就占用一半内存，bug的原因，内存泄露。
19、app对手机本身的权限。（测试要站在用户的角度来思考问题，和设计测试用例）
20、长时间运行app，是否有异常情况出现。 （压力测试一个体现，也是可靠性测试。）
21、多语言和地区设置
22、后台多任务切换和异常测试
23、手势冲突测试
24、用户体验测试
25、及时显示和同步消息的测试
26、app支持的多种文件格式的测试。
27、app在高内存占用的情况下测试。
18、移动端和Web端兼容性测试
对于web端而言，兼容性测试就是测试各种浏览器上和系统上之间是否有不兼容等问题或软件问题。
对于移动端而言，主要兼容手机的型号，操作系统，厂商，分辨率，网络是否兼容
移动端进行兼容兼容以下几个方面，网络兼容：弱网，4G，wifi，主流品牌：小米，苹果，华为等。
系统版本，安卓的7.0，8.0，9.0，苹果的10.0，11.0分辨率：5.0，5.5，6.0等
Web端的兼容性主要因为其内核的差异性，兼容我们的ie Win7 、8.0 ,版 10、 11、12 自带的版本，火狐64，谷歌 72 360 苹果safari 5.34 H5手机浏览器网站 uc 百度 QQ 自带
19、谈谈你职业生涯中遇到最难的 BUG
以前遇到一个 bug ，是因为有一个控件虽然显示上隐藏了，但如果按到那个区域，还是会产生响应。而且如果刚好和另一个没有隐藏的控件同时按，会引起 app 崩溃。
通过和开发一起抓日志进行定位。发现底层系统，因为资源不够使用，发生争抢导致，死锁等问题而崩溃。
20、测试结束标准是什么？
测试用例执行完毕，代码覆盖率达到95%以上，缺陷全部关闭并确保无误。
[规定用于暂停全部或部分与本计划有关的测试项的测试活动的标准。规定当测试再启动时必须重复的测试活动。]
1) 软件系统在进行系统测试过程中，发现一、二级缺陷数目达到项目质量管理目标要求，测试暂停返回开发；
2) 软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据；
3) 如有新的需求变更过大，测试活动应暂停，待原测试计划和测试用例修改后，再重新执行测试；
4) 若开发暂停，则相应测试也应暂停，并备份暂停点数据；
5) 所有功能和性能测试用例100％执行完成；
此外，测试是有成本的，当你2周发现2个bug有类似此种情况时，在产品质量要求不是十分严格的情况下，即可以停止测试了。
单元测试退出标准
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%
注：这只是一套比较理想化的退出标准，但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是100%。现在的军方标准是达到99%。对于通用软件来说就要根据公司实际情况了。
21、你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？
因为我们是测试人员一定要坚持自己的观点，和要有敏锐的洞察力和分析能力，首先要第一时间抓出这个Bug的详细日志，以及BUG依据（截图，录屏操作），以及记录重现步骤，以及它的复现频率。根据它复现的频率和范围，来判断这个Bug的等级。如果他还不认为是一个bug，我们就行使测试的权利，在证据面前让他们承认这是bug，然后Bug等级、用户体验和是否影响其他模块，跟相关开发和产品经理讨论，是否进行修复。在测试的立场上，我们坚决不放过一个bug。在测试工作过程中，我们必须时时刻刻保持着高度严谨的态度。对事不对人的原则，我们是整个产品的检察官、
22、请列举测试手机客户端视频观看功能时都需要考虑哪些方面
0、 视频资源可以正常获取
1、 关闭打开播放器
2、 上一个视频，下一个视频
3、 音量大小调节，静音
4、 视频最大化，最小化切换测试、半屏和全屏的切换测试
5、 快进退后按键、暂停、播放进度条
6、 视频频率大小、
7、 兼容性测试（ 兼容性测试，验证平台，系统版本是否能正常播放，与其他类型播放器是否兼容）
8、 视频的标准，高清，蓝光切换，流畅度，播放效果。
9、 文件格式（不支持，是否有相应提示）
10、播放错误，不影响其它媒体文件播放
11、是否能播放不完整文件
12、是否能打开多个播放器
13、记忆播放进度，记忆以前的播放列表
14、在不同客户端上观看同一个媒体文件。
15、画面移动、
16、播放视频速度倍数、
17、片尾片头、
18、截图录屏、
19、网络连接、
20、播放时上下滚动页面。
21、播放列表播放顺序的验证，播放列表添加，删除，查看功能。
22、播放时，杀掉进程，重新进入，查看播放进度。
23、兼容性测试，验证平台，系统版本。
24、横竖屏切换测试
25、视频中断测试
26、视频易用性测试
27、一次性添加多个文件到播放列表，看播放器的反应时间。
28、播放大容量视频文件，看加载时间和是否能正常播放
29、播放时，是否可以修改媒体文件相关属性。
30、播放时，客户端是否支持静默升级。
31、能否播放被隐藏的文件
32、拍摄视频
33、拍摄清晰度测试
34、卡顿测试
35、草稿测试
36、时间精准测试
37、播放视频
38、播放秒开测试
39、卡顿测试
40、清晰度测试
41、音画同步测试
42、播放秒开测试
43、播放器测试
44、解码性能，软解硬解
45、预加载、IP直出等策略测试
46、预加载时机、不同网络下的预加载
47、竞品对比测试
48、相同的场景、网络情况，对比竞品
49、自动化测试
50、UI自动化，接口自动化
51、清晰度测试
52、全参考清晰度测试
53、计算清晰度值，使用PSNR/SSIM/自研算法
54、各阶段视频编码参数测试对比
55、三个阶段：
录制视频
合成视频
后台转码视频
56、AI评测清晰度，监控外网过虑模糊视频
23、fiddler原理是什么，怎么抓取手机上的数据包？
Fiddler是一个代理服务器，可以拦截请求以及返回的数据，进行一系列的调试、修改和mock数据。
抓取手机上的数据包呢，首先配置Fiddler服务器可以远程抓取数据包，然后配置手机端的代理服务器的ip地址为fiddler的服务器地址还有8888端口号，然后在手机端的浏览器访问Fiddler服务器进行安装证书,就可以进行抓取了。
24、如果让你测app的升级，你怎么测，写出测试点？
1. 正常的下载升级过程，升级之后查看升级的功能是否可用，且原版本的功能是否正常
2. 考虑iOS和安卓的下载渠道不同
3. 考虑网络的影响：2G/3G/4G wifi下是否都能正常升级或者能够基于流量的影响进行智能下载
4. 考虑中断下载和升级过程后是否和继续或者重新下载和升级，手动中断后可以继续进行相关操作
5. 考虑断电和内存不足的问题能够继续进行相关升级，对于内存有友好的提示
6. 考虑应用权限问题：如果新版本对于应用权限有了扩展，需要进行权限确认
7. 考虑不同机型：升级测试需要对各种机型进行覆盖测试
8. 选择升级情况下旧版本的兼容性
如果不是强制升级，那新旧版本的app同时运行时必不可少的，此时需要考虑新旧版本并行时后台接口的兼容性。在进行旧版本功能兼容性验证时，可以进行主要流程的测试和变更的接口影响到的功能详细验证，这样可以缩小测试范围，减少测试时间同时又能保证相应的变更都进行了测试。
9. 覆盖升级后新版本的使用情况
10. 除了新版本自身的新功能验证之外，要进行主要业务流程的验证。
11. 在覆盖升级前，需要模拟使用旧版本的用户进行缓存数据的创建，然后进行升级，确认缓存数据升级后可以正常显示，相关功能工作正常。
25、针对目前常见的手机验证码 你会如何进行测试？
1、在输入正常手机号情况下，能否发送验证码，且验证码是否可用；
2、验证码是否可重复使用；
3、输入错误验证码；
4、超时后再输入验证码；
5、输入错误手机号，能否发送验证码；
6、验证码多久能再次发送； 且再次发送后是否还能再用上一次的验证码；
7、断网情况下是否可发送验证码；
26、怎么拿到手机上的log日志？
这里用到的是adb logcat 来进行APP运行日志的抓取。
27、什么是monkey测试，使用monkey测试主要做什么。
常用的Monkey命令参数的意义？
monkey测试是Android平台自动化测试的一种方法，通过monkey程序来模拟用户真实行为，对设备上的程序进行施压。
monkey主要就是用于对Android平台进行模拟用户的按键，触屏，手势输入等随机流的一种稳定性测试，看多久会出现异常。
常用的参数：
1、p: 指定被测的包名
2、throttle：在事件之间插入固定延迟。通过这个选项可以减缓Monkey的执行速度。如果不指定该选项，Monkey将 不会被延迟，事件将尽可能快地被产成。
3、pct-touch ： 调整触摸事件的百分比。
4、pct-motion ：调整动作事件的百分比。
5、pct-nav ： 调整“基本”导航事件的百分比。
6、pct-trackball ：调整轨迹事件的百分比
28、怎么判断一个bug 是前端代码问题还是后端接口问题？
前端主要是指客户端层面的问题， 后端主要是指提交后服务器处理返回及数据库交互层面的问题；
例：可以从请求跟响应这一过程判断，如果前端已经把数据发送给了后端，后端没有返回数据则是后端问题；
如果前端在用户输入数据之后发送请求，前端没有带数据在请求中就是前端的问题
29、Web测试和移动端测试有什么区别？
从功能测试方面的来看，在流程和功能测试上是没有区别的。
先来web和app的区别，web项目，一般都是b/s架构，基于浏览器的，而app功能测试则是c/s的，必须要有客户端。那么在系统测试测试的时候就会产生区别了。
首先从系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。其次在性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。
在兼容方面，web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。
相比较web测试，app更是多了一些专项测试，比如一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。
其中弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。
web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。
而对界面操作上，现在app产品的用户都是使用的触摸屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，事件触发区域等测试。
30、在智能手机(android)上安装客户端的过程中需要注意哪些方面(写测试点)？
1）安装的版本是否对应；
2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。
3）软件安装向导的UI测试
4）软件安装过程是否可以取消，点击取消后软件安装的情况。
5）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
6）安装空间不足时是否有相应提示
7）安装后没有生成多余的目录结构和文件
8）对于需要通过网络验证之类的安装，在断网情况下尝试一下
9）安装后再次安装，或者app更新安装
10）还需要对安装手册进行测试，依照安装手册是否能顺利安装
11）安装时对app的说明，例如版本号、适合安装的手机系统版本要求等
12）安装时获取的一些权限，例如摄像头、录音等
13）安装后再次安装，或者app更新安装
14）安装后app的图标，名称显示
15）安装过程中的提示信息正常
卸载
1）直接删除安装文件夹卸载是否有提示信息。
2）测试系统直接卸载程序是否有提示信息。
3）测试卸载后文件是否全部删除所有的安装文件夹。
4）卸载过程中出现的意外情况的测试（如死机、断电、重启）。
5）卸载是否支持取消功能，单击取消后软件卸载的情况 。
6）系统直接卸载UI测试，是否有卸载状态进度条提示 。
7）卸载后是否有残留文件夹
31、接口测试
1.什么是接口？
外部系统与系统之间以及内部各个子系统之间的交互点，通过这些交互点来进行数据之间的交互。
2.接口都有哪些类型？
程序内部的接口（方法与方法之间，模块与模块之间的交互）、系统对外的接口（可以获取第三方接口的功能，以及共享给你的数据服务。）
3、接口的分类
webservice接口、http api接口
webService接口是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。
http api接口是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。
json是一种通用的数据类型，所有的语言都认识它。（json的本质是字符串，他与其他语言无关，只是可以经过稍稍加工可以转换成其他语言的数据类型，比如可以转换成Python中的字典，key-value的形式，可以转换成JavaScript中的原生对象，可以转换成java中的类对象等。）
4、接口的本质及其工作原理是什么？
接口你可以简单的理解他就是URL，工作原理就会说URL通过get或者post请求像服务器发送一些东西，然后得到一些相应的返回值，本质就是数据的传输与接收。
5、什么是接口测试？
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
6.为什么要做接口测试？
①.越底层发现bug，它的修复成本是越低的。
②.前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。
③.检查系统的安全性、稳定性，前端传参不可信，比如京东购物，前端价格不可能传入-1元，但是通过接口可以传入-1元。
④.如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。
⑤. 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
⑥. 现在很多系统前后端架构是分离的，从安全层面来说：(1)、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。
7.怎样做接口测试？
首先要依据接口文档进行测试。
由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
也可以用 接口自动化来实现，就是用代码实现，框架和UI自动化差不多，发送请求用断言来判断。
8.接口测测试点是什么？
目的：测试接口的正确性和稳定性；
原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；
重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；
核心：持续集成是接口测试的核心；
优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显（提高测试效率，提升用户体验，降低研发成本）；
用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统接口（验证系统处理后的数据是否正常）；
PS：设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能，外部用户真正需要什么功能；
1、基本功能测试：
由于是针对基本业务功能进行测试，所以这部分是两种测试重合度最高的一块，开发同学通常所指的也主要是这部分的内容。
2、边界分析测试：
在基本功能测试的基础上考虑输入输出的边界条件，这部分内容也会有重复的部分（比如业务规则的边界）。但是，前端的输入输出很多时候都是提供固守的值让用户选择（如下拉框），在这种情况下测试的边界范围就非常有限，但接口测试就不存在这方面的限制，相对来说接口可以覆盖的范围更广，同样的，接口出现问题的概率也更高。
3、性能测试：
这个比较容易区分，虽然都需要做性能测试，但关注点确大不相同。App端性能主要关注与手机相关的特性，如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别，所以这部分内容是需要分开单独进行测试的，理论上来说这也是不同的部分。
综论：
1、接口测试和app测试的活动有部分重复的内容，主要集中在业务功能测试方面。除此之外，针对各自特性的测试都不一样，需要分别进行有针对性的测试，才能确保整个产品的质量。
2、接口测试可以关注于服务器逻辑验证，而UI测试可以关注于页面展示逻辑及界面前端与服务器集成验证
3、接口测试持续集成：
对接口测试而言，持续集成自动化是核心内容，通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化，主要应用于回归阶段，后续还需要加强自动化的程度，包括但不限于下面的内容：
a) 流程方面：在回归阶段加强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化。
b) 结果展示：更加丰富的结果展示、趋势分析，质量统计和分析等
c) 问题定位：报错信息、日志更精准，方便问题复现与定位。
d) 结果校验：加强自动化校验能力，如数据库信息校验。
e) 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提高代码覆盖率。
f) 性能需求：完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。
4、接口测试质量评估标准：
a) 业务功能覆盖是否完整
b) 业务规则覆盖是否完整
c) 参数验证是否达到要求（边界、业务规则）
d) 接口异常场景覆盖是否完整
e) 接口覆盖率是否达到要求
f) 代码覆盖率是否达到要求
g) 性能指标是否满足要求
h) 安全指标是否满足要求
9.接口测试都要掌握哪些知识？
①了解系统及内部各个组件之间的业务逻辑交互；
②了解接口的I/O（input/output：输入输出）；
③了解协议的基本内容，包括：通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等；
④常用的接口测试工具，比如：jmeter、loadrunner、postman、soapUI等；
⑤数据库基础操作命令（检查数据入库、提取测试数据等）；
⑥常见的字符类型，比如：char、varchar、text、int、float、datatime、string等；
如何学这些技能？
①系统间业务交互逻辑：通过需求文档、流程图、思维导图、沟通等很多渠道和方式；
②协议：推荐《图解http》这本书，内容生动，相对算是入门级的书籍，其他的还有《图解tcp、IP》等；
③接口测试工具：百度这些工具，然后你会发现，好多的教学博客、相关问题解决方案、以及一些基于工具的书籍，当然，选择合适的书很重要；
④数据库操作命令：学习网站（W3C、菜鸟教程）、教学博客，以及一些数据库相关书籍，入门级推荐：《mysql必知必会》、《oracle PL/SQL必知必会》等
⑤字符类型：还是百度，有句话这么说：内事不决问百度，外事不决问Google。。。
如何获取接口相关信息？
一般的企业，都会由开发或者对应的技术负责人员编写接口文档，里面会注明接口相关的地址、参数类型、方法、输入、输出等信息，如果没有，想办法获取。。。
接口文档八要素：
封面：封面最好是本公司规定的封面，有logo，内容标题，版本号，公司名称，文档产生日期；
修订历史：表格形式较好些，包括：版本、修订说明、修订日期、修订人、审核时间审核人等；
接口信息：接口调用方式，常用的GET/POST方式，接口地址；
功能描述：简洁清晰的描述接口功能，比如：接口获取的信息不包括哪些；
接口参数说明：每个参数都要和实际中调用的一样，包括大小写；参数的含义言简意赅的说明，格式，是string 还是int 还是long等格式；
说明部分，说明参数值是需要哪里提供，并详细说明参数怎么生成的，例如时间戳，是哪个时间段的，参数是否必填，一些参数是必须要有的，有些是可选参数等；
返回值说明：
①最好有一个模板返回值，并说明每个返回参数的意义；
②提供一个真实的调用接口，真实的返回值；
调用限制，安全方面：
加密方式，或者自己公司一个特殊的加密过程，只要双方采用一致的加密算法就可以调用接口，保证了接口调用的安全性，比如常见的md5；
文档维护：文档在维护的时候，如有修改一定要写上修改日期，修改人，对大的修改要有版本号变更
10、webservice接口怎么测试：
它不需要你在拼报文了，会给一个webservice的地址，或者wsdl文件，直接在soapui导入，就可以看到这个webservice里面的所有接口，也有报文，直接填入参数调用，看返回结果就可以了。
11、什么情况下开展接口测试？
1.项目处于开发阶段，前后端联调接口是否请求的通？（对应数据库增删改查）--开发自测
2.有接口需求文档，开发已完成联调（可以转测），功能测试展开之前
3.专项测试：如测流量大小，查看图片压缩大小，测试接口请求响应时间
4.版本上线前，进行整体回归测试，查看接口是否有异常（如404等）。对准备上线的版本进行抓包，查看服务器地址是都正确
5.版本功能稳定后，接口自动化
6.还可以应用在安全测试，性能测试领域等。。
12、根据接口文档进行测试
功能: 发送信息HTTP请求方式:GET/POST请求 URL http://localhost:8080/sms/mt.jsp?cpName=用户账号&cpPwd=用户密码&phones=号码&msg=内容
返回结果：
参数名称 类型 描述返回描述 String 发送成功返回0，如果发送不成功，则返回“ERROR&&对应的错误信息”
接口测试用例设计
接口测试是无界面的功能测试，设计用例思路跟功能测试一样（只是一个注重的是测前端页面，一个注重的是测后端接口）
1.输入参数测试： 针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长；
2.功能测试：接口是否满足了所提供的功能，相当于是正常情况测试
3.异常场景，如：请求超时、快速连续点击、请求失败情况（任务型的，失败后是否可以重新下发任务）
13、接口测试经常遇到的bug和问题？
（1）传入参数处理不当，导致程序crash；
（2）类型溢出，导致数据读出和写入不一致；
（3）因对象权限未进行校验，可以访问其他用户敏感信息；
（4）状态处理不当，导致逻辑出现错乱；
（5）逻辑校验不完善，可利用漏洞获取非正当利益等。
14、接口功能测试要点
单接口测试：
1. json格式测试：
通常我们的接口一般设计的都是传递json串，那么就需要去测试
如果传递非json的情况，这时候程序会不会正确的处理，返回相应的error code
2. 默认值测试：
很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量，
默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。
3. 异常类型测试：
比如上面的count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以
转换为int类型值来测试代码是否加入判断
4. 必传项测试：
如果接口的参数有必传项，那么需要测试在不传这个参数的时候接口返回情况，测试是否会提示
相应的error code
5. 非必传项测试：
如果接口有非必填项，当我不传递这些参数的时候会不会正常的返回相应的结果
6.非空测试：
无论是必传的和非必传的参数，传递的key是正确的，但是value=null，这时候返回结果是否正确
7.业务逻辑测试：
传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行
增删改的操作，也需要看数据库是否同步进行了这些操作
8.兼容性测试：
比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式
9.错误码测试：
通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况
10.数据异常测试：
假如数据库设计为32位varchar类型，那么如果传33位会是什么情况，会不会抛出相应的错误码，而不会抛出数据库异常
11.返回值测试：
返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析
12.加密测试：
15、组合接口测试（场景测试）
单个的接口测试通过后，需要将单个的接口组成连续的场景，比如说投资接口需要用到一个类似token的
参数，而这个参数是登陆接口获取到的，所以就需要先调用登陆接口，然后再去调用投资接口。还有就是
像数据权限与操作权限这些，都会依赖一些其他的接口，那么把这些依赖的接口组成一个场景来测试数据的
正确性。还有一部分接口是内部调用的，比如说注册接口，在注册的时候通常需要获取一个验证码，然后输入
验证码再进行提交注册的操作，在这过程中，验证验证码的操作是在注册的内部完成的，那么其实在组合场景
的时候就不需要再去中间加入验证验证码的接口。
16、请简单解释下如何做好接口测试？
1、接口正确性是双方保障，都要进行测试
2、根据接口类型，合理进行测试分析，注意测试重点
3、注重业务逻辑分析，包括正向反向操作
4、注重数据文件检查
5、接口测试的工具
17、请简述接口测试的作用有哪些？
天生为高复杂性的平台带来高效的缺陷监测和质量监督能力；平台越复杂，系统越庞大，接口测试的效果越明显（提高测试效率，提升用户体验，降低研发成本）
18、简述下接口测试的作用和优势有哪些？
1. 提升测试效率：底层的1个bug能引发上层的8个bug
2、能快速定位bug：直接根据哪个接口出问题了就能找到问题根源
3、定位安全缺陷
4、定位性能缺陷
19、web接口测试中需要测试的几个点
1、接口返回
数据格式是否与预期一致。
2、接口数据处理的正确性
数据库插入、修改、删除是否成功。
3、容错处理
参数传值错误时，接口是否能给出相应的返回。
4、参数边界值处理
如传递的参数足够大或为负数时，接口是否可以正常处理。
5、安全
如对外暴露的接口，这点尤为重要！
6、性能
是否能满足性能需求。
7、敏感数据的是否经过处理
例如传递交易密码、登录账号等等。
20、如何根据接口，判断是前端的问题还是后端的问题？
找出接口文档，fiddler查看请求参数和响应结果。
若是调用接口传参有误，导致问题，前端的问题
若是传参正确，返回结果异常，后端的问题
若是返回值异常值前端没做异常处理，前端同时也有问题。
这些都可以通过fiddler打断点，修改请求参数、响应参数来测试验证
本质是拆分每一步，查证每一步谁有问题，从源头找出问题
21、请写出接口测试的流程？
工作流程如下：
需求讨论、需求评审、场景设计、用例设计、数据准备、执行
具体的接口测试流程如下：
模拟客户端连接服务器
客户端发送报文请求
服务器端接收请求并做处理
检查返回的预期结果并与实际结果对比
接口测试报告
22、写出接口测试与功能测试的区别与联系?
区别：
功能测试，一般指的是业务上的功能，而不是接口功能。
接口测试是针对一个接口实现的功能以及接口内部逻辑进行测试。
接口测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
联系：
有的接口功能单一，有的接口功能复杂， 针对功能复杂的接口，可以按照其功能点拆分测试。接口应该是业务逻辑的最小单元。接口可能包含了内部逻辑测试和接口功能测试。当然只有接口功能正确的实现了，我们才有可能去集成业务功能测试。
23、请简述AppScan的工作原理？
AppScan，其安装在 Windows 操作系统上，可以对网站等 Web 应用进行自动化的应用安全扫描和测试。
通过探索发现整个web应用结构，根据分析，发送修改的http request进行攻击尝试（扫描规则库），通过对于Response的分析验证是否存在安全漏洞
24、在真正开始接口测试之前，我们需要做哪些准备工作？
了解系统及内部各个组件之间的业务逻辑交互，
了解协议的基本内容，
数据库基础操作命令，
常用的接口测试工具
25、请简述你对jmeter、postman、appscan是如何理解的？
都是测试工具，jmeter更倾向于接口性能测试，postman倾向于接口功能。Web是安全测试工具。
26、请简述你知道的几种安全测试的类型
用户程序安全：系统中不同用户权限、会不会出现用户冲突、用户登陆密码是否是可见、可复制等
系统网络安全：模拟非授权攻击，看防护系统是否坚固；采用各种木马检查工具检查系统木马情况等
数据库安全：系统数据是否机密；系统数据的完整性；系统数据可备份和恢复能力。
27、postman进行http接口测试的优点是什么?
1、支持用例管理
2、支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能
3、支持批量运行
4、支持用例导出、导入
5、支持云端保存用例【付费用户】
28、同一个项目android和ios 测试时会有什么区别？
1. 手机操作系统，Android较多，ios较少且不能降级，只能单向升级；新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用，低版本ios系统中的应用调用了新的资源库，会直接导致闪退（Crash）；
2. 操作习惯：Android，Back键是否被重写，测试点击Back键后的反馈是否正确；应用数据从内存移动到SD卡后能否正常运行等；
3. push测试：Android：点击home键，程序后台运行时，此时接收到push，点击后唤醒应用，此时是否可以正确跳转；ios，点击home键关闭程序和屏幕锁屏的情况（红点的显示）；
4. 安装卸载测试：Android的下载和安装的平台和工具和渠道比较多，ios主要有app store，iTunes和testflight下载；
5. 升级测试：可以被升级的必要条件：新旧版本具有相同的签名；新旧版本具有相同的包名；有一个标示符区分新旧版本（如版本号），对于Android若有内置的应用需检查升级之后内置文件是否匹配（如内置的输入法）
29、简述参数化与关联和区别？
关联也属于参数化，但是一般的参数化来源于一个文件、一个table、通过sql写的结果集，而关联所获取的的参数是服务器响应请求所返回的一个符合条件的动态的值。
30、Web安全测试通常要考虑的测试点
1、输入的数据没有进行有效的控制和验证
2、用户名和密码
3、直接输入需要权限的网页地址可以访问
4、认证和会话数据作为GET的一部分来发送
5、隐藏域与CGI参数
6、上传文件没有限制
7、把数据验证寄希望于客户端的验证
8、跨站脚本（XSS）
9、注入式漏洞（SQL注入）
10、不恰当的异常处理
11、不安全的存储
12、不安全的配置管理
13、传输中的密码没有加密
14、弱密码，默认密码
15、缓冲区溢出
16、拒绝服务
31、postman返回数据的格式有哪几种，如何设置请求的body？
Pretty、RAW、Preview
Pretty可以看到格式化后的JSON，Raw就是未经处理的数据，Preview可以预览HTML页面
有四种方式进行设置： form-data、 urlencoded、raw 以及 binary
form-data是网页表单用来传输数据的默认格式
urlencoded同前面一样，注意,你不能上传文件通过这个编码模式。
Raw raw request可以包含任何东西。所有填写的text都会随着请求发送。
binary image, audio or video files.text files 。 也不能保存历史，每次选择文件，提交。
32、SQL注入是什么？
SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
33、你们性能测试如何做的？
1、首先需要了解性能测试需求，明确测试目的，获得有效的性能需求；
2、编写性能测试计划方案；
3、搭建性能测试环境，准备性能测试数据，相关资源准备；
4、录制性能测试脚本，对脚本进行优化调整；设计测试场景，执行性能测试并收集测试结果，分析结果系统调优及回归测试；
5、性能测试通过后编写性能测试报告；
34、性能测试的并发数是怎么算出来的？
参考答案：根据系统的访问用户数，一个用户的访问时长，和系统的运行时长；
根据C = nL/T来计算平均的并发用户数
例：假设有一个OA系统，该系统有3000个用户（可以看注册信息），平均每天大约有400个用户要访问该系统（日志文件查看），对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），可以得到：
C = 400*4/8 = 200
C’≈200+3*根号200 = 242
35、你们一般用多少用户做并发？
参考答案：我们要确定系统并发用户数，一般情况下需要先确认需求，如果需求不明确，首先需要去找相关人员调研，去获取系统的访问用户数，和系统的业务使用情况
36、性能测试指标都包括哪些
参考答案： 响应时间、吞吐量、TPS、点击率、事物成功率、服务器（CPU、内存、IO）；
37、简述下性能测试的步骤
1、需求分析（挖掘出关键业务的接口和操作逻辑）
2、性能指标制定（预期值，例如1000个并发用户，平均响应时间在1秒之内，超过这个就是bug。）
3、脚本开发（代码或者工具，一般都是选择用工具Jmeter来进行测试）
4、场景设置（场景用于模拟用户实际业务操作。工具就是调试Jmeter符合关键业务的场景。设置并发数，添加参数，设置参数值等，）
5、监控部署（一般企业都会有运维搭建的一套监控系统，可以监控软硬件服务器日志啊、数据库，缓存、中间件、Tomcat、jvm、硬件服务器的cpu、内存、磁盘IO等详细使用情况已报表展现出来。
6、测试执行（开始执行Jmeter配置好的脚本）
7、性能分析（通过监控部署，运维的监控系统的报表以及详细的硬，软服务器的日志，可以分析出来哪些地方性能比较差。超出了我们的预期）
8、性能调优（根据分析的结果，例如mysql连接数少了，通过调优mysql的连接数来进行优化，然后在进行测试，分析，调优一个循环的过程，直到达到我们的预期）
9、性能测试报告（把jmeter跑出来的监控图表，运维监控系统的数据和图表，以及各项关键的性能指标，以及我们对此次的结论，把性能的情况，以及是否满足上线的条件以邮件的形式发给领导）
38、 一个页面性能要求页面响应时间不能超过2秒，测一下系统支持的并发量，怎么进行测试？
1、先需要跑一个基准测试，根据系统特点，先跑一个基准并发用户量；
2、再根据基准并发的结果来逐渐的加大或减少用户，直到跑到达到响应时间不能超过2秒的要求的最大范围；
39、性能指标都有哪些？
重点关注： API接口、数据库的性能~
具体详细的性能指标单位毫秒：
缓存响应时间、外部服务器响应时间、数据库调用时间、应用层时间、吞吐率、 内存使用量、CPU使用率、慢事务、最耗时事务、错误率。
并发用户数：同一单位时间内对系统发起请求的用户数量。比如一秒内。
吞吐量：一次性能测试过程中网络上传输、下载的数据量的总和。
吞吐率： 吞吐率在性能测试中指单位时间内在网络上传输的数据量。是衡量网络性能的主要指标（公式：吞吐量 / 传输时间 （单位时间内网络上传输的数据量））
TPS ：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
QPS ：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
点击率 ：每秒钟用户向服务器提交的请求数。
资源使用率 : 对不同系统资源的使用情况，如CPU,内存，磁盘IO
举例MySQL数据库的的QPS和TPS计算公式：
TPS（ 事务数/秒） = (Com_commit + Com_rollback) / Seconds 就可以计算数据库TPS的指标。
Com_commit: mysql数据库执行事务提交的次数 .Com_rollback:myslq数据库执行回滚的次数。
QPS（ 查询量/秒） = (Q2 - Q1)/10 间隔10秒查询两次并记录Q1，Q2，以此计算出QPS值
Q2 、Q1 :是已经发送给MySQL服务器的查询的个数。
移动端性能指标：
activity的启动时间， 电量使用情况、流量(上传，下载)、FPS值、CPU使用率、内存使用率、CRASH（崩溃）、ANR（应用无响应）、卡顿的次数。
通过腾讯GT、网易Emmagee 性能测试工具，云管理系统用来收集崩溃信息（https://www.bugtags.com/）进行实时跟踪用户的操作过程以及收集所产生的日志。
也可以通过自动化的方式，通过写Python脚本调用ADB调试命令，获取移动终端的信息，应用的信息进行统计分析出报表
部门内容来源：
32、当我们登陆请求成功之后，并不跳转到成功页面，是什么原因？
首先我们要分析是后台跳转 还是js跳转。如果是后台代码有可能是上下文环境以及路径配置错误，js的话有可能是后台传过来的json数据格式不正确，或者js语法有问题。
我们要分析登陆的后台代码，和前台js代码的逻辑进行分析！
33、如何定位前后台的Bug？
我们定位一个bug是前台还是后台问题的话一般都是用fiddler工具来做，它可以设置请求断点和响应断点查看请求数据和响应数据，从而分析数据是前台出错还是后台出错，如果是请求数据和前台输入的一致，说明前端没有问题，如果说请求数据和前端输入的不一致，那就是前端问题了，不过我们公司患有一种方法来检测前端还是后台出错，我们会准备两台手机，一台安卓，一台ios，做相同的操作，安卓出错的话就是安卓前端的问题，苹果前端出错的话就是苹果前端问题，如果都出错了，那基本就可以断定是后台出错了
34、你是如何进行弱网测试的？
首先判断弱网测试对象是在PC端？App端？还是Web端？然后再针对性选择测试方式与工具。
1.PC端应用，之前做游戏测试的时候用Network-Emulator-Toolkit，建立连接后设置UpStream和DownStream；
2.App端应用，常用的就是fiddler，自定义延迟，通过网络模拟设定参数。或者找个网络信号差的地方实操下，地下车库、封闭电梯看看这种网络环境下的表现；
3、Web端的话就用Chrom自带的开发者工具，Network自定义选择。
35、说说进程和线程关系及区别。
进程有点像操场，带了很多跑步用的设置，而线程像赛道，可以多个并行跑，并一起公用进程里面的资源。
共用不好就会死锁。
我们的测试点就是，测试一个应用程序在多并发的时候，是否会死锁
36、请问你一般如何做测试分析？
作为一名QA，需要对需求文档进行分析看它是否有遗漏、模糊、错误等，发现问题及时和产品沟通。
然后对历史遗留的Bug ，以前发生过解决了，或者没解决的我们要重点关注，如果是新需求，新模块的内容和之前大部分一致，并且在之前版本出现过的bug，特殊规则，注意事项等，要及时和开发回顾和讨论解决方案。（尤其是项目里新加入的新手开发的时候）
然后我们要确定开发的提测日期，根据提测日期我们测试的排期，用例的编写，测试数据的构造，测试环境的搭建、测试资源的准备等。一旦开发正式提测，我们就可以正式进入测试阶段，测试过程中发现的bug，进行严格管理和跟踪以及关闭，到灰度以及最终的验收，保证项目稳稳的上线。以及上线前期的持续跟踪！
37、软件测试的策略有哪些？
简单答： 软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束
而规定的软件测试的原则、方式、方法的集合。
测试策略是描述测试项目和测试任务之间的关系。它用来说明要测什么，如何测，如何协调测试资源和测试时间等。
测试策略制定的是否合理高效会对测试项目的进度产生很大的影响。那么，如何制定一个好的测试策略并且能防止遗漏呢？一个好的测试策略又包含哪些方面呢
1. 测试安排、发布计划
2. 测试范围（按优先级排列）
3. 测试资源
4. 测试环境
5. 测试方法
6. 用例设计方法
7. 文档管理
8. 风险管理
9. 发布包验证
38、如何梳理测试点
首先有一定的业务能力（懂内部构造）对需求理解透彻
测试经验足够，作为测试，从（页面样式，默认显示，边界值，交互效果，规则，异常，安全）方面进行检验。
组内各抒己见完善测试点。
APP常见测试点总结：
1.安装、卸载测试
主要针对编译后源程序生成的APK安装文件。
主要测试点：a.生成的APK文件在真机上可以安装及卸载；
b.Android手机端的通用安装工具，如：豌豆荚及91助手等工具可以正常安装及卸载程序。
2.在线升级测试
测试点：a.验证数字签名 b.升级后可以正常使用 c.在线跨版本升级
3.业务逻辑测试
业务逻辑测试：主要测试客户端业务能否正常完成
功能点测试：主要测试客户端功能点是否正常使用
关联性测试：主要测试客户端与PC端的交互，客户端处理完后，PC端与客户端数据一致
4.异常测试
主要包含了断网、断电、服务器异常等情况下，客户端能否正常处理，保证数据正常性。
5.交互性测试
客户端作为手机特性测试，包含被打扰的情况13种，来电，来短信，低电量测试等，还要注意手机端硬件上，如：待机，插拔数据线，耳机等操作不会影响客户端。
6.易用性测试
界面与交互性测试：符合android交互规范，符合用户使用习惯，操作方便简单，具有一致性。
可用性测试：用户体验好，用户操作方便，用户使用错误率低。
7.适配测试
手机不同分辨率支持：客户端支持800*480,960*540,1920*1280等；
手机不通版本的支持：4.0, 5.0, 6.0；在测试计划中，需要安排单独的时间用于android不同系统的兼容性测试，包括7.0版本等；
手机不同厂家系统的支持：不同厂家会有不同android系统，例如：小米收，华为输入法。是市场主流的系统及厂家不同型号的支持；
手机不通尺寸的支持：4.0到7.0屏幕在UI显示有区别的，要支持最大到最小。
解决方案：
a.自行购买或者使用借来设备来实际验证。耗费资金，购买几台。
b.第三方云测试的解决方法。
c.整理不兼容的地方，然后去分析app总可能不兼容的代码。对技术能力的要求比较高，前期也需要花费不少的时间。
d.利用友盟等第三方统计平台获得应用对应的TOP N 的记性重点进行测试。
8.客户端侧性能测试
偏重客户端侧CPU、MEM、流量、电量以及客户端在不同网络环境下响应速度等等。
大数据的测试：主要在特定环境下，客户端一次性更新大量的数据，客户端能否正常处理，分为三种情况：
a.客户端第一次使用，的一次就更新大量数据
b.客户端在平时更新中，更新大量的数据
c.客户端已经在手机本地下载很多数据后，再次更新大量数据。
9.电量与流量测试
手机的电量及流量测试主要是为了站在用户角度思考，毕竟电量、流量消耗比较大，会影响客户的使用感受。手机端量使用是和CPU使用率成正比的。由于这个没有比较详细的规定，只能出一个通用范围。CPU使用率不能超过10%以上，流量不要超过10M以上。一般通过android手机端一些监控软件获取数据。
当然也可以通过代码打点获取。
10.内存泄漏测试
OutOfMemory。
11.外网与场景测试
主要是模拟客户使用网络环境，检验客户端程序在实际网络环境中使用情况及进行业务操作。外网测试主要覆盖到wifi3G4G、netwap、电信移动联通，所有可能的组合进行测试。
原则：a.尽可能全面覆盖用户的使用场景，测试用例中需要包含不同网络排列组合的各种可能； b.模拟信号被屏蔽时候，客户端的影响等； c.做外部场景测试，在高山、丘陵、火车上等特殊环境下进行全面测试。
12.APP性能测试分类
客户端：
a.应用测试（关注CPU、MEM、流量、GPU等）
b.ROM测试
c.其他（web页面，现在APP大多都是web页面）
服务器端：性能测试方法和WEB差不多
tips：客户端的测试其实比较推荐专用的硬件设备来，这样测出的数据更加准确，比如高速相机、功耗仪等
13.APP自动化测试分类
UI(robotium、Appium等)
接口
单元（junit、Robolectric等）
持续集成
tips：一句话，对编程要求高，逻辑性思维要求高
14.测试启动时间
a.代码里插入时间并打印Log.e
b.命令方式
adb shell
am start -W -n 包名/activity名
-W是指启动完成之后，返回启动耗时
c.秒表、高速相机
d.adb logcat
adb logcat >d:log.txt
启动应用，待加载完成后ctrl+c停止
find "Displayed" d:log.txt>d:log1.txt
find "包名" d:log1.txt>d:]log2.txt
15.代码静态扫描
代码扫描工具Lint，它能非常容易得帮米找出代码上的结构问题
具体的检察规则可以自定义（局部，全局）
lint --list 获得检查项id和简要说明
lint --show xxx 获得详细说明
jenkins：持续版本构建，与lint搭配使用
lint:检查已有规则规范
findbugs：针对java平台代码的检查
16.traceview
手机root，代码中埋点，加SD卡读写权限。通过monitor.bat打卡.trace文件。
Debug.startMethodTracing("路径"); //在oncreate方法中，开始埋点
Debug.stopMethodTracing(); //ondestroy中，结束
17.手机电量测试
a.利用硬件设备：比如耗电量测试仪
b.第三方软件来检测：手机自带电量监控、360助手、GT等
c.命令方式（5.0以上版本）
//初始化batterystats数据
adb shell dumpsys batterystats --reset
//得到整个设备的电量消耗信息
adb shell dumpsys batterys > /storage/sdcard0/Download/b1.txt
//得到指定app相关的电量消耗信息
adb shell dumpsys batterystats 包名 > /storage/sdcard0/Download/b1.txt
18.测试流量
流量分两种：a.操作app b.不操作app
测试方法：
a.各类云测平台、DDMS的Network
b.命令（模拟器不支持，某些真机不支持）
ps | grep com.android.browser 获取pid
cat /proc/pid/status 获取uid
cat /proc/uid_stat/uid/tcp_snd 发送的流量byte
cat /proc/uid_stat/uid/tcp_rcv 接受的流量byte
c.android自带api
long uidrx=TrafficStats.getUidRxBytes(10053); //10053表示uid
d.抓包（最好用root真机练习）
通过tcpdump抓包，再通过wireshark直接读取报信息来获取流量
19.GPU
通过开发者模式-》显示GPU过度绘制
20.CPU
a.第三方工具、各类云测平台
b.dumpsys命令
adb shell dumpsys cpuinfo | grep com.android.browser > /storage/sdcard0/Download/cpu.txt
c.top命令
adb shell top | grep com.android.browser > /storage/sdcard0/Download/cpu.txt
tips：关注活动状态和静默状态下的情况
21.线上监控的方法
a.第三方的标准化的开源、商业产品，如Nagios、zabbix、Ganglia、百度统计等
b.自主研发的监控手机平台
c.APM，比如听云
d.用户反馈
app埋点监控测试：如友盟
作者：gantao754246624
原文：https://blog.csdn.net/gantao754246624/article/details/77985073
APP测试基本流程
APP测试点
1.2测试周期
测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即15个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。
1.3测试资源
测试任务开始前，检查各项测试资源。
--产品功能需求文档；
--产品原型图；
--产品效果图；
--行为统计分析定义文档；
--测试设备（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）；
--其他。
1.4日报及产品上线报告
1）测试人员每天需对所测项目发送测试日报。
2）测试日报所包含的内容为：
--对当前测试版本质量进行分级；
--对较严重的问题进行例举，提示开发人员优先修改；
--对版本的整体情况进行评估。
3）产品上线前，测试人员发送产品上线报告。
4）上线报告所包含的内容为：
---对当前版本质量进行分级；
---附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果）；
--总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。
2 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 Berry OS 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）菜单层次是否太深
5）交互流程分支是否太多
6）相关的选项是否离得很远
7）一次是否载入太多的数据
8）界面中按钮可点击范围是否适中
9）标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换
10）操作应该有主次从属关系
11）是否定义Back的逻辑。涉及软硬件交互时，Back键应具体定义
12）是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计
2.11 硬件环境测试
2.11.1手势操作测试
1）手机开锁屏对运行中的App的影响
2）切换网络对运行中的App的影响
3）运行中的App前后台切换的影响
4）多个运行中的App的切换
5）App运行时关机
6）App运行时重启系统
7）App运行时充电
8）App运行时kill掉进程再打开
2.11.2网络环境
手机的网络目前主要分为2G、3G、wifi。目前2G的网络相对于比较慢，测试时尤其要注意此块的测试。
1) 无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash。
2) 内网测试时，要注意选择到外网操作时的异常情况处理。
3) 在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash。
4) 在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据交换失败时要给予提示。
5) 在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他操作的情况，有无异常情况。此问题也会经常出现程序crash。
2.11.3服务器宕机或出现404、502等情况下的测试
后台服务牵涉到DNS、空间服务商的情况下会影响其稳定性，如：当出现域名解析故障时，你对后台API的请求很可能就会出现404错误，抛出异常。这时需要对异常进行正确的处理，否则可能会导致程序不能正常工作。
2.12接口测试
服务端一般会提供JSON格式的数据给客户端，所以我们在服务端需要进行接口测试，确保服务端提供的接口并转换的JSON内容正确，对分支、异常流有相应的返回值。此块测试可以采用itest框架进行测试。最方便的是采用httpclient进行接口测试。
进行服务端测试时，需要开发提供一份接口文档。
2.13客户端数据库测试
1）一般的增、删、改、查测试。
2） 当表不存在时是否能自动创建，当数据库表被删除后能否再自建，数据是否还能自动从服务端中获取回来并保存。
3） 在业务需要从服务端取回数据保存到客户端的时候，客户端能否将数据保存到本地。
4） 当业务需要从客户端取数据时，检查客户端数据存在时，app数据是否能自动从客户端数据中取出，还是仍然会从服务器端获取？检查客户端数据不存在时，app数据能否自动从服务器端获取到并保存到客户端
5） 当业务对数据进行了修改、删除后，客户端和服务端是否会有相应的更新。
-------------------
作者：一枚IT程序媛
原文：https://blog.csdn.net/suizhituan8337/article/details/8059625
WEB测试点
前言
前面一篇文章讲解了app测试一些功能点。那么相应的也梳理一下web测试相关的功能的测试点吧，此篇文章只是给你们一个思路，如果要涉及web端每个测试点，基本不可能实现的，所以只是提供一个设计的思路，希望能够开阔你们的视野，使你们走的更远。来，直接上干货吧！
一、输入框
1、字符型输入框：
（1）字符型输入框：中文，英文全角、英文半角、数字、空或者空格或者回车、特殊字符（~！@#￥%……&*？[]{}”（特别要注意单引号和&符号））。禁止直接输入特殊字符时，使用”复制+粘贴”功能尝试输入。
（2）长度检查：最小长度、最大长度、最小长度-1、最大长度+1、输入超长字符比如把整个文章拷贝过去。
（3）空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格
（4）多行文本框输入：允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）
（5）安全性检查：输入特殊字符串（null,NULL, ,javascript,<script>,</script>,<title></title>,<html></html>,<td></td>）、输入脚本函数(<script>alert("abc")</script>)、doucment.write("abc")、<b>hello</b>、sql注入）
2、数值型输入框：
（1）边界值：最大值、最小值、最大值+1、最小值-1
（2）位数：最小位数、最大位数、最小位数-1、最大位数+1、输入超长值
（3）特殊字符：输入空白（NULL）、空格或"~!@#$%^&*()_+{}|[]:"<>?;',./?;:'-=等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等
（4）异常值：输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）
（5）安全性检查：不能直接输入就copy，输入内容如上
3、日期型输入框：
（1）合法性检查：(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30][31]、输入非闰年，月输入[2]，日期输入[28、29]、输入闰年，月输入[2]、日期输入[29、30]、月输入[0、1、12、13]
（2）异常值、特殊字符：输入空白或NULL、输入~！@#￥%……&*（）{}[]等可能导致系统错误的字符
（3）安全性检查：不能直接输入，就copy，是否数据检验出错
4、信息重复：在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理
二、搜索功能
若查询条件为输入框，则参考输入框对应类型的测试方法
1、功能实现：
（1）如果支持模糊查询，搜索名称中任意一个字符是否能搜索到
（2）比较长的名称是否能查到
（3）输入系统中不存在的与之匹配的条件
（4）用户进行查询操作时，一般情况是不进行查询条件的清空，除非需求特殊说明。
（5）拼音查询
2、组合测试：
（1）不同查询条件之间来回选择，是否出现页面错误（单选框和多选框最容易出错）
（2）测试多个查询条件时，要注意查询条件的组合测试，可能不同组合的测试会报错。
三、添加、修改功能
1、特殊键：（1）是否支持Tab键 （2）是否支持回车键
2、提示信息：（1）不符合要求的地方是否有错误提示
3、唯一性：（1）字段唯一的，是否可以重复添加，添加后是否能修改为已存在的字段（字段包括区分大小写以及在输入的内容前后输入空格，保存后，数据是否真的插入到数据库中，注意保存后数据的正确性）
4、数据正确性：
（1）对编辑页的每个编辑项进行修改，点击保存，是否可以保存成功，检查想关联的数据是否得到更新。
（2）进行必填项检查（即是否给出提示以及提示后是否依然把数据存到数据库中；是否提示后出现页码错乱等）
（3）是否能够连续添加（针对特殊情况）
（4）在编辑的时候，注意编辑项的长度限制，有时在添加的时候有，在编辑的时候却没有（注意要添加和修改规则是否一致）
（5）对于有图片上传功能的编辑框，若不上传图片，查看编辑页面时是否显示有默认的图片，若上传图片，查看是否显示为上传图片
（6）修改后增加数据后，特别要注意查询页面的数据是否及时更新，特别是在首页时要注意数据的更新。
（7）提交数据时，连续多次点击，查看系统会不会连续增加几条相同的数据或报错。
（8）若结果列表中没有记录或者没选择某条记录，点击修改按钮，系统会抛异常。
四、删除功能
1、特殊键：（1）是否支持Tab键 （2）是否支持回车键
2、提示信息：（1）不选择任何信息，直接点击删除按钮，是否有提示（2）删除某条信息时，应该有确认提示
3、数据 实现：（1）是否能连续删除多个产品（2）当只有一条数据时，是否可以删除成功 （3）删除一条数据后，是否可以添加相同的数据（4）如系统支持批量删除，注意删除的信息是否正确 （5）如有全选，注意是否把所有的数据删除（6）删除数据时，要注意相应查询页面的数据是否及时更新 （7）如删除的数据与其他业务数据关联，要注意其关联性（如删除部门信息时，部门下游员工，则应该给出提示）（8）如果结果列表中没有记录或没有选择任何一条记录，点击删除按钮系统会报错。
如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
单项功能测试（增加、修改、查询、删除）
增加——>增加——>增加 （连续增加测试）
增加——>删除
增加——>删除——>增加 （新增加的内容与删除内容一致）
增加——>修改——>删除
修改——>修改——>修改 （连续修改测试）
修改——>增加（新增加的内容与修改前内容一致）
修改——>删除
修改——>删除——>增加 （新增加的内容与删除内容一致）
删除——>删除——>删除 （连续删除测试）
五、注册、登陆模块
1、注册功能：
（1）注册时，设置密码为特殊版本号，检查登录时是否会报错
（2）注册成功后，页面应该以登陆状态跳转到首页或指定页面
（3）在注册成功后，删除注册的账号，检查是否可以注册成功
（4）注册已注册的账号，检查是否可以注册成功
（5）改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分）
（6）看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示
（7）对于账号输入与密码输入运用等价类、边界值写就好了，这里不再累述
2、登陆功能：
（1）输入正确的用户名和正确的密码
（2）输入正确的用户名和错误的密码
（3）输入错误的用户名和正确的密码
（4）输入错误的用户名和错误的密码
（5）不输入用户名和密码（均为空格）
（6）只输入用户名，密码为空
（7）用户名为空，只输入密码
（8）输入正确的用户名和密码，但是不区分大小写
（9）用户名和密码包括特殊字符
（10）用户名和密码输入超长值
（11）已删除的用户名和密码
（12）登录时，当页面刷新或重新输入数据时，验证码是否更新
六、上传图片
（1）上传各种主流的图片格式文件
（2）上传非图片格式的文件
（3）上传图片文件的大小，几k，上百k，到几兆，几十兆
（4）上传正在被其他应用使用的图片文件
（5）上传的手动输入上传地址
（6）上传地址输入不存在的图片地址
（7）上传地址输入图片名称来上传
（8）不选择文件直接点击上传，查看是否给出提示
（9）连续多次选择不同的文件，查看是否上传最后一次选择的文件
（10）同时上传多张图片文件
七、查询结果列表
（1）列表、列宽是否合理
（2）列表数据太宽有没有提供横向滚动
（3）列表的列名有没有与内容对应
（4）列表的每列的列名是否描述的清晰
（5）列表是否把不必要的列都显示出来
（6）点击某列进行排序，是否会报错（点击查看每一页的排序是否正确）
（7）双击或单击某列信息，是否会报错
八、界面和易用性测试
1、风格、样式、颜色是否协调
2、界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条
3、界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字）
4、操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作）
5、提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等）
6、界面中各个控件是否对齐
7、日期控件是否可编辑
8、日期控件的长度是否合理，以修改时可以把时间全部显示出来为准
9、查询结果列表列宽是否合理、标签描述是否合理
10、查询结果列表太宽没有横向滚动提示
11、对于信息比较长的文本，文本框有没有提供自动竖直滚动条
12、数据录入控件是否方便
13、有没有支持Tab键，键的顺序要有条理，不乱跳
14、有没有提供相关的热键
15、控件的提示语描述是否正确
16、模块调用是否统一，相同的模块是否调用同一个界面
17、用滚动条移动页面时，页面的控件是否显示正常
18、日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX
19、页面是否有多余按钮或标签
20、窗口标题或图标是否与菜单栏的统一
21、窗口的最大化、最小化是否能正确切换
22、对于正常的功能，用户可以不必阅读用户手册就能使用
23、执行风险操作时，有确认、删除等提示吗
24、操作顺序是否合理
25、正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
26、系统应该在用户执行错误的操作之前提出警告，提示信息.
27、页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
28、合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
29、检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业
九、兼容性测试
兼容性测试不只是指界面在不同操作系统或浏览器下的兼容，有些功能方面的测试，也要考虑到兼容性，包括操作系统兼容和应用软件兼容，可能还包括硬件兼容。比如涉及到ajax、jquery、javascript等技术的，都要考虑到不同浏览器下的兼容性问题。
十、链接测试
主要是保证链接的可用性和正确性，它也是网站测试中比较重要的一个方面。
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到30k以下。
（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。
十一、业务流程测试（主要功能测试）
业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的数据进行测试。
十二、安全性测试
（1）SQL注入（比如登陆页面）
（2）XSS跨网站脚本攻击：程序或数据库没有对一些特殊字符进行过滤或处理，导致用户所输入的一些破坏性的脚本语句能够直接写进数据库中，浏览器会直接执行这些脚本语句，破坏网站的正常显示，或网站用户的信息被盗,构造脚本语句时，要保证脚本的完整性。
document.write("abc")
<script>alter("abc")</script>
（3）URL地址后面随便输入一些符号，并尽量是动态参数靠后
（4）验证码更新问题
（5）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（6）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（7）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（8）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（9）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
（10）用户名密码传输过程中是否加密传输。
十三、测试中应该注意的其他情况
1、在测试时，与网络有关的步骤或者模块必须考虑到断网的情况
2、每个页面都有相应的Title，不能为空，或者显示“无标题页”
3、在测试的时候要考虑到页面出现滚动条时，滚动条上下滚动时，页面是否正常
4、URL不区分大小写，大小写不敏感
5、、对于电子商务网站，当用户并发购买数量大于库存的数量时，系统如何处理
6、测试数据避免单纯输入“123”、“abc“之类的，让测试数据尽量接近实际
7、进行测试时，尽量不要用超级管理员进行测试，用新建的用户进行测试。测试人员尽量不要使用同一个用户进行测试
8、提示信息：提示信息是否完整、正确、详细
9、帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
10、可扩展性：是否由升级的余地，是否保留了接口
11、稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
12、运行速度：运行的快慢，带宽占用情况
作者：丨Fighter.Lu丨 点滴记录，开源共享。帮助更多有需要的人解决问题！博主博客地址：http://www.cnblogs.com/fighter007/
39、什么是关联 手动关联和自动关联的区别，如何进行Jmeter的参数关联？
关联： 第二个请求提交的参数要从第一个请求的返回数据中获取。
在LR中有自动关联跟手动关联，但在我看来手动关联更准确，在jmeter中，就只有手动关联。
在Jmeter中关联一般都是在获取数据的请求上，右键 -->后置处理器，选择正则表达式提取器，提取出其他接口想要的参数，在使用时用${}，用美元符号和大括号来引用提取的参数。
40、 在 windows 下保存一个文本文件时会弹出保存对话框，如果为文件名建立测试用例，等价类应该怎样划分？
单字节，如 A；
双字节， AA、我我；
特殊字符 /‘。‘；、=-等；
保留字，如 com；
文件格式为 8.3 格式的；
文件名格式为非 8.3 格式的；
/,,*等九个特殊字符。
假设有一个文本框要求输入 10 个字符的邮政编码，对于该文本框应该怎样划分等价类？
特殊字符，如 10 个*或￥；
英文字母，如 ABCDefghik；
小于十个字符，如 123；
大于十个字符，如 11111111111；
数字和其他混合，如 123AAAAAAA；
空字符；
保留字符
41、如果有机会转成开发人员，你会去做开发工作吗？
如果公司确实需要我可以从事开发，但我还是喜欢做测试，我认为我更适合做测试。
42、给你一个网站，你如何测试？
首先，查找需求说明、网站设计等相关文档，分析测试需求。制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
设计测试用例：
功能性测试可以包括，但不限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
提交功能的测试。
多媒体元素是否可以正确加载和显示。
多语言支持是否能够正确显示选择的语言等。
界面测试可以包括但不限于一下几个方面：
页面是否风格统一，美观
页面布局是否合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但未安装的控件，是否提供自动下载并安装的功能
文字检查
性能测试一般从以下三个方面考虑：
压力测试；负载测试；强度测试
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
安全性测试：
基本的登录功能的检查
是否存在溢出错误，导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如SQL注入等
如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
兼容性测试，根据需求说明的内容，确定支持的平台组合：
浏览器的兼容性；
操作系统的兼容性；
软件平台的兼容性；
数据库的兼容性
开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
定期评审，对测试进行评估和总结，调整测试的内容。
43、如何保证测试的整体覆盖率。
测试用例覆盖率很难达到100%，越复杂的功能越难保证，只能说尽量提高测试覆盖率，通过检查相关需求，设计文档是否有问题，然后整理成需要覆盖的功能列表或者思维导图，性能需求，兼容需求，都要列出来。
然后对新增，修改的以及现有的功能进行一个梳理，检查是否会与其他功能有交互，整理出影响点。然后把功能列表，发给组员，找时间进行会议评审，主要对功能进行查漏补缺，形成最终版本的CheckList列表。
最后才能进行测试用例的编写，一定要注意规范，然后在把用例发给组员进行用例的规范，检查点，测试点进行查漏补缺。在 执行测试用例的时候，发现用例错误，不完善，要及时修改，和调优，测试完毕后对遗漏的bug进行测试用例的补充，
44、集成测试的策略：
自顶向下，自底向下，广度优先、深度优先。
详细：1、大爆炸集成
2、自顶向下集成
3、自底向上集成
4、三明治集成适应于大部分软件开发项目
5、基干集成
6、分层集成
7、基于功能的集成
8、基于消息的集成
9、基于风险的集成
10、基于进度的集成
45、测试的六条基本法则是什么：
一功(功能)二可（可靠性）三效（效率）四易（易用性）五维（可维护性）六移（可移植性）
46、如何测试云音乐 网易app 语音识别功能？
功能描述：比如用户唱了首歌：快使用双截棍哼哼哈希， 网易云音乐app 要识别到并且播放歌曲。
1.针对输入源来测试：
（1）用户正常比较标准的哼唱，查看识别结果，并且能够点播；
（2）用户加了特效的哼唱，比如加了电音效果，查看识别结果；
（3）用户的哼唱咬字不清或者是错字，查看识别结果；
（4）用户的哼唱停顿点节奏不对，查看识别结果；
（5）用户的哼唱音调比较低，查看识别结果；
（6）用户的哼唱音调比较高，查看识别结果；
（7）还可以从用户哼唱的音色来看，音色明亮和低沉，查看识别结果；
（8）输入比较短的哼唱，比如1秒，查看识别结果；
（9）输入比较长的哼唱，就是哼唱的特别慢，查看识别结果；
2.对识别结果测试：
（1）对正常比较标准的哼唱输入，查看得到的结果，是否正确，是否模糊匹配到其它歌曲，准确度如何；
（2）对非正常的哼唱输入，结果显示如何，是否需要显示空白提示页
3.容错性和性能测试：
（1）哼唱的环境有比较多杂音，查看识别结果；
（2）哼唱的声音时大时小，查看识别结果；
（3）哼唱识别得到结果后，多次反复哼唱，查看是否每次都能够识别出结果；
4.兼容性测试：
（1）平台测试：iOS和Android；
（2）设备系统测试：iOS8-11系统，Android4.0-8.1等，具体得看需求支撑哪些系统；
（3）设备内存和存储等，如存储不够的时候，输入一段音频，是否会出现crash等；
（4）分辨率：手机不同分辨率，页面显示；这个也可以归为UI测试了。
可量化的标准数据测试：
语音采集：语音输入方式（人声、录音、广播等）、语音的类型（男生、女生、童声等）、不同语音环境（室外、室内、浴室、火车站、大厅等等），声音大小；
语音特征提取结果：不同采集的声音特征提取结果，是否可正常提取到特征值，声音识别率；
语音比对：比对速度、准确性；
性能数据：
乐库容量对识别速度和结果的影响数据；什么量级，什么结果；
服务器并发量；
兼容性：
方言识别；
47、语音识别怎么测试？
功能测试，我理解的语音大概分语音录制、解析、反馈。
录制的话跟硬件有关系，与设备的距离，说话的语速、时间长短
解析的话，录制的语言（不同语种国语、粤语、四川话、英语）解析、特殊名称、地名（相同名字的省、市、区、县）、常用词、口语等等
反馈，这个需要根据录制语音的内容，对话、提问、闲聊、命令，反馈的都不一样，多选答案什么的
当然还要做场景测试：比如网络，车载设备还要考虑各种车上的场景；内存/cpu、响应速度
功能业务测试组：
1、符合话题，正常表述完整
2、符合话题，正常表述5秒/10秒/30秒/60秒
3、符合话题，音量小
4、符合话题，环境噪音大
5、不符合话题，但正常表述
6、不符合话题，讲中文
7、完全非正常朗读（敲桌子声音，嘈杂讲话声等）。
48、有一个移动app 电影票，现有个活动，能以20%的价格买入1000张电影票，每人限购1张，作为测试负责人如何设计这个测试。
反问：如过我是测试的leader，那么我有多少人，分别是什么水平。然后我再去进行相关的测试设计
1、界面测试。 （HTML5的测试，大方向测的是它的兼容性，和某些资源的渲染速度）页面实时刷新的测试，界面的交互是否简单，提示是否友好，界面设计是否美观大方等等
2、兼容性测试。这个活动页面，在xxx手机显示不了。
3、提示信息：卖完，有提示信息，在次购买，有提示张数。限购提示信息，查上限1000张全部售出验证是否还可以继续购买。也有强制提示信息，只能购买一张
4、活动期限的测试。如果第二天还显示活动入口就是个bug。
5、安全测试：实名认证，手机验证码，IP限购，人脸识别，防止刷票。
6、1000人之前是否都已百分之20的钱进行购买，尤其是在并发的时候。
7、防止VIP优惠的基础上，购买优惠券，防止超低价格买入。
8、测试点：对优惠劵的退费流程的测试。
9、一共只有1000张20%价格的票，第1001张是否按原价出售了，买到第1000张的时候并发会不会有更多的人买到特价票。
10、20%这个折扣也需要测试，会不会有小数产生。
11、具体测试起来就多了，前台展示、后台接口、数据库、性能、中断、弱网等。
12、构造不同的用户，来检测到底是否已百分之20,
13、考虑并发，高峰等测试，加载Ｈ５页面的时间。
14、可靠性检查（模拟ｍｏｎｋｅｙ测试１００００次随机事件，来检查活动页面的可靠性）
15、服务器端检查（活动相关接口性能，接口的响应时间，平均时间等等。）
16、既然是活动，考虑活动时间范围检查。
17、检查前端提交的表单数据，数据方面的检查。数据对比测试，根据前台页面显示的结果跟实际后台数据库里面的数据进行对比。
18、活动相关接口性能，接口的响应时间，平均时间等等、
19、该活动界面的CPU,GPU，耗电量，流量消耗
20、弱网络，不同网络wifi,3G ,4G 浏览的情况
21、断网情况下的检查
22、提交按钮双击检查。
23、最好做下fiddler的抓包，篡改数据后重新发包，看后端的处理。
24、用户体验检查（因为是一个电影app的售票活动，用户应该基本是青年，首先定位，青年群体.）
25、比如混合去买活动＋非活动的票、买了退票，再买、比如我看完了，用完了，再买。
49、测试过程中遇到app出现crash或者ANR，你会怎么处理， Android 和 iOS 上是分别怎么抓取日志的
一般会出现Crash闪退的异常：数组越界、空引用、引用未定义方法、内存空间不足，存储空间不足。
可以先把日志过滤出来： 安卓就用adb logcat | findstr xxxxx(过滤日志信息) ，然后再搜索其中的关键字，IOS使用Xcode获取所有日志并进行过滤，或者直接从苹果手机设置-隐私-分析-分析数据。
比如：exception、crash，看看是那些方法或者异常导致了问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复。
50、微信和支付宝的步数谁更准，怎么测试，为什么？
每日凌晨数据初始清零开始计算。
行走1000米
正常人175cm，行走100米，测步记录三次。微信及支付宝分别记录。
A/B/C：
A：0开始，网络已连接，直线行走100米。
B：0开始，网络已连接，行走20米，断网，直线行走80米，连接网络。
C：0开始，网络断开，直线行走100米。
其他因素：
1.不同特征的人可能会产生不同的数据。
2.跑步、跳跃、小步走。
3.非直线路径、上坡，爬山。
可能都会导致数据统计不准确。
51、安卓应用或者游戏 启动时间如何测试。
一般最常用的是录屏，因为最接近用户感受，极限一点就叫开发打adb log。 或者通过这个 adb shell am start -W 获取冷热时间。
52、你觉得app的性能测试，即专项测试，需要重点关注那些方面？
CPU、内存、流量、电量、帧率/流畅度等等.
53、什么是灰度发布，什么是灰度测试？
灰度发布，又名金丝雀发布，或者灰度测试，是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。
灰度发布的意义
灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。
灰度发布步骤
定义目标
选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
产品完善
新一轮灰度发布或完整发布
54、产品上线后，用户发现了bug，应该怎么处理
1、测试人员复现问题后，提交问题单进行跟踪；
2、评估该问题的严重程度，以及修复问题时和影响范围，回归测试需要测试哪些功能；
3、问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4、总结经验，分析问题发生的原因，避免下次出现同样问题
55、产品上线后是如何跟踪的？
我们前期通过在产品内部通过打点的方式，监控用户体使用app过程中的出现的异常日志信息，以及统计用户经常使用哪些功能，用户的操作习惯和逻辑。对服务器接收到用户端的异常日志信息，要及时报警和监控，进行bug的复现，和具体的分析，到最终发布平滑稳定的解决方案，不给用户造成任何的困扰，并且有24小时的运营和IT远程技术支持人员，随时都可以响应用户的问题。
56、如果项目周期很短，测试人力匮乏，你是怎么协调的？描述下你团队的测试分工对于团队成员，你是如何打kpi的？
如果项目周期很短，测试人力匮乏，你是怎么协调的？
1. 测试有压力，开发必然有压力，和开发一起砍需求
2. 系分和测分增加投入，做更精准的测试
3. 测试提前进入
4. 加强开发自测，拉取开发交付用例
5. 加班
描述下你团队的测试分工
1. 业务压力大的时候，业务为主，技术为辅
2. 业务少的时候，技术为主，业务也不丢
3. 老人带新人，新人帮老人，选出业务领头人和技术领头人，形成团队梯队
对于团队成员，你是如何打kpi的？
1. 成员自评和一对一沟通，了解成员的想法
2. 对于老黄牛类型的，吃苦卖力但是没有突破的，给中等绩效
3. 对于老白兔类型的，混吃等死，计划淘汰
4. 对于独狼类型的，抢食，不听指挥的，果断淘汰
5. 对于头狼类型的，吃苦卖力，有惊喜，给优秀绩效
57、SQL说下左链接和右链接、什么是索引、使用SQL产生10万条数据。
左链接就是返回左表的全部数据以及右表满足条件的数据， 右链接与之相反。索引就是数据字典key，通过给字段加索引可以增加数据查询速度。
使用SQL产生10万条数据，一般有3种方案，
1、利用存储过程，利用变量和循环体，不断执行insert语句，但是效率较慢。
2、利用编程方式，利用高效率多线程编程算法，模拟大规模数据量瞬间插入的场景。推荐此种*（3秒--7秒之间可以插入几十万条数据。）
3、利用成熟的ETL工具（例如Kettle），来进行造数据等。
58、SQL语法的考察
SELECT DISTINCT 要查询的字段1，字段2 ------------要查询的字段。
FROM 表1，表2，表3 ---------具体查询的表名
WHERE 条件1 or / and 条件2 ----------条件查询
GROUP BY 需要分组查询的字段（男或者女） -----------分组查询
HAVING AVG(成绩)>=80 -----------分组过滤
ORDER BY 分数 ASC （升序） 或者 DESC （降序） -------------排序
Limit m,n 从m条到n条. ------------分页
子查询：
SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);
SELECT (SELECT s1 FROM t2) FROM t1;
SELECT * FROM t1 WHERE column1 = (SELECT MAX(column2) FROM t2); #= > < >= <= <> != <=>
SELECT s1 FROM t1 WHERE s1 > ANY (SELECT s1 FROM t2); 任何一个
SELECT s1 FROM t1 WHERE s1 > IN (SELECT s1 FROM t2); 里面的一个
SELECT s1 FROM t1 WHERE s1 > ALL (SELECT s1 FROM t2);
SELECT * FROM t1 WHERE (col1,col2) = (SELECT col3, col4 FROM t2 WHERE id = 10);
SELECT * FROM t1 WHERE ROW(col1,col2) = (SELECT col3, col4 FROM t2 WHERE id = 10);
SELECT column1,column2,column3 FROM t1 WHERE (column1,column2,column3) IN (SELECT column1,column2,column3 FROM t2);
多表连接：（找到table1，table2，table3）三个表中名称相同的字段进行关联。
SELECT 要查询的字段
FROM table1
LEFT JOIN table2
ON table1.id = table2.id
LEFT JOIN table3
ON table2.id = table3.id;
常用的函数 sum（）、 count（）、max（）、min（）、avg（），用在具体字段上。
1.用一条SQL 语句 查询出每门课都大于80 分的学生姓名
SELECT name
FROM grade
GROUP BY name
HAVING min( score)>80
2、查询一班得分在80分以上的学生
SELECT*
FROMstudent
WHERE score > 80
AND s_id IN ( SELECTs_id FROMstudent_class WHERE c_id = ( SELECTc_id FROMclass WHERE c_name = '一班' ) )
3、 查询所有班级的名称，和所有班中女生人数,和女生的平均分
SELECT c.c_name,count( s.s_id ),avg( s.score )
FROM class c
inner join student_class sc ON sc.c_id = c.c_id
inner join student s ONs.s_id = sc.s_id
WHERE s.sex = '女'
GROUP BYc.c_name
4、查询表中80分以上的学生信息 (姓名 分数 科目)
SELECT s.stuname, c.score, e.cname
FROM student s
Left JOIN sc c ON s.s_id = c.sid
Left JOIN course e ON e.cid = c.cid
WHERE c.score > 80;
59、Linux常考必会命令
|
1、cd
|
目录切换
|
|
2、ls
|
显示目录和文件列表
|
|
3、pwd
|
显示当前路径
|
|
4、mkdir
|
创建文件夹
|
|
5、cp
|
复制文件
|
|
6、touch
|
创建文件
|
|
7、rm -rf
|
强制删除文件
|
|
8、mv
|
移动文件和文件命名
|
|
9、find
|
查找
|
|
10、ln
|
创建链接（加-s是软连接，不加是硬链接）
|
|
11、du
|
查看文件目录大小
|
|
12、chmod
|
改变文件权限
|
|
13、tar
|
解压
|
|
14、tail
|
查看日志后几行（默认后10行，需要多少行使用-n选项）
|
|
15、head
|
查看日志前几行（默认前10行，需要多少行使用-n选项）
|
|
16、grep
|
内容过滤和搜索
|
|
17、sed
|
文本内容修改，增加、删除
|
|
18、ifconfig
|
查看ip
|
|
19、netstat
|
查看网络相关信息，例如端口，网络链接情况
|
|
20、SCP
|
远程文件传输
|
|
21、shutdown、poweroff
|
关机
|
|
22、su
|
切换账号
|
|
23、vi
|
本文编辑，wq保存，a插入、q! ：不保存退出，撤销：u 恢复：ctrl+r
|
|
24、ps -ef |grep java
|
查看java进程
|
|
25、kill -9 进程id
|
杀掉进程
|
|
26、date -s 日期时间
|
修改系统时间
|
|
27、df
|
查看磁盘使用情况
|
|
28、diff
|
查看两个文件内容不同的地方
|
|
29、free
|
查看内存占用
|
|
30、top
|
查看各个进程的资源占用情况，如CPU使用率，就是windows的任务管理器。
|
|
31、stat
|
显示文件详细信息
|
|
32、wc
|
统计文件内容数量，如行数、列数，文件中某个单词的出现的数量。
|
|
33、cut
|
可以按文件的行进行分隔，或者只展示某个字段，过滤作用
|
|
34、sort
|
对文件进行内容排序
|
|
35、mount
|
挂载硬盘
|
|
36、firewall
|
防火墙
|
|
37、split
|
将大文件分割成很多个小文件
|
|
38、nestat -antu | grep 端口号
|
查看端口是否被占用（状态为LISTEN表示被占用）
|
|
39、cat access.log|awk '{print $1}'|sort -n|uniq -c|sort -nr|head -5
|
查看日志里5个访问最频繁的IP
|
|
40、firewall-cmd --zone=public --list-ports
|
查看linux所打开的端口
|
|
41、firewall -cmd --zone=public --add-port=8080/tcp --permanent
|
打开8080端口
|
|
42、firewall-cmd --reload
|
更新防火墙规则
|
|
43、find . -type f -size +xxk
|
搜索大于xxkb的文件。 在linux 中如何查找大于5mb小于10mb的文件。-size+5M -size -10M、
|
|
44、scp -r /tmp/tempA/ wasadmin@10.127.40.25:/tmp/wang/
|
把当前文件夹tempA拷贝到 目标服务器10.127.40.25 服务器的 /tmp/wang/文件夹下，其中wasadmin是目标服务器的用户名，执行命令提示输入密码，然后输入密码即可
|
|
45、find . -name "*abc*" -type f -print -exec rm -rf {} ;
|
在linux 下如何删除当前目录及其子目录下所有文件名包含abc的文件
|
|
46、chmod u + x start.sh
|
将start.sh文件改为可执行权限
|
|
47、find -type f -print | wc -l
|
查找文件数量
|
60、ADB必会常考
1、链接逍遥游模拟器
adb connect 127.0.0.1:21503
2、查看连接的设备状态
adb devices
3、列出所有应用的package
adb shell pm list packages
4、根据产品关键英文单词，查找具体app的包名。
adb shell pm list packages | findstr tencent
5、只显示系统应用
adb shell pm list packages -s
6、只显示第三方应用
adb shell pm list packages -3
7、包名包含某字符串的应用
adb shell pm list packages tencent
adb shell pm list packages | findstr appium windows版本
adb shell pm list packages | grep appium linux版本
8、安装apk
后缀是.apk的文件，是安卓app的离线安装文件。就跟我们windows上的.exe文件是一样的。
adb install [-lrtsdg] <path_to_apk>
adb install -r c://zhihu1111.apk
|
参数
|
含义
|
|
-l
|
将应用安装到保护目录 /mnt/asec
|
|
-r
|
允许覆盖安装
|
|
-t
|
允许安装 AndroidManifest.xml 里 application 指定 android:testOnly="true" 的应用
|
|
-s
|
将应用安装到 sdcard
|
|
-d
|
允许降级覆盖安装
|
|
-g
|
授予所有运行时权限
|
9、清除应用数据与缓存
adb shell pm clear com.zhihu.android
10、卸载应用
adb uninstall com.zhihu.android
11、查看前台 Activity页面名称
adb shell dumpsys activity activities | findstr mFocusedActivity
返回的结果：com.tencent.mm/.ui.LauncherUI 斜杠左面的是包名，后面的是首页面activity的名称。
12、查看应用的详细信息
adb shell dumpsys package com.tencent.mm
输出中包含很多信息，包括 Activity Resolver Table、Registered ContentProviders、包名、userId、安装后的文件资源代码等路径、版本信息、权限信息和授予状态、签名版本信息等。
13、查看应用安装路径
adb shell pm path com.zhihu.android
Android系统的底层，封装的就是一个类似Liunx系统的微型控制系统。所以它大多数命令，都跟Linux命令很像，它的目录结构跟Linux也是一样的
14、启动app、停止app
启动：
adb shell am start -W -n com.zhihu.android/.app.ui.activity.MainActivity
ThisTime:最后一个启动的Activity的启动耗时； 跟淘宝，百度 这种公司的app 的thistime 做对比，如果这个值比他们的值，大好多，那就得报bug，app页面启动耗时太长，影响用户体验，导致用户流失，是个严重bug。
TotalTime:自己的所有Activity的启动耗时；（ 表示新应用启动的耗时，包括新进程的启动和 Activity 的启动
停止：
adb shell am force-stop com.zhihu.android （强制退出，不杀后台进程。）
15、广播
Android中广播的是操作系统中产生的各种各样的事件。例如，收到一条短信就会产生一个收到短信息的事件。而Android操作系统一旦内部产生了这些事件，就会向所有的广播接收器对象来广播这些事件。
adb shell am broadcast -a android.intent.action.BOOT_COMPLETED 关闭所有组件 ，相当于系统假装重启。
16、把移动设备里面的文件复制到电脑上。
pull：拉取的意思，从我们的手机或者模拟器里面，把文件拉取到本地，就是指我们的电脑。
adb pull /etc/ztloo22.txt c://logs
adb pull /sdcard/YK_ANR_Error.png c://log
17、把电脑上的文件移动到设备里面
adb remount 。意思是将设备改为可读可写
adb push c://logs/ztloo22.txt /etc/
18、操作按键
操作home键
adb shell input keyevent 3
操作返回键
adb shell input keyevent 4
增加音量
adb shell input keyevent 24
静音：
adb shell input keyevent 164
点亮屏幕：
adb shell input keyevent 224
熄灭屏幕：
adb shell input keyevent 223
19、电池状况 (性能测试领域，必测项目)
adb shell dumpsys battery
其中 scale 代表最大电量，level 代表当前电量。
20、获取屏幕参数
获取屏幕分辨率：
adb shell wm size
获取屏幕密度：
adb shell wm density
显示屏参数
adb shell dumpsys window displays
21、获取IMEI 号
在 Android 4.4 及以下版本可通过如下命令获取 IMEI：（通过IMEI分辨长相相同的手机）,其中的 Device ID 就是 IMEI。
adb shell dumpsys iphonesubinfo
22、获取安卓系统版本
adb shell getprop ro.build.version.release
23、获取内存信息
adb shell cat /proc/meminfo
其中，MemTotal 就是设备的总内存，MemFree 是当前空闲内存。
24、截图操作
adb shell screencap -p /sdcard/sy.png
25、录制屏幕
adb shell screenrecord /sdcard/zhihulz.mp4
录制屏幕以 mp4 格式保存到 /sdcard,需要停止时按 Ctrl-C，默认录制时间和最长录制时间都是 180 秒。
26、流量监控
adb shell ps | findstr com.android.browser
adb shell cat /proc/1242/net/dev （1242 是通过上一条命令获取的进程id）
27、cpu监控
// -d 1秒中的收集刷新频率 ，收集cpu信息到
adb shell top -d 2 | findstr browser >d:cpu1.txt
61、 直播平台的送礼物环节，关注点有哪些?
1、送小礼物后是否能在屏幕上看到送礼消息
2、送大礼物是否可以播放动画、动画是否流畅
3、送礼后账户余额是否扣除相应金额
4、可连续点击赠送的礼物，在余额不足时是否停止送礼并给出充值提示
5、送礼物过程中充值是否会中断画面、充值成功是否继续播放
看过的直播抽奖都是通过截屏来看的
所有只想到要验证截屏时观众看直播是否流畅、画面是否有卡顿、无声音现象
6、礼物的combo展示是否正常
7、送礼是否触发长链，触发后数据是消息体，数据是否正确
8、针对获取不到礼物后是否有默认icon
9、礼物列表打开后icon展示是否正常
10、不同礼物的展示效果是否正确
11、 接口容错
62、社交类APP的问题关键在于功能性的那些方面？
登录注册、定位服务、社交模块和个人信息管理模块都容易出现大量问题。
对于一般开发团队来说，深度全覆盖性的功能测试还是建议和第三方合作进行测试，这样来说效果才比较理想
63、一个测试工程师应具备那些素质和技能？
掌握基本的测试基础理论
本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现
可熟练阅读需求规格说明书等文档
以用户的观点看待问题
有着强烈的质量意识
细心和责任心
良好的有效的沟通方式（与开发人员及客户）
具有以往的测试经验
能够及时准确地判断出高危险区在何处.
64、 软件产品质量特性是什么? ?
功能性：适应性、准确性、互操作性、依从性、安全性。
可靠性：成熟性、容错性、以恢复性。
可使用性：易理解性、易学习性、易操作性。
效率：时间特性、资源特性。
可维护性：易分析性、易变更性、稳定性、易测试性。
可移植性： 适应性、易安装性、遵循性、易替换性。
65、一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别? ?
300 个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果，线程之间也会发生干扰，出现一些异常， 300 个用户在一个客户端上，需要更大的带宽。
IP 地址的问题，可能需要使用 IP Spoof 来绕过服务器对于单一 IP 地址最大连接数的限制。
所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置
66、软件测试分为几个阶段 各阶段的测试策略和要求是什么?
测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段
单元测试：
单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。
答：逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
集成测试：
集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在
产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开
发人员来完成的。
系统测试：
系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并
完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有
重大的影响。
验收测试：
验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。
对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功
能模块的全面测试，尤其要进行文档测试。
单元测试测试策略：
自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。
自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。
孤立单元测试策略：最好的单元测试策略。
集成测试的测试策略：
大爆炸集成：适应于一个维护型项目或被测试系统较小
自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经
常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系
统功能行为。
自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
基于进度的集成
优点：具有较高的并行度；能够有效缩短项目的开发进度。
缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。
系统测试的测试策略：
数据和数据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；强度测试；容量测
试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测
试；版本验证测试；文档测试
67、软件测试各个阶段通常完成什么工作？各个阶段的结果文件是什么？包括什么内容？
单元测试阶段：
各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进
行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷
报告。
集成测试阶段：
集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成
模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生
成集成测试报告，提交缺陷报告。
系统测试阶段：
将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持
软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功
能覆盖。该阶段需要提交测试总结和缺陷报告。
68、简述软件系统中用户文档的测试要点？
（1）读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位
（2）术语。文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
（3）正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
（4）完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
（5）一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
（6）易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。
（7）图表与界面截图。检查所有图表与界面截图是否与发行版本相同。
（8）样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。
（9）语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
（10）印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。
69、你为什么离开上家公司？离职原因
答案1：为了自己的职业发展，和能拿到更高的工资 , 逼迫自己成长，不想再一个没有任何挑战和竞争的环境里生存！
答案2：离家太远，当时为了照顾自己生病的妹妹，为了不影响公司的制度，和影响项目的进度，做完交接之后，进行主动请辞的！
70、你的测试职业发展目标是什么？
答案1：
我的职业发展 目标是，先做功能测试积累测试经验，因为这是测试的必经之路，然后是性能测试，对系统底层，IT架构有个全面的了解，做到极致之后，会往测试开发的道路发展。
因为测试开发具有诱人的薪酬，本身我又有不错的代码功底。之后我会去带新人，带团队，形成行业顶尖测试解决方案。降低各企业项目的质量风险 。
答案2：
测试经验够多，测试能力越高， 所以我的职业发展是需要进行时间积累的，一步步向着高级测试工程师发展。而且我也有初步的职业规划，
前三年积累测试经验，按如何做好测试工程师的标准要求自己，不断的更新自己，改正自己，做好测试任务。
71、你对我们公司了解有多少？
我对咱们公司有深入的了解，从公司的文化，起家，组织架构等，和公司各个成员。因为我特别喜欢你们公司的团队文化，以及项目的前景，特别期待加入我们这么优秀的团队，一起共事，一起打拼。
72、你认为做好测试计划工作的关键是什么？
坚持“5W”规则，明确内容与过程，采用评审和更新机制，保证测试计划满足实际需求。
73、你有什么优点和缺点？
我这个人非常挑剔，喜欢鸡蛋里挑骨头，做事情一板一眼，要做就做到极致，不想做就一点也不做，做工作的严谨性，有时候可能会给一些自私自利的同事，带来一些困扰，所以跟一部分同事处的很不融洽。
所以这也是我的缺点也是我的优点。工作时候有事说事，有问题解决问题，如果领导说错了，思想传递有误，我都会直接指出！
私下里我比较随性，娱乐，工作两不误，玩的时候不谈工作，工作时候不谈玩！
（按照自己的性格说就行，如上是作者个人真实答案，可能有些公司不喜欢）
74、为什么从开发转测试。
对开发代码能力这块很长时间没有提升，编程技术一直处于基础 ， 也会拖慢项目的进度，觉得开发不太适合我。
但是我这个人性格比较细心，逻辑严谨，喜欢检查东西，再加上我从小就喜欢check各种东西的习惯，给同事挑一挑代码上的逻辑，条件判断的问题。
我觉得测试更较适合我，在加上测试领域发展前景也不错，薪资也不低，后期也能发展也想往自动化测试，性能测试方向发展。
75、我们公司经常加班。你对加班怎么看？
答案：理解，任务没有完成或者要赶进度加班也是可以的，多劳多得，（我家里人很支持我的事业，不会反对我加班。加班对我成长有很大帮助，我不排斥）
76、你为什么选择我们公司？
答案:贵公司在行业内领先，我可以学到很多东西（贵公司处于发展期，我认为可以有很大的职业上升空间）
77、你能为我们做什么?
答案：我办事效率高，能提高贵公司测试项目的效益（我经验丰富，能提高贵公司测试项目的质量。）
我对管理流程很熟悉，能规范贵公司测试项目的流程。我开发能力强，对自动化又熟悉，能引进自动化技术，缩短测试周期。
78、你有什么要问的么？
不要问你多少钱，不要问人家公司规模，如果明知人家是中小型公司，还问，就是让人家尴尬！
1、我此次面试哪些地方有所欠缺呢？我回去好好补足这方面所欠缺的知识。
2、如果我入职了，我需要做哪些准备，
3、如果我一直在测试行业发展下去，您作为资深人士，能否给一些建议。
4、咱们公司的项目都运用了哪些技术架构！
79、你认为你做测试的优势在哪里？
答案：优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但我有信心在工作中发挥测试需要的基本技能。
80、如果开发人员时间安排有矛盾，或者开发延迟开发时间，你会怎么做
答案：加班把测试工作完成，或者和开发人员商量，让开发人员分担，目的只有一个，务必准时上线，事后，分析开发延迟原因，下次尽量避免类似事情发生。
81、请定义什么是bug。
答案：跟预期不符合，影响用户体验，造成财产，生命损失的。
82、什么是性能测试，什么是负载测试，什么是压力测试
答案：性能测试：通过自动化的测试工具模拟多种正常，峰值， 以及异常负载条件来对系统各项性能指标进行测试。
负载测试：是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试：是通过确定一个系统的瓶颈，或者不能接收的 性能点，来获得系统能提供的最大服务级别的测试。
83、什么时候可以开始执行性能测试
答案：在产品相对比较稳定，功能测试完成后，其灵活性比较强、
84、响应时间和吞吐量之间的关系是什么？
答案：吞吐量显示的是虚拟用户，每秒钟从服务器接收到的字节数，当和响应时间比较时，可以发现随着吞吐量的降低，响应时间也降低，同样，吞吐量的峰值和最大响应时间差不多在同时出现、
85、如果web服务器，数据库以及网络都正常。问题会出现在哪里。
答案：通过网络带宽，内存，存储，CPU分析，问题可能存在系统本身，或应用服务器，或为应用编写的代码中。
86、你是一个什么样的人？
答案：乐观、不斤斤计较，上进等。
87、你找工作时， 最重要的考虑因素是什么?
答案: 工作的性质和内容是否能让我发挥所长，并不断成长。
88、为什么我们应该录取你
答案：您可以由我过去的工作表现所呈现的客观数据，明显地的看出我全力以赴的工作态度。
89、工作中，你和你平级同事竞争一个职位，你又跟他在一个团队，如何相处？
答案：作为同一个团队成员，必然存在两层关系，竞争与合作，我认为作为一个专业人士，应该以合作第一，竞争第二为原则，因为在同一个团队，就一定有共同利益，大家都在同一条船上，必须把共同利益维持好
才会有更好的发展。另外成功晋级也有两种结果，一种是伴随鲜花和掌声，另一种是带着同事的不屑和蔑视，我希望我是第一种。
90、如果我今天把你拒绝了，觉得你不适合干这行，你会怎么做？
我喜欢这行，我会继续努力，另外，我想了解您拒绝我的理由，方便我出去后重整旗鼓，毕竟您是有经验的，经验比我丰富，一定能看到我自己看不到的缺点
91、如下图所示，是某公司门户网站的股票栏目中的行情“搜索”功能，你认为应该从哪些方面来测试。
答案：1、控件是否正常（行情搜索框，行情数据不同组合）
2、下面Tab上的数据图是否正确。
92、某银行，由于新上线的后台对账项目突然出现崩溃，系统处于停用状态，最后查明系统可能存在性能瓶颈，你作为项目的主要测试负责人，面对突如其来的事件，该如何处理。
答案：首先回滚线上环境，让线上使用旧版本，确保线上系统 正常运行，然后跟着 开发一起查找，修复问题后，重新上线。
93、web测试中，经常会设计安全模式，那什么是SQL注入
答案：就是通过把SQL命令插入 到web表单递交或输入域名或页面查询的字符串，最终达到欺骗服务器并执行恶意的SQL命令的效果。
94、 现在小明一家过一座桥，过桥时候是黑夜，所以必须有灯。现在小明过桥要１秒，小明的弟弟要３秒，小明的爸爸要６秒，小明的妈妈要８秒，小明的爷爷要１２秒。每次此桥最多可过两人，而过桥的速度依过桥最慢者而定，而且灯在点燃后３０秒就会熄灭。问小明一家如何过桥？
95、有一个5升 的桶、 3升的桶，得到4升的水。
把5升桶装满水，倒入3升的桶，5升桶剩2升水，然后在把灌满水的3升桶倒掉，在把5升桶剩的二升水 倒入到3升桶里面，这时候3升桶就差一升水就满了。再把5升桶灌满，用5升桶然后把3升桶灌满，这时候5升桶恰好去掉 一升，留下4升水了。
96、编程题
0、字符串逆序
result = s[::-1]
1、排序
# 一、冒泡
def bubbleSort(nums):
for i in range(len(nums)-1): # 这个循环负责设置冒泡排序进行的次数
for j in range(len(nums)-i-1): # ｊ为列表下标
if nums[j] > nums[j+1]:
nums[j], nums[j+1] = nums[j+1], nums[j]
return nums
nums = [5,2,45,6,8,2,1]
print(bubbleSort(nums))
# 二、快速排序
#QuickSort by Alvin
def QuickSort(myList,start,end):
#判断low是否小于high,如果为false,直接返回
if start < end:
i,j = start,end
#设置基准数
base = myList[i]
while i < j:
#如果列表后边的数,比基准数大或相等,则前移一位直到有比基准数小的数出现
while (i < j) and (myList[j] >= base):
j = j - 1
#如找到,则把第j个元素赋值给第个元素i,此时表中i,j个元素相等
myList[i] = myList[j]
#同样的方式比较前半区
while (i < j) and (myList[i] <= base):
i = i + 1
myList[j] = myList[i]
#做完第一轮比较之后,列表被分成了两个半区,并且i=j,需要将这个数设置回base
myList[i] = base
#递归前后半区
QuickSort(myList, start, i - 1)
QuickSort(myList, j + 1, end)
return myList
myList = [49,38,65,97,76,13,27,49,444]
print("这个是快速排序的结果: ")
QuickSort(myList,0,len(myList)-1)
print(myList)
2、回文判断
def isPalindrome1(x):
"""
:type x: int
:rtype: bool
"""
a = str(x)
b = []
for i in a:
b.append(i)
c = b.copy()
c.reverse()
if c == b:
return True
else:
return False
isPalindrome1(222)
# 判断字符串回文
def is_palindrome2(text):
t1 = text[::-1]
if t1 == text:
print('the text 是回文')
else:
print('the text 不是回文')
、
3、质数（素数）的判断
# 七、判断是否是质数（素数）
def handlerNum(num):
# 质数大于 1
if num > 1:
# 查看是否有其他因子
for i in range(2, num//2+1):
if (num % i) == 0:
print(num,"不是质数")
break
else:
print(num, "是质数")
# 如果输入的数字小于或等于 1，不是质数
else:
print(num, "不是质数")
handlerNum(5)
# 八、求质数（素数）的个数
def countPrimes(n):
if n <= 2:
return 0
else:
res = []
for i in range(2, n):
flag = 0 # 质数标志，=0表示质数
for j in range(2, i):
if i % j == 0:
flag = 1
if flag == 0:
res.append(i)
return len(res)
4、判断三角形
# 第二十六、判断三角形类型
def triangle(a,b,c):
if a>0 and b>0 and c>0:
if a+b>c and b+c>a and a+c>b:
if a == b and b == c:
return ("这是等边三角形")
elif a == b or b == c or c == a:
return("这是等腰三角形")
else:
return("这是不规则三角形")
elif a+b==c or b+c==a or a+c==b:
return("这是个直角三角形")
else:
return('这好像不是个三角形')
else:
return("请输入大于0的数字")
5、多数求和
# 九、多数求和
def manySum(x):
n = 0
for x in range(x):
n = x + n
return n
manySum(101)
6、找出一个字符串中第一次不重复出现的字符
def find_str(arr):
dic={}
for i in range(len(arr)):
if arr[i] in dic:
dic[arr[i]]+=1
else:
dic[arr[i]]=1
for i in range(len(arr)):
if dic[arr[i]]==1:
return arr[i]
微信扫一扫，打赏作者吧～
