测试面试（自用）-CSDN博客

c、了解你的前任。他或她有哪些长处?如果还能联系到他们，他们能提供指导吗?如果联系不到他们，谁是他们信任的同事?在高级职位上，重要的是发出这样的信号，你不是个替换者;你就是你自己。但明白你的前任看重什么是明智之举，只要确保你不会不知不觉地受到挫折。在职位描述之外还有很多东西，所以确保你明白了每个人都希望什么。

你希望通过这份工作获得什么?

对我来说，最重要的是自己所做的工作是否适合我。我的意思是说，这份工作应该能让我发挥专长——这会给我带来一种满足感。我还希望所做的工作能够对我目前的技能水平形成挑战，从而能促使我提升自己。

个人长期目标短期目标

同所有现实目标一样，我的目标经常改变。不论在长期还是短期，我的个人策略是根据当前目标评价自己所处的位置，然后相应地修改自己的计划。比如，我每五年就制定一项个人计划，这个计划中包含一个总体目标和一系列短期目标。每6 个月我就回顾一下自己的进展，然后做出必要的修改。很明显，我当前的计划就是实现职业转变，也就是找到更满意的工作。除此之外，我已经实现了近期制定的个人目标。

你还有什么问题

贵公司对新入公司的员工有没有什么培训项目，我可以参加吗? 这个问题看上去可有可无，其实很关键，HR 不喜欢说“没有问题”的人，因为其很注重员工的个性和创新能力。HR 不喜欢求职者问个人福利之类的问题，如果有人这样问：贵公司对新入公司的员工有没有什么培训项目，我可以参加吗?或者说贵公司的晋升机制是什么样的? HR 和公司将很欢迎，因为体现出你对学习的热情和对公司的忠诚度以及你的上进心。

为什么你希望来我们公司工作?

你可能说你的研究表明这个公司所做的工作正是你说希望参与的，并且他们做这个工作的方式极大的吸引了你。例如，如果这个公司由于强大的管理而着称，纳闷你的答案可以提到这个事实，并表示你希望成为这个小组的一员。如果这个公司着重强调研发，那么就强调你希望创造你的事物，而你知道这个公司非常鼓励这样的行为。如果这个公司强调经济控制，你的答案就应该包含对数字的热爱。

自我介绍

你好，我叫XX,我现在就读于重庆工程学院软件工程专业，于大二下学期加入重庆工程学院软件研究所开始了项目制的学习，一开始学习了性能测试和自动化测试在智慧农业牧业养殖系统项目中，通过jemeter性能测试评估农牧惠养殖平台在高负载和大规模数据情况下的性能，如查询速度、响应时间、并发用户支持等，通过设计并实现简单的自动化测试脚本，提高测试效率，减少人工错误，在大三上学期加入研究所项目组开始接触商业项目，最近在做的一个项目财税票RPA系统测试平台我的职责就偏向于数据核对以及缺陷跟踪，例如财税票的采集，数据解析，调用接口完成接口测试，以及测试计划测试用力的编写以及执行，现在还在进行一些基础的python测试脚本的编写

性能测试

JMeter性能测试步骤可以简单概括为以下几个步骤:

1.建立测试计划:在JMeter中创建一个新的测试计划，设置线程组、目标服务器等参数。

2.添加测试元素:向测试计划中添加需要测试的元素，如HTTP请求、FTP请求、数据库请求等。

3.配置测试元素:对每个测试元素进行参数配置，如设置请求的URL、请求方式、请求参数等。

4.添加断言:为了验证测试结果的准确性，可以添加断言来检査返回结果的正确性。

5.添加监听器:添加监听器来监听测试结果，如査看响应时间、吞吐量等。

6.运行测试:启动测试，并根据需要监控服务器端的性能指标。

7.分析测试结果:查看测试结果并进行分析，如查找性能瓶颈、优化系统配置等。

目前主要的测试用例设计方法是什么？

白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖

黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法

软件产品质量特性是什么?

功能性：适应性、准确性、互操作性、依从性、安全性。

可靠性：成熟性、容错性、易恢复性。

可使用性：易理解性、易学习性、易操作性。

效率：时间特性、资源特性。

可维护性：易分析性、易变更性、稳定性、易测试性。

可移植性：适应性、易安装性、遵循性、易替换性

测试人员在软件开发过程中的任务是什么？

1、尽可能早的找出系统中的 Bug；

2、避免软件开发过程中缺陷的出现；

3、衡量软件的品质，保证系统的质量；

4、关注用户的需求，并保证系统符合用户需求。

总的目标是：确保软件的质量。

在您以往的工作中，一条软件缺陷（或者叫 Bug）记录都包含了哪些内容？

如何提交高质量的软件缺陷（Bug）记录？

一条 Bug 记录最基本应包含：

bug 编号；

bug 严重级别，优先级；

bug 产生的模块；

首先要有 bug 摘要，阐述 bug 大体的内容；

bug 对应的版本；

bug 详细现象描述，包括一些截图、录像....等等；

bug 出现时的测试环境，产生的条件即对应操作步骤；

高质量的 Bug 记录：

1) 通用 UI 要统一、准确，

缺陷报告的 UI 要与测试的软件 UI 保持一致，便于查找定位。
2) 尽量使用业界惯用的表达术语和表达方法

使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

3) 每条缺陷报告只包括一个缺陷

每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。

4) 不可重现的缺陷也要报告

首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现

的频率。

5) 明确指明缺陷类型

根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。

6) 明确指明缺陷严重等级和优先等级

时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装

饰性问题可能被当作高优先级。

7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

如何测试一个纸杯？

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；

盛上汽油（案例二）放 24 小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？

软件测试计划是指导测试过程的纲领性文件：

领导能够根据测试计划进行宏观调控，进行相应资源配置等

测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等

便于其他人员了解测试人员的工作内容，进行有关配合工作

包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测

试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成

员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程

的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划编写 6 要素（5W1H）：

why——为什么要进行这些测试；

what—测试哪些方面，不同阶段的工作内容；

when—测试不同阶段的起止时间；

where—相应文档，缺陷的存放位置，等；

who—项目有关人员组成，安排哪些测试人员进行测试；

how—如何去做，使用哪些以及测试方法进行测试

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要

从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法

（最好是能先评审）。

详细的描述一个测试活动完整的过程。（供参考，本答案主要是瀑布模型的做法）

项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成

需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突

或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户

的意见，完成项目计划。然后 SQA 进入项目，开始进行统计和跟踪

开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内

容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档，测试

计划包括的内容上面有描述。

测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要

设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

测试用例完成后，测试和开发需要进行评审。

测试人员搭建环境

开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测

试，发现 BUG 后提交给 BugZilla。

开发提交第二个版本，包括 Bug Fix 以及增加了部分功能，测试人员进行测试

软件测试的策略是什么?

软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的

特定环境约束而规定的软件测试的原则、方式、方法的集合。

软件测试分为几个阶段各阶段的测试策略和要求是什么?

和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验

收测试四个主要阶段：

单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正

确性检验的测试工作，通常由开发人员进行。

集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发

现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行

联合调试，因此在大部分企业中集成测试是由开发人员来完成的。

系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证

各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测

试部门最大最重要的一个测试，对产品的质量有重大的影响。

验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要

求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来

说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行

文档测试。

单元测试测试策略：

自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一

个好的选择。

自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。

孤立单元测试策略：最好的单元测试策略。

集成测试的测试策略：

大爆炸集成：适应于一个维护型项目或被测试系统较小

自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底

层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽

早被验证；希望尽早能看到产品的系统功能行为。

自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件

较早被完成。

基于进度的集成

优点：具有较高的并行度；能够有效缩短项目的开发进度。

缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。

系统测试的测试策略：

数据和数据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；

强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测试；配置测

试；安装测试；加密测试；可用性测试；版本验证测试；文档测试

问：给你一个网站，你如何测试？

首先，查找需求说明、网站设计等相关文档，分析测试需求。

制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测

试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试

设计测试用例：

功能性测试可以包括，但不限于以下几个方面：

链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的

出错信息返回。

提交功能的测试。

多媒体元素是否可以正确加载和显示。

多语言支持是否能够正确显示选择的语言等。

界面测试可以包括但不限于一下几个方面：

页面是否风格统一，美观

页面布局是否合理，重点内容和热点内容是否突出

控件是否正常使用

对于必须但未安装的控件，是否提供自动下载并安装的功能

文字检查

性能测试一般从以下两个方面考虑：

压力测试；负载测试；强度测试

数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的

存取操作，数据内容的验证等方面。

安全性测试：

基本的登录功能的检查

是否存在溢出错误，导致系统崩溃或者权限泄露

相关开发语言的常见安全性问题检查，例如 SQL 注入等

如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者

获取支持

兼容性测试，根据需求说明的内容，确定支持的平台组合：

浏览器的兼容性；

操作系统的兼容性；

软件平台的兼容性；

数据库的兼容性

开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，

建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资

源等内容）。

定期评审，对测试进行评估和总结，调整测试的内容。

什么是软件测试？软件测试的目的与原则

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试的目的：

测试是程序的执行过程，目的在于发现错误

一个成功的测试用例在于发现至今未发现的错误

一个成功的测试是发现了至今未发现的错误的测试

确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。

确保产品满足性能和效率的要求

确保产品是健壮的和适应用户环境的

软件测试的原则：

测试用例中一个必须部分是对预期输出或接过进行定义

程序员应避免测试自己编写的程序

编写软件的组织不应当测试自己编写的软件

应当彻底检查每个测试的执行结果

测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效

和未预料到的输入情况

检擦程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序

是否“做了其不应该做的”

应避免测试用例用后即弃，除非软件本身就是个一次性的软件

计划测试工作时不应默许假定不会发现错误

程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比

软件测试是一项极富创造性，极具智力的挑战性的工作