面试八股文-测试理论_测试面试八股文

基础理论

测试用例的组成元素

用例编号

用例标题

功能模块名称

前置条件

输入数据

操作步骤

预期结果

优先级

执行结果

编写人

执行人

其他补充项

BUG描述、评级

对bug的描述尽量简短但要求清晰，对bug出现的条件进行详细的描述，包括输入的测试用例、使用的环境、有没有和其他软件同时运行，以及需要写清bug出现的位置，帮助开发更好定位。

按照用户体验（bug是否很严重的影响用户体验）、影响系统的程度进行评级。

一条bug记录的组成
（1）bug内容

（2）bug发现时间

（3）测试条件（系统配置信息、环境、软件版本、浏览器版本…）

（4）预期结果和实际结果的对比，相关的分析

（5）如何重现这个bug的步骤

（6）这个bug的严重性（会多大程度的影响系统或用户使用）

（7）bug发生的位置

性能测试

性能测试的指标

响应时间 ：用户发出请求到服务器处理完成请求返回给客户端的这段时间
吞吐量：衡量系统的业务处理能力。TPS:每秒事务数。QPS:每秒请求数
资源利用率： cpu、内存、网络、磁盘读写io。一般资源的利用率不高于70%-80%,如果某项高于这个值，则可能是性能瓶颈
错误率：系统在负载情况下，失败请求的概率。错误率=（失败请求数/总请求数）*100。和功能测试的错误相区别，在性能测试中，所谓的错误一般是指由系统超时引起的错误，而不是指功能错误。不同的系统错误容错率不同。普通的业务系统，错误率不超过万分之一就可以了，有的大型系统，亿分之一。
并发数：同时向服务端发起请求的虚拟用户数，在不同的工具里可以用多个进程/线程来实现

如果确定系统最大负载？

通过负载测试，不断增加用户数，随着用户数的增加，各项性能指标也会相应产生变化，当出现了拐点，如：当用户数达到某个数量级时，响应时间突然增长，那这个拐点就是系统的最大用户数。

如何识别系统瓶颈？

首先，要先做一份现有系统的性能测试报告，如cpu消耗、内存消耗、磁盘i/o,如果发现其中一项或多项达到瓶颈，那么就要考虑是硬件不够导致性能上不去，还是系统实现不合理导致满了；如果是硬件问题，那么就要考虑扩容；如果是资源都没到几线或确认系统实现有问题，那么就要针对性地对系统响应功能进行相应地拆解或者是监控函数级的耗时。

稳定性测试怎么做

稳定性测试主要看某个业务在高并发情况下是否能持续稳定运行，大部分核心业务都需要做稳定性测试，需要将并发数设置为峰值，然后循环次数设置为永远。

有验证码的功能，怎么做性能测试？

将验证码暂时屏蔽，完成性能测试后，再恢复；
使用万能的验证码。

并发数是怎么确定的？

先上线一段时间，根据收集到的用户访问数据进行预估；
根据需求来确定（使用高峰期，登录用户数，响应时间）。

如何分析性能测试结果？

首先看事务通过率，然后分析响应时间、CPU、内存等指标是否满足需求，如果结果不可信，则分析异常原因并复测

确定性能结果可信之后，如发现以下问题，按下面思路来定位问题：

1.响应时间不达标：首先看事务所消耗的时间主要是在网络传输还是服务器，如果是网络，就需要结合网络吞吐量图，计算宽带是否存在瓶颈，如果存在就需要考虑增加宽带；

如果不存在则有可能是网络不稳定导致的。如果是服务器，就要分别查看web服务器和数据库服务器的CPU、内存的使用率是否过高，因为过高的CPU，内存必定会造成响应时间过长；

2.服务器CPU指标异常：把web服务器对应上对应的用户操作日志取下来，发给开发定位；

3.数据库CPU指标异常：把数据库服务器对应上对应的日期取下来，发给开发定位；

4.内存泄漏：把内存的heap数据取下来，分析是那个对象消耗内存最多，然后发给开发定位；

5.程序在单用户场景下运行成功，多用户运行失败，提示连不上服务器：程序可能是单线程处理机制。

如果用户并发要慢慢加载，你会怎么设置？

设置并发数的时候，我们会设置启动时间，比如说设置50个并发用户数就是设置50个线程组，启动时间会设置成10秒，让用户慢慢起来。

响应超时，怎么定位的？

1. 首先考虑中间件（tomcat、apache的连接数问题），可以尝试增加连接数，看是否变化
2. 查看是否是数据库的连接数问题，也可以尝试增加，看是否有变化。
3. 查看数据库的访问效率，要考虑数据库的操作是否添加索引，如果没有添加索引，可以让开发优化下数据库的访问速度，添加索引，或者优化sql语句。
4. 查看后台代码的架构是否设计合理，代码算法是否足够优化。
5. 如果以上问题都不能解决，那么只能考虑增加服务器的cpu内存，或者增加网络带宽，看响应时间是否可以得到优化。

如果要做万并发，怎么做

考虑使用分布式压测，需要准备几台测试机，master机器要设置，奴隶机要设置。

并发用户数跟响应时间与吞吐量的关系

并发数越多，响应时间越长
并发用户越多，吞吐量会一直增加，增加到一个临界点（系统瓶颈）不再增加，有少许回落。

你们的吞吐量是多少，响应时间是多少，你设置了多少并发

登录：吞吐量大概在13.5/sec响应时间<1S,设置的并发数180.
查询：吞吐两大概在36/sec响应时间<3s，设置的并发数500.
下单：吞吐两大概在25.6/sec响应时间<3s，设置的并发数350.

以百度搜索为例，设计测试方案

功能测试：

• 输入搜索信息，点击搜索按钮是否能获取搜索结果，跳到结果界面；

• 搜索结果界面弹出的信息是不是符合我输入的信息

• 没有输入信息，按搜索看会有什么结果

• 对输入框能输入的最大字符数进行边界测试，（假设限制是30个字符），那么分别输入20，30，31个字符的文本进行测试，测试超出输入限制会出现的结果

• 测试输入敏感词时的搜索结果

• 输入不同国家语言的搜索结果

• 查询不到搜索结果的情况显示的结果

• 从搜索结果界面返回的按钮能不能正常返回

• 点击百度的标签能不能跳到相关的热搜界面

• 测试百度的图片搜索能不能正常使用

• 图片拖曳和上传的功能是否均能实现，粘贴图片网址能不能用

• 如果粘贴的图片网址不存在是否能给出正确的提示反馈

• 输入特别大的图会发生什么现象

性能测试：

• 测试搜索时的响应时间能否符合需求

• 网速慢的条件下还能不能正常搜索

• 多用户同时访问，或者一个时间点访问量突然增大的情况，对这些特殊情况进行模拟，测试还能不能进行正常搜索

易用性测试：

• 使用操作是否简单，是不是输入查询信息之后点击搜索按钮就行了；

• 在输入框输入搜索词的过程中下拉框能否弹出相关的联想搜索（你可能要搜）

• 输入框有没有保存最近搜索的信息的记录

• 除了点击搜索按钮进行搜索，测试按回车进行检索的功能

兼容性测试：

多种系统下的多种不同的浏览器下是否能正常显示、正常使用；

在不同的手机浏览器中打开是否能正常显示、正常使用；

各种语言平台下是否都能正常使用

安全性测试：

能不能防止搜索时对数据库的恶意攻击的情况，如SQL注入

UI

界面设计是否简介，是否符合用户审美

图标能不能正常显示，界面有无错别字

测试用例：上传文件

界面测试：

• 上传文件的按钮文字是否正确
• 上传后正确&错误提示的文字是否正确
• 说明性文字是否正确

文件名称测试：

• 上传的文件各为中文
• 上传的文件名称为英文
• 上传的文件名称中含有特殊字符
• 上传的文件名称为数字
• 上传的文件名为中文、英文、数字等组合名称
• 长传的文件名中含有空格

文件格式测试：

• 上传的文件名称长度超出限定范围
• 上传文件的格式为图片(Jpg， jpeg， png）
• 上传文件的格式为txt文本
• 上传文件的格式为word (后缀名为doc，docx)
• 上传文件的格式为视频
• 传文件的格式为音频
• 上传文件的格式为excel （后缀名为xls，xlsx）
• 上传文件的格式为ppt
• 上传文件为可执行的exe文件
• 上传文件的格式为压缩文件(.rar，.zip)
• 上传文件的格式为bat文件
• 上传文件的格式为jsp文件
• 上传文件的格式为iso镜像文件

文件大小测试：

• 上传文件的数量为1个
• 上传文件的数里为限制个数N个
• 上传文件的数量为限制个数N-1个
• 上传文件的数量为限制个数N+1个
• 上传文件的大小为0kb
• 上传文件的大小为2G以上的超大文件(超过限制大小)

其他测试：

• 上传文件方式，可以从目录中选择
• 上传的文件可以拖拽上传
• 上传的文件可以手动输入地址上传
• 手动输入正确的文件路径
• 手动输入错误(不存在)的文件路径
• 上传一个正在打开中的文件
• 文件上传成功后，上传后的文件名和文件内容是否正确显示
• 删除上传成功的文件，再次提交上传

性能测试：

• 上传文件时时网速很慢(限速)
• 上传文件过程中断网
• 上传过程中服务器突然停止工作

测试用例：微信扫码点餐

如何测试网站的高并发性

• jemeter多线程

• 测试多用户同时访问，访问量的缓慢增加/迅速增加。。。

• 大量相同类型访问，大量不同类型的访问

• 服务器角度，能够承受多大的压力（？），客户端角度，数据能否成功得到需要的信息，响应时间怎么样

• 实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息

• 一方面保证数据不丢失、一方面保证性能

测试一个前端页面，button按钮不好使，原因，不获取源码的前提下，如何解决（提示接口测试）

• 因为这是个前端界面，可以按F12打开开发者工具，在network里按钮点击时请求有没有发出去，看状态码，有没有生成新文件之类的，确定是不是连接的问题。
• postman模拟发包过去测试也行。

接口测试