欢迎使用CSDN-markdown

1.简单概述缺陷报告包含哪些内容？
报告编号
唯一的索引标识
标题
简单的描述，传达缺陷的基本信息
报告人
缺陷报告的原始作者
日期
首次报告该缺陷的日期
版本号
软件的哪个版本出现了该缺陷
优先级
开发人员处理和修复缺陷的先后的先后顺序
严重级
描述所报告的缺陷的严重程度
缺陷描述
缺陷的简单描述
运行环境
缺陷报告发生的环境中操作系统的信息
重现步骤
对发现的缺陷进行详细的描述
实验结果
运行测试用例产生的实际结果
预期结果
由需求报告得知的运行测试用例可能产生结果
附件
添加图片或结果文件的方式直观展示缺陷
2.开发人员修复缺陷后，如何保证不影响其他功能？
重新执行用例、看是否出现错误结果。并对周围的一些相关功能点追加新的测试用例。
3.压力测试和负载测试的区别？需要关注哪些指标？
压力测试：
对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能
接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个 Web 站
点在大量的负荷下，何时系统的响应会退化或失败。
性能测试：
在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统
的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度
测试应该于性能测试一同进行。

从外部看，性能测试主要关注如下三个指标
1.吞吐量：每秒钟系统能够处理的请求数、任务数。
2.响应时间：服务处理一个请求或一个任务的耗时。
3.错误率：一批请求中结果出错的请求所占比例
压力测试中的指标
1.TPS
2.QPS
3.平均处理时间（RT）
4.并发用户数(并发量)
5.换算关系
6. TPS和QPS的区别
4.sql语句中having的作用是？WHERE和Having有什么区别？
作用：对由sum或其它集合函数运算结果的输出进行限制。
区别：
select ··· from ···where ···(只能对分组前的属性进行筛选)
group by ···having ···(只能对分组后的每个组的整体属性进行筛选，用聚合函数体现)
····–不使用group by就默认表的整体为一组
速度上：where更快
使用上：1、having先分组后计算，where反之 2、having后面可以跟聚合函数，where不可以。
5.如何准备测试数据？如何防止数据污染？
如何准备测试数据：
在软件测试过程中，测试数据的准备是一个工作量很大而且也是一个技术活。因此如何准备大量的测试数据，而且如何准备高质量的测试数据，满足测试的需求，就是一个重要的话题。
首先看数据的来源，数据的来源一般来讲有三个个，一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。这不仅仅包括最基本的基础数据，比如：用户、权限、配置、基础编码、原数据等，还包括上面提到的业务数据。这对于比较小型的系统来说还是可行的，对于大型的系统来说可能就是一个巨大的工程了。
第二种方式就是利用现有系统，这适合已有类似系统，测试是针对升级或者增加功能的产品化的系统。这种情况把已经在生产环境中运行的数据导出。在此基础上再进行数据的整理、加工为测试数据。
还有一种方式就是将现有非电子化的业务数据录入到系统中，在验证业务的同时也完成了测试数据的积累。即边测试边积累数据。但是这种情况积累的数据往往有一定局限性，因为已经发生的业务数据基本是正确的、一致的，而且可能缺少某些特定业务的数据（不常发生的业务）。这样就需要根据对测试需求的分析，追加新的测试数据，以便能完整覆盖业务类型。
确定好数据来源后，还需要对已有数据进行分析、验证、检查，保证数据的质量，数据的质量一般要满足测试需求、覆盖被测业务、覆盖测试边界，以及要满足完整性、一致性等要求。检查完后要整理和完善数据，清除无用和冗余的数据、补录不完整的数据，修改一些错误的数据。
经过整理好的数据要纳入配置管理，以后根据需求和变更要进行数据的维护和更新，以保证满足系统测试的要求
如何防止数据污染：

初始数据
设置使数据库的自动提交失效
删除数据操作
查看删除后的数据
回滚数据
再次查看数据
修改回初始的配置
最后查看数据
前面的所有操作围绕的核心是数据库表的事务操作。首先对事务的自动提交功能取消，然后对数据库中的表进行增删改操作，再次是事务回滚操作，最后将自动提交功能还原。
注意：
操作是围绕数据库表的事务操作，所以只能是对支持事务操作的引擎进行操作。如，InnoDB，当然对ENGINE是MyISAM的无效。
该操作中还有值得注意的是在事务回滚rollback之前不能执行commit。
6.如果项目周期很短，测试人力匮乏，你是怎么协调的？
依据代码review的结果和影响范围，对测试内容进行适当的裁剪。
借助自动化工具的支持，提高测试案例的执行效率。
调整组内任务的优先级，进行人力协调，优先投入最紧要的项目。
必要的情况下加班

在微信客户端使用搜狗输入法打字，手机屏幕突然黑了，请问哪些原因会导致这个现象？分别如何进行排查？
方案1：仔细检查是否是自己的执行步骤，或者误操作导致的bug，提交给相关人员
方案2：通过日志相关信息处理，提交相关开发人员
方案3：通过截图方式尽量复现当时的情景
方案4：和相关测试人员商议，确定bug的优先级与开发沟通，猜测可能出现问题的地方，在代码中设桩，添加状态打印信息，进行有针对性的测试。
方案5：考虑采用自动化，进行压力测试，测试过程中注意收集log信息，统计bug出现的概率。
方案6：（前提：项目组相关人员均知晓）关注发布后的用户反馈，跟进bug
1.为了提高测试的效率，应该（D）
A 随机地选取测试数据
B 取一切可能的输入数据作为测试数据
C 在完成编码以后制定软件的测试计划
D 选择发现错误可能性大的数据作为测试数据
2.软件测试员究竟做些什么（C）
A 软件测试员的目的是发现软件缺陷
B 软件测试员的目的是发现软件缺陷，尽可能早一些
C 软件测试员的目的是发现软件缺陷，尽可能早一些，并确保其得以修复
D 软件测试员的目的是发现软件缺陷，尽可能早一些，并将其得以修复
3.下列说法不正确的是（D）
A 测试不能证明软件的正确性
B 测试员需要良好的沟通技巧
C 验收测试是以最终用户为主的测试
D 成功的测试是发现了错误的测试
4. Linux系统中下面命令中哪个是用来停止进程的命令（C）
A stop
B down
C kill
D 以上都不是
5.用于文件系统直接修改文件权限管理命令为：（B）
A chown
B chmod
C chgrp
D umask
6.改变文件所有者的命令为( C)
A chmod
B touch
C chown
D cat
7. 下面有关软件缺陷的说法中错误的是（C）
A 缺陷就是产品在开发中存在的失误
B 缺陷就是软件维护过程中存在的错误，毛病等各种问题
C 缺陷就是导致系统程序崩溃的错误
D 缺陷就是系统所需要实现某种功能的失效和违背
8.下列项目中不属于测试文档的是（C）
A测试计划
B测试用例
C程序流程图
D测试报告

9.划分软件测试属于白盒测试还是黑盒测试的依据是（C）
A 是否执行程序代码
B 是否能看到软件设计文档
C 是否能看到被测源程序
D 运行结果是否确定
10.下列不属于软件测试缺陷的是（D）
A软件未达到产品说明书标明的功能
B软件出现了产品说明书指明不会出现的错误
C软件功能超出了产品说明书指明范围
D测试人员主观认为不合理的地方
多选题
1.软件验收测试的合格通过准则是：（A，B，C，D）
A软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求
B所有测试项没有残余一级，二级和三级错误
C立项审批表，需求分析文档，设计文档和编码实现一致
D验收测试工件齐全
2.软件测试计划评审需要哪些人员参加（A，C，B）
A 项目经理
B 软件质量保证负责人
C 配置负责人
D 测试组
3.软件测试设计活动主要有：（A,B,C,D）
A 工作量分析
B 确定并说明测试用例
C 确立并结构化测试过程
D 复审并评估测试覆盖
4.测试设计员的职责有：（A,B）
A 制定测试计划
B 设计测试用例
C 设计测试过程，脚本
D 评估测试活动
5.软件测试常用的性能测试工具（A,C,）
A jmeter
B postman
C LoadRunner
D Flidder

Load Runner分为三个模块：Vugen（用于开发脚本、Controller（用于建立用户场景）、Analyser（对测试结果进行统计分析）

常见的黑盒测试方法：等价类划分法、边界值分析法、因果图、场景法、错误推测法等

典型的软件测试过程模型有：瀑布过程模型（Wiston Royce）、增量模型(1996 史蒂夫. 迈克尔康奈尔)、演化模型：快速原型、演化模型：螺旋模型（1988 Barray Beohm）、演化模型：喷泉模型（1990 B.H Soller/ J.M Edwards） 等

在测试中的80-20原则是指：我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

目前Unix 操作系统提供的一个常用的文本编辑器是vi , 其有 指令模式，编辑模式，命令行命令模式。三种模式

软件的六大质量特性包括功能性、可靠性、易用性、效率性、软件维护性、软件可移性

软件缺陷产生的原因包括：软件说明书、设计，编写代码 以及其他原因。

jmeter测试元件的执行顺序：
1、线程组
2、配置元件
3、前置处理器
4、定时器
5、取样器
6、后置处理器(如果存在且取样器的结果不为空)
7、断言(如果存在且取样器的结果不为空)
8、监听器(如果存在且取样器的结果不为空)

ORALCE数据库默认的监听端口号为1521 ;MYSQL的默认端口号为3306

使用Loadrunner的步骤:
1、测试分析
2、 创建虚拟用户脚本
3、 创建运行场景
4、 运行测试脚本
5、 监视场景
6、 分析测试的结果

软件测试是通过运行程序来查看错误。（×）

验收测试是以最终用户为主的测试。（√）

测试程序仅仅按预期方式运行就行了。(×)

回归测试是用于验收改变了的系统或组件是否保持原有的特性。（√）

好的测试员不懈追求完美。（×）

软件测试工具可以代替软件测试员。（×）

软件测试是一个过程，包含若干活动，运行软件进行测试只是活动之一。（√）

自动化测试可能延误项目进度。（√）

软件测试是有效的排除软件缺陷的手段。（√）

只要能够达到100%的逻辑覆盖率，就可以保证程序的正确性。（×）

什么是软件测试
软件测试的基本操作就是找bug；可以理解为在规定条件下对程序进行操作，找出错误，并对程序或者系统是否满足预期功能做出评估

软件测试的目的
使用人工或自动化手段来运行或测定某个系统的过程，其目的在与检验是否满足规定的的需求或是弄清预期结果与实际结果之间的差距。
测试的目的是验证需求，而bug是这个过程中的产品而非目标。

什么是集合点？设置集合点有什么意义？Loadrunner中设置集合点的函数是哪个？
集合点:是一个并发访问的点，例如在测试计划中，可能会要求系统能够承受1000人同时提交数据，在LoadRunner中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner就会检查同时有多少用户运行到集合点，如果不到1000人，LoadRunner就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000人时，LoadRunner命令1000人同时去提交数据，并发访问的目的。
注意:集合点经常和事务结合起来使用，常放在事务的前面，集合点只能插入到Action部分，vuser_ init和vuser end中不能插入集合点。集合点函数如下:
lr_ rendezvous (“SubmitData” )

性能测试中tps如果上不去原因有哪些？
1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2、连接池
可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
3、垃圾回收机制
从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS 也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
4、数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等， 就会导致数据库事务处理过慢，影响到TPS。
5、通信连接机制
串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
6、硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
7、压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。

8、压测脚本
以jemter举个例子，之前遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。
还有录制的脚本，需要删除一些不必要的脚本，对脚本进行优化，免得这些不必要的请求占用资源。
提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。

9、业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。

10、系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。

响应时间和吞吐量之间的关系是什么？响应时间越短，单位时间内的吞吐量越大；响应时间越长，单位时间内的吞吐量越小。
tps和qps的区别
QPS：Queries Per Second，意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器（比如是读写分离的架构，就是读的服务器）在规定时间内所处理流量多少的衡量标准。
TPS：TransactionsPerSecond，意思是每秒事务数，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数
jmeter的接口测试、jmeter的压力测试、jmeter的参数化关联
接口测试：
1 添加线程组
在“测试计划”上点击鼠标右键–>添加–>threads(Users)–>线程组。
2 添加http请求
在“线程组”打开鼠标右键–>添加–>sampler–>http请求

添加完http请求后，填写对应的域名、接口以及请求参数，如下图所示：

3 添加断言

在每一个http请求下，都应该增加一层判断机制（response的关键字），即添加结果断言。
在“http请求”打开鼠标右键–>添加–>Assertions–>response Assertion

4 查看请求结果
在“线程组”打开鼠标右键–>添加–>监听器–>察看结果树、断言结果、聚合报告

压力测试
1、打开Jmeter，添加线程组
2、添加HTTP请求
3、添加查看结果树
4、填写HTTP请求信息
5、运行
6、查看结果
7、添加断言
8、添加断言结果
9、使用命令的方式进行压力测试
10、查看压力测试报告
jmeter的参数化关联

新建线程
建立一个HTTP请求和一个查看结果树
在线程里新建一个用户定义的变量

之后运行就会有数据

jmeter的正则提取器的使用（获取token值）
注意：需要在返回的数据中有token值的时候用（我用的是在app上抓的地址）

新建登录接口

登录接口中新建正则表达式提取器

3.通过fiddler抓取到的信息看，token值是在cookie里面

4.增加信息头管理器，把token放到cookie里面

5.新增一个请求，看一下，是否把token值传递过去了

6.看一下token是否在cookie data中

7.数据返回成功

session cookis token的区别
cookie
cookie：浏览器与服务器进行会话时,产生一种本地存储技术
session：
Session其实是利用Cookie进行信息处理的，当用户首先进行了请求后，服务端就在用户浏览器上创建了一个Cookie，
当这个Session结束时，其实就是意味着这个Cookie就过期了。
cookie和session的共同之处在于：
cookie和session都是用来跟踪浏览器用户身份的会话方式。
cookie 和session的区别是：
cookie数据保存在客户端，session数据保存在服务器端
(1)cookie数据存放在客户的浏览器上，session数据放在服务器上
(2)cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，
如果主要考虑到减轻服务器性能方面，应当使用COOKIE
(4)单个cookie在客户端的限制是4K，就是说一个站点在客户端存放的COOKIE不能4K。
(5)所以：将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中
在测试的过程中如何获取token值 （2个接口的上下游之间来实现获取token
在一个线程组中，B请求需要使用A请求返回的数据，也就是常说的关联，将上一个请求的响应结果作为下一个请求的参数，则需要对A请求的响应报文使用后置处理器，其中最方便最常用的就是正则表达式提取器了。
一、首先来介绍一下Jmeter中正则表达式提取器的元素组成，下图所示：
下面是各参数值的含义：

这种最简单的情况在Jmeter正则表达式提取器和HTTP请求中的设置如下：

这种情况在Jmeter正则表达式提取器和HTTP请求中的设置如下：

若希望取到17这个值，则对应的是第二列第二行（2 22, j a v a w d g 2 ） ， 如 果 是 第 三 列 第 四 行 的 数 据 ， 则 对 应 的 是 （ 333 , {javawd_g2}），如果是第三列第四行的数据，则对应的是（3 33, javawd
g
​
2），如果是第三列第四行的数据，则对应的是（333,{javawd_g4}）