软件测试工程师之——软件测试工程师 面试100题 基础篇持续更新中.....
Posted 测试萌萌
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试工程师之——软件测试工程师 面试100题 基础篇持续更新中.....相关的知识，希望对你有一定的参考价值。
1 软件的含义 程序、数据及相关文档的完整集合。
2 测试与调试的区别是什么？
测试是由测试人员来进行，主要目标是发现、报告和跟踪缺陷。 调试是由开发人员进行，主要目标是定位缺陷位置，分析缺陷原因，修复缺陷。
3 IEEE 是什么意思？
国际电气电子工程师协会
4 GB 是什么意思？
国家标准
5 软件测试的含义 简单讲，软件测试是发现缺陷的过程；
IEEE 中的定义是，软件测试是使用人工或自动手 段来运行或测定某个系统的过程，目的在于检验它是否满足规定的需求或弄清预期结果与实 际结果之间的差别。
6 软件测试的目的
（1）验证软件是否满足各类文档说明书等规定的软件质量要求
（2）找出软件缺陷
（3）为软件产品的质量测量和评价提供依据
（4）帮助开发改进开发流程
7 什么是功能、性能、兼容性 功能代表一个软件能做什么；
性能反映软件运行的速度或效率、占用资源的多少等指标； 兼容性表示一个软件与其所在运行环境的依赖程度，包括与硬件、操作平台、其他软件的依 赖。
8 测试分为哪几个阶段？每个阶段的测试目的是什么？
测试分为单元测试、集成测试、系统测试、验收测试四个阶段。前三个阶段的目的是尽 可能多的发现缺陷，而验收测试是要验证软件满足了用户需求，帮助用户建立系统可以正常 使用的信心，发现缺陷不是此阶段的目标。
9 解释 QA 及其职责 QA 的含义是软件质量保证（人员）。
主要职责是制定和加强促进软件开发并防止软件缺陷的标准和方法，并监督标准和过程 被正确的遵循。
10 测试工程师与软件质量保证的区别 测试工程师的主要任务是在最短的时间内发现尽可能多的缺陷，并确保这些缺陷得以修 复。软件质量保证的主要职责是制定和加强促进软件开发并防止软件缺陷的标准和方法，并 监督标准和过程被正确的遵循。
11 测试应该由什么人来进行？
测试应该由独立的第三方来进行，第三方表示测试人员不参与程序的开发。
12 pareto 法则、帕累托法则、28 原则、82 原则 一般情况下 80%的缺陷聚集在 20%的关键核心业务模块中，这个原则至少告诉我们在做 测试时，应该重点分析和测试 20%的核心业务，具体说要做好需求分析。
13 杀虫剂怪事 杀虫剂怪事用于描述软件测试越多，其对测试的免疫力越强的现象。这个现象告诉我们， 测试时，应尝试新方法、不同的测试程序，对程序进行测试，以找出更多软件缺陷。
14 木桶原理 木桶原理在软件方面的主要含义是全面质量管理，另外还告诉我们测试时要关注团队中 较弱的人。
15 Good-enough 原则 Good-enough 原则告诉我们做测试的时候既不要做过多测试，也不做不充分的测试。至 于多少测试合适，需要我们不断积累经验，在项目中可以指定最低测试通过标准和测试内容， 然后具体问题具体分析。
16 群集效应 群集效应的含义是发现的缺陷越多，证明软件存在的缺陷越多。群集效应指导我们在找 到软件缺陷的地方要继续找找。
17 什么是确认测试？回归测试？
确认测试也称再测试：缺陷修复以后，验证缺陷是否真正修复 回归测试：缺陷修复以后，确保对程序的修改没有给软件其他未改变部分带来新的缺陷。
18 测试人员应该具备哪些素质？
要有责任心，要有破坏的态度，对事不对人，三心二意（细心、信心、耐心、缺陷预防 意识、沟通意识），具有一定的开发技能，善于思考。
19 如果测试提交的缺陷开发人员不认可，该怎么办？
首先分析或与开发沟通开发不认可的原因。 如果拒绝原因是提交的不是缺陷，而且自己分析后，的确不是缺陷，则应该注意以后再 做测试时要做好复现，认真研读需求，提高自己找缺陷的能力。 如果拒绝原因是提交的不是缺陷 但自己分析时认为缺陷应该是存在的，则再次研读需 求并做好复现，拿出确实是缺陷的证据，然后与开发沟通。 如果拒绝原因是认可缺陷，但不予修复，如果自己觉得必须修复，则拿出充分理由和证 据和不修复的不利影响和影响范围，再与开发沟通。 注意沟通技巧，合理的论述，向开发说明自己的判断的理由，注意客观、严谨，不掺杂 个人情绪。 把问题交给测试经理，等待测试经理做出最终决定，如果仍然存在争议，可以通过公司 政策所提供的渠道，向上级反映，并由上级做出决定。
20 如何解决开发和测试的矛盾？
（1）以沟通和合作的方式开展工作
（2）提高开发技能
（3）换位思考
（4）进行有效沟通
21 测试团队中都有哪些角色？各负责什么任务？各有多少人？
测试负责人：制定测试计划，监督安排任务，进行测试总结，1 测试工程师：进行测试需求分析、设计用例、搭建环境、执行用例、提交并跟踪缺陷 ， 3 技术支持：负责环境维护，1 配置管理员：维护版本架构，维护版本库，文档配置，1 质量保证人员：负责软件质量方面的工作，1
22 什么是软件开发生命周期？
从软件最初构思到公开发行的过程。瀑布模型的过程是计划、需求、设计、编码、测试、 运行、维护循环。瀑布模型有严格的开发步骤，每个阶段是按顺序进行的，每个阶段都必须编写完整的文 档，每个阶段完成后必须经过审查才能进入下一步。 瀑布模型不能迭代、不能反复；测试在编码之后，测试太晚；测试的只是程序。
23 软件开发有什么模型？
软件测试主要有哪些模型？ 软件开发模型：大爆炸模型、边写边改模型、瀑布模型、螺旋模型、敏捷开发模型 软件测试模型：V 模型、W 模型、H 模型、X 模型、前置测试模型、敏捷测试模型
24 简述 V 模型。
V 模型的过程：用户需求→需求分析→概要设计→详细设计→编码→单元测试→集成测 试→系统测试→验收测试。
优点：
（1）V 的左端表示传统的瀑布开发模型，V 的右端明确地将测试分为不同的级别或阶 段，测试过程更为具体；
（2）测试各个阶段和开发的各个阶段相对应；
（3）V 模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性， 高层测试是为了整个系统满足用户的需求。
缺点：
（1）测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证 和确认的功能，直到后期的验收测试才被发现。
（2）测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系 统测试阶段才被发现。
25 简述 W 模型。
W 模型的过程：左边 V 是需求分析→概要设计→详细设计→编码实现→模块集成→系 统构建→系统安装；右边 V 是需求测试→概要设计测试→详细设计测试→单元测试→集成 测试→系统测试→验收测试。
优点：
（1）W 模型体现了尽早和不断测试的原则，既强调测试方案设计，也强调测试执行。
（2）左侧 V 是开发，右侧 V 是与开发并行的测试，相对于 V 模型，W 模型增加了软件 各开发阶段中应同步进行的验证和确认活动，W 明确表示出了测试与开发的并行关系。测 试与开发是同步进行的，有利于尽早地全面的发现问题。
（3）测试伴随整个软件开发周期，且测试的对象不仅仅是程序，需求、设计等同样要 测试。
缺点：
在 W 模型中，需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种 线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代 的开发模型，不利于当前软件开发复杂多变的情况。
26 简述 H 模型。
H 模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执 行活动清晰地体现出来。H 模型的测试流程是只要测试准备工作完成，达到测试就绪点，测 试就可以执行了。
优点：
（1）软件测试不仅仅指测试的执行，还包括很多其他的活动。
（2）软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。 当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
（3）H 模型反映出软件测试要尽早准备，尽早执行。
（4）软件测试可以进行迭代、反复进行。
27 敏捷开发 敏捷开发的核心思想是：以人为本，适应变化。 具体讲：
（1）认为个体和交互重于过程和工具，强调通过过程和工具理解个人和交流的作用；
（2）认为可用软件重于完备文档，强调通过全面的文档理解运行的软件；
（3）认为客户协作重于合同谈判，强调通过合同和谈判得到客户的协作；
（4）认为响应变化重于遵循计划，强调在计划的执行中做出对变更的响应。
特点：
（1）敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。
（2）敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好 “迎接变化”的准备，客户是敏捷的关键环节。
（3）敏捷开发没有单一固定的开发方法或过程，敏捷开发有三个共同点：依赖客户的 参与、测试驱动以及紧凑的迭代开发周期。
28 敏捷测试
（1）敏捷测试是协同测试的一种形式，程序员结对编程，程序员分饰测试员角色，敏 捷测试是连续测试。
（2） 敏捷测试侧重单元测试和验收测试。单元测试的过程是先设计单元测试用例，然 后进行编码，之后执行测试。
（3）敏捷测试强调客户参与，单元测试通过之后代码集成到代码库中，再由客户进行 验收测试，验收测试的结论反馈给开发人员，缺陷得以迅速修复。
29 软件质量要求有哪些？
功能要求和非功能要求。
30 软件非功能要求有哪些？
性能要求（负载测试、压力测试、容量测试、可靠性测试）、界面测试、兼容性测试、 易用性测试、文档测试、可用性测试、安装测试、安全测试、灾难恢复测试等。
31 简述测试的基本过程
（1）测试人员进行测试需求分析。
（2）测试负责人编写测试计划。
（3）测试人员根据测试需求分析设计和编写测试用例。
（4）测试人员搭建测试环境、创建测试数据、执行测试用例、提交缺陷报告并进行跟 踪、记录测试事件。
（5）进行测试评估和总结。 每一分步工作完成后都进行评审。
32 拿到一个软件后，应该怎样开始工作？
编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执 行测试用例、提交缺陷报告→进行评估和总结
33 怎么做测试？
编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执 行测试用例、提交缺陷报告→进行评估和总结
34 简介测试流程 编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执 行测试用例、提交缺陷报告→进行评估和总结。
35 怎么进行测试需求分析？
（1）收集各类文档，仔细阅读文档，提出问题，分析问题或沟通解决，整理需求信息。
（2）编写测试需求分析说明书：功能分解，编写检查点和测试点。
（3）需求评审。
36 拿到项目后，需要分析或咨询软件哪些方面的问题？
软件主要的功能、流程、开发环境（开发语言<含数据类型>、数据库、中间件）、运行 环境（硬件、软件、网络、软件架构）、用户群、测试范围、测试优先级。
37 什么时候提交发现的缺陷？
测试执行发现缺陷时立即提交缺陷。
38 什么是入口准则、出口准则？
入口准则是进行一项测试工作前需要准备好的前提条件。 出口准则是一项测试工作可以结束的前提条件。
39 需求评审都有哪些人参与？
项目经理、开发经理、测试经理、测试人员、开发人员、市场经理、客户等。
40 怎么做需求评审或者说需求评审需要评审哪些方面？
编写或设计需求评审检查单，比如可以检查有无错别字、病句，标点符号使用是否正确， 格式是否一致，是否还有多余需求，是否有错误需求，是否有遗漏需求等。
41 测试资源需求有哪些方面？
人力资源、硬件资源、软件资源。
42 什么是测试策略？什么是测试范围？
测试策略主要指如何进行某种测试（如功能测试、性能测试、兼容性测试、可用性测试、 易用性测试等），用于说明测试方法以及如何使用测试方法。测试范围有时候等价于测试策 略，有时候可以表示要进行测试的某个软件部位。
43 什么是 BVT？冒烟测试？版本验证测试？怎么测？
也称冒烟测试、版本验证测试、小版本验证测试、版本构建测试。冒烟测试用例是一组 想先运行以确定这个给出的小版本是否可以测试的测试用例。冒烟测试主要测试软件的基本 功能，以判断整个软件值不值得进行大规模测试。通常由一个人进行 1-2 小时的测试，一般 不测试次要功能和各种错误。
44 测试计划的内容和目的是什么？
包含了产品概述、测试区域/测试策略/测试范围/测试目标（测试项、被测特征）、测试 配置/测试资源、测试周期、进度安排（测试任务、人员安排）、测试方法/途径、测试交流、 风险分析等内容。目的是指导测试过程，规定测试活动的范围、方法、资源和进度；明确正 在测试的项目、要测试的特性、要执行的测试任务、每个任务的责任人以及与计划相关的风 险。
45 怎么判断是不是软件缺陷？
（1）软件未达到产品说明书标明的功能；
（2）软件出现了产品说明书指明不会出现的错误；
（3）软件功能超出产品说明书指明范围；
（4）软件未达到产品说明书虽未指出但应达到的目标；
（5）软件测试员具体问题具体分析，认为软件难以理解、不易使用、运行速度缓慢， 或者最终用户认为不好。
46 缺陷的产生主要有哪些原因？最主要的原因是什么？
需求频繁变更、沟通不良、不了解客户的需求、实现新功能或很酷的功能、追求新技术、 项目期限的压力、需求分析或设计投入的时间和精力不够、产品的复杂度、开发人员疲劳、 压力过大或受到干扰、缺乏足够的知识、技能和经验、缺乏动力等。 最主要的原因：需求方面的原因
47 当你发现一个缺陷时，应该怎么确认的确是一个缺陷？
根据缺陷的判断原则来甄别发现的问题是不是一个缺陷，发现缺陷后，应该做好分离和 再现（3 次），然后才能提交。
48 在正式提交一个缺陷前，你应该做些什么？
分离缺陷、再现缺陷（3 次），然后才能提交。
49 怎么处理无法再现的缺陷？ 首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员。 其次，对于寻找难以再现的缺陷要合理地安排时间，对一时难以再现的缺陷可以暂时搁 置，以保证项目的正常进度。 最后，在测试过程中对未再现缺陷予以关注。
50 什么是重复缺陷？怎么避免重复缺陷？
提交了一个缺陷库中存在或者开发人员已经知道的缺陷。
1、如果缺陷是跟同事提交的重复，任务分工解决，也可以在提交之前查询下库缺陷是 否存在。
2、如果缺陷是与自己提交的缺陷重复，则需要提高发现缺陷的能力，通过提高开发能 力来理解两个缺陷本质上是一个缺陷。
51 什么是无效缺陷？怎么避免无效缺陷？
提交的缺陷不是真正的缺陷。 充分了解需求、提高自己识别缺陷的能力、提高缺陷写作能力 52 缺陷报告的写作准则是什么？ Correct（准确）：每个组成部分的描述准确，不会引起误解； Clear（清晰）：每个组成部分的描述清晰，易于理解； Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； Consistent（一致）：按照一致的格式书写全部缺陷报告。
53 缺陷报告的内容有哪些？
缺陷标题（或者说缺陷摘要、缺陷概述、缺陷基本信息） 预处理 复现步骤 预期结果 实际结果 严重程度 优先级 测试环境 测试版本 测试执行人 注释
54 缺陷报告的组织结构是什么？
缺陷标题（或者说缺陷摘要、缺陷概述、缺陷基本信息） 预处理 复现步骤 预期结果 实际结果 严重程度 优先级 测试环境 测试版本 测试执行人 注释
55 缺陷报告的写作需要注意什么问题？
不要使用我、你、他等字眼，不要使用情绪化的语言和强调符号、不要使用“似乎”、 看上去可能等不确定性内容、不要使用认为比较幽默的内容、不要使用不确定的测试问题(不 确定是否是缺陷)、不要人身攻击。
56 简述缺陷报告的处理流程 软件测试人员提交缺陷报告；
测试负责人审核后将缺陷报告分配给相关的开发人员修改； 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测 返测通过的缺陷报告由负责人关闭； 返测未通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员返测，直到测试 和开发达成一致处理意见。
57 简述缺陷的生命周期 软件测试人员提交缺陷报告；
测试负责人审核后将缺陷报告分配给相关的开发人员修改； 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测 返测通过的缺陷报告由负责人关闭； 返测未通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员返测，直到测试 和开发达成一致处理意见。
58 简述重复缺陷的处理流程
提交缺陷→分配缺陷→是重复缺陷→置为无效缺陷。
59 缺陷按照严重程度可以分为哪些类型？
致命缺陷、严重缺陷、一般缺陷、较小错误、意见建议等
60 缺陷按照优先级可以分为哪些类型？ 缺陷必须立即解决； 缺陷需要正常排队等待修复或列入软件发布清单； 缺陷可以在方便时被纠正； 下一个版本修复； 不修复。
61 缺陷的状态有哪些？
新建/已提交 打开已拒绝 已解决/已修复 已验证 已关闭
62 测试有哪些级别？
单元测试、集成测试、系统测试、验收测试
63 测试有哪些阶段？
单元测试、集成测试、系统测试、验收测试
64 什么是单元测试？
单元测试谁来做？ 针对一个软件单元的测试。开发人员或懂开发的测试人员
65 什么是桩模块、驱动模块？
桩模块：被被测模块调用的模块。 驱动模块：调用被测模块的模块。
66 什么时候可以进行组件测试？
完成编译的测试对象，测试环境，开发工具，测试对象的规范说明书。
67 单元测试使用技术？测试重点是什么？测试条件是什么？
单元测试的技术：黑盒白盒技术，但是白盒居多，黑盒居少，一般先做黑盒再做白盒。 单元测试重点：功能性测试，健壮性（逆向测试：无效值），性能。 单元测试前提条件：完成编译的测试对象，测试环境，开发工具，测试对象的规范说明 书。
68 什么是集成测试？
组件间的接口与交互的测试。
69 集成测试的测试重点是什么？测试条件是什么？使用什么技术？
接口和系统内不同部分的相互作用（交互）。 测试条件是完成集成的被测系统，测试台，有关组件间交互的文档。 测试技术包括白盒技术、黑盒技术，白盒居多，黑盒居少，对比单元测试，白盒下降， 一般先做黑盒再做白盒。
70 集成测试有哪些策略？
自顶向下集成 自底向上集成
71 什么是系统测试？
对整个系统能不能满足用户需求的测试。
72 系统测试的目的是什么？
检查软件是否满足需求。
73 系统测试能够发现哪些缺陷？会遗留哪些缺陷？ 发现：非功能性缺陷、涉及整个系统的问题。 遗漏：对用户的需求的错误理解、没有实现或者没有完全实现用户的隐性需求。
74 什么是验收测试？ 一般由用户/客户进行的确认是否可以接受一个系统的验证性测试。验收测试根据用户 需求，业务流程进行的正式测试以确保系统符合所有验收的准则。
75 验收测试有哪些人进行？ 客户或用户，测试人员可以介入。
76 验收测试的目标是什么？
对系统或子系统建立信心、对系统非功能性的特性赢得信任。
77 什么是 alpha、beta 测试？有何区别？
Alpha 测试：潜在的客户/用户在开发场地进行的测试。 Beta 测试：由潜在客户/用户在自己的环境下测试软件系统。
78 什么是维护测试？ 软件正常使用后，对软件的变更、更新进行测试
79 什么是性能测试？负载测试？压力测试？有什么区别？
性能表现处理速度、响应时间、CPU 使用、内存使用、硬盘使用等。 负载测试：通过不断增加负载来测试一个系统的性能。 压力测试：通过增加负载超过系统正常工作能力来考察系统能否在异常情况下正常工作
80 什么是功能测试？
测试一个软件能做什么，是不是做了应该做的工作，没做不该做的工作。
81 什么是结构测试？
白盒测试也称结构测试、逻辑驱动测试、基于程序本身的测试，是对程序结构进行的测 试。
82 什么是与变更相关的测试？
有哪些具体类型？ 与变更相关的测试是对修改过的程序进行的测试。 确认测试（再测试）和回归测试。
83 什么是静态测试？动态测试？如何区分二者？
静态测试：不执行程序的测试。针对文档和不需执行的代码。动态测试需要执行程序，方法一般采用黑盒测试方法和白盒测试方法。
84 圈复杂度怎么计算？
不重叠的闭合环数+1
85 什么是黑盒测试？白盒测试？
黑盒测试也称功能测试，基于规格说明书的测试，关注输入数据到程序中，输出结果是 否正确，侧重于测试软件能做什么 白盒测试也称结构测试、逻辑驱动测试，是对程序内部逻辑结构进行的测试
86 白盒测试有哪些方法？具体解释每种方法？
白盒测试主要使用逻辑覆盖测试方法，包括语句覆盖、判定覆盖、条件覆盖、判定-条 件覆盖、条件组合覆盖、路径覆盖等。 语句覆盖：程序中的每个可执行语句至少被执行一次。能发现语句错误，但不能发现逻 辑错误。判定覆盖：也称分支覆盖，程序中的每个判定的取真分支和取假分支至少执行一次。能 发现逻辑错误，但不能发现组合判断中的条件错误。 条件覆盖：程序每个判定中每个条件的可能取值至少满足一次。能发现条件错误，但不 能发现逻辑错误。 判定-条件覆盖：每个条件中的所有可能取值至少执行一次，同时，每个判定的可能结 果至少执行一次。 条件组合覆盖：每个判定中的所有的条件取值组合至少执行一次。 路径覆盖：用例覆盖程序中的所有可能的执行路径。如果路径数很多，会变得不切实际。
87 什么是配置测试？
不同配置环境下进行测试。
88 什么是文档测试？
不仅包括测试文档校对，还有文档和软件不一致
89 什么是国际化测试？本地化测试？
国际性的软件 翻译成本国语言的，测试是否符合本国的语言习惯，是否符合本国法律，是否符合本国 的国情。
90 测试用例的内容是什么？
用例编号，测试概述或用例标题、测试步骤，预期结果，输入数据，优先级，前置条件 等
91 测试用例有哪些元素？
用例编号，测试概述或用例标题、测试步骤，预期结果，输入数据，优先级，前置条件 等 或者说测试目标 Why、测试对象 What、测试环境要求 Where、测试前提 When，输入 数据
92 什么是 UI、GUI？UI 测试什么意思？
界面图形界面 界面测试
93 测试用例的优先级如何？
冒烟测试 高中低
94 解释测试目标、测试环境、测试对象、前置条件、测试策略、测 试范围的含义？
测试目标：功能测试、性能测试、界面测试、易用性测试、兼容性测试、安全性测试 测试策略：某类别测试的过程、方法以及方法如何应用，测试的注意事项等 测试环境：硬件环境、软件环境、网络环境 前置条件：进行某些测试工作需要做好的准备条件 测试范围：软件需要测试的某个部位
95 用例评审一般使用什么方式？
哪些人参与评审？ 检查单。一般由测试人员进行
96 测试计划由谁编写？测试需求说明书由谁编写？测试用例谁编 写？测试总结谁编写？
测试负责人。测试人员（测试需求分析人员）。测试人员（测试设计工程师）。测试负责 人
97 软件投入运行后还需要测试吗？需要哪些测试？
需要测试。维护测试（含升级测试）、数据迁移测试、备份恢复测试、灾难恢复测试等
98 SP2 什么意思？
第 2 个版本的服务包或补丁包
99 给你一个网站，你如何测试？
首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试、界 面测试、性能测试、数据库测试、安全性测试、兼容性测试。
设计测试用例：
功能性测试可以包括，但不限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确 的出错信息返回。
提交功能的测试。
多媒体元素是否可以正确加载和显示。
多语言支持是否能够正确显示选择的语言等。 界面测试可以包括但不限于一下几个方面：
页面是否风格统一，美观
页面布局是否合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但未安装的控件，是否提供自动下载并安装的功能
文字检查
性能测试一般从以下两个方面考虑：
压力测试、负载测试
数据库测试要具体决定是否需要开展。
数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
安全性测试：
基本的登录功能的检查
是否存在溢出错误，导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如 SQL 注入等
兼容性测试，根据需求说明的内容，确定支持的平台组合：
浏览器的兼容性；
操作系统的兼容性；
软件平台的兼容性；
数据库的兼容性
开展测试，并记录缺陷。
合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需 求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
定期评审，对测试进行评估和总结，调整测试的内容。
100 一台客户端有三百个客户与三百个客户端有三百个客户对服务 器施压，有什么区别?
300 个用户在一个客户端上
会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生 一些异常。
需要更大的带宽。
IP 地址的问题，可能需要使用 IP 欺骗来绕过服务器对于单一 IP 地址最大连接 数的限制。
不必考虑分布式管理的问题。
用户分布在不同的客户端上
需要考虑使用控制器来整体调配不同客户机上的用户。
需要给予相应的权限配置和防火墙设置。
最后：
一线互联网 软件测试 的高级进阶路线思维图
看完这篇内容后，相信以下两件事，也会对你的个人提升有所帮助：
1、 点赞，让更多人能看到这篇文章，同时你的认可也会鼓励我创作更多优质内容。
2、 让自己变得更强：想一想，如果你想在测试这个行业一直做下去，你的经验和测试技术是远远不够的，你需要进阶，你需要丰富你的技术栈！还等什么！
最后:【可能给予你助力的教程】
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。
关注我的微信公众号：【伤心的辣条】免费获取~
如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！
好文推荐：
我TM谢谢你！给我100块羞辱离职，原来是激励我“卧薪尝胆”！
以上是关于软件测试工程师之——软件测试工程师 面试100题 基础篇持续更新中.....的主要内容，如果未能解决你的问题，请参考以下文章