测试面试总结

最新推荐文章于 2024-03-11 23:30:00 发布

点点圈�

最新推荐文章于 2024-03-11 23:30:00 发布

阅读量230

点赞数 1

文章标签：面试前端职场和发展

本文链接：https://blog.youkuaiyun.com/w1958199625/article/details/121718691

版权

本文探讨了web应用的浏览器兼容性测试，强调了浏览器内核和系统兼容的重要性，对比了web与app的测试区别，涉及参数化测试（如JMeter中的CSV读取）、Fiddler抓包技巧和接口测试要点。同时，文章还涵盖了bug管理、提交规范和测试用例设计的关键要素，以及如何通过日志分析定位前端后端问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、app，web的兼容性怎么测的？

web：web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容（Windows7、Windows10、 Linux等），不过一般还是以浏览器的为主。而浏览器的兼容测试一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。

app：app的则是兼容的手机设备，不同品牌，不同分辨率，不同的Android版本，甚至不同的操作系统的兼容测试。系统总的来说也就分为Android和iOS，使用Testin这样的商业工具也可以做测试。

二、app和web的区别

web项目，一般都是b/s架构，基于浏览器的，而app则是c/s的，必须要有客户端

性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU等

兼容方面，web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主，在不用浏览器进行测试。app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。在不同操作系统测试。

三、Jmeter如何做参数化?

方式一: CSV DATA SET Config(线程组, 右键添加, 配置原件中)

1. 使用文本文件可以将.txt后缀,直接修改为 .csv格式,即可.

2. 使用excel文件, 必须通过另存为 CSV逗号分隔方式才可以被识别.

方式二: 通过函数助手对话框, 选择__CSVread

1. 数据文件的路径及名称

2. 列号

点击生成, copy生成后的引入方式即可使用.

四、fiddler抓包主要看哪些点?如何打断点?

**(1)**1. 没有接口文档时, 可以以抓取的接口为参照

2. 用于定位问题.(前端/后端问题)

1. 通过页面发起请求, 抓包, 抓包之后确认一下,前端传递数据的准确性

2. 前端调用接口的逻辑是否通畅

3. 是否有多次/冗余调用

4. 后端响应中, 1. HTTP协议响应状态码 2. 响应数据是否准确

5. 业务逻辑是否正确

(2) rules --> automatic breakpoints --> before requests after responses

五、接口测试的重点,与你认为的难点

(1)重点：关注业务逻辑，和业务逻辑产生的数据，会分析接口文档

(2)难点：对关联接口，要清楚接口之间的数据依赖关系。对前、后台的数据交互过程、后端业务处理逻辑非常清楚。

六、为什么要做接口测试？

1、接口测试位于测试的前期阶段，越早接入测试，发现问题的成本越低。

2、接口测试相对容易实现自动化持续集成，且相对UI自动化也更加稳定，可以减少回归测试人力成本与时间，缩短测试周期，支持后端快速迭代需求。接口持续集成是为什么能低成本高收益的根源。

3、现在多数系统采用前后端分离架构，从安全层面来说：

a. 为防止直接绕过前端，在篡改请求数据后发起请求，所以前后端有时需要进行同样进行校验，在这种情况下就需要从接口层面进行验证。

b. 前后端敏感数据传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如姓名、手机号、身份证、银行卡、登录密码等。、

七、测试流程

从产品经理手中拿到需求规格说明书，先进行需求分析，然后需求评审，然后编写测试计划,编写测试用例，测试用例的评审，执行测试用例，提交bug，用禅道工具进行bug’的跟踪，回归测试（bug的修复情况）测试总结。等待下一版本的测试。

八、提bug后开发不认同如何处理？

(1)先对需求分析，确认此bug是否为真正的bug

(2)如何看缺陷的等级，如果是比较严重的bug，一定要先告知开发，分析利弊

(3)保存bug的复现记录，截图或者视频，保留证据

(4)在沟通无效后，如果是事态紧急，很严重的bug，要找领导解决。

九、如何提交BUG

Bug标题，bug状态，bug编号。发现人、提交人、指定处理人、严重程度、所属模块、重现步骤、附件。

十、测试用例包含什么

所属模块，用例标题，前置条件，重要级别，测试输入，操作步骤，预期结果

十一、测试计划/方案里面包含什么内容？

1、测试目标：对测试目标进行简要的描述。
2、测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
3、测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
4、重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
5、质量目标：制定测试软件的产品质量目标和软件测试目标。
6、资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
7、人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
8、测试策略：制定测试整体策略、所使用的测试技术和方法。
9、发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
10、测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的。

十二、如何进行需求评审

需求评审必须要有用户或用户代表参与，同时还需要包括项目的管理者、系统工程师、相关开发人员、测试人员、市场人员、维护人员等。在项目开始阶段就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏部分人员的意见，导致需求的缺失。

对需求的评审应从以下几个方面进行：

完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或相关标准规定不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的限制范围内可以实施的。
无二义性：对所有需求说明都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：每项需求的制定都是必要的且能够追溯的。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在软件需求说明书中出现一次，这样更改时易于保持一致性。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明。

十三、会搭建测试环境么？你们测试环境包括什么？

（1）.搭建测试环境

如果你需要搭建的测试环境是刚装的linux操作系统，上面没有tomcat和数据库，那需要在搭建测试环境之前先装tomcat和数据库
1.安装jdk
如果有自带，先卸载再装
1.把包复制/usr/local
2.解压
3.配置环境变量
export JAVA_HOME=/usr/local/jdk1.7.0_71
export CLASSPATH=.: $JAVA_HOME/lib/dt.jar:$ JAVA_HOME/lib/tools.jar
export PATH= $JAVA_HOME/bin:$ PATH
4.检查java是否安装成功
java -version
2.安装tomcat
1.把下载的tomcat包复制/usr/local
2.解压
3.在tomcat/bin目录执行startup.sh文件
启动服务
在浏览器中连接：IP:8080
4.如果连接不上，但tomcat又是显示启动OK，检查firewall
路径为 /etc/sysconfig/iptables，将8080端口开启
5.重启服务
3.安装数据库
数据库一般安装mysql和oracle多一些
首先下载相应的数据库安装包
mysql安装比较简单，可以使用源码安装，也可以使用yum在线安装，在这里简单地介绍一下yum在线安装
用yum在线安装
\1. rpm -qa|grep mysql --检查linux是否有存在的mysql
2.如果有mysql,卸载
rpm -e --nodeps mysql
3.安装
yum install mysql-server mysql mysql-dev -y
4.安装成功后，启动服务
service mysqld start
service 服务名 restart/start
5.直接输入mysql 进入到数据库

十四、你认为做好测试用例工作的关键是什么？

需求和设计文档的理解程度，对系统的熟悉程度**

十五、简述一下缺陷的生命周期？

提交->确认->分配->修复->验证->关闭

十六您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

十七、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。