📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

1、软件的生命周期

计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne）

2、什么是软件测试，测试的目的是什么

定义：

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

目的：

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

软件测试为了发现程序中存在的代码或业务逻辑错误

软件测试为了检验产品是否符合用户的需求

软件测试为了提高用户体验

软件测试的原则：

测试应尽早启动、介入（需求分析阶段），所有的测试应追溯到用户需求，测试证明软件存在缺陷，不可能执行穷尽测试，完全测试是不可能的，测试需要终止。

二八原则，测试发现的错误中80%很可能的起源于20%的模块中。（缺陷存在群集现象）

对错误结果要进行一个确认的过程（测试的详细数据，截图，前置条件等），制定严格的测试计划；妥善保管测试过程中的所有文档；程序员尽量避免自己的检查程序；设计测试用例是应该考虑到合法的输入和不合法的输入

3、测试的流程，测试分为哪几个阶段

获取需求 ->测试方案计划编写 ->测试用例编写与评审 ->用例执行与bug提交验证 ->测试报告编写 ->版本上线与交付

需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。

制定初步的项目计划。

测试准备：组织测试团队、培训、建立测试和管理环境等。

测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计和测试脚本的开发等。

测试实施：按照测试计划实施测试。

测试评估：根据测试的结果，出具测试评估报告。

一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试

单元测试：是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。

集成测试：是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。

系统测试：是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。

验收测试：以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。

4、测试有哪些策略

黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）

4.1、单元测试对象，及策略有哪些

单元测试对象是模块内部的程序错误，目的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计，测试方法是采用白盒测试。

逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

单元测试测试策略：

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

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

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

4.2、集成测试有哪些策略

大爆炸集成、自顶向下集成、自底向上集成、三明治集成（适用于大部分软件开发项目）、基干集成、分成集成、基于功能集成、基于消息集成、基于风险集成、基于进度集成

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

自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。

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

4.3、系统测试有哪些策略

数据和数据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测试；版本验证测试；文档测试

5、测试的原则

追溯到需求

冒烟测试

按照用例全部覆盖测试

回归测试

业务流程测试

发散测试，尽可能的让问题提前暴露出来，避免随意测

6、测试退出的标准

系统测试用例已经通过评审

按照系统测试计划已经完成了系统测试

系统测试的覆盖率达到了100%

系统的功能和性能满足产品需求规格说明书的要求

在系统测试中发现的错误已经修改且各级缺陷修复率达到标准

系统测试中不存在A、B、C类缺陷

D类缺陷允许存在，不超过总缺陷的5%

E类缺陷允许存在，不超过总缺陷的10%

注：以上为比较理想化的退出标准，但实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷覆盖率不可能是100%，军方标准是达到99%。对于通用软件来说是根据公司实际情况。

7、软件测试类型有哪些

功能测试

性能测试（压力测试、负载测试、稳定性测试、并发测试、强度测试等）

安全测试

兼容性测试

配置测试

网络测试（弱网测试）

UI界面测试（分辨率测试）

安装测试

内存测试

文档测试

发散性测试

7.1、什么是兼容性测试？兼容性测试侧重哪些方面？

兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。

兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。

兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。

兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的

8、测试的分类

1、按测试技术分类（黑盒测试、白盒测试、灰盒测试）

黑盒测试：主要关注被测软件的功能实现，而不是内部逻辑。在黑盒测试中，被测试对象内部结构，运作情况对测试人员是不可见的。常见黑盒测试：功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等

白盒测试：对系统内部的结构和工作原理有清楚的了解，并基于该知识设计用例。白盒可以检测代码中每条分支和路径，揭示隐藏在代码中错误

灰盒测试：一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法，这种测试就称做灰盒测试

2、按测试方式分类（静态测试、动态测试）

静态测试：指不实际运行被测软件，只是静态地检查程序代码、界面或文档中可能存在的错误的过程

动态测试：运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程

3、diff测试

也可称为一致性测试，通过对比相同输入、相同接口，不同代码的测试，对比其结果的差异，从而发现潜在的bug

4、黑盒测试与白盒测试的优缺点

优点：

黑盒测试：简单、不需要了解程序内部代码的实现。从用户角度触发，自测过程中知道软件实现了哪些功能

白盒测试：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题

缺点：

黑盒测试：不可能覆盖所有的代码，覆盖率较低，大概质量达到总代码量的30%，自动化测试的复用性较低

白盒测试：程序运行有很多不同的路径，不可能测试所有的运行路径。测试基于代码，只能测试验证代码是否存在错误，无法验证设计正确与否，会存在遗漏功能需求。当系统庞大时，浪费时间。

α测试：是由用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

β测试：由软件的一个或多个用户在实际使用环境下进行的测试， 开发者通常不在测试现场，Beta测试不能由程序员或测试员完成

9、软件测试的风险

1、测试人员：业务不熟、人员变动、疲态、同化效应、定位效应

2、测试材料：需求变更，质量标准不一样，测试用例或测试数据设计不充分

3、测试环境：测试软件版本、硬件/软件环境等不统一、硬件不到位

4、测试时间：测试时间不足、测试时间延长

5、测试方法：错误或缺失测试方法、场景缺失、测试用例实施不充分

10、测试计划主要包含哪些内容？

背景、目标、范围、测试进度安排、测试组织、测试执行中开始与结束的标准、测试相关的风险

参考：https://blog.csdn.net/weixin_43664254/article/details/89239052

测试目标

测试概要

测试范围：测试计划所包含的测试软件需测试的范围和优先级、测试点（重点测试、无需测试、无法测试、推迟测试）

重点事项：列出需要测试的软件所有的主要功能和测试重点

质量目标：制定测试软件的产品质量目标和软件测试目标

资源需求：测试所需的软硬件、测试工具、必要的技术资源、培训、文档等

人员组织

测试策略：制定整体策略、测试技术和方法

发布提交：按照测试计划进行测试发布后的需要交付的软件产品、测试案例、测试数据和文档

测试进度和任务人员安排

测试开始/完成/延迟、继续的标准

测试风险

10.1、做好测试计划工作的关键是什么？

软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；

 做好测试计划工作的关键 ：目的，管理，规范

1）明确测试的目标，增强测试计划的实用性编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确

2）坚持“5W”规则，明确内容与过程“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。

3）采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。

4）分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

11、测试方案与测试计划的区别？

1、测试方案包括测试计划。测试方案一般在项目立项或者项目分析的时候，就需要考虑产品/项目的测试方案，测试技术，测试工具等。测试计划一般在项目执行时候，测试带组人员安排并编写，目的是按照待测版本需要多少人力

2、测试方案：描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计与选择、测试用例的设计方法、测试代码的设计方案。偏技术层面文档，主要什么技术、什么工具，怎么测试等

3、测试计划：描述了要进行的测试活动的范围、方法、资源和进度的文档。主要包括测试项、被测特性、测试任务和测试人员等。属于组织管理层面的文档，主要目标、时间、人员等

12、测试用例的设计方法有哪些？

黑盒：等价类划分法，边界分析法，因果图法，错误猜测法、场景法等

白盒：逻辑覆盖法，循环测试路径选择，基本路径测试

如：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则。

首先利用等价划分法，可以一个或多个结果是ok的测试用例，后确认多个NG的测试用例，后利用边界值分析法，对结果为ok和NG的测试用例进行补充。详见测试设计方法

1）等价类划分    

划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试。因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.    

2）边界值分析法    

边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.      

3）错误推测法    

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.      

4）因果图方法    

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况

13、测试用例通常包含哪些元素？

用例编号、用例标题、预知条件、操作结果、预期结果、重要级别、编写人、日期等

13.1、描述测试用例设计的完整过程？

1、需求分析 + 需求变更的维护工作；

2、根据需求得出测试需求；

3、设计测试方案，评审测试方案；

4、方案评审通过后，设计测试用例，再对测试用例进行评审；

14、测试用例评审都有哪些人参加？？

产品、开发人员、测试人员

目的：

1）用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖

2）优先级安排是否合理

3）是否覆盖测试需求上的所有功能点

4）用例是否具有很好可执行性。如 用例的前提条件等

5）是否已经删除冗余的用例

评审是对测试用例进行检查；评审类型：同行评审、小组评审、部门评审、三方评审评审目的：发现测试用例的不足，方便测试人员改进测试用例，提高测试质量评审过程：循环执行  “测试用例评审 --》改进测试用例”

15、怎么才能够全面地测试到每一个点？

测试的全面性主要在设计测试计划时考虑，从测试策略，产品需求等多个角度考虑从而定义全部的测试点

16、完整的测试有哪些？

需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）

需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求

测试计划：根据需求估算测试所需资源（人力，设备等），所需时间、功能点划分、合理分配安排资源等

用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例

执行测试：根据测试用例的详细步骤，执行测试用例

执行结果和bug记录：对每个case记录测试结果，记录管理bug

bug跟踪和关闭

测试报告：通过不断测试、追踪，直到被测试软件达到测试需求，无重大bug，整理测试报告

用户反馈、软件发布等

17、SQA的职责和工作活动(如软件度量)的理解?

SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案，必要时可以向高层经理汇报以求问题的解决。

通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。SQA主要的工作活动包括制定SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等；对项目开发过程中产生的数据进行度量等等。

18、什么是软件配置管理

项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制，配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大，配置管理就越显得重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并只有经过授权后才能变更这个标准。配置管理工具主要有CC，VSS,CVS,SVN等。

19、Beta测试与Alpha测试有什么区别？

Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场

Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试

20、缺陷的生命周期有哪些，内容？

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

硬件平台和操作系统

测试应用的硬件平台（Platform），通常选择“PC”。

测试应用的操作系统平台（OS）。

a) 版本  提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。

b) Bug报告优先级

c) Bug状态

d) Bug的编号

e) 发现人

f) 提交人

g) 指定处理人

h) 概述

i) 从属关系

j) 详细描述

k) 严重程度

l) 所属模块

m) 附件

n) 提交日期

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
​​
​​