测试面试题汇总
软件测试理论及流程
流程是什么
软件的生命周期：计划阶段（planning），需求分析（requirement），设计阶段（design），编码（coding），测试（testing），运行与维护（running maintrnacne）
缺陷的生命周期：新建--提交--确认--分配--修复--验证--关闭
测试方法
测试计划
内容有哪些
1、 测试目标：对测试目标进行简要的描述。
2、 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
3、 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
4、 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
5、 质量目标：制定测试软件的产品质量目标和软件测试目标。
6、 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
7、 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
8、 测试策略：制定测试整体策略、所使用的测试技术和方法。
9、 发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
10、 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。
11、 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。
12、 风险分析：需要考虑测试计划中可能的风险和解决方法。
测试方案
测试用例
禅道
mysql
SQL去重distinct
mongoDB
db.getCollection("stockout").find({"shopNO":"s0000016"});
loadrunner
性能测试指标
TPS和响应时间(2)、服务器资源使况是否合理(3)、应用服务器和数据库资源使用是否合理(4)、系统能否实现扩展(5)、系统最多支持多少用户访问、系统最大业务处理量是多少(6)、系统性能可能存在的瓶颈在哪里(7)、更换那些设备可以提高性能(8)、系统能否支持7×24小时的业务访问
Tps，错误数，平均响应时长，90%的平均响应时长，结果准确性，线程数
某个线程使用cpu过高导致服务整体慢等都可以通过在这些命令辅助linux命令看出来。
top，vmstat,sar,dstat，traceroute，ping，nc，netstat，tcpdump，ss等等具体请百度。
负载测试（Load Testing）：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。
压力测试（Stress Testing）：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。
容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试、压力测试参考答案如上题。
测试需求：
1、需要将开发给定的需求转为吞吐量和响应时间。
2、根据测试目的，细化需求
测试准备：
测试准备包括测试客户端机器准备、测试数据准备、测试脚本准备。
测试执行：
● 测试的执行中，需要监控测试客户端和服务器性能，监控服务器端应用情况：
● 客户端的系统资源（cpu、io、memory）情况
● 服务端的系统资源（cpu、io、memory）情况
● 服务器的jvm运行情况
● 服务端的应用情况，看是否有异常
● 响应时间、吞吐量等指标
● 系统资源监控，linux下可以采用的工具有：vmstat、top、meminfo等。
● JVM的监控，可以用jprofiler工具，linux下面的jmap、jhat等。
● 响应时间、吞吐量等，由grinder提供。
jmeter
压力测试和负载测试区别
压力测试：高并发，高用户的情况下
负载测试：慢慢增加用户数和并发数
全局变量
Sampler：BeanShell Sampler（取样器）--设置全局变量（${__setProperty(newtoken,${token})}）
配置原件：CSV Data Set Config --参数化
定时器：同步定时器 Synchronizing Timer -- 集合点
配置原件：JDBC Connection Configuration-- 连接数据库
测试计划的元素执行是有序的，通过以下方式执行：
1–配置元件（Config Element）
2–前置处理器（Pre Processors）
3–定时器（Timer）
4–取样器（sampler）
5–后置处理器（Post Processors，只在有结果可用情况下执行）
6–断言（Assertions，只在有结果可用情况下执行）
7–监听器（Listener，只在有结果可用情况下执行）
正则
* 匹配前面的子表达式零次或多次。要匹配 * 字符，请使用 \*。
+ 匹配前面的子表达式一次或多次。要匹配 + 字符，请使用 \+。
. 匹配除换行符 \n 之外的任何单字符。要匹配 . ，请使用 \. 。
【.】匹配任意字符
【*】匹配任意字符长度
【+】一次or多次
【?】遇到第一个匹配值即结束
数字：^[0-9]*$
零和非零开头的数字：^(0|[1-9][0-9]*)$
26个英文字母组成的字符串: ^[A-Za-z]+$
Loadrunner
create/EditScripts：创建和录制脚本
Run Load Tests：运行负载测试
Analyze TestResults：分析检测结果
事务：lr_start_transaction("start") lr_end_transaction("start", LR_AUTO)
检查点：web_reg_find
集合点：lr_rendezvous("aaa");
思考时间：lr_think_time(5)
参数化1：右击选择Replace with a Parameter，弹出窗口Select or Create Parameter
参数化2：工具栏有个P的图标（parameter type）
用LoadRunner进行负载测试的流程通常由五个阶段组成：
计划、脚本创建、场景定义、场景执行和结果分析。
(1)计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需响应时间。
(2)创建 Vuser 脚本：将最终用户活动捕获到自动脚本中。
(3)定义场景：使用 LoadRunner Controller 设置负载测试环境。
(4)运行场景：通过 LoadRunner Controller 驱动、管理和监控负载测试。
(5)分析结果：使用 LoadRunner Analysis 创建图和报告并评估性能。
-------------------------------------------------分割线-------------------------------------------------
LoadRunner 在负载下对基于 Web 的应用程序进行测试的过程（分六个步骤）：
1、计划测试
定义明确的测试计划将确保制定的 LoadRunner场景能完成您的负载测试目标。
2、创建 Vuser 脚本
Vuser通过与基于 Web 的应用程序的交互来模拟真实用户。Vuser 脚本包含场景执行期间每个 Vuser 执行的操作。
（1）每个 Vuser 执行
（2）同时多个 Vuser 执行
（3）选择具体的事务度量
3、创建场景
使用 LoadRunner Controller 创建场景。场景描述测试会话期间发生的事件。场景中包括运行 Vuser 的计算机列表、Vuser 运行的脚本列表以及场景执行期间运行的指定数量的 Vuser 或 Vuser 组。
通过定义 Vuser 组（将为这些组分配一些单独的 Vuser）、Vuser 脚本和运行脚本的负载生成器来创建场景。
或使用百分比模式来创建场景，在该模式下，您可以定义场景中要使用的 Vuser 的总数、负载生成器计算机以及要分配给每个 Vuser 脚本的 Vuser 占总数的百分比
4、运行场景
通过指示多个 Vuser 同时执行任务来模拟服务器上的用户负载。增加或减少同时执行任务的 Vuser 数可以设置负载级别。
创建手动场景模式：
运行场景之前，需要设置场景配置和计划。这将决定运行场景时所有负载生成器和 Vuser 的行为。可以运行整个场景、Vuser 组或单个 Vuser。场景运行时，LoadRunner 将度量并录制每个 Vuser 脚本中定义的事务。还可以联机监控系统的性能。
5、监控场景
使用 LoadRunner 监控运行时、事务、系统资源、Web 资源、Web 服务器资源、Web 应用程序服务器资源、数据库服务器资源、网络延时、流媒体资源、防火墙服务器资源、ERP/CRM 服务器资源、Java 性能、J2EE/.NET 事务细分、应用程序部署、中间件性能、应用程序组件和基础结构资源监控器来监控场景执行。
6、分析测试结果
在场景执行期间，LoadRunner 将录制不同负载下应用程序的性能。您可以使用 LoadRunner 的图和报告来分析应用程序的性能。
性能指标
1） 吞吐量（throughput）：指单位时间内处理的客户端请求数量。直接体现软件系统的性能承载能力。
2） 并发数量（concurrency）：多个同事并发的业务操作。如：100个用户谈事点击登录界面的“登录”按钮操作。
3） 思考时间（think time）：录制脚本过程中，每个请求之间的时间间隔，即操作过程中停顿的时间。
4） 响应时间：指用户从客户端发起一个请求开始，到客户端接受到服务器端返回结果的响应结束，结果信息展现在客户端整个过程所耗费的时间。
5） 点击数：它是统计根据客户端向Web服务器发了多少次HTTP请求计算的。
6） 性能计数器（counter）：是描述相关服务器、操作系统、中间件等性能的一些数据指标。如：Windows系统的内存数（memory inusage）、进程时间（total processtime）都是常见的计数器。
7） 资源利用率：资源利用率通常是指系统各种资源的使用情况，一般用“资源使用量”/“总的资源可用量”× 100%。
8） 网络吞吐量：指在网络工作正常的情况下，单位时间内通过的数据数量。该指标用于衡量系统对于网络设备或链路传输能力的需求。
9） 错误率：指系统在负载的情况下，失败交易的概率。错误率= 失败交易次数/交易总数×100%。
10） 系统稳定性：用户提出的重要指标，如：稳定运行时间7*24等。
fiddler
如何抓取https数据
首先对Fiddler进行设置：打开工具栏->Tools->Fiddler Options->HTTPS
udp协议和tcp协议
TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，UDP（用户数据包协议）是同一层内另一个重要的传输协议。
在因特网协议族中，TCP所在层位于IP层之上、应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。
UDP（User Datagram Protocol，用户数据报协议）是OSI参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，IETF RFC 768是UDP的正式规范。UDP在IP报文的协议号是17。
TCP优点：可靠、稳定。可靠体现在TCP在传输数据之前，会有三次握手来建立连接，而且在数据传输时，有确认、重传、滑动窗口、拥塞控制等机制，在数据传完后，还会断开连接用来节约系统资源。
TCP缺点：慢，效率低，占用系统资源高，易被攻击。TCP在传递数据之前，要先建立连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制等都会消耗大量时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。由于TCP存在确认机制和三次握手机制，这些会导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。
UDP优点：快，比TCP稍安全。UDP没有TCP的握手、确认、滑动窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如UDP Flood攻击等。
UDP缺点：不可靠，不稳定。因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。
Tcp 应用层 传输层 网络层 数据链路层 物理层
http常见状态码
200 接口正常
400 请求报文中存在语法错误，接口发送的参数错误
403 服务器拒绝该次访问，
404 服务器上无法找到请求的资源，接口输入地址不正确
405 接口类型不正确
500 服务器在执行请求时发生了错误
503 服务器暂时处于超负载或正在进行停机维护，无法处理请求；
cookie 和session的区别是:cookie数据保存在客户端,session数据保存在服务器端。
Http和Https的区别
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
接口：
http请求由三部分组成，分别是：请求行、消息报头、请求正文
- Get是不安全的，因为在传输过程，数据被放在请求的URL中；Post的所有操作对用户来说都是不可见的。
- Get传送的数据量较小，这主要是因为受URL长度限制；Post传送的数据量较大，一般被默认为不受限制。
一、系统架构
- web为b/s结构，只有一个版本，服务端和web端更新了之后，刷新一下页面也就同步更新了
- pc、app为c/s结构，服务端更新了，需要对各个主流版本进行兼容测试及回归测试，客户端更新的话，还需要重新安装或升级应用
- web端主要兼容不同的操作系统、浏览器、分辨率
- pc客户端主要兼容不同的操作系统、分辨率
- app需要兼容不同的手机系统（iOS、Android）、不同的系统版本、不同的机型、不同的分辨率、屏幕大小等
- web端、pc客户端主要监测响应时间、cpu、内存
- app端除了要监测响应时间、cpu、内存，还要监测流量、耗电量、温度等
区别于web端和pc客户端，app端还有一些专项测试
1、干扰测试
如电话中断、关机、闹铃、音乐播放等
2、界面测试
如横竖屏切换、多点触控、前后台切换、锁屏、手势缩放等
3、弱网测试（web和pc也需要）
限制网速、断网、切换WiFi/4G/3G/2G，以及丢包情况
4、安装、卸载、更新（pc客户端页需要）
- 安装：需考虑安装时弱网、断网、中断，安装后删除安装文件
- 卸载：需考虑卸载后是否删除app相关文件
- 更新：考虑强制更新、非强制更新、增量更新、断点续传、弱网状态下更新
5、安全测试（还需学习了解）
安装包是否可反编译代码、安装包是否签名、权限设置等
6、边界测试
可用存储空间少、没有SD卡、双SD卡、飞行模式、系统时间有误、第三方依赖等
7、权限测试
是否可获取权限，如访问相册、通讯录、照相机等