Q1、什么是软件测试？
软件测试是验证和验证软件应用程序是否满足指定要求并能够正确工作的一系列过程。它通过运行测试用例来找出软件中的错误或缺陷，以确保软件的质量。
Q2、软件测试的目的？
软件测试的目的是：
- 发现缺陷：识别和修复软件中的错误和缺陷。
- 验证功能：确保软件按照需求文档规定的功能工作。
- 提高质量：通过检测缺陷，改进软件的可靠性和性能。
- 减少风险：确保软件没有重大缺陷，以降低项目失败的风险。
- 用户满意度：提高软件的可用性和性能，从而提高用户体验。
Q3、测试工程师的职责
测试工程师的主要职责包括：
- 设计和执行测试用例：根据需求和设计文档编写测试用例并执行测试。
- 缺陷管理：发现并记录软件中的缺陷，跟踪缺陷的修复。
- 回归测试：在修复缺陷后，进行回归测试以确保问题没有复发。
- 自动化测试：开发自动化测试脚本，提升测试效率。
- 协作沟通：与开发团队和项目经理沟通测试结果和缺陷。
Q4、什么是软件的生命周期？
软件生命周期（Software Development Life Cycle, SDLC）指软件从需求分析、设计、实现、测试、部署、运维到退役的全过程。常见的阶段包括：
- 需求分析
- 系统设计
- 编码实现
- 测试
- 部署
- 维护
Q5、软件带来错误的原因很多。主要的原因有哪些？
- 需求不明确或需求变化频繁：导致开发时未能正确理解需求。
- 设计缺陷：在系统设计阶段未考虑到所有场景。
- 编码错误：程序员在实现时犯的逻辑或语法错误。
- 不充分的测试：测试覆盖面不广，未能检测出所有缺陷。
- 环境问题：开发环境和生产环境不一致。
Q6、C/S 模式的优点和缺点
优点：
- 客户端可以处理复杂的任务，响应速度快。
- 可离线工作，客户端具有较高的自主性。
- 安全性较高，通信数据传输相对安全。
缺点：
- 开发和维护成本高，客户端软件需要定期更新。
- 需要不同平台的客户端支持，兼容性问题较多。
- 不适合大规模用户使用。
Q7、B/S 模式的优点和缺点
优点：
- 维护和部署方便，所有操作通过浏览器完成，不需要安装客户端。
- 适用于跨平台应用。
- 适合大规模用户访问，扩展性强。
缺点：
- 依赖网络，如果网络环境不好，用户体验差。
- 安全性较差，浏览器漏洞可能导致安全风险。
- 功能相对较弱，尤其是需要大量客户端运算的应用。
Q8、比较负载测试、压力测试，容量测试和强度测试区别
- 负载测试：评估系统在设计容量范围内正常或高负载情况下的性能。
- 压力测试：通过超过系统设计承受能力的方式，测试系统在高压情况下的表现。
- 容量测试：确定系统在资源限制下的最大承载能力。
- 强度测试：评估系统在长时间持续运行下的稳定性和性能。
Q9、比较黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系
- 黑盒测试：不关注内部代码结构，只测试软件功能是否符合需求。
- 白盒测试：关注代码的内部逻辑结构，测试路径、分支、循环等。
- 单元测试：测试代码的最小功能单元，通常是函数或模块。
- 集成测试：测试多个模块的集成和交互情况。
- 系统测试：在一个整体系统中，测试所有功能是否按预期工作。
- 验收测试：由客户执行，确认软件是否满足业务需求。
Q10、在软件开发过程中 5 个常见的问题是什么?
- 需求变更频繁：导致开发过程中经常需要调整设计。
- 沟通不畅：团队之间缺乏有效沟通，导致误解。
- 缺乏测试：未能进行充分测试，导致缺陷滞后暴露。
- 技术债：开发中临时解决方案过多，导致系统复杂度增加。
- 时间和成本超支：项目未按时交付，成本超出预算。
Q11、针对软件开发过程中的问题，有哪些解决方法？
- 明确需求：在项目开始前充分理解并锁定需求。
- 敏捷开发：采用迭代开发方法，定期反馈调整需求。
- 加强沟通：定期召开会议，确保团队信息透明。
- 自动化测试：引入自动化测试工具，提高测试效率。
- 技术债管理：定期重构代码，减少临时解决方案。
Q12、说出10个以上的Linux命令
ls：列出目录内容cd：切换目录pwd：显示当前工作目录cp：复制文件或目录mv：移动或重命名文件rm：删除文件或目录cat：显示文件内容grep：搜索文本内容chmod：更改文件权限ps：显示进程状态top：实时显示系统资源使用情况df：显示磁盘空间使用情况du：显示目录大小find：查找文件tar：压缩/解压文件
Q13、在RedHat中，从root用户切到user1用户，一般用什么命令？
使用 su - user1 或者 su user1。
Q14、Linux中，一般怎么隐藏文件？
在Linux中，文件名前加上点号（.），文件就会被隐藏。例如：mv filename .filename。
Q15、在Linux系统中，一个文件的访问权限是755，其含义是什么？
权限755表示：
- 文件所有者拥有读、写、执行权限（7 = rwx）。
- 同组用户和其他用户只有读和执行权限（5 = r-x）。
Q16、如何查看 CPU 信息？
使用命令 cat /proc/cpuinfo 或 lscpu。
Q17、查看占用 CPU 使用率最高的进程？
使用 top 或 htop 命令，然后查看列表中CPU使用率最高的进程。
Q18、如何查看一个文件的末尾 50 行？
使用命令 tail -n 50 filename。
Q19、如何过滤文件内容中包含”ERROR“的行？
使用命令 grep "ERROR" filename。
Q20、如何查询出 tomcat 的进程并杀掉这个进程，写出 linux 命令？
1.你们原来项目的测试流程是怎么样的？你可以跟我说一下吗？ 答：我们的测试流程主要有三个阶段：需求了解分析，测试准备和测试执行 第一步：我们会有一个需求澄清会议，我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等，产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致 第二步：会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人 负责的模块，然后我们就根据自己负责的模块用xmind（思维导图）进行测试需求分析，分析测试点，以及编写测试用例。 第三步：开发人员编写好代码之后，我们会把代码包部署到测试环境中，在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测。 在执行测试的过程中，我们如果重现有bug就会用禅道记录并且提交bug ，也会进行回归测试，一直到没有重现bug达到上线为止，每一轮测试结束之后我们都会写一个测试报告。一般情况下，测 试2-3轮之后会达到上线要求。上线前我们会做UAT测试，当达到上线的标准后，测试报告会认为测试通过，由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告， 总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进。
2.UAT测试是什么？ UAT测试（User Acceptance Testing，用户验收测试），一般是由具有代表性的用户来进行测试的，理论上来说该用户是精通系统业务逻辑的。在UAT测试结束之后，就可以发布生产环境了。
3.SIT测试是什么？ Sit测试（System Integration Testing，又称系统集成测试），是在单元测试之后需要进行的测试，一般是由公司测试人员来测试，目的是检验系统功能的性能、可靠性等。
4.你介绍下，你最熟悉的项目？（你们原来项目的主要的功能模块有哪些，你主要负责哪些模块？ ） 我最熟悉的项目是一个数字孪生智能监控巡检系统项目。这是一个由国家电网部署的系统，专为变电站设备的检修和维护人员设计的远程巡视管理服务系统。该系统不仅通过图文数据展示设备状态，还通过三维模型的形式直观呈现变电站内部设备的实时情况，用户可在前端点击各个设备模型或摄像头进行交互操作，从而查看设备的详细状态和运行情况，并在发现异常时进行记录和上报。项目的核心业务是通过远程数字孪生技术实现对变电站设备的全方位监控和管理，提升设备维护效率、降低人员巡检成本，并在异常情况发生时进行及时预警和响应。该系统的前端模块主要有：三维监控视图、设备状态展示、告警管理、历史记录查询、异常记录和统计分析等；后端主要负责设备数据的采集、存储和分析。在项目周期内编写并执行了超过150条测试用例，整个测试过程中共发现了56个缺陷，所有严重和中等缺陷都得到了及时修复，最终产品交付后未出现重大问题。
5.如何制定测试策略，特别是对于功能测试、性能测试和接口测试的优先级分配？ 在该项目中，我首先通过分析需求文档和设计文档，明确系统的核心功能和各模块之间的依赖关系。然后，根据业务优先级和风险评估制定测试策略。优先执行功能测试，确保系统的基本功能正常；其次是接口测试，验证前后端数据交互的正确性；最后进行性能测试，分析系统在高并发场景下的处理能力。在设计测试用例时，我确保了每个核心功能模块和重要接口都被测试覆盖，确保覆盖率达到90%以上。
6.你如何确定系统的性能瓶颈？是通过响应时间、吞吐量，还是其他指标？ 我通常通过多项性能指标来定位系统瓶颈。首先，在JMeter中设定不同的并发用户场景（如100, 500, 1000等），监测响应时间、吞吐量和资源使用情况（如CPU、内存）。如果响应时间显著上升，或者吞吐量达到峰值后没有增加，我会进一步分析是否存在数据库查询过慢、内存溢出等问题。
7.如何验证接口的稳定性和可靠性？ 对于接口测试，我首先设计了功能性测试用例，验证每个接口的正常逻辑流程。其次，通过模拟各种异常输入（如非法参数、缺失参数）来测试接口的鲁棒性。此外，我还编写了Postman集合，定期自动化运行，来检测接口的稳定性和返回数据的正确性。在返回数据不一致时，我会通过请求参数、后端日志和数据库状态进行排查，以快速定位问题。
8.如何进行缺陷的分类和优先级管理？ 我在管理缺陷时，通常将其分为“严重”、“中等”和“轻微”三种类型。对于严重缺陷（如系统崩溃、数据丢失等），我们要求开发团队在24小时内完成修复，并进行立即回归测试。中等缺陷（如某个功能异常但不影响整体流程）修复时限为3个工作日。对于轻微缺陷（如UI小问题），则安排在下一个版本修复。在缺陷修复后，我会优先进行回归测试，确保相同问题不会再次出现。
9.三维模型交互测试时，重点关注哪些内容？ 在测试三维模型交互时，我主要关注以下几点：视角旋转、缩放操作是否流畅；模型元素与实际数据的匹配度（如变电站设备的位置、大小与现实一致性）；以及用户点击模型时，设备详情信息的展示是否正确。此外，对于前端与后台数据的同步性，我会使用自动化脚本进行定时验证，确保设备状态在数据更新后实时反映在三维模型上。
10.如何模拟设备出现异常的情况？ 在测试告警管理模块时，我通常采用两种方式来模拟异常：一是通过后台修改设备数据（如手动将设备状态设置为“故障”），触发告警；二是通过编写模拟程序，生成高频异常数据，来测试系统对大规模告警的处理能力。我会关注系统是否能够正确记录告警信息，告警规则是否按预期触发，以及告警的处理逻辑（如通知用户、触发其他操作）是否正常。
11.如何处理自动化脚本不稳定的问题？ 在自动化测试中，脚本不稳定通常是由于元素识别失败或前端渲染速度不一致造成的。我通过以下几种方法来提升自动化测试脚本的稳定性：首先，使用显式等待而不是固定延时，以确保元素可见时再进行操作。其次，使用唯一且稳定的元素选择器（如ID或自定义属性）来定位元素，避免因页面布局变动导致定位失败。最后，对于三维模型的渲染异常，我会先行检查数据是否加载完毕，再进行交互操作。
12.产品是怎么上线的？ 首先，开发将代码打包到生产环境的服务器中，把代码包替换到服务器的目录中。如果数据表有变化，开发就会运行sql脚本，创建表，修改表的操作； 接着，我们测试就开始先测试主体业务功能以及新增的功能模块；测试通过之后，我们会在界面上把上线测试的数据删除，在规定的日期正常上线。 如果发现bug，开发人员当场修复bug，修复成功之后我们测试再复测，通过就可以正常上线。
13.你提交的bug，开发不认可怎么办？ 【首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug】 如果是bug再去让身边的同看看听下他们的意见，然后自己先再三确去复测，并且保存好截图和日志， 确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志。如果开发还是不认可的话我就跟产品或项目经理说明白情况
14.对应无法重现bug，应该怎么处理？ 首先，我会多测几次，测了好多次都无法重现的话我就先把bug挂起。并且留意一下，看看往后的测试中会不会重现类似代码的bug，因为有些是偶现bug。如果在后面的测试中重现bug就激活。如果经过几个版本都还没发现的话就关闭bug】
15.原来项目有遇到哪些经典的bug，你是怎么发现的，最后怎么解决的？ 问题描述： 在三维模型中，点击变电站某个设备时，弹出的状态信息与实际后台数据不一致。例如，某个变电设备的状态在后台数据库中显示为“异常”，但前端显示为“正常”。 发现方式： 在测试过程中，我设计了对三维模型的交互性测试用例，包括点击设备节点查看实时状态、状态变化后前端的实时更新等。在执行这些用例时，我发现某些设备的状态与后台数据对比存在不一致现象。为了进一步验证，我使用了以下几种方法：手动对比三维模型与数据库中的状态数据。 使用Postman调取设备状态接口，验证接口数据是否正确传递。 根本原因： 经过分析发现，该问题的根本原因是前端的WebSocket连接在某些情况下丢失或延迟，导致设备状态更新时没有及时推送到前端，造成了前端与后端数据不同步的情况。
16,数据库原来工作当中是怎么用的？ 原来我们数据库用的比较多的，就是数据结果检查，测试一些数据准备，性能测试造大量数据 测试执行到的结果，我们需要通过sql语句select来查找数据库对应的表，看看数据库信息跟我们执行的结果是否一致 我们在测试执行时需要做一些测试数据准备，我们就用insert into输入数据或（者 update set 修改数据），我们需要到数据库查看有没有相关记录保存，保存的数据跟我们输入或者修改的记录是否一致；比如：原来我们一个功能里面有个分页功能，测试分页功能，需要100条数据，我们就通过数据库操作添加100，可以用insert into。 insert into 表名 value（） insert ignore insert 表名 value（） 忽略主键重复 replace insert 表名 value（）主键或者unique索引重复时替换
17.接口测试怎么做的？ 分析接口需求文档： 首先，我会仔细阅读项目的需求文档、接口文档（API文档），明确每个接口的功能、请求方法（GET/POST等）、请求参数及其类型、响应格式、状态码和可能的异常情况。 重点识别核心接口，如设备状态更新接口、告警记录接口设计测试用例： 根据接口文档，设计详细的测试用例，包括： 正常测试用例：验证接口在输入正确参数时，能否返回预期结果。 异常测试用例：测试接口在输入非法参数（如类型不匹配、缺失参数、超出范围等）时，是否能正确返回错误信息。 边界测试用例：测试接口在极限输入值（如最大、最小字符长度）时的处理情况。 安全性测试用例：验证接口是否能够防御SQL注入、跨站请求伪造（CSRF）、敏感数据泄露等常见的安全问题。 为了保证测试覆盖率，我使用了“同类等价划分”、“边界值分析”等测试用例设计方法，确保所有可能的输入场景都被覆盖。 执行测试（使用Postman或JMeter）： 使用Postman作为主要的接口测试工具，通过手动验证接口返回数据的正确性和一致性。 对于批量接口测试，我使用了Postman的Collection Runner功能，批量执行接口测试，并生成详细的测试报告。 在进行压力测试时，我会使用JMeter，通过模拟多并发用户访问同一接口，检查接口在高负载时的表现、历史数据查询接口等，作为接口测试的重点。
18.协议了解有哪些？ HTTP协议:无状态,无连接,基于请求和响应：基本的特性，由客户端发起请求，服务端响应简单快速、灵活,通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性。 HTTPS协议:是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
19.性能测试怎么做的？ 创建测试计划（Test Plan） 步骤1：在JMeter中创建一个新的 Test Plan。 步骤2：为每个测试场景创建不同的 Thread Group，每个Thread Group对应一个测试场景。 线程数（Number of Threads）：设置并发用户数量。例如，设置为1000，表示模拟1000个用户同时访问。 Ramp-Up 时间（Ramp-Up Period）：设置并发用户启动的时间。例如，将1000个用户在60秒内逐渐启动，确保不是瞬间并发。 循环次数（Loop Count）：根据需求设置循环次数，通常设置为10次。
配置HTTP请求（HTTP Request） 步骤1：为每个Thread Group添加一个 HTTP Request Sampler。 步骤2：设置接口的请求URL和方法（GET、POST等），以及所需的参数。
模拟高并发测试 配置多个线程组，并同时启动，模拟系统在高并发、多场景下的负载情况。例如： 1000个用户同时查询设备状态。 500个设备同时上报告警信息。 300个用户同时查询历史数据。
启动JMeter，逐步增加线程数，观察系统的表现，记录响应时间、错误率和服务器端资源使用情况。 通过JMeter生成的 Summary Report、Response Time Graph 和 Aggregate Report，对测试数据进行分析，关注以下几个关键点： 平均响应时间（Average Response Time）：是否在预期范围内（例如是否小于2秒）。 最大响应时间（Max Response Time）：在高峰时段的最大响应时间是否超过阈值。 吞吐量（Throughput）：是否能够支持预期的请求数（如200 TPS）。 错误率（Error Rate）：是否存在错误请求或超时请求，错误率是否控制在1%以下。 资源利用率（Resource Utilization）：通过JVisualVM监控CPU、内存的使用情况，查看是否存在瓶颈。
- 查找Tomcat进程：
ps -ef | grep tomcat - 杀掉Tomcat进程：
kill -9 PID（PID为进程号）。
