软件测试面试题

目录：
1.B/S架构和C/S架构区别
2.HTTP协议
3.POST与GET区别
4.Cookie和Session的区别与联系
5.测试的目的
6.软件测试原则
7.软件测试分为哪几个阶段？
8.单元测试与集成测试的侧重点
9.系统测试范围
10.a测试与ß测试的区别
11.验收测试怎么做？
12.白盒、黑盒和灰盒测试区别
13.冒烟测试的目的
14.回归测试怎么做？
15.全部回归与部分回归的区别？
16.需求分析的目的
17.测试计划的目的
18.什么时候开始写测试计划
19.由谁来编写测试计划
20.测试计划的内容
21.结束条件(项目上线的条件)
22.常见的测试风险
23.测试用例的要素
24.测试用例级别的划分
25.怎样保证覆盖用户需求？
26.写好测试用例的关键 /写好用例要关注的维度
27.测试用例的状态
28.常见的测试用例设计方法
29.判定表用在哪些时候/哪些功能
30.什么时候用到场景法
31.测试环境怎么搭建的？
32.偶然性问题的处理
33.当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
34.产品在上线后用户发现bug，这时测试人员应做哪些工作？
35.二八定理
36.如何跟踪缺陷
37.缺陷的状态
38.缺陷的等级
39.缺陷单应该包含这些要素
40.测试报告的主要内容
41.如何定位bug：
42.Cookie和Session的区别与联系
42.开发没时间修复，如何推进bug的修复：
43.软件测试流程
44.项目介绍
45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计
46.在项目中发现哪些经典bug？什么原因导致的？
47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
48.在需求文档不太详细的情况下，如何开展测试？
49.如何尽快找到软件中的bug?
50.什么是bug？
51.ATM机吞卡的吞卡现象是不是BUG?
52.如何减少非问题单的提交？
53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
54.你们发现bug会怎么处理。
55.请写出设计测试用例所需的文档资料
56.请说明功能测试的重点
57.请详细说明 Web 功能测试的方法主要包括的内容
58.请列举在进行性能测试之前我们应掌握的相关文档
59.简述系统测试的测试类型
60.中断测试可分为：人为中断、硬件异常中断、程序执行中断以及意外中断 4 种情况，请分别说明这 4 种情况
61.请详细列举验收测试的首要条件
62.请列举验收测试过程中所涉及到的相关文档
63.正式验收测试是什么？它的优缺点又是什么？请介绍之
64.请介绍非正式验收测试的两个过程
65.请说明回归测试的范围是什么
66. 请详细说明确认测试的内容（功能测试和性能测试）
67. 请用简短的语言介绍一下易用性测试
68. 请详细说明易用性测试中的用户界面测试的内容
69. 你对测试最大的兴趣在哪里？为什么？
70. 你以前工作时的测试流程是什么？
71.什么时候开始进行性能测试？
72.什么是性能测试、负载测试、压力测试？
73.一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别? ?
74.给你一个网站，你如何测试？
75.软件的安全性应从哪几个方面 去测试？
76.在您以往的工作中，一条软件缺陷（或者叫 Bug ）记录都包含了哪些内容？如何提交高质量的软件缺陷（ Bug ）记录？
77.您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试„„）
78.web测试和APP测试的区别
79.没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
80.以windows对文件的复制粘帖功能为例，尽可能多地写出测试思路
81.python常用模块大全
82.指定 logcat 的日志输出格式 （日志级别）
83.monkey事件简介
84.请你分别画出OSI的七层网络结构图
86.如何定位bug
87.如何判断bug是前端 还是后端
88.Bug不能复现怎么办?
89.功能测试:三轮测试的定义
90.在测试工作中bug是不会流转的，是需要追踪的
91. APP测试和web测试区别
92. 常用工具的使用，postman
93.如果在购物平台上选购了物品，并且成功支付，但在“我的订单”中没有查到该笔订单，此时怎么处理？
94.app注册你怎么测的
95.面试时让你说一个印象最深的bug，该怎么回答
96.web端和app端性能测试关注的指标是什么？
97.bug不能复现怎么办？
98.测试人员在软件开发过程中的任务是什么？
99.详细的描述一个测试活动完整的过程。（供参考，本答案主要是瀑布模型的做法）？
100.app的闪退通常是什么原因造成的？
101.ios和android测试的侧重点是什么
102.push消息测试如何测试
103.常见的接口协议/类型是什么
104.常见的接口请求方式
105.接口测试的原理是什么
106.性能测试都包含哪些
107.接口测试的流程，步骤
108.如何编写接口测试用例
109.什么时候执行性能测试

1.B/S架构和C/S架构区别

区别：
	B/S ：
			只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢 
	C/S：
			响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统,需要针对性的开发,并且维护成本高

2.HTTP协议

	超文本传输协议，应用层协议，由请求与响应组成。
	常见的请求方式有POST/GET,常见的状态码200ok，301永久移动，302临时移动，404找不到资源，500服务器内部错误。

HTTP协议:点击跳转查看详情
HTTP和https的区别：

HTTP和https的区别：点击跳转查看详情

	安全性上，HTTPS是安全超文本协议，在HTTP基础上有更强的安全性。简单来说，HTTPS是使用TLS/SSL加密的HTTP协议
	
	申请证书上，HTTPS需要使用ca申请证书
	
	传输协议上, HTTP是超文本传输协议，明文传输；HTTPS是具有安全性的 SSL 加密传输协议
	
	连接方式与端口上，http的连接简单，是无状态的，端口是 80； https 在http的基础上使用了ssl协议进行加密传输，端口是 443

3.POST与GET区别

1.Get是不安全的，因为在传输过程，数据被放在请求的URL中； Post的所有操作对用户来说都是不可见的。
2.Get传送的数据量较小，这主要是因为受URL长度限制；Post传送的数据量较大，一般被默认为不受限制。
3. Get限制Form表单的数据集的值必须为ASCII（a思k）字符；而Post支持整个ISO 10646字符集。
4.Get执行效率却比Post方法好。Get是form提交的默认方法。

4.Cookie和Session的区别与联系

区别：

1.Cookie是把数据保存在浏览器端的内存中

Session把数据保存在服务器端的内存中

2、cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

cookie与session的联系：

当服务器端生成一个session时就会向客户端发送一个cookie保存在客户端，这个cookie保存的是session的sessionId。。这样才能保证客户端发起请求后客户端已经登录的用户能够与服务器端成千上万的session中准确匹配到已经保存了该用户信息的session，同时也能够确保不同页面之间传值时的正确匹配。

5.测试的目的

1.测试是程序的执行过程，目的在于发现错误

2.一个成功的测试用例在于发现至今未发现的错误

3.一个成功的测试是发现了至今未发现的错误的测试

4.确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。

5.确保产品满足性能和效率的要求

6.确保产品是健壮的和适应用户环境的

6.软件测试原则

1. 测试用例中一个必须部分是对预期输出或接过进行定义
2. 程序员应避免测试自己编写的程序
3. 编写软件的组织不应当测试自己编写的软件
4. 应当彻底检查每个测试的执行结果
5. 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
6. 检擦程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
7. 应避免测试用例用后即弃，除非软件本身就是个一次性的软件
8. 计划测试工作时不应默许假定不会发现错误
9. 程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比
10. 软件测试是一项极富创造性，极具智力的挑战性的工作

7.软件测试分为哪几个阶段？

1、单元测试阶段：单元测试是以最小单位的测试、也是最初期的测试阶段、一般是以一个函数方法窗口、一个功能模块、都可以看做是一个单元，主要依据的是详细设计文档。主要以白盒为主，一般有开发人员完成

2、集成测试阶段:
集成测试又称组装测试，在单元测试的基础上把软件逐渐组装起来一起继续测试的过程。逐渐组装的过程中会出现很多临时版本(迭代测试)。集成测试主要以黑盒为主(当然接口测试也在这阶段进行)

3、系统测试阶段:
整个功能全部完成后对集成了硬件和软件的完整系统进行模拟真实的环境模拟、测试重点主要在于1)整个系统能否正常运行2)真个系统的兼容性测试

4、验收测试阶段: 由用户参与完成的过程

8.单元测试与集成测试和系统测试的侧重点

单元测试

   是在软件开发过程中要进行的最低级别的测试活动，
   在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，
   测试重点是系统的模块，包括子程序的正确性验证等。

集成测试

    也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，
    组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，
    但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
    测试重点是模块间的衔接以及参数的传递等。

系统测试

    是将经过测试的子系统装配成一个完整系统来测试。
    它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
    测试重点是整个系统的运行以及与其他软件的兼容性。

9.系统测试范围

其实也差不多就是我们的黑盒测试，系统测试，是不基于代码和模块之间，只是基于我们从外观入口的测试，这个更多的其实就是模仿用户的操作来进行测试。所以，我们每天使用的app，网页，也可以当做是为他们做了一个功能测试。

    我这里说的，是我们从事功能测试需要从哪些方面去思考这个测试该怎么做覆盖面会广一些：
    1、UI：这是最能直观反应我们系统的最好地方。就像现在是一个看颜值的时代，一个好看的美女 | 帅哥，就会有一种看一眼，再看一眼，我还要看一眼的感觉，这个时候这个人是好是坏，都会暂且不伦，就一句话，好看就完事了。

    2、功能：功能是最能反应一个系统的强大之处。就好像一个人的内涵，我们常常都会说，你看别人家的孩子多牛啊，你看别人家的老公多成功啊，你看别人家的妻子多贤惠啊，咳咳。。。跑偏了。我们可以这样看，XX博士精通8国语言汉、韩、日、英、德、法、俄、匈，精通琴棋书画，擅长各类运动，身高180cm、体重75kg，XX研究院教授，兼职健身教练，还会客串XX美食节目等。那么就可以看出这个人的技能很多，人的技能转换成应用就是功能。

    3、易用性：就是看这个系统是不是很好操作，很好上手。就好像我们使用搜索引擎，输入自己的内容，就可以出现想要的答案；再比如，我们再领取了什么优惠券，或者说我们跨平台登录之后，自动返回系统主页，也就是对用户的一种引导性操作，很人性化；之前使用过一个app，就是点击一个按钮之后，弹窗提示请签约，但是不会跳到签约界面上，自己找半天才找到签约的地方，这种在操作上就会流失用户，体验就没有那么高。

    4、安全：这是比较大的一块，现在我还没有接触到，不敢妄述，以后再补充吧。

    5、网络：网络的影响会影响到用户的体验，一般遵守258原则是最好的。2秒内反应，欢呼雀跃；5秒内反应，还能接受；8秒之后，不能忍受。就像我们叫一个人，那个人立刻就回答你，我们就会觉得被尊重，而一个人半天不理你，是不是可能心里就会有点其他的想法。网络我们可以测试联网，断网，弱网，切换网络等等情况。

    6、稳定：我觉得这是一个系统的健康。就好像一个人三天两头的就感冒生病，你觉得他的这个身体系统会很稳定吗。

    7、兼容：不管是app，还是web都会有兼容的测试。web兼容各种浏览器以及不同浏览器的版本，app的话系统的选择、厂家的选择、分辨率的选择、运行内存的选择等等。

10.a测试与ß测试的区别？

α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。 

经过α测试调整的软件产品称为β版本。β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见

11.验收测试怎么做？

测试步骤：

1、制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。
2、建立测试环境，设计测试用例，并经过评审。
3、准备测试数据，执行测试用例，记录测试结果。
4、分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。
测试项目通过； 测试项目没有通过，并且不存在变通方法，需要很大的修改；
测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进；
测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。
5、提交测试报告。

验收测试：在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。
验收测试的目的：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试的参与者：用户，还可能有软测工程师等。
前提: 系统或软件产品已通过了系统测试的软件系统。
测试内容: 验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接
受。主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、操作手册等）测试等几个方面的内容。

任务： 验证软件的功能和性能符合用户期待。

验收标准和注意事项：

验收测试完成标准: 完全执行了验收测试计划中的每个测试用例。
在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留待下一版本中修改。
完成软件验收测试报告。

注意事项：

必须编写正式的、单独的验收测试报告
验收测试必须在实际用户运行环境中进行 由用户和测试部门共同执行。
如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行。

12.白盒、黑盒和灰盒测试区别

白盒、黑盒和灰盒测试区别

白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。

> 黑盒测试

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

> 白盒测试

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。

采用什么方法对软件进行测试呢？常用的软件测试方法有两大类：静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。

> 灰盒测试

灰盒测试是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

13.冒烟测试的目的

冒烟测试其实就是确保该版本的系统基本功能能正常运行。如果冒烟测试不通过，测试人员是不会进行测试，打回给开发

14.回归测试怎么做？

回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误

1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

15.全量回归与部分回归的区别？

全量回归：

对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全量回归；

部分回归

当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。

16.需求分析的目的

1. 把用户需求转化为功能需求：1）对测试范围进度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确。

2. 明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。

17.测试计划的目的

测试计划的目的：编写软件测试计划的目的是指导测试组成员进行工作和让测试组以外的项目成员了解测试工作的。

测试计划的内容：测试目的和测试项目简介、测试参考文档和测试提交文档、术语和定义、测试策略、确定测试内容、资源、测试进度、测试员的职责与任务分配、项目通过或失败的标准、暂停和重新启动测试的标准、风险和问题等。

最重要的 ： 测试策略、确定测试内容、资源、测试进度、测试员的职责与任务分配、项目通过或失败的标准。

18.什么时候开始写测试计划

我这边的测试计划都是在需求形成文档时候开始的,也就是常说的软件需求分析阶段就开始,因为从这个时候就要进行需求测试了。

19.由谁来编写测试计划

需要编写测试计划的人员有：项目经理、测试经理、测试人员，他们将根据每个所处的位置编写相应的测试计划，下面我们看下每个人写的主要内容是哪些？

1.项目经理
项目经理当然是从整个项目角度出发，编写整体项目计划，那么其中就包括测试的计划了，他依赖于对应的开发计划，也就是首先要有开发计划、提测计划，再评估测试计划，最终得出上线时间

2.测试经理
测试经理主要是从测试组角度出发，编写项目的测试计划，重点就是项目的任务拆分、合理的安排人力资源、预估时间和风险等

3.测试人员

测试同学本人收到测试经理同步过来的具体分工后，也需要编写自己的测试计划，重点就是详细的说明自己的时间规划、每一个测试任务的前期准备以及开始和结束测试的时间等

20.测试计划的内容

测试背景，测试目的，确定测试范围，制定测试策略（功能测试/业务测试…），测试资源安排，测试时间安排，测试人员分配，风险评估

21.结束条件(项目上线的条件)

如何确认软件测试结束的标准（系统可以上线）

基于“测试阶段”的原则：
　　每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100%经过Code
Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。
基于“验收测试”的原则：
　　很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试;如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。

第一类标准：测试超过了预定时间，则停止测试
第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试
第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础
第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订数目的故障
第五类标准：根据单位时间内查出故障的数量决定是否停止测试

22.常见的测试风险

1、需求风险

产品需求的不明确，对产品需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，测试用例维护成本增加，实时更新时存在误差。

2、测试用例风险

测试用例设计不完整，忽视了边界条件、异常输入等情况，用例覆盖率没有做到足够覆盖，测试用例没有得到全部执行，有些用例被有意或者无意的漏测，需求变更导致的测试时间被压缩等情况。

3、缺陷风险

某些缺陷偶发，难以重现，容易被遗漏；缺陷跟踪不够积极主动，没做好缺陷记录和及时更新，同样的缺陷，导致的原因可能不同，对这点没意识到导致的线上生产问题等。

4、代码质量风险

代码质量差，可读性差，重构性差，没做好注释等原因导致缺陷较多，修改难度增大；另外还有系统架构设计的不足，导致的扩展性不足，性能兼容差等问题。

5、测试环境风险

测试环境和生产环境配置不同，测试环境交叉影响较大，测试环境数据量不足导致的测试结果误差等问题。

6、测试技术风险

某些项目存在技术难度，测试能力和经验所限，技术水平相对较差导致测试进展缓慢，测试结果准确性不够，项目发布日期延期等问题。

7、回归测试风险

回归测试，一般时间相对来说较少，且大多只回归主要的功能点用例，可能造成漏测；另外还有回归验证缺陷时业务流走不通导致的打回修复再验证造成的时间延后问题。

8、沟通协调风险

项目进行过程中需要多方沟通协调，不同部门，岗位之间的沟通、协作，难免存在误解、沟通不畅的情况，比如需求变更没有及时沟通，开发代码提交没有及时告知，测试结果的反馈不及时等问题。

9、研发流程风险

其中包括从产品需求评审、研发设计、代码提交、测试发布等一些列流程，流程的不规范不协调很可能导致很多问题；比如开发在不告知其他成员的情况下提交代码，发布没有预生产环境，生产出现

问题无法及时回滚等很多说烂了的情况。流程没必要一板一眼的执行，但没有流程是万万不行的。

10、其它不可预计风险

一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。对于这种情况，往往一时无法解决，建议做好备份方案和容灾机制，或者采用灰度发布等措施。

PS:以上是测试过程中可能发生的风险及原因，其中有的风险是难以避免的，如缺陷风险；有的风险从理论上可以避免，如需求风险，沟通风险等；还有些风险在实际操作过程中出于时间和成本的考虑，

也难以完全回避，如回归测试风险等。

对于这些风险的存在，要尽量避免，也要做好备份方案和容灾机制，规范流程，明确职责，尽可能将风险降到可接受范围内。。。

23.测试用例的要素

下面我们就聊一聊每个要素都是干什么的；

标题： 是对测试用例的描述，标题应该清楚的表达测试用例的用例。

操作步骤：执行当前测试用例需要经过的操作步骤，需要明确的给 出每一个操作的详细描述，测试人员可以根据测试用例 操作步骤完成测试用例执行。

功能模块：这个要测试的功能模块是什么。

重要性：分为高、中、低三等： 高级别：保证系统基本功能、核心业务、重要特性、实际 使用频率比较高的用例；
级别： 中级别：重要程度介于高和低之间的测试用例； 低级别：实际使用的频率不高，对系统业务功能影响不大 的模块或功能的测试用例。

测试前提：就是执行当前测试用例的前提描述，如果不满足这些 条件，则无法进行测试。

测试环境：在什么设备上，或者浏览器上进行的测试。

测试数据：测试用例执行时，需要用来测试的一些数据信息。

预期结果：当前测试用例的预期输出结果，用来与实际结果比较， 如果相同则该测试用例通过，否则该测试用例失败

24.测试用例级别的划分

测试用例的优先级别

优先级一般都是和缺陷的严重程度对应的。

一般可以把优先级分为三种：

高（Highs）：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。

中（Mediums）：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计

低（Lows）：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别。

我们将测试用例分成：高，中和低。测试用例的优先级在后边我们进行”冒烟测试”的执行也是比较关键的，如果你还不清楚”冒烟测试”是什么，可以看这篇文章：。

怎样分配优先级别

1.把需求文档中描述的功能点和实现的功能逻辑正确性、流程是否正常使用标注为高优先级别。

2.所有功能点拆分之后的错误、边界值或因果图、流程图中的错误、异常等情况用例为中优先级别，接口测试用例设计其实将其进行拆分也可以分到高和中级别。

3.把你所有非功能性的测试（例如性能和可用性）标注为低优先级别.

一般高级别的测试用例在整体用例中占30%，中级别的测试用例占60%左右，低级别的用例占5%-10%左右。

在定级某个测试用例时可以从几方面说明：

1.这个功能的失败将影响用户的正常使用，高优先级。

2.没有按照产品的需求文档开发，或者开发同学没有理解清楚需求，开发的产品不符合产品同学的规范，高优先级。

异常情况下打开软件是否是展示的错误，未登录状态下去请求需要登录才能访问的地址，这种是中优先级。
4.用户打开软件访问非常慢，属于低优先级。

最后，拥有划分了优先级别的测试用例也为你潜在的，待定的自动化项目给出了一个好的起点。比如，自动化执行冒烟测试中的测试用例，度量收益，改进测试自动化，自动化高优先级的测试用例等方面。

25.怎样保证覆盖用户需求？

需求的来源：原型图、需求文档、通用的协议规范

用户需求：描述了用户使用产品必须要完成的任务，在软件开发活动中，属于基本的需求。

系统需求：描述了软件设计人员、编程人员必须要完成的任务。系统分析员通过分析用户需求，把用户的需求转变成开发设计人员看得懂的系统需求。

测试需求：描述了软件测试人员必须要完成的任务。测试工程师通过分析系统需求，产生测试需求，作为测试活动的指导。

1、首先，确认需求

这个需求是怎样的项目背景或基于什么前提下而做的；会涉及到哪些支撑平台；具体需要怎样的权限可以上传操作；该功能的迭代会影响到哪些其他的存量功能等，是否有明确的性能需求等

2、梳理需求，确认测试范围

是否需要考虑历史数据，数据来源，用户角色，支持哪些操作系统，兼容性要求（考虑平台兼容性、浏览器兼容性、手机型号
版本等），是否提供接口文档，DB设计文档等等

3、制订测试计划

通过测试需求与测试范围，制订测试计划，我需要运用到的测试方法，工作量预估，测试资源，每个节点的测试类型，以及结束测试标准等等（可以针对此面试题来描述）

测试计划需要经过项目组干系人评审通过后才可以进行下一步

4、根据测试计划设计测试用例

当然，此步会根据个人习惯和经验来适当增减，如先使用思维导图理出测试想法，
然后再扩展。可以按可接受性测试用例、系统测试用例（接口、功能、性能、安全、UI、DB…）来开始设计用例。这样就可以按照所学的N+测试方法来充分设计Case了，而有了测试计划中的相关策略来指导
，也不会疏漏其他的需求点了。

5、后续的执行测试步骤（可以依情况来作描述）我们暂且就此面试题展开分析 ，故不作深入探讨 。

目前大多数需求分析都会将软件需求分解成一条条功能清单，然后将对应的功能点与对应的测试做一对多的映射建立，保证测试设计可以覆盖到每个最小单位的功能点。

而以上一系列的测试步骤是从测试技能的角度来分析如何做测试设计可以保证到需求的覆盖率。

26.写好测试用例的关键 /写好用例要关注的维度

写好测试用例的关键：
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测 试，以最少的用例在合理的时间内发现最多的问题
写好用例要关注的维度：
功能，性能，可靠性，可测试，易用性，可维护性，安全性

27.测试用例的状态

排队（In Queue）： 测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。

进行中（IP）：
该测试正在进行，并且会持续一段时间。（如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态）

阻塞（Block）：
一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。

跳过（Skip）：
你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。

通过（Pass）： 测试运行结束，测试人得到了预料中的测试结果状态和测试行为。

失败（Fail）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。

警告（Warn）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大（我通常会在测试包总结工作表的通过一栏记为警告，而不是另加一栏）。另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。

关闭（Close）：
一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。

28.常见的测试用例设计方法

1．等价类划分法：
等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类；如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。有效等价类：有意义的合理的正确输入；无效等价类：非法的错误的异常的输入；
2．边界值分析法 ：
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生
在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计 测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,
就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据, 而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法 ：
错误推测法主要是测试设计人员的测试经验相关，测试经验不同，设计出来的测试用例也区别很大。
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例 的方法. 错误推测方法的基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情 况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产
品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行.
这些都是容易发生错误的情况. 可选择这些情况下的 例子作为测试用例.
4．因果图方法 ：
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条 件之间的联系, 相互组合等.
考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要 检查输入条件的组合不是一件容易的事情,
即使把所有输入条件划分成等价类,他们之间的 组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个
动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成 的就是判定表. 它适合于检查程序输入条件的各种组合情况
5. 场景法 ：
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
场景法特别适用于控制流清晰的系统。测试过程中可以针对不同的场景设计测试用例。
6.正交表 ：
用于多个下拉框之间的组合，可以通过正交助手生成测试用例
输入条件很多时，因果图等设计方法设计出来的用例数往往多的惊人，用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试，从而减少测试用例数。

29.判定表用在哪些时候/哪些功能

判定法适用于不同的输入组合可能会产生不同的输出这种情况，
比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，
输出的结果是不一样的，这样的功能就要用到判定表

30.什么时候用到场景法

应用场合
1、在软件中当测试软件的业务过程和业务逻辑时，常用场景法。

2、场景法是基于软件业务的测试方法。

3、测试人员将自己看成是最终用户，模拟用户使用该软件时的各种情景：

模拟两种情景：
1）模拟正确的业务实现过程–验证功能是否能正确实现。

2）模拟错误的业务过程。–验证程序的异常处理能力

场景法的测试过程 案例：ATM取款

场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

31.测试环境怎么搭建的

jdk、mysql 数据库、Tomcat、navicat、谷歌浏览器
接口测试工具： postman
性能测试工具： jmeter
bug管理工具： 禅道 badboy（web端录制工具，生成。jmx文件）、charles抓包工具
自动化的话：用的是python开发工具，pycharm

搭建测试环境，确定测试目的 测试环境尽可能的模拟真实环境 确保环境无毒 营造独立的测试环境 构建可复用的测试环境

1、向运维申请一台服务器

2、安装依赖软件

拿python项目举例

安装python3、pymysql、redis等需要的工具。

导入flask、pymysql、redis等需要的第三方模块

拿Java项目举例

安装JDK、tomcat、数据库等需要的工具。

3、拉取代码

需要知道SVN地址或者Git地址

4、修改配置文件

修改数据库、redis等配置文件的配置信息，修改成测试环境的配置信息

5、编译、打包（python不需要编译直接可以运行，如果是Java、c、 c++需要编译）

6、导入基础数据

建表、导入管理员账号之类的信息，即把sql在测试数据库执行一次

7、启动程序

32.偶然性问题的处理

一、一定要提交！！

1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。 5．
对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

二、程序不是测试人员写的，出问题也不是测试人员的原因
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现
三、下次再遇到的时候，拉他们来看就可以了
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。 而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。

四、你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
在我们这里上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。
至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。
这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有bug，是否可以说程序员工作不到位的呀）。

六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。
我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题其实只要自己尽到心就可以了，管别人怎么说呢。

33.当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

首先，将问题提交到缺陷管理库里面进行备案。

然后，要获取判断的依据和标准：

根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；

如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；

根据用户的一般使用习惯，来确认是否是缺陷；

与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。

等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

34.产品在上线后用户发现bug，这时测试人员应做哪些工作？

评估BUG的严重程度当程度高的时候应立即提示用户下线止损。

测试复现后提交缺陷管理软件，考虑bug的优先级别，再考虑修复的影响范围和难易度，然后出对应得补丁包。
在分析bug的原因，判断是什么因素导致的问题，再前往bug内容对相近的模块和类似的接口处进行复查。出现问题进行风险预防。

当BUG的程度不高为中等时提示用户维护或在下次版本迭代时进行修复进行回归测

首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。

当BUG解决且上线没有问题之后，我们再看后续的处理。

追查原因及处理方法：这个BUG出现的原因是什么。这有分为几种情况：

1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。

解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。

2）漏测：

a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例

解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。

b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。

解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因，对该名测试人员发出警告，对相关测试主管，项目经理，产品经理发出警告。

c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的。

解决方法：找到原因，并进行记录，在以后的项目或者下一版本重点关注。

最最重要的：补测试用例！

最后说说追责，一般来说，上线的BUG不能完全归咎于某个人，或者是归咎于测试部、研发部，这是一个团队合作的过程，除了纰漏谁也逃不掉，应该及时止损，吸取教训，在今后的版本或者项目中避免类似的问题发生。当然，如果真的是某个人的责任，那么项目组就应该考虑，是否继续任用他了！

35.二八定理

80%的缺陷出现在20%的代码中，体现了软件缺陷群集现象

二八定律是一种社会准则，符合大多数社会现象的规律。同样也适用于互联网领域。

比如一个网站有成千上万的用户，但是80%的用户请求是发生在20%的时间内，比如大家去网上购物，基本也都集中在中午休息或晚上下班后。二八定律的核心原则是关注重要部分，忽略次要部分。系统性能如果能支撑发生在20%时间内的高并发请求，必然也能支持非高峰期的访问。

80%的缺陷出现在20%的代码中；80%的BUG发现在20%的时间中；80%的花费在20%的错误代码上

1.80%的工程活动是由20%的需求用掉的。
2.80%的软件成本是由20%的构件用掉的。
3.80%的缺陷是由20%的构件引起的。
4.80%的软件废品和返工是由20的缺陷引起的。
5.80%的资源是由20%构件用掉的。
6.80%的工程活动是通过20%的工具完成的。
7.80%的进展是20%的人完成的。

36.如何跟踪缺陷

发现缺陷–>提交缺陷–>将缺陷指派给开发–>开发确认缺陷–>研发去修复缺陷–>回归测试缺陷–>是否通过验证–>关闭缺陷

一般缺陷分几个状态，新建 确认 修复 重新打开 关闭 这几个状态完成过程就代表一个缺陷跟踪的过程。

新建bug 相关人员确认bug 开发进行修复bug 然后你再次验证bug 如果该缺陷已修复，将bug关闭
如果该缺陷没有修复，将重新打开bug

1.找到缺陷后，记录缺陷的各方面信息（如：日志，图片，测试步骤，是否能重复等等）.

2.提交缺陷报告.

3.跟踪这个缺陷，看其何时修复.

4.当缺陷修复后，再对其进行测试.并对因这个缺陷而受影响的其它功能进行测试.（如果没有就不测）

5.如果这个缺陷测试通过，关闭这个缺陷报告.如果没有通过，则再次指回修复缺陷人员，重新修复.

37.缺陷的状态

1、New（新的）：bug提交到缺陷库中会自动的被设置成New状态

2、Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

3、Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”

4、Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

5、Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

6、Postponed（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”

7、Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”

8、Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”

38.缺陷的等级

bug缺陷等级一般划分为四个等级，致命、严重、一般、提示

1、致命（一级bug）通常表现为: 主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。

  比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。

2、严重（二级bug）通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

  比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。

3、一般（三级bug）通常表现为：界面、性能缺陷。

  比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。

4、提示（四级bug）通常表现为：易用性及建议性问题

  比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。

39.缺陷单应该包含这些要素

缺陷标题，缺陷描述，重现步骤，预期结果，实际结果，缺陷优先级，缺陷严重程度，附件

所属产品 所属模块 当前指派 重现步骤 严重程度 bug类型 操作系统 优先级 附件

缺陷ID、缺陷描述、所属模块、用例ID、缺陷名称、bug等级、bug严重程度、bug状态、提交人、解决人、提交时间、解决时间、备注、版本号

40.测试报告的主要内容

一、概述 包括项目背景、需求分析

二、测试时间、测试环境

三、测试过程 评审记录、测试范围、测试用例

四、功能实现清单 列出是否已经按照测试计划实现功能

五、缺陷统计 测试缺陷统计； 测试用例执行情况统计

六、测试统计情况 资源统计 执行情况 问题统计 问题列表 遗留的问题

七、测试总结

测试结论；（是否通过） 测试内容、测试用例的覆盖程度、bug的解决程度 八、测试风险

41.如何定位bug：

	1.检查测试环境配置是否有问题，测试数据是否有问题 
	2.用fiddler抓包，分析请求和响应数据是否存在问题 
	3.查看应用服务器的日志
	4.然后再查看数据库的数据是否存在问题

1、用户层面： 检查host、使用环境ping 或操作问题（浏览器缓存、fiddler工具影响等）
指的是用户自己的环境问题或者操作问题，比如环境不通，或者操作不正确

2、web页面样式------观察样式是否与需求一致

3、F12----查看状态码

​ 4XX 客户端问题， 比如发生了401，那么要看下是否带了正确的身份验证信息；发生了403则要看下是否
有权限访问；404则要看下对应的URL是否真实存在；

​ 5xx服务端出现问题（配合服务器log进行定位，发生了502错误则可能是服务器挂了导致的问题、发生503
错误可能是由于网络过载导致的问题、发生504错误则可能是程序执行时间过长导致超时。

4、查看服务器日志----发生5XX问题，检查后端接口执行的sql是否正确，tomcat日志

5、检查接口请求、返回参数----点击Response标签将标签内的内容复制出来，问了更好的查看可以将其粘贴到格式化json的工具上（如果返回类型是json）工具地址：http://json.parser.online.fr/，然后查看这里面展示的记录数是不是跟UI上展示的一致，如果不一致可以判断是前端的Bug

6、查看需求文档----前端和服务器交互正确，但从测试角度看不合理，查看需求文档， 前端只负责渲染展示，后端负责业务逻辑处理；

7、检查配置----不是代码问题，则检查tamcat、nginx配置，版本

ps：定位完bug后 再次确认bug—是否必现，是否概率性，是否是浏览器兼容问题；

​ 如果实在定位不出来，就交给开发，不要浪费太多时间；

8、是数据库。代码没有问题，不代表软件没有问题。数据库层面也可能会有各种各样的问题，比如字段的约束问题等等。假如一个文本框的前端校验和接口校验的文本长度最大是50，但数据表字段设定的是varchar(30)，那么在存数据的时候肯定会报错。再比如之前发现一个数据库的问题，测试环境没有，到线上却有了，那么也可以看下是不是数据库版本不同导致的。

9、中间件

1、发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题

2、检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常

3、确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析，比如firebug插件等

4、如果产品或业务有相关的日志记录，可通过分析日志来确认bug

5、当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了（注意沟通技巧）

6、如果各方面都分析完还不能确认bug的原因，可以找开发一起定位（注意保留bug现场或者可以复现bug场景）

7、确认bug后，提单给开发进行bug跟踪。

问题单上要描述清楚以下信息：

具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象（最好截图）、日志记录、预期结果、bug确认相关人员等

8、跟踪bug，等开发人员修复bug后进行回归测试。（关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）

42.开发没时间修复，如何推进bug的修复：

开发不修改bug的原因有四：bug路径较深、上线时间紧急、改动影响范围大、第三方应用问题

1. 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点

a.从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性

b.可以和开发人员列举一个之前的类似问题，为开发提供参考

c.产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。

2. 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改

3. 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案

4. 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题

43.软件测试流程

立项(确定项目)–编写需求(需求人员)–需求评审(编写需求人员发起)–开发编写概要和详细设计(编码并自测[开发环境]) --测试:测试用例-测试用例评审(测试人员发起)–部署环境–冒烟测试(通过)–提交bug–回归测试(测试报告)–验收测试–上线

我们一般在项目进行开立项会【产品经理 项目经理 开发人员 测试人员】的时候进行参与，
讨论需求并提出建议，在立项会中制定需求文档，由ui设计原型图，开发根据需求文档进行编码， 我们测试会根据需求文档进行编写
测试计划，根据模块的（颗粒度）划分并编写测试用例以及对用例的评审， 开发结束侯测试对主要功能进行冒烟测试，执行测试用例，提交bug
开发进行修改，修改成功后关闭bug， 进行回归测试，在上线前进行测试总结。

44.项目介绍

这里是引用

45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计

1.功能测试： 圆珠笔按下是否能正常书写。

2.性能测试： 笔芯弹出弹回的快慢。

3.负载测试： 连续按，看弹簧能经受多少次伸缩。

4.兼容性测试： 看是否可以使用其他笔芯。

5.强度测试： 用力过度会有什么影响

6.可恢复性测试： 长时间按住弹簧，松开后看弹簧是否可以恢复

7.界面测试： 笔的外观，舒适度

8.安全性测试： 是否会对使用者造成伤害

46.在项目中发现哪些经典bug？什么原因导致的？

1.支付后，状态没有同步。

2.金额是不足1元，会显示为小数点前面的0不见了

3.查询功能第二页的内容与第1页的内容完全相同

4.导出为excel文件，内容乱码（后台管理员端会涉及导出）

5.导入：商品上架可以支持导入，导入上千个商品曾发生卡死。（线上Bug）

6.查询订单时，系统提示订单不存在。

7.按钮不起作用，比较容易发生在返回按钮，上一步按钮

8.付款账号和收款账号相同，会导致交易失败

9.存在页面某个数据显示为Null，这个数据没有同步过来。响应中没有这个数据

10.错误信息显示为错误代码，在测试环境比较容易出现。

11.同一个账号显示为不同格式，比较容易出现在手机号的显示。13800138001 138 0013 8001

12.时间的显示格式不正确，没有做出适合中国人的显示格式

13.数据的状态不正确，有一笔订单是已经支付，但在某些地方显示为未支付。

14.偶尔可能出现乱码，只有中文乱码

15.输入框输入过长的内容，也能够提交

47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%

48.在需求文档不太详细的情况下，如何开展测试？

把app的所有功能都操作一遍，理清项目的数据流，澄清存在异议的地方，提取测试点；

根据提取的测试点编写测试用例，并评审；

执行测试用例，提交问题单并跟踪，直至问题被解决；

测试结束后，收集测试数据，输出测试报告。

1. 解决用户问题或达到用户目标需要具备的条件或能力

2. 遵守合同、协议、规范或其他要求

49.如何尽快找到软件中的bug?

尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；

把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗?

善于怀疑，不要过于相信开发人员的能力；

不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己，要始终以用户的需求为根本；

使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了；

善于学习他人经验，进行总结，转化为自己的知识体系

50.什么是bug？

产品说明书中规定要做的事情，而软件没有实现 
产品说明书中规定不要做的事情，而软件确实现了 
产品说明书中没有提到过的事情，而软件确实现了  
产品说明书中没有提到但是必须要做的事情，软件确没有实现 
软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的

注：产品说明书中没有提到但是必须要做的事情，软件确没有实现。软件实现了产品的功能，但是没有考虑软件在弱网络、
低电量的情况下也能正常使用，而做出来的产品在弱网络或低电量的情况下报错，那么这也是一个bug。

51.ATM机吞卡的吞卡现象是不是BUG?

不是 是特意设置的安全措施 防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款 所以特意设置了倒计时，限时内没有取走银行卡就会吞卡

52.如何减少非问题单的提交？

熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；

跟产品确认该问题是否属于非问题单。

53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准 3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，

性能监视器打开方法：

一、【开始》运行】输入perfmon，回车 二、右键【计算机》管理】

54.你们发现bug会怎么处理。

这里是引用

55.请写出设计测试用例所需的文档资料

设计测试用例所需要的文档资料包括：

★ 软件需求说明书；
★ 软件设计说明书；
★ 软件测试需求说明书；
★ 成熟的测试用例（案例库或财富库）

56.请说明功能测试的重点

功能测试工作一般由程序员担当，测试的结果交系统设计、测试人员审核通过。 功能测试的重点应注意如下两大点内容：
A 整体性
（1）符合标准和规范；
（2） 直观性；
（3） 一致性；
（4） 灵活性。
B 重点性
（1） 确认每个功能是否都能正常使用， 每项功能符合实际要求；
（2） 是否实现了产品规格说明书的要求；
（3） 否能适当地接收输入数据而产生正确的输出结果；
（4）用户界面测试、是否有相应的提示框、适当的错误提示；
（5） 系统的界面是否清晰、美观；
（6） 菜单、按钮操作正常、灵活，能处理一些异常操作；
（7） 是否能接受不同的数据输入（能接受正确的数据输入，对异常数据的输入可以
进行提示、容错处理）；
（8） 数据的输出结果准确，格式清晰，可以保存和读取；
（9） 功能逻辑清楚，符合使用者习惯；

57.请详细说明 Web 功能测试的方法主要包括的内容

Web 功能测试通常又称为网站（网页）测试。测试的方法主要有如下几点：

	1. 页面链接检查：每一个链接都要有对应的页面，并且页面之间切要正确。
	2. 相关性检查：检查删除/增加其中每一项是否会对其他项产生影响，如果产生影响，
	这些影响是否都正确。
	3. 检查按钮的功能是否正确，如 Add，delete，save，update 功能键.
	4. 字符串长度检查：输入超出所要求的字符串长度的内容，看系统检查字符串长度
	时会不会出错。
	5. 字符类型检查：在应该输入指定类型的地方输入其他类型的内容，例如在应该输
	入浮点型的地方输入其他字符类型，看系统是否检查字符类型时是否报错。
	6. 标点符号检查：输入内容包括各种标点符号，特别是逗号、句号、空格、回车键、
	回格键。看系统处理是否正确。
	7. 中文字符处理：在可以输入中文的地方输入中文，看是否出现乱码或出现错误。
	8. 检查带出信息的完整性：在查看信息和更新信息时，查看所填写的信息是否全部
	带出以及带出和添加的信息是否一致。
	9. 信息重复：在一些需要命名并且名字是唯一的信息中输入重复的名字，看系统是
	否处理、报错；重名包括是否区分大小写；以及在输入内容的前后输入空格，系统是否作出
	正确处理。
	10. 检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按
	“delete”键，看系统如何处理，是否出错;然后选择一个和多个信息，进行删除，看是否
	正确处理。
	11. 检查添加和修改是否一致：检查添加和修改信息的要求是否一致，例如添加要求
	必填的项，修改也应该必填;添加规定为浮点型的项，修改也必须为浮点型。
	12. 检查修改重名：修改时把不能重名的项改为已存在的内容，看能否处理、报错。
	同时也要注意，会不会报和自己重名的错。
	13. 重复提交表单：一条已经成功提交的纪录，回格后再提交，看看系统是否做了处
	理。
	14. 检查多次使用回格键的情况：在有回格的地方回格，回到原来页面，再回格，重
	复多次，看会否出错。
	15. Search 检查：在有 search 功能的地方输入系统存在和不存在的内容，看搜索结
	果是否正确。如果可以输入多个搜索条件，可以同时添加合理和不合理的条件，看系统处理
	是否正确。
	16. 输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否会
	跳动。
	17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件能否打开。对上传
	文件的格式有何规定，系统是否有解释信息，并检查系统能否做到。
	18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提
	示信息。
	19. 快捷键检查：是否支持常用快捷键，如 Ctrl+C ，Ctrl+V 等，对一些不允许输入
	信息的字段，如选人，选日期对快捷方式是否也做了限制。 
	20. 回车键检查：在输入结束后直接按回车键，看系统处理如何，是否报错。 

58.请列举在进行性能测试之前我们应掌握的相关文档

 （1）用户需求规格说明及其相关文档；
 （2）软件开发的前期数据；
 （3）前期工作的详细资料（单元测试、集成测试、功能测试等的相关文档）；
 （4）在真正进入性能测试之前的软件数据的备份等；
 （5）性能测试的测试大纲；
 （6）性能测试的审批文稿及所签署的合同等

59.简述系统测试的测试类型

	系统测试一般要考虑:
	功能测试、
	性能测试、
	负载测试、
	容量测试、
	安全性测试、
	用户界
	面测试、
	配置测试、
	安装测试、
	回归测试等。

60.中断测试可分为：人为中断、硬件异常中断、程序执行中断以及意外中断 4 种情况，请分别说明这 4 种情况。

	1. 在测试中人为中段是为了表现测试结果而设置的中断。在测试中是常用的一种手
	段。
	2. 而硬件异常中断是由计算机硬件异常或故障引起的中断，对硬件异常中断主要
	测试系统设备有没有在线功能和备用设备。
	3. 程序执行中断主要是由程序中执行了中断指令引起的中断，也称为软中断。
	这是不应该发生的，对这类问题测试重点审查集成测试的过程和结果。
	4. 意外中断主要是外部原因引起的中断，对他的测试主要是审查有没有备用电
	源、有没有安装 UPS。 

61.请详细列举验收测试的首要条件。

	验收测试的首要条件有以下几点：
	1． 软件开发已经完成，并全部解决了已知的软件缺陷；
	 2． 验收测试计划已经过评审并批准，并且置于文档控制之下；
	 3． 对软件需求说明书的审查已经完成；
	 4． 对概要设计、详细设计的审查已经完成；
	 5． 对所有关键模块的代码审查已经完成；
	 6． 对单元、集成、系统测试计划和报告的审查已经完成；
	 7． 所有的测试脚本已完成，并至少执行过一次，且通过评审；
	 8． 使用配置管理工具且代码置于配置控制之下；
	 9． 软件问题处理流程已经就绪；
	10．新系统已通过尝试运行工作；
	11．所被测的新系统应该是稳定的，要符合技术文档和标准的规定；
	12．已经制定、评审并批准验收测试完成标准；
	13．合同、附件规定的各类文档齐全。 

62.请列举验收测试过程中所涉及到的相关文档。

	测试过程中涉及到的文档有：
	1. 测试任务说明书；
	2. 测试计划说明书；
	3. 测试用例说明书；
	4. 测试报告说明书；
	5. 测试总结说明书；
	6. 测试验收说明书；
	7. 缺陷跟踪报告说明书。 

63. 正式验收测试是什么？它的优缺点又是什么？请介绍之。

	正式验收测试，是系统测试的后续，也就是说正式测试的测试工作和系统测试差不多，
	测试计划和测试用例设计都应很详细，在这个测试过程中应用的测试用例应是系统测试的用
	例的子集，不能对系统的测试方向有所偏离，在很多测试过程中，正式验收是自动进行测试
	的。
	正式验收测试的优点是：
		1) 要进行验收测试的软件的功能和特性都是已知的；
		2) 可以对测试的过程进行评测；
		3) 正式验收测试可以自动进行测试；
		4) 对软件的要求是由用户需求说明书所决定的。
	正式验收测试的缺点：
		1) 进行正式验收测试需要大量的资源和计划；
		2) 正式验收测试可能和系统测试差不多；
		3) 正式验收测试过程中可能不能发现某些缺陷。 

64. 请介绍非正式验收测试的两个过程

	非正式验收测试过程分为 Alpha 测试 和 Beta 测试。
	Alpha 测试
		Alpha 测试是用户在开发环境下所进行的测试，或者是开发内部的人员在模拟实际环境
		下进行的测试。Alpha 测试没有正式验收测试那样严格，在 Alpha 测试中，主要是对用户使
		用的功能和用户运行任务进行确认，测试的内容由用户需求说明书决定。
	Beta 测试
		进行 Beta 测试时，各测试员应负责创建自己的测试环境、选择数据，决定要研究的功
		能、特性或任务，并负责确定自己对于系统当前状态的接受标准。 

65. 请说明回归测试的范围是什么。

在进行回归测试的时候，必须决定回归测试的范围，具体表现在以下几个方法：
(1) 测试所有修改或修正过的功能模块；
(2) 测试与被修改的模块相关的模块；
(3) 测试所有新增加的功能模块；
(4) 测试整个系统。
方法(1)、方法(2)和方法(3)中只进行了部分的回归测试，这样的测试是不健全的，因
为在软件系统中，对本地代码的修改可能导致整个系统产生副作用。

66. 请详细说明确认测试的内容（功能测试和性能测试）

	确认测试内容主要包括功能和性能两部分。
	（1）功能测试
			功能测试考察软件对功能需求完成的情况，应该设计测试用例使需求规定的每一个软件
			功能得到执行和确认。
			 ★ 按照系统给出的功能列表，逐一设计测试案例；
			 ★ 对于需要资料合法性和资料边界值检查的功能，增加相应的测试案例；
			 ★ 运行测试案例；
			 ★ 检查测试结果是否符合业务逻辑；
			 ★ 评审功能测试结果。
	（2）性能测试
			性能测试是检验软件是否达到需求规格说明中规定的各类性能指标，并满足一些与性能
			相关的约束和限制条件。
			★ 测试软件在获得定量结果时程序计算的精确性；
			★ 测试在有速度要求时完成功能的时间；
			★ 测试软件完成功能时所处理的数据量；
			★ 测试软件各部分工作的协调性，如高速操作、低速操作的协调性；
			★ 测试软件/硬件中因素是否限制了产品的性能；
			★ 测试产品的负载潜力及程序运行时占用的空间。

67. 请用简短的语言介绍一下易用性测试。

	易用性是交互的适应性、功能性和有效性的集中体现。易用性一般分为两个层次，即用
	户界面的易用性和操作系统的易用性。易用性测试包括针对应用程序的测试，同时还包括对
	用户手册系统文档的测试。通常采用质量外部模型来评价易用性。

68. 请详细说明易用性测试中的用户界面测试的内容

	用于与软件交互的方式称为用户界面或 UI，易用性包括如下方面的测试：
	（1）符合标准和规范
			用户界面要素要符合软件现行的标准和规范。
	（2）直观
			用户界面是否洁净、不拥挤；
			布局是否合理；
			 是否有多余功能。
	（3）一致
			如果软件或者平台有一个标准，就要遵守它。如果没有，就要注意软件的特性，确保相
			似的操作以相似的方式进行。
	（4）灵活
			多种视图的选择；
			状态跳转；
			状态终止和跳过；
			数据输入和输出。
	（5）舒适
			软件使用起来应该舒适，不能给用户工作制造障碍和困难。
	（6）实用
			是否实用是优秀用户界面的最后一个要素。 

69.你对测试最大的兴趣在哪里？为什么？

	最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经
在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了 11，12 点，
有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的 1，2 点我没有把握，
其他点我都很有信心做好它。
 刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲
着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我
很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难
更有挑战性，想做好测试的意志就更坚定了。
 不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经
验，技术的不足，做测试的你一定也能理解）。
 我觉得做测试整个过程中有 2 点让我觉得很有难度（对我来说，有难度的东西我就非常
感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出
来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试
一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产
品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学
习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么
响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好
基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例
的时候发现。
 第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始
测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更
多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，
通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测
试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描
述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以
哪些最少的操作步骤就能重现这个bug，这个 bug产生的规律是什么？如果你够厉害的话，可
以帮开发人员初步定位问题。

70.你以前工作时的测试流程是什么？

	公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我
	1 年来不断改正（自己总结，吸取同行的方法）后的流程吧。
		需求评审（有开发人员，产品经理，测试人员，项目经理）－>
		需求确定(出一份确定的需求文档)－>
		开发设计文档（开发人员在开始写代码前就能输出设计文档）－>
		想好测试策略，写出测试用例－>
		发给开发人员和测试经理看看（非正式的评审用例）－>
		接到测试版本－>执行测试用例（中间可能会补充用例）－>
		提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，
		难以重现的），有些可以直接录制进TD）－>
		开发人员修改（可以在测试过程中快速的修改）－>
		回归测试（可能又会发现新问题，再按流程开始跑）。

71.什么时候开始进行性能测试？

性能测试一般分前期阶段和后期阶段。

前期阶段是功能实现后还没有到系统集成时期。 可以针对功能实现进行性能测试，看看单独功能实现的响应时间

后期阶段是指系统功能通过功能性测试完毕后，到整体的性能测试阶段。

72.什么是性能测试、负载测试、压力测试？

性能测试（Performance Test）：通常收集所有和测试有关的所有性能，被不同人在不同场合下进行使用。 关注点：how much和how fast

负载测试（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。 关注点：how much

压力测试（Stress Test）： 压力测试（又叫强度测试）也是一种性能测试，它在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。

1.负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题
负载测试：多用户，用户数渐增，持续同时发同一业务请求，产出最大TPS

2.压力测试是在高负载情况下对系统的稳定性进行测试。是在高负载（大数据量、大量并发用户等）下的测试，观察系统在峰值使用情况下的表现，从而发现系统的功能隐患
压力测试：多用户，资源使用饱和，持续同时发同一业务请求，产出系统瓶颈或使用极限

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

资源方面：一台客户端三百个客户，则会占用更多资源，各线程之间可能会有干扰，影响结果；后者则没有这个问题。

带宽：一台客户端三百个客户，会占用更多带宽；后者则要求更宽松

IP 地址的问题：一台客户端三百个客户，如果有ip限制，则需要绕过ip限制，如采用ip欺骗。

一个客户端，三百个用户

只有一个客户端，三百个用户肯定不能同时进行操作，假设每次一人操作客户端对服务器施压，服务器承受的压力小但持续时间长

三百个客户端，三百个用户

假设三百个客户端同时进行操作对服务器施压，就要求服务器带宽能够承受三百人同时在线操作，且服务器短时间内承受压大但持续时间短

74.给你一个网站，你如何测试？

	1、查找需求说明、网站设计 m 等相关文档，分析测试需求。
	2、制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：
	     功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
	3、设计测试用例：
	     功能性测试可以包括，但不限于以下几个方面：
	     链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。提交功能的测试。
	     多媒体元素是否可以正确加载和显示。多语言支持是否能够正确显示选择的语言等。

	界面测试可以包括但不限于一下几个方面：
		页面是否风格统一，美观
		页面布局是否合理，重点内容和热点内容是否突出                                                               
		控件是否正常使用
		对于必须但为安装的空间，是否提供自动下载并安装的功能
		文字检查
	性能测试一般从以下三个方面考虑：
	     压力测试；             负载测试；             强度测试
	数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
	
	
	安全性测试：
		基本的登录功能的检查
		是否存在溢出错误，导致系统崩溃或者权限泄露
		关开发语言的常见安全性问题检查，例如 SQL 注入等。
		如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持兼容性测试，根据需求说明的内容，确定支持的平台组合：
	兼容性包括：
		浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性
	
	4、开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。
	
	在搜索引擎中输入汉字就可以解析 到对应的域名，请问如何用 r LoadRunner  进行测试。
	建立测试计划，确定测试标准和测试范围
	
	设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等
	
	根据测试用例，开发自动测试脚本和场景：
	
	录制测试脚本
	新建一个脚本（Web/HTML 协议）
	点击录制按钮，在弹出的对话框的 URL 中输入”about:blank”。
	在打开的浏览器中进行正常操作流程后，结束录制。
	调试脚本并保存。可能要注意到字符集的关联。
	设置测试场景
	针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标
	针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件
	下，系统是否会崩溃。
	
	执行测试，获取测试结果，分析测试结果

75.软件的安全性应从哪几个方面 去测试？

		软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
		用户认证安全的测试要考虑问题：
		明确区分系统中不同用户权限
		系统中会不会出现用户冲突
		系统会不会因用户的权限的改变造成混乱
		用户登陆密码是否是可见、可复制
		是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）
		用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统
		系统网络安全的测试要考虑问题
		测试采取的防护措施是否正确装配好，有关系统的补丁是否打上
		模拟非授权攻击，看防护系统是否坚固
		采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，
		现在最常用的是 NBSI 系列和 IPhacker IP ）
		采用各种木马检查工具检查系统木马情况
		采用各种防外挂工具检查系统各组程序的外挂漏洞

	数据库安全考虑问题：
			系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）
			系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这
			个系统的功能实现有了障碍）
			系统数据可管理性
			系统数据的独立性
			系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

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

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

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

77.您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试„„）

	测试类型有：功能测试，性能测试，界面测试。
	功能测试：
			在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个
			黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的
			内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错
			误推测、因果图和综合策略。
	性能测试：
			是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各
			项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载
			测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指
			标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能
			提供的最大服务级别的测试。
	界面测试;
			界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印
			象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如
			同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成
			功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的
			畏惧与放弃中付诸东流。
	区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的
	功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关
	注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），
	是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，
	当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

78.web测试和APP测试的区别

仅仅从功能测试的层面上来讲的话，在流程和功能测试上是没有区别的。那么区别在哪里呢？
由于载体不一样，所以系统测试和一些细节可能会不一样。
那么我们就要先来了解，web和app的区别。

web项目，一般都是b/s架构，基于浏览器的，而app则是c/s的，必须要有客户端。那么在系统测试测试的时候就会产生区别了。

首先从系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

接着是性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。至于服务端的性能是没区别，这里就不谈。

相比较web测试，app更是多了一些专项测试：

健壮性测试：

一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。

而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过，这里不再讲了。
　　
安装、卸载、更新：
　　web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。
　　
就自动化来讲，web大多用的selenium、webdriver，而app则是appium。
性能使用的工具web则是LR，app使用Jmeter要多一点

79.没有产品说明书和需求文档地情况下能够进行黑盒测试吗？

这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。

在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。

##3 测试中的“杀虫剂怪事”是指什么？
“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。

为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。

80.以windows对文件的复制粘帖功能为例，尽可能多地写出测试思路

	1、 基本功能测试： 文件的复制粘贴功能，首先关键字“文件”，文件有不同的分类（图片、视频、音频、文档等），每个分类又有不同的类型（文档类型：txt doc execl pdf等），每个文件又有不同的大小，而且文件还有很多权限，是不是隐藏，是不是只是管理员可执行。选择不同分类的不同类型，不同大小的文件做测试资源。比如：文档类型里面txt文件可以分为 1.KB的txt文件、1MB的txt文件、1GB的txt文件。。。。
	下一个关键字 复制粘贴 复制有多种方式 右击选择、Ctrl+C、 拖动复制，对应粘贴也有各种方式。然后从哪复制，粘贴到哪，比如 可以有本机硬盘、移动硬盘、优盘、内存卡、软盘、光盘、连接手机存储，复制到网络地址等等。复制粘贴后文件是不是可用，文件权限是不是有变化。复制过去容量不够怎么处理？复制过后有重名文件怎么处理？复制过程中取消、关机、拔优盘怎么处理？复制过程能不能执行文件？
	
	2.性能测试：复制粘贴功能性能怎么样？复制文件的速度可不可以接受？同时复制多个文件是不是可以完成?复制文件过程中占用CPU资源大不大，耗电量大不大？
	
	3.兼容性测试 Windows XP, Windows 7, Windows 8 , Windows 8.1, Windows 10等各种windos版本是不是都支持这个功能。
	
	4.交互测试; 复制粘贴文件时，使用windows存储的其他功能是否有影响？比如播放本地的音频、视频、等同时复制文件是不是有影响。一边复制，一边粘贴是不是有影响。
	
	粘贴的稳定性：粘贴完了大小会不会变化，内容格式会不会变化，粘贴不上，误操作以后还能不能找到复制的内容等
	
	粘贴的安全性：粘贴的内容粘贴好了以后会不会存在别处泄露等
	
	2.性能测试：（1）时间：复制粘贴的响应时间？页面的显示时间？（2）负载：多次重复进行复制粘贴是否有异常？复制粘贴容量很大的一个或多个文件是否能承受？（3）强度：保证容量足够的条件下，分别复制粘贴50GB，100GB，500GB，…大小的文件，看什么时候出现失败，失败后的表现，能否重新正常复制粘贴50G？（4）容量：在不同CPU资源条件下，持续复制粘贴5分钟，最多能复制粘贴多少容量的文件？
	
	5.界面测试：复制粘贴时进度条的显示界面是否与系统的设计风格一致？显示界面是否有文字性错误？显示界面的布是否合理？界面上的按钮是否可用（如：是否可以选择中止？是否可用最小化？）
	
	6.本地化测试：不同语言环境下的显示正常
	
	7.辅助性测试：高对比度下能否显示正常
	
	链接：https://www.nowcoder.com/questionTerminal/ad274cafadf64222bb8805df45828741?orderByHotValue=1&pos=3
	来源：牛客网
	
	1 、复制粘贴方法
	
	快捷键测试：测试 Ctrl+C ，是否正确执行复制、 Ctrl+v 是否支持粘贴功能
	
	右键测试：查看复制粘贴功能是否正确执行；
	
	在 cmd 命令行中使用复制粘贴命令；
	
	2 、文件大小测试
	
	源文件为空， 0 字节；
	
	源文件正常大小；
	
	源文件为超大文件： **G/ 等；
	
	3 、文件格式
	
	测试各种文件格式下是否正常复制粘贴：如：图片、声音、视频、压缩文件、办公文件： word\excel\ppt 等、二进制文件；
	
	测试共享文件、隐藏文件
	
	4 、复制和粘贴文件路径
	
	在系统不同文件路径下复制粘贴，
	
	测试相对路径和绝对路径下文件复制粘贴；
	
	测试文件夹下和另一个不同文件夹复制粘贴；
	
	测试不同 C\D\E 盘之间；
	
	测试复制粘贴至：移动硬盘、 U 盘、读卡器以及其它外部存储设备；
	
	5 、异常测试
	
	测试被损坏文件、不完整文件名称、禁止复制和粘贴的文件、超出规定大小文件等；
	
	同名称文件测试是否提醒替换或覆盖；
	
	6 、兼容性
	
	测试不同操作系统之间、不同应用程序（如： QQ ）；
	
	7 、性能测试：
	
	测试复制粘贴可支持最大文件大小；复制粘贴操作的相应速度、执行完毕时间；
	
	一次支持不同格式的文件同时操作；
	
	支持大量文件同时复制粘贴；

81.python常用模块大全

Python常用模块大全

	1.os模块:
	2.stat模块：
	3.sys模块：
	4.datetime,date,time模块：
	5.hashlib,md5模块：
	6.random模块：
	7.types模块：
	8.string模块
	9.math模块
	10.re模块
	11.logging模块

82.指定 logcat 的日志输出格式 :

	– "-v"选项 : 使用adb logcat -v time 命令, 可以啥看日志的输出时间;
	将手机日志输出到本地文件中
	adb logcat -v time > C:/log/aa.txt
	
	Android 的日志分为如下几个级别：
	V —— Verbose（最低，输出得最多）
	D —— Debug
	I —— Info
	W —— Warning
	E —— Error
	F —— Fatal
	S —— Silent（最高，啥也不输出）
	按某级别过滤日志则会将该级别及以上的日志输出。
	比如，命令：adb logcat *:W 将 Warning、Error、Fatal 和 Silent 日志输出
	显示所有优先级大于等于“warning”的日志

83.monkey事件简介

	操作事件简介
	Monkey所执行的随机事件流中包含11大事件，分别是触摸事件、手势事件、二指缩放事件、轨迹事件、屏幕旋转事件、基本导航事件、主要导航事件、系统按键事件、启动Activity事件、键盘事件、其他类型事件。Monkey通过这11大事件来模拟用户的常规操作，对手机App进行稳定性测试。下面让我们来详细了解这11大事件。
	
	1.触摸事件
			触摸事件是指在屏幕某处按下并抬起的操作，可通过–pct-touch参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到。 该事件由一组Touch（ACTION_DOWN）和Touch（ACTION_UP）事件组成，在手机上看到实际操作类似于点击。
	
	2.手势事件
			手势事件是指在屏幕某处的按下、随机移动、抬起的操作，即直线滑动操作。可通过–pct-motion参数来配置其事件百分比。
	
	该事件是由一个ACTION_DOWN事件、一系列ACTION_MOVE事件和一个ACTION_UP事件组成的，在手机上看到的实际操作是一个没有拐弯的直线滑动操作。
	
	3.二指缩放事件
			二指缩放事件是指在屏幕上的两处同时按下，并同时移动，最后同时抬起的操作，即智能机上的放大缩小手势操作。可通过–pct-pinchzoom参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到：
	
	该事件起始是一个ACTION_DOWN事件和一个ACTION_POINTER_DOWN事件，即模拟两个手指同时点下；中间是一系列的ACTION_MOVE事件，即两个手指同时在屏幕上直线滑动；结束是由一个ACTION_POINTER_UP事件和一个ACTION_UP事件组成的，即两个手指同时放开。
	
	4.轨迹事件
			轨迹事件是由一个或多个随机的移动组成的，有时会伴随着点击。很早之前的Android手机带有轨迹球，这个事件就是模拟的轨迹球的操作。现在的手机几乎都没有轨迹球，但轨迹球事件中包含曲线滑动操作，如果被测程序需要曲线滑动时可以选用此参数。可通过–pct-trackball参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到：
	
	该事件是由一系列的Trackball（ACTION_MOVE）事件组成的，观察手机上的操作，即为一系列的曲线滑动操作。
	
	5.屏幕旋转事件
			屏幕旋转事件是一个隐藏事件，在Android官方文档中并没有记录这个事件。它其实是模拟的Android手机的横屏和竖屏切换。可通过–pct-rotation参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到： [代码] 该事件由一个rotation事件组成，其中degree表示的是旋转方向，顺时针旋转，0表示旋转90度的方向，1表示旋转180度的方向，2表示旋转270度的方向，3表示旋转360度的方向。在执行过程中，可以看到手机屏幕在横竖屏之间不断地切换。
	
	6.基本导航事件
			基本导航事件是指点击方向输入设备的上、下、左、右按键的操作，现在手机上很少有上、下、左、右按键，这种事件一般用得比较少。可通过–pct-nav参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到：
	
	该事件是由一个Key（ACTION_DOWN）和一个Key（ACTION_UP）组成的，点击的就是上、下、左、右四个方向按键。
	
	7.主要导航事件
			主要导航事件是指点击“主要导航”按键的操作，这些按键通常会导致UI界面中的动作，如键盘的中间键、回退按键、菜单按键。可通过–pct-majornav参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到： [代码] 该事件是由一个Key（ACTION_DOWN）和一个Key（ACTION_UP）组成的，点击的按键就是中间键和菜单键。
	
	8.系统按键事件
			系统按键事件是指点击系统保留使用的按键的操作，如点击Home键、返回键、音量调节键等。可通过–pct-syskeys参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到： [代码] 该事件是由一个Key（ACTION_DOWN）和一个Key（ACTION_UP）组成的，点击的就是上面说到的几个系统按键。
	
	9.启动Activity事件
			启动Activity事件是指在手机上启动一个Activity的操作。在随机的时间间隔中，Monkey将执行一个startActivity（）方法，作为最大限度上覆盖被测包中全部Activity的一种方法。可通过–pct-appswitch参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到： [代码] 该事件是由一个Switch操作组成的，从手机上看，上面的操作实际是打开了com.android.settings这个应用的一个com.android.settings.Settings的Activity界面。
	
	10.键盘事件
			键盘事件主要是一些与键盘相关的操作。比如点击输入框、键盘弹起、点击输入框以外区域、键盘收回等。可通过–pct-flip参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到： [代码] 如日志所示，这里主要是键盘的打开和关闭操作。
	
	11.其他类型事件
			其他类型事件包括了除前面提到的10种事件外其他所有的事件，如按键、其他不常用的设备上的按钮等。可通过–pct-anyevent参数来配置其事件百分比。从Monkey执行该事件对外输出的日志可以看到： [代码] 该事件是由一个Key（ACTION_DOWN）和一个Key（ACTION_UP）组成的，点击的按键就是其他的一些系统按键，如字母按键、数字按键等。因为现在手机很少带字母按键或数字按键，所以这个事件一般使用得比较少。

84.请你分别画出OSI的七层网络结构图

	答：OSI七层网络结构图，由上至下：
	​ 		应用层 ；表示层 ;会话层 ;传输层 ;网络层 ;数据链路层;物理层
	
	TCP/IP的四层结构图：
	​ 		答：应用层;传输层;互联层;链路层

86.如何定位bug

	#### 如何定位bug
	
	（1）查看报错日志
	
			 查看报错日志，通过日志分析，需要有一定的经验，并且有一定的代码基础，才能更好地定位问题。
	
	（2）查看数据库的数据
	
	 		了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。
	
	（3）查看缓存（如Memcache、apc、redis等缓存）是否正确

87.如何判断bug是前端 还是后端

	前台的bug通常是功能、界面和兼容性等有关；后台的bug与逻辑、性能和与数据相关的错误、排序安全性有关。

平常提bug的时候，前端开发和后端开发总是扯皮，不承认是对方的bug
这种情况很容易判断，先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对
请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题咯

88.Bug不能复现怎么办?

		1. 首先考虑环境问题，看是否能够还原原来的环境
		2. 遇到问题就要提，不能放过任何一个Bug，在提交的Bug描述中加上一句话，那就是复现概率，尝试20次，出现一次或尝试10次，交给开发，开发会根据Bug的复现概率，调整改Bug的优先级。
		3. 尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现
		4. 与开发人员配合，让开发人员对相应的代码检查，看是否通过代码层面检查出问题  也许是代码变更，引起的Bug
		5. 保留发生bug时的log，附加到提交的Bug中，希望可以通过log中找到一些蛛丝马迹。

89.功能测试:三轮测试的定义

简洁版：
				第一轮测试：要覆盖所有测试用例。所有功能都要zhi跑一遍。
				第二轮测试：重点功能的测试。还要把第一轮测shu试发现的问题，根据开发修改完成的结果，进行验证。
				第三轮回归测试：验证所有bug是否都修改完毕。
				测试计划要制定每轮测试的开始和结束时间。设计测试用例的时间。最后发布版本的时间。当然还要包括提交评审的时间。

90.在工作中bug是如何的流转的?

	正规的bug追踪是，测试工程师提出新的bug给测试经理审批，测试经理审批通过后，提交给开发，开发将bug处理后提交给测试经理，测试经理在将bug，提交给测试工程师复测，复测之后再走一边上面的流程，直到这个bug被关闭。
	
	实际工作中，一般采用bug管理软件，如禅道，jira，bugzilla，bugfree等，依据测试管理关键设置的流程来追踪bug，
	
	小公司对bug的做法就是非常简单了，测试提交给开发，开发处理后在提交给测试，如此反复，直到bug关闭

91.APP测试和web测试区别?

	答：App测试与Web测试从功能测试和整体流程角度来讲，几乎没有什么区别，都是点点点的测试。Web测试，包含了UI测试、链接测试、搜索测试、表单测试、输入域测试、数据交互、兼容性测试、安全性测试、性能测试等等很多方面。而App测试，是基于客户端进行测试，测试人员的手机型号不同、版本不同、测试环境不同，涉及到的兼容性问题会有很多。
	
	系统架构：Web测试一般是B/S架构，只要更新了服务器端，客户端就会同步更新。而且客户端能保证每位用户的客户端完全一致。但是App端一般是C/S架构，除非用户更新客户端，否则无法保证软件在各人手机中的一致性。如果在App下修改了服务端，就意味着又需要进行回归测试。
	
	性能测试：Web测试比较关注网页的响应时间，而App除了关注在流畅网络下的响应时间，还需要关心流量、电量、CPU、GPU、Memory等等因素。
	兼容性测试：Web端的测试更倾向于浏览器、电脑硬件配置以及电脑系统方向的兼容，不过一般还是以主流的浏览器为主。而App的测试则必须依赖移动端的设备：手机、平板等，不仅要看设备型号，还要看设备系统：Android和iOS。
	
	App专项测试：异常场景的考虑以及弱网测试。比如：中断，来电，短信，关机，重启等。而弱网测试是App测试中必须执行的一项测试。包括弱网和网络切换，需要测试弱网时的用户体验问题，提示语和等待页面的设置，回退和刷新是否会造成二次提交，以及延时的处理机制等。
	
    针对App产品性质的测试内容，绝大多数用户使用的都是触屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，功能触发区域等测试。
	     
	Web测试是针对浏览器，无需考虑安装卸载问题。而App是客户端，需要测试安装卸载和更新的情况。除了常规的操作还要考虑到异常场景。比如说：安装时的中断、弱网、安装后删除文件，强制更新与非强制更新、断点续传、弱网，卸载后删除App相关的文件等等。

92.常用工具的使用，postman，jmeter，Fiddler

（此处常用工具的使用是检查一名测试人员基本技能的基础，也是项目组最为关注的点，这里只简单介绍操作步骤，候选人若能答出流程即可）
Postman：postman是一个开源的接口测试工具，无论是做单个接口的测试还是整套测试脚本的拨测都非常方便。
1）get请求：
Get请求是最简单的请求方式，输入URL就能完成。 　　
第一步：新建一个tab页面 　　
第二步：输入URL ,选择请求方式为GET 　　
第三步：点击“send”按钮 　　
第四步：查看返回码是否异常。

2）post请求：
Post请求跟Get的区别除了请求方式不同之外，还需要添加请求体，请求体内容多半为Json格式。 　
第一步：新建一个tab页面
第二步：输入URL ,选择请求方式为POST 　　
第三步：输入请求体内容 　　
第四步：点击“send”按钮
第五步：查看返回码，返回信息等

3）带cookie的请求： 该请求需要在Heards里面添加Cookie 　　
第一步：新建一个tab页面
第二步：输入URL ,选择请求方式为POST 　　
第三步：输入请求体内容 　　
第四步：在Heard里面添加Cookie信息
第五步：点击“send”按钮 第六步：查看返回码，返回信息等

4）带Header的请求：该请求需要在Heards里面添加Cookie。
第一步：新建一个tab页面 　　
第二步：输入URL ,选择请求方式为POST 　　
第三步：输入请求体内容
第四步：在Heard里面对应的内容 　　
第五步：点击“send”按钮 第六步：查看返回码，返回信息等

5）文件上传的请求：发送请求前需要先上传文件。 　　
第一步：新建一个tab页面 　　
第二步：输入URL ,选择请求方式为POST
第三步：输入请求体内容，文件内容选择file, 选择本地的文件上传 　　
第四步：点击“send”按钮 第五步：查看返回码，返回信息等
第五步：查看返回码，返回信息等

93.如果在购物平台上选购了物品，并且成功支付，但在“我的订单”中没有查到该笔订单，此时怎么处理？

	（该问题旨在考察候选人在面临场景问题时的处理问题能力，并且如何准确定位问题，解决问题的思路，答案不固定）
	答：测试人员发现问题后，先确认该问题是否满足需求，若在需求要求下，则：
	1.重现问题：如果是测试环境，可以再做一笔订单，详细记录该笔订单讯息，检查该问题是否为偶发性问题，此处分两种情况：
	1）若该笔订单能够查到，则需判断，没有找到订单的那笔有可能是偶发现象，需明确记录；
	2）若该笔订单还是无法找到，则需确定是前端还是后端问题。
	2. 排查问题：若为web类测试，通过开发者工具查看界面返回结果，若“我的订单”中有返回值，但在页面中没有展示，需找前端同事确认是否是做数据处理时没有展示结果；若“我的订单”中没有返回值，有可能是数据没有传给前端，需确认是否是接口没有返回或数据传输丢失。此时可以通过检查数据库对应表格、或者用抓包工具检查接口是否报错。若为APP类测试，通过抓包工具检查接口返回，同时检查数据库中对应表，是否有存储该笔数据。
	3. 确认是前端或后端问题后，可以截图发送给对应同事确认问题，并将该问题提交至缺陷管理工具中，并及时跟踪问题。若问题较严重并短期内无法解决，需及时与负责人，项目经理联系，及时汇报该问题。
	4. 若该问题为偶发问题，需记录该笔订单详细情况，并在后期测试中重点关注，若经过几个迭代后该问题没有再次出现，则可降低该问题等级，但仍需留意。

94.app注册你怎么测的

	 1，先测界面，看下注册按钮，输入框是否都符合要求是否都和原型图一致，
	 2，通过有效场景，无效场景，等价类，边界值的方法测他的功能举例。
	    有效的场景就是用户名，密码，确认密码，验证码都填写正确，点击注册，可以生成
		我会到数据库看下数据库中是否生成了这个用户的信息，
	 3.无效的场景有，用户名跟限制的字符不一致，比如系统限制6-12个字符，那我会用5,13两个无效的场景去测
	 4.密码符合限制...........省略，确认密码.......省略然后我说大概就这样       面试官（没有了？）
	   我有点虚在努力回忆，然后说没有了   面试官（嗯）
	   过了数秒我说，我漏说了，还有我会抓包看下密码用户名传输过程中有没有加密
	   然后他说还有吗？我说没有了（我觉得这里他可能想我把app测试的所有测试都说出来，1.功能 2.兼容 3.安全 
     5.中断
	 6.性能，这个我说了注册没必要测性能 6.......省略一万个测试点）

95.面试时让你说一个印象最深的bug，该怎么回答

	第一个：数据精度相关
	
			这还是实习生刚进入公司的时候，公司的线上项目出现的问题。用户在下单的时候，购物车的结算金额的会出现xx.xxxxxxxxxx这样的金额，简直逆天啊。后来才知道是在数据的各种换算的时候出现了错误。后来在测试中也会出现各种各样奇怪的数据就还好了。
	
	第二个：我的第一个线上Bug
	
			这个时候刚好测试组老人都走了，线上有反馈回来一个bug，说是在某个二级下拉框选择的时候没有限制在一级下拉框的条件下，后台后台人员更改之后，确定测试通过了发布上线之后，一看怎么有不对呀。结果说是不知道那个开发自己做了什么，代码冲突，发布的代码吧这段代码注释了，你能信？？
			
	第三个：和预览功能相关
	
			有的用户在系统成功上传文档之后，点击文档的名称没法进行预览。后面是开发做了优化，发布后用户才能使用了。（这个bug是我第一次真正意识到兼容性测试的重要性，也增加了我对兼容性测试的认识）
			
	第四个：和支付相关
	
			一直来对于线上的支付我都是很谨慎的，这可是公司的财务来源呀。在测试一个活动的支付的时候，有一种情况是用户使用支付宝支付，但是没有安装支付宝app，只用网页版支付。支付成功之后成功回调了，但是没有点击网页版支付成功右上角的成功，直接这个时候进程杀掉app,那么支付宝展示用户实际支付成功，但是在我们系统看起来是支付失败。还好有这样子奇葩的用户不多，最后我们这边移动端的做了修改。（这是因为测试支付的时候没有考虑到各种异常中断的情况）

96.web端和app端性能测试关注的指标是什么？

web端性能测试关注点

APP端性能测试关注点

97.bug不能复现怎么办？

1. 遇到问题就要提，在提交的Bug描述中需要加上一句话，那就是复现概率，尝试10次，出现1次或者尝试10次，出现5次，开发会根据bug的复现概率，调整改bug的优先级
2. 在发现 bug 时，要分析产生的原因，尽量多尝试可能出现的步骤。排除环境和自己电脑配置的原因，比如浏览器的版本，系统的版本等。还可以寻找开发帮助，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题。
3. 保留发生bug时的log，附加到提交的bug中，希望可以通过log中找到一些蛛丝马迹，或使用录屏工具将操作步骤录下来
4. 与开发人员配合，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题
5. 在接下来的测试中，时刻保持关注，每次执行同样或者相近的步骤的时候，看下是否能够复现之前的bug通过上述的办法，仍然无法复现，根据bug的优先级，在上线之前对该bug进行处理，严重级别的bug，要召集项目组的成员，集合大家的力量尽可能的复现bug，不严重的bug，也不要关掉，上线后及时的关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将bug暂时关掉了，同时关掉的时候要进行评论说明并不是因为修复，而是经过x个版本后不复现了。

98.测试人员在开发过程中的任务是什么？

1、寻找 Bug；
2、避免软件开发过程中的缺陷；
3、衡量软件的品质；
4、关注用户的需求。
总的目标是：确保软件的质量。

99.详细的描述一个测试活动完整的过程。（供参考，本答案主要是瀑布模型的做法）？

项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

测试用例完成后，测试和开发需要进行评审。

测试人员搭建环境

开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

如果有客户反馈的问题，需要测试人员协助重现并重新测试。

100.app的闪退通常是什么原因造成的？

1.缓存垃圾过多
		由于安卓系统的特性,如果长时间不清理垃圾文件.会导致越来越卡.也会出现闪退情况.
2. 运行的程序过多,导致内存不足

3.应用版本兼容问题
 		如果应用版本太低，会导致不兼容，造成闪退。此外，有些新版本在调试中，也会造成应用闪退。
	解决方法：如果是版本太旧，更新为新版本即可；如果是新版本闪退，可能是应用在改版调试，可卸载后安装旧版。

4.检查APP中访问网络的地方，组件中的ImageView是否可以正常的下载并显示到app 页面上。   

5.检查APP的sdk和手机的系统是否兼容。

6、手机本身内存不够

7、内存泄漏，程序没有及时释放内容

8、权限问题，也可能导致闪退

9、弱网络情况下，服务端响应不及时，可能倒是闪退

10、设计不合理，1个接口，拉取的数据量太大，请求结果会很慢，且占用大量内存，APP会闪退（比如，我们现在做的记录仪，进入相册列表时候，要拉取所有图片，拉取太慢了，就闪退了）

11、不同APP间切换，交互测试，可能会出现闪退

12.在App软件更新迭代时候，迭代的代码写的错误

闪退后，如何处理和分析日志

1、Android手机，一般用adb logcat或者ddms可以抓取到日志，查看关键字anr、crash、no responsed可以看出哪块出了问题

2、ios手机的所有crash日志都会自动保存，连接xcode可以直接导出来查看 常见的集中闪退原因

1、NullPointerException - 空指针引用异常

2、ClassCastException - 类型强制转换异常。

3、IllegalArgumentException - 传递非法参数异常。

4、ArithmeticException - 算术运算异常

5、ArrayStoreException - 向数组中存放与声明类型不兼容对象异常

6 IndexOutOfBoundsException - 下标越界异常

7 NegativeArraySizeException - 创建一个大小为负数的数组错误异常

8 NumberFormatException - 数字格式异常

9 SecurityException - 安全异常

10 UnsupportedOperationException - 不支持的操作异常

101.ios和android测试的侧重点是什么

	1、Android长按home键呼出应用列表和切换应用，然后右滑则终止应用；

	2、多分辨率测试，Android端20多种，ios较少；

	3、机操作系统，Android较多，ios较少且不能降级，只能单向升级；新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用，低版本ios系统中的应用调用了新的资源库，会直接导致闪退（Crash）；

	4、操作习惯：Android，Back键是否被重写，测试点击Back键后的反馈是否正确；应用数据从内存移动到SD卡后能否正常运行等；

	5、push测试：Android：点击home键，程序后台运行时，此时接收到push，点击后唤醒应用，此时是否可以正确跳转；ios，点击home键关闭程序和屏幕锁屏的情况（红点的显示）；

	6、安装卸载测试：Android的下载和安装的平台和工具和渠道比较多，ios主要有app store，iTunes和testflight下载；

	7、升级测试：可以被升级的必要条件：新旧版本具有相同的签名；新旧版本具有相同的包名；有一个标示符区分新旧版本（如版本号），对于Android若有内置的应用需检查升级之后内置文件是否匹配（如内置的输入法）

102.push消息测试如何测试

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

http类型/协议：
	通过get或post来获取数据，在数据处理上效率比较高
web service类型/协议：
	通过soap协议来获取数据，比起http来说能处理更加复杂的数据类型，本质上也是http协议。

104.常见的接口请求方式

1、Get 向特定资源发出请求（请求指定页面信息，并返回实体主体）

2、Post 向指定资源提交数据进行处理请求（提交表单、上传文件），又可能导致新的资源的建立或原有资源的修改

3、Put 向指定资源位置上上传其最新内容（从客户端向服务器传送的数据取代指定文档的内容）

4、Head 与服务器索与get请求一致的相应，响应体不会返回，获取包含在小消息头中的原信息（与get请求类似，返回的响应中没有具体内容，用于获取报头）

5、Delete 请求服务器删除request-URL所标示的资源*（请求服务器删除页面）

6、Trace 回显服务器收到的请求，用于测试和诊断

7、opions 返回服务器针对特定资源所支持的HTML请求方法 或web服务器发送*测试服务器功能（允许客户端查看服务器性能）

8、Connect HTTP/1.1协议中能够将连接改为管道方式的代理服务器

二．get 和 post区别：
1.get请求无消息体，只能携带少量数据，且不安全

   post请求有消息体，可以携带大量数据，且安全

2.携带数据的方式：

   get请求将数据放在url地址中

   post请求将数据放在消息体body中

3.GET方式提交的数据最多只能有1024字节，而POST则没有此限制。 

105.接口测试的原理是什么

原理：模拟客户端向服务器发送请求报文，服务器接受请求报文后对相应的报文做处理并向客户端返回应答，客户端再接受应答的一个过程。
接口测试是黑盒测试。作为黑盒测试，基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑。

106.性能测试都包含哪些

107.接口测试的流程，步骤

1.接口测试流程
接口测试的流程和功能测试流程类似，依据的对象是需求说明书和接口需求，接口测试流程如下：

108.如何编写接口测试用例

设计测试用例为了让我们理清思路,避免漏测,从而可以提高测试的效率,也方便我们跟进测试的进度.

109.什么时候执行性能测试

性能测试一般分前期阶段和后期阶段。

前期阶段是功能实现后还没有到系统集成时期。可以针对功能实现进行性能测试，看看单独功能实现的响应时间

后期阶段是指系统功能通过功能性测试完毕后，到整体的性能测试阶段。

110.请问你一般如何做测试分析？

测试分析：
1、对需求进行通读，熟悉该需求的目的以及大概的功能；
2、进行制定测试计划，此次测试需要几个阶段，每个阶段做哪些类型的测试，如：功能测试、UI 测试、兼容性测试、稳定性测试、性能测试等；
3、对需求进行第一次详细分析，并制作出需求功能测试点，可以借助流程图等来辅助分析；
4、对功能测试点转化成详细的测试用例；
5、对需求进行第二次详细分析，分析其非功能测试点，例如是否需要做兼容性测试、稳定性测试、性能测试等，给出测试策略；
6、与开发、产品讨论分析得出其影响范围，制定影响测试用例；
7.执行测试、疯狂提 bug、bug 修复验证
8.根据开发人员水平，需求复杂度等等等 重复 6-7 N 次
9.最后回归，测试开发产品三方验收

111.性能测试步骤/流程？

	step1 分析 性能测试需求
	step2 编写 性能测试计划
	step3 编写 性能测试用例
	step4 编写 测试脚本
	step5 设计 测试场景
	step6 执行 场景
	step7 监控 场景运行
	step8 分析 测试结果
	step9 系统性能 调优
	step10 性能测试总结
	
	ps:重复5-9步直到测试计划完成、结果满意。

112.你如何识别性能瓶颈？？

	你如何识别性能瓶颈？
	自己的理解，瓶颈产生在以下几方面：
	● 网络瓶颈，如带宽，流量等形成的网络环境
	● 应用服务瓶颈，如中间件的基本配置，CACHE等
	● 系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
	● 数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
	● 应用程序本身瓶颈，

113.响应时间，并发用户数、吞吐量、性能计算器、tps、qps、hps的含义？

	响应时间：客户端发出请求，到接受到返回的时间。
	
	并发用户数：某一时刻同时向服务器发送请求的用户数
	
	吞吐量：
	QPS（TPS）：每秒钟request/事务 数量

    并发数： 系统同时处理的request/事务数

    响应时间：  一般取平均响应时间

	性能计算器:
	理解了上面三个要素的意义之后，就能推算出它们之间的关系：
	QPS（TPS）= 并发数/平均响应时间    或者   并发数 = QPS*平均响应时间
	
	QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

	TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器		  做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
	
	HPS：Hits Per Second，每秒点击数。Hit 一般在性能测试中，都用来描述 HTTP Request。
	但是，也有一些人用它描述真正的客户在界面上的点击次数。关于这一点，就只有在具体的项目中才能规定得具体一些。
	当它描述 HTTP Request 时，如果 RPS 也在描述HTTP Request，那这两个概念就完全一样了

114.你知道Python基本数据类型是哪6个么？

Python 是强类型语言，在学习 Python 时，有必要了解 Python 有哪些基本数据类型，一共 6 个：
Number（数字）、
String（字符串）、
List（列表）、
Tuple（元组）、
Set（集合）、
Dictionary（字典）。
数据类型的知识是非常多的，一篇文章讲不明白，本文仍然属于入门系列，内容主要是基础简介。

115.给你一个App，你将如何测试？？

在日常工作的摸索中，我将如何做好app的测试简单归结为如下内容。

(1) 功能测试

每项开发的新功能都需要进行测试。app测试中功能测试是一个重要方面。测试人员应该要进行手动测试和后期的自动化测试维护。刚开始测试时，测试员必须把app当做"黑盒"一样进行手动测试，看看提供的功能是否正确并如设计的一样正常运作。除了经典软件测试，像点击按钮、提交订单看看会发生什么，测试员还必须执行更多功能的app测试。

除了整个手动测试过程，测试自动化对移动app也很重要。每个代码变化或新功能都可能影响现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化回归测试。现在市面上有很多自动化测试工具，有商业的也有开源的，面向各个不同平台，如Android，iPhone，WindowsPhone7，BlackBerry以及移动Webapp。根据开发策略和结构，品质管理测试专家需找出最适合他们环境的自动化工具。

(2) 客户端性能测试

一个App做的好不好，不仅仅只反应在功能上。被测的app在中低端机上的性能表现也很重要。比如：一个很好玩的游戏或应用，只能在高端机上流畅运行，在中低端机上卡的不行，也不会取得好的口碑。

关于App的性能测试，我们比较关注的参数有：CPU，内存，耗电量，流量，FPS。同时也需关注一下App的安装耗时和启动耗时。

目前大家可能比较困惑的一个问题，多高的CPU，内存，耗电量，流量，FPS才算是符合发布的值呢？这里可以告诉大家，可以参考精品游戏的一些数值，将自己研发的app与业内精品的app数据做对比。

(3) 适配兼容测试

App在经过功能测试后，也需对其进行适配兼容测试需要检查的项主要有以下几点：

(a) 在不同平牌的机型上的安装、拉起、点击和卸载是否正常；

(b) 在不同的操作系统上的安装、拉起、点击和卸载是否正常；

我们在实际测试中，常常会遇到下列问题：

(a) 在某个平牌某个系统上，app安装不上；

(b) 在某个平牌某个系统上，app无法拉起；

(c) 在某个平牌某个系统上，app拉起后无响应或拉起后黑屏、花屏；

(d) 在某个平牌某个系统上，app无法顺利卸载；

(4) 安全测试

App在上线前，都需要做详细的安全测试。安全测试主要为了检测应用是否容易被外界破解；是否存在被恶意代码注入的风险；上线后外挂的风险高不高等。

(5) 服务器性能测试

服务器性能测试，主要包含单机容量测试和24小时稳定性测试。单机容量测试，可以检测到单机服务器在90%的响应时间和成功率都达标的前提下，能够承载多少用户量。使用特定游戏模型压测24小时，服务无重启，内存无泄漏，并且各事务成功率达标。

一、安装和卸载
1、用户能否自己选择安装路径，在不同的操作系统（android、ios）下安装是否正常、能否正常的运行。
2、安装的文件和文件夹是否写入了制定的目录里面。 3、考虑该款软件最高支持的系统版本、和最低支持的系统版本。 4、是否支持后台安装。
5、在不同的来源下是否能正常安装。 6、安装成功后是否会有提醒提醒用户app需要开启的权限。
7、是否能根据手机屏幕分辩率正常的全屏显示8、软件安装成功后是否会出现花屏、闪退等异常情况。
二、UI测试
1、在不同的手机分辨率的情况下，页面布局能否正常显示主要查看是否会出现图片变形、文字显示不清楚等情况。
2、页面是否美观、是否会出现格局不符合大众化、提示不符合大众化等情况 3、操作是否具有友好性，操作是否过于繁琐、复杂。
4、是否符合行业标准。
三、功能测试
1、APP的正常打开与关闭。 2、是否支持用户的后台切换。 3、是否支持首次登陆后，下次免登录功能。
4、展示首页后是否支持数据自动更新功能。 5、是否支持离线浏览功能。 6、开启相关权限后是否能正常调用手机系统软件功能。
7、是否支持在线升级、更新功能。 8、是否支持数据同步功能 。
四、兼容性操作
1、在不同的手机品牌、不同的操作系统下使用是否能正常运行、安装和卸载、是否会出现程序崩溃、闪退、花屏、卡死等严重情况。
2、是否与其他手机本地app或者是文件发生冲突导致程序无法运行 。
五、安全性测试
1、程序是否容易被外人破解，导致用户重要资料丢失。
2、登录时时密码是否已暗文的方式进行展示。 3、密码或其他重要信息是否支持复制粘贴。 4、登录验证时是否会有验证码。
5、密码是否能设置纯数字密码，是否强制要求用户设置英文与数字结合的方式
六、App性能测试
1、APP在运行时是否会出现cpu占用率高、内存占用率高、手机耗电量高、数据流量消耗率大等问题。
2、在打开页面消耗时长、启动程序消耗时长、退出程序消耗时长等问题。 3、页面切换是否快速、流畅，是否会出现卡顿情况。
4、在弱网情况下app的运行情况。 5、在2g、3g、4g以及wifi不同网络情况下app的运行情况。 6、在离线情况下app的运行情况。
七、服务器性能测试
1、最大支持的用户并发数。 2、是否满足多用户的疲劳测试。

《该文档仅供个人参考，如有不足之处请博友多多指教》

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

什么是测试用例:
			一组由前提条件、输入、执行条件、预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档
什么是测试脚本：
			测试脚本是为了进行自动化测试而编写的脚本。
两者什么关系：
			测试脚本的编写必须对应相应的测试用例

117.简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试？

静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。

动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。


黑盒测试一般用来确认软件功能的正确性和可操作性，目的是检测软件的各个功能是否能得以实现，把被测试的程序当作一个黑盒，不考虑其内部结构，在知道该程序的输入和输出之间的关系或程序功能的情况下，依靠软件规格说明书来确定测试用例和推断测试结果的正确性。

白盒测试根据软件内部的逻辑结构分析来进行测试，是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。α测试发现的错误，可以在测试现场立即反馈给开发人员，由其分析和处理。目的是评价软件的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。可在编码结束/子模块测试完成之后开始。有关手册应该在测试前完成。

β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
因此是开发者无法控制的环境下进行的软件现场应用。同时，用户记录下所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者做修改，最终将软件产品交付给全体用户使用。Β测试更注重于产品的支持性，包括文档、客户培训和支持产品的生产能力。α测试ok后才开始β测试。

118.描述一个测试活动完整的过程。？

详细的描述一个测试活动完整的过程。（供参考，本答案主要是瀑布模型的做法）

1.项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

2.开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3.测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

4.测试用例完成后，测试和开发需要进行评审。

5.测试人员搭建环境

6.开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

7.开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

8.重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

9.如果有客户反馈的问题，需要测试人员协助重现并重新测试。

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

1. 测试有压力，开发必然有压力，和开发一起砍需求

2. 系分和测分增加投入，做更精准的测试

3. 测试提前进入

4. 加强开发自测，拉取开发交付用例

5. 加班

120.软件测试人员分工？

集体测试：

　　也许专业测试里讲这种方式，很可能不叫“集体测试”。因为我根据的自己的理解起了大概符合意思的名词叫集体测试“集体测试”。

  就是测试模式就是，公司里所有的测试人员抱成一团儿，来一个项目，所有测试人员就集中测试一个项目。
  

先说这种分工方式的优点：

　　1、因为测试团队的中每个成员有都有优缺，人员在工作之中相互取长补短。可以很快的找出软件中的缺陷。三个臭皮匠顶一个诸葛亮，一个经验再丰富的测试不一定有三个水平一般的测从员发现的问题多。

　　2、人多的另一个好处是测试项目能可以在更快的时间内发现更多人缺陷。总结一下就是更短时间内发现更多的问题。

再来说说这种方式的缺点：

　　1、一个人员一张嘴，人力成本很长（人员工资，人员平均时间投入，测试机等硬件资源投入）。

　　2、当同时需要测试多个项目中时，不要意思，按顺序来，请在后面排好队。

　　3、工作重复，同样一个缺陷，很可以同时被所有测试员发现，或者叫重复率很高。

　　4、人员水平难以区分，在一个项目测试过程中，有的测人员可能一个缺陷也没找到，有的测试人员却发现了几乎所有的问题。也许这个项目一个缺陷也没找到的测试员在下个项目中却发现了很多缺陷。

　　5、了漏测现象是整个测试团队的责任。（这也不是明确的缺点，要看团队的氛围是积极的还是消极的。）

（也许，你说想照这么个分析法是不是漏了太多东西，也许你有兴趣继续看下去话，我后面会讲解。）

好吧！集体测试缺点太多，就像国家成立初期的“吃大锅饭”，肯定是阻碍发展的。那我们来看看几种分工方式。

按测试内容分工：

　　一个项目的测试包括文档测试，易用性测试，逻辑功能测试，界面测试，配置和兼容等多个方面。我们可以根据人员的特点为每个人员分配不同的测试内容。

内容分工方式的优点：

　　1、分工明确，每位人员都清楚自己的测试的内容重点。

　　2、责任到位，通过漏测的缺陷就可明确是谁的责任。

按测试流程划分：


　　我们的项目测试流程一般需要，制定测试计划，编写测试用例，执行测试用例，输出测试报告等工作，我们可以根据流程中的各个阶段来进行划分。

不同的人员负责不同测试阶段的工作。

优点：

　　1、流程清晰，就像瀑布试项目开发流程，不同阶段的工作由不同的人员担任。

　　2、划分流程的每个阶段难易程度和所需要的技能。

编写测试计划人员需要对整个项目的工作时间、资源分配，测试内容，实施过程有整体的把控能力。

用例辨析人员，需要对项目需求，测试方法，测试点有深入的了解。

用例执行人员需要细心，使用缺陷系统，沟通，协助研发定位缺陷。

输出测试报告人员需要对项目的测试过程，缺陷数量，类型，分布。用例执行请况等进行统计。也可以由测试执行人员担任。

按项目模块划分：

　　对中大型的项目，这种划分就非常必要了，项目的模块非常多，功能也非常多。不同的测试人员负责不同模块的功能，这样会使用测试工作变得更加清晰。

　　1、人员利用率高，为什么这么说呢? 不同的人员负责的功能不一样。工作就不会存在交叉与重复。

　　2、更容易挖掘深度缺陷，假如A人员今天测试这个功能，明天测试那个功能，他就不可以对被测功能内部逻辑与业务有深入有了解。找到的也只是很表面的缺陷。那么如果一个人员长期负责一个模块的功能，那么就会更容易发现更有深度的缺陷。而往往深度的缺陷是致命的。

按照测试类型分工：
　　我们知道软件除了功能需要测试以外，软件在编码阶段需要单元测试，接口测试等，在系统测试阶段，为提高功能测试的效率，可能对某些模块进行功能自动化，我们还要考虑软件的性能、安全性等问题。这些类型也是我项目中最常见的分类。我们可以根据这些类型为测试人员分配测试工作。当然，其专业性对测试人员的要求也比较高。

这种分工方式的特点。

　　1、专业技能要求较高，在这些分类中除了手工测试要求较低外（表面看是这样的），其它分类都需要较高的专业技能。例如，安全性测试需要掌握网络协议，编程技术，脚本攻击，SQL注入，漏洞分析等方面的技能。

　　2、不同分类之间交互性低，正国为不同分类需要的技能不同，虽然同为“测试”工作，但一个做单元测试的人就无法让其去做性能测试。

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

web端：
一、客户端兼容性

  1、浏览器的兼容性测试

      a、内核角度

      	国内主流的浏览器内核主要有3种：IE内核、Firefox内核和Chrome内核；

		（1）IE内核常见的浏览器有：IE6、IE7、IE8、IE9、IE10、IE11、360安全浏览器（兼容模式）、360极速浏览器（兼容模式）、搜狗浏览器（兼容模式）、QQ浏览器等等；
		
		（2）Firefox内核常见的浏览器即火狐浏览器（Firefox）；
		
		（3）Chrome内核常见的浏览器有：Chrome、360安全浏览器（极速模式）、360极速浏览器（极速模式）、搜狗浏览器（高速模式）
		
		同一个应用在不同的浏览器下，可能会有兼容性问题，可能有些浏览器正常，有些浏览器不正常，我们应该当针对当前主流的浏览器版本进行兼容性测试；

     b、浏览器版本角度

        浏览器版本之间差异性很大的比如：IE

        代表：Chrome45版本前后完成禁用了NPAPI插件，因此依赖此插件的软件肯定有问题，Chrome45之后是PPAPI，一般用43和46版本。

         原则：用最新版本前两三个版本，最新版本，UI自动化测试用稳定版本

2、显示器分辨率测试

可以通过对浏览器的缩放的比例进行不同分辨率的测试；

(1)常见台式机分辨率：

17寸液晶或crt显示器1024×768

19寸液晶显示器(普屏) 1280×1024

19寸液晶显示器(宽屏) 1440×900

22寸液晶显示器宽屏16：10和宽屏16：9的比例，最佳分辨率分分别是16：10的分辨率是1680*1050，16：9的最佳分辨率是1920*1080。



(2)笔记本电脑分辨率

    屏幕尺寸      比例      分辨率  

	 12’’       4:3         1024X768 

                4:3         1400X1050  

                16:10     1280X800   

                16:9       1366X768 

     13’’       16:9      1366X768

                16:10     1440X900

                16:9       1600X900

    14’’        4:3       1024X768

                 4:3         1400X1050

                 16:10     1280X800

                 16:10     1440X900

                 16:9       1366X768 

    15’’         4:3          1024X768

                 4:3         1400X1050 

                 4:3         1600:1200 

                 16:10     1280X800 

                 16:10     1680X1050 

                 16:10     1920X1200 

                 16:9       1366X768   

                 16:9       1600X9000

二、服务端测试

   1、硬件兼容性

        适配其它电脑和外设设备；

        比如：打印机（这就是设计到beta测试到客户环境测试）。

   2、操作系统兼容性

       市场上有很多不同的操作系统，常用的有Windows XP、Windows7、Mac、Linux等操作系统；
       同一个应用在不同的操作系统下，可能会有兼容性问题，可能有些系统正常，有些系统不正常，
       我们应该当针对当前主流的操作系统版本进行兼容性测试；

  3、数据库兼容性（架构师）

        Oracle、MySQL等，数据迁移。

  4、web服务器兼容性（中间件/web容器）

       Apache、IIS、Tomact、websphere等。

三.网速测试

待测项目在不同的网络环境中能正常的运行测试，可以通过Fiddler、360插件等软件进行设置限速测试。

移动端：
1、适配系统版本： 知道要测试的软件的最低支持系统版本，然后选择机型
安卓 4.4、5.x、6.x、7.x、8.x、9.x、10.x iOS 9.x、10.x、11.x、12.x、13.x、最新
可能有的兄弟问，去哪里还能找到这么低版本的设备呢？答：某鱼二手、某转二手、某靓机绝对能找到。
2、 适配不同机型： 比较痛苦，每家厂商还要有自己单独的UI，结合实际情况，公司不可能把每个厂商的各个版本机型都给购买回来，我们在选择的时候还可以参考用户的喜好，选择主流机型。以下供参考
安卓 华为、荣耀、小米、红米、oppo、vivo、三星、魅族、一加、其他
iOS 5、6、7、8、X、XR、Xmax、Pro、Promax
3、适配尺寸：
手机从3.x英寸一直到现在的7英寸，选择挺多 安卓 5.0及以下、5.1、5.2、5.3、5.5、5.7、5.8、6、6.1、6.5、7
iOS 4.0、4.7、5.5、5.8、6.1、6.5

4、适配分辨率： 分辨率常见的720p(720×1280),1080p(1080×1920),2k(2560×1440)
5、适配网络： 传统的移动厂商：联通、移动、电信 信号：2G、3G、4G、5G WiFi 6、适配异形屏
现在手机花里胡哨的，刘海屏、挖孔屏、全面屏、3D屏越来越多，所以我们也需要测试一下系统状态栏 7、其他
部分功能涉及到蓝牙、耳机等就比较看对应功能需要了。

122.移动应用的灰度是怎么做的？

	Android上比较容易灰度发布的。
	一、发布版本号较低的灰度测试版本，如beta版本号为3.1.0.1，正式发布时为3.1.1.0。
	发送的形式主要有：
	1、在单独的下载点/下载渠道发布灰度测试版本，比如在网页上开一个测试版下载的口子。
	2、通过APP内置的更新通知进行一定比例的发布，推送更新的机制在服务端需要处理好，比如APP启动时获取机器特征上传到服务器，
		然后对应下发版本更新通知，或者直接按百分比下发。
		这种实现较为复杂但可参考意义最大，一些PC软件也采用这种方法，比如我知道360、tencent。
	二、正式版本发布时再进行高版本推送，之前灰度发布的测试版通过对比版本号会提醒更新到最新版本。

123.移动应用在升级安装时应该考虑的场景？

1.APP有新版本时，打开APP是否有更新提示。
2.当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
3.当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出APP。下次启动app时，仍出现强制升级提示。
4.不删除APP直接更新，检查是否能正常更新，更新后能否正常工作。 
5.删除老的APP，重新下载APP，能不能正常工作。
6.不删除APP直接更新，检查更新后的APP和新安装的APP提供的功能一样。
7.检查在线跨版本升级能否成功，版本过老是否提示用户重装。
8.更新成功后，用户数据有没有丢失，各个配置项是否还原。

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

我过去的主要工作是系统测试和自动化测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class
5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。
在测试中，我感觉对用户需求的完全准确的理解非常重要。另外，就是对BUG的管理，要以需求为依据，并不是所有BUG均需要修改。
测试工作需要耐心和细致，因为在新版本中，虽然多数原来发现的BUG得到了修复，但原来正确的功能也可能变得不正确。因此要注重迭代测试和回归测试

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

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

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

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

127.软件测试用例评审的过程？内容？相关角色?？

1:评审的过程
A:开始前做好如下准备
	1、确定需要评审的原因
	2、确定进行评审的时机
	3、确定参与评审人员
	4、明确评审的内容
	5、确定评审结束标准
	6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
	7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
	8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
B：开始评审
	1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
	2、 通用邮件与相关人员沟通
	3、 通用IM工具直接与相关人员交流
	4、根据评审内容进行评审
2：评审内容
	1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
	2、 优先极安排是否合理。
	3、 是否覆盖测试需求上的所有功能点。
	4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
	5、 是否已经删除了冗余的用例。
	6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
	7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
	8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
3：参与评审人员（这里会分为多个级别进行评审）
	1、 部门评审，测试部门全体成员参与的评审。
	2、公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
	3、 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

128.时间上不允许进行全部测试，测试负责人应该如何做？

这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试，
而是指测试负责人制定的测试计划包含的全部测试内容。
通常，都会发生耽误进度的情况。一旦整体进度不能向后延迟，尤其在功能还没有开发完成的情况下，
这种现象更为突出。担负着质量重任的测试经理，如何来解决这个问题呢？
比较好的做法是按照下面的步骤：
（1）按照测试任务的轻重缓急,尽最大努力完成 在时间不足的情况
		我们应该对测试任务按照优先级来划分,重要紧急的任务先完成，这个时候的测试任务是一种助性工作,其 目的就是尽最大努力来提高质量，
		因此，面对这种情况测试负责人要做的就是带领小组充分利用所有资源来保证质量

（2)在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开提高了， 才能从根源上解决问题，
因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式 ，从而使项目规划的更加合理，从而按照预定计划来开展工作。
总之，在任何情况下，测试负责人都不应该抱怨，只有积极面对问题，才能更好的解决问题。

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

1.id 属性：方法：driver.find_element_by_id()
2. name 属性：方法：driver.find_element_by_name()
3. class 属性：方法：driver.find_element_by_class_name()
4. link_text ：方法：driver.find_element_by_link_text()
5.  partial_link_text：方法：driver.find_element_by_ partial_link_text ()
6. 元素标签名称 ：方法：driver.find_element_by_tag_name()
7. xpath路径定位：方法：driver.find_element_by_xpath()
8.  css选择器定位：方法：driver.find_element_by_css_selector()

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

硬性等待：也叫线程等待，通过休眠的方式完成等待如等待5秒Thead.sleep(5000) 

隐式等待：通过imlicitlyWait完成延时等待，这种事针对全局设置的等待，如设置超市10秒，使用imlicitlyWait后，
		如果第一次没有找到元素，会在10秒之内不断循环查找元素，如果超时间10秒还没有找到，则抛出异常 

显式等待：智能等待，针对指定元素定位指定等待时间，指定的范围内进行元素查找，找到元素则直接返回，超时没有找到元素则抛出异常 

131.自动化测试用例的覆盖率多少?

40-60%
测试覆盖率应该区分[自动化测试](javascript:;)覆盖率和[功能测试](javascript:;)用例覆盖率。

　　对于自动化测试覆盖率，应是=(自动化测试脚本执行过的代码/总代码）。


　　对于[**测试用例**](javascript:;)覆盖率，应是=（测试用例覆盖的功能点/产品设计的所有功能点）。

实施自动化测试最重要的就是要保证其可用性，而不少同学写了不少自动化测试用例，但感觉到其可用性不高。究其原因，不是自动化测试本身的问题，是实施自动化测试的时候没有考虑周全。

 1、不合事宜地引入自动化测试      

在公司业务发展稳定前，或是产品变动频繁的阶段，为了自动化测试而做自动化测试。此时的自动化测试失败率会非常高，不仅维护成本高，而且没有达到自动化测试回归与监控的目的。于是，就会造成放弃自动化测试，或是怀疑自动化测试的作用。在此时，不要急于引入自动化测试，如果确实需要引入自动化测试时，需要把测试粒度设置的粗一点儿，覆盖核心和变动不大的业务线。 

2、没有统筹进行自动化架构设计      

自动化测试用例不能是简单的测试用例的集合，如果将一个个单独的自动化测试用例放在一起，就组成自动化测试工程的话，那后期的管理与执行就会相当复杂。投入产出比与预期相差太远，这也不是一个正常的自动化测试工程的实施过程。正常情况下，需要先对自动化测试工程进行架构设计，选择合适的设计模式，对代码做分层架构设计，自主选择要执行的测试用例集等。 

3、测试用例选择不合理      

在实施自动化测试用例之前，没有对测试用例进行合理的选择，拿着手工测试用例一个个转化自动化测试用例。如果在此情况下，测试用例肯定覆盖不全面。所以需要前期对测试用例进行合理的选择，做智能化处理，如根据业务需求，选择核心业务的测试用例；或是如前面提到的，通过最短路径算法，选择覆盖率较高的测试用例集合。先从用例选择的角度来分析用例覆盖率，而后再转化成自动化测试用例，从而更好的提高自动化测试用例覆盖率。      

从事自动化测试的测试开发同学很多，但是相应的级别也不尽相同，从T3到T6都有可能。其实施的自动化测试工程也就各有所长，这也说明自动化测试的技术有很大的提升空间。所以要沉下心来，不断地提升自己，不要刚刚学习了自动化测试就感觉自己能力很强，或是动不动就说测试发展遇到了瓶颈。不断的打好测试技术相关的基础，完善知识体系，提高解决问题的能力，开阔视野才能步步高升。 

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

这个要根据自动化的所测试到的模块以及用力条数去进行分析，可以简单的列下你们公司每次运行自动化一个具体的时间进行回答 

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

UI要半个小时，接口大概10min左右吧？没计算过接口的 

133.什么是分层自动化?

传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。 

分层自动化是为了解决测试成本问题。在 watir 和 selenium，qtp 之类的框架在自动化测试中大行其道后，
逐渐暴露出了一些维护问题。 大量的测试用常常支覆盖了最基础的功能，自动化 case 编写效率低。
遇到展现发生变化会导致很多的 case fail，维护自动化的成本变大，甚至是不可接受。 

134.你的测试数据是怎么准备的?

在软件测试过程中，测试数据的准备是一个工作量很大而且也是一个技术活。因此如何准备大量的测试数据，而且如何准备高质量的测试数据，满足测试的需求，就是一个重要的话题。

首先看数据的来源，数据的来源一般来讲有三个个，一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。这不仅仅包括最基本的基础数据，比如:用户、权限、配置、基础编码、原数据等，还包括上面提到的业务数据。这对于比较小型的系统来说还是可行的，对于大型的系统来说可能就是一个巨大的工程了。

第二种方式就是利用现有系统，这适合已有类似系统，测试是针对升级或者增加功能的产品化的系统。这种情况把已经在生产环境中运行的数据导出。在此基础上再进行数据的整理、加工为测试数据。

还有一种方式就是将现有非电子化的业务数据录入到系统中，在验证业务的同时也完成了测试数据的积累。即边测试边积累数据。但是这种情况积累的数据往往有一定局限性，因为已经发生的业务数据基本是正确的、一致的，而且可能缺少某些特定业务的数据(不常发生的业务)。这样就需要根据对测试需求的分析，追加新的测试数据，以便能完整覆盖业务类型。
确定好数据来源后，还需要对已有数据进行分析、验证、检查，保证数据的质量，数据的质量一般要满足测试需求、覆盖被测业务、覆盖测试边界，以及要满足完整性、一致性等要求。检查完后要整理和完善数据，清除无用和冗余的数据、补录不完整的数据，修改一些错误的数据。
经过整理好的数据要纳入配置管理，以后根据需求和变更要进行数据的维护和更新，以保证满足系统测试的要求。

135.请简述Appium和selenium的原理?

selenium的操作原理：

1. 初始化一个service对象，通过WebDriver打开chromedriver.exe浏览器驱动程序   
2. 通过RemoteWebDriver向浏览器驱动程序发送POST请求，浏览器驱动程序解析请求，打开浏览器，并获得sessionid，以后携带此sessionid对浏览器进行操作
3. 打开浏览器后，所有的selenium操作都是通过调用RemoteConnection的execute方法来完成（execute方法也是通过向remote service发送POST/GET请求）

##### appium工作原理

当开启appium服务器的同时就开启了监听端口；我们运行脚本的时候，调用任何的appiumAPI，都会向Appium Server端post一条HTTP请求，请求内容就是根据webdriver wire protocol协议规定的一条JSON格式的数据；Appium Server端接收到请求后，解析出JSON数据并发送到 [手机 ](https://www.jianshu.com/writer)端；手机端上已经由BootStrap.jar(iOS为BootStrip.js)开启的socket服务器监听相应的端口，BootStrap.jar在appium每个session第一次访问手机端的时候会自动安装；手机端接收到对应的请求后，通过BootStrap.jar翻译成UIAutomator能执行的命令，然后通过UIAutomator处理并操作APP完成测试。

Appium操作原理:

- Appium client: 实现了webdriver协议的脚本 或者Appium Desktop自带的client
- webdriver协议: 同上
- Appium server：默认端口4723
- device: 安卓真机或虚拟机

1.  python/java脚本，向Appium Server发送http请求
2.  Appium server 收到请求后，将根据请求生成对应的Bootstrap.jar/bootstrap.js
3.  将Bootstrap.jar/bootstrap.js注入device中，驱动uiautomator，执行操作，并将结果返回给Appium server
4.  Appium server将结果以http响应的形式返回给client

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

	第一步：首先我们需要对要拦截的接口进行断点调试   breakpoints
	
	第二步：然后我们就正常的请求接口，这个时候charles断点的原因，会导致请求被等待中 edit request
	
	第三步：这个时候我们就可以修改返回结果了 execute

137.从一个数组中找出前4个最大的数,用最优解

def qiuckSort(list):
    if len(list)<2:
        return list
    mid = list[0]
    left = [i for i in list[1:] if i <= mid]
    right = [i for i in list[1:] if i  mid]
    finallyList = qiuckSort(left)+[mid] + qiuckSort(right)
    return finallyList
array = [3, 0, 1, 832,23,45, 5, 5, 6,46, 9, 56, 897]
print(qiuckSort(array)[-4:])

138.写一个方法把字符串转为数字,比如str-"1234",变成int 1234,并且测试这个程序

def StrToInt(a):
    res ,mult,flag = 0,1,1
    if not isinstance(a,str):
        raise TypeError("a is not str")
    if a[0] =='-' or a[0] == '+':
        if a[0] == '-':
            flag = -1
        a = a[1:]
    for i in range(len(a)-1,-1,-1):
        if '9' =a[i] = '0':
            res +=(ord(a[i]) -48) * mult
            mult = mult *10
        else :
            return 0
    return res * flag

def test_strToInt2(self):
    with pytest.raises(TypeError):
        StrToInt(34)

测试用例：
def test_strToInt3(self):
    assert StrToInt('测试赛') == 0

def test_strToInt4(self):
    assert StrToInt('+2147689') == 2147689

def test_strToInt5(self):
    assert StrToInt('45') == 45

def test_strToInt6(self):
    assert StrToInt('1a33') == 0

def test_strToInt7(self):
    assert StrToInt('-5') == -5

139.黑盒测试方法有哪些？（写出15种以上）

 1.动态测试 	 	2.故障转移和恢复测试 	 	3.配置测试 	 	4.容量测试 	 	5.UI测试 	 	6.数据和数据库完整性测试 	 7.	易用性测试 	
  8.功能测试 	 	9.性能测试 	 	10.自动化测试 	 	11.健壮性测试 	 12.	稳定性测试 	 	13.场景测试 	 	14.逻辑测试 	 	15.随机测试 	
    	16.集成测试 	 	17.系统测试 	 	18.验收测试 	 	19.冒烟测试 	 	20.兼容性测试 	 	21.逆向思维测试 	 	22.本地化测试 	 	23.接口测试 	
    	24.回归测试 	 	25.Cookie测试 	 	26.Alpha测试 	 	27.Beta测试 	 	28.安全性和访问控制测试

137.

137.

137.

137.

137.

137.

137.