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

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

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

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

2、我现在有个程序，发现在 Windows 上运行得很慢，那么怎么辨别是程序存在的问题还是软硬件系统存在的问题？

检查系统是否有中毒的特征。

检查软件/硬件的配置是否符合软件的推荐标准。

确认当前的系统是否是独立，即没有对外提供什么消耗 CPU 资源的服务。

如果是 C/S 或者 B/S 结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的。

在系统没有任何负载的情况下，查看性能监视器，确认应用程序对 CPU/内存的访问情况。

3、测试的策略有哪些？

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

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

需求分析 + 需求变更的维护工作。

根据需求得出测试需求。

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

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

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

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

6、测试活动中，如果发现需求文档不完善或者不准确，怎么处理？

应该立即和相关人员进行协调交流。

7、你认为做好测试计划工作的关键是什么？

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

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

8、一套完整的测试应该由哪些阶段组成？

测试计划、测试设计与开发、测试实施、测试评审与测试结论

9、简述集成测试与系统测试关系？

集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书。

集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。

10、功能测试用例需要详细到什么程度才是合格的？

这个问题也是测试工程师经常问的问题。

有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作，主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。

另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。

实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子:“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出几种以上，如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。

另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。

因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。

11、发现的缺陷越多，说明软件缺陷越多吗？

这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接二连三的发现很多缺陷，颇有个人成就感。

其中的原因主要如下:

代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味着可能也复制了缺陷。

程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体力不支时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰是测试工程师大显身手的地方。

“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。

12、写出 Bug 报告流转的步骤，每步的责任人及主要完成的工作。

测试人员提交新的 Bug 入库，错误状态为 New。

高级测试员/测试经理验证错误，如果确认是错误，分配给开发组。设置状态为 Open。如果不是错误，则拒绝，设置为 Declined 状态。

开发经理分配 Bug 至对应的模块开发人员。

开发人员查询状态为 Open 的 Bug，如果不是错误，则置状态为 Declined；如果是 Bug 则修复并置状态为 Fixed；不能解决的 Bug，要留下文字说明及保持 Bug 为 Open 状态。

对于不能解决和延期解决的 Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。测试人员查询状态为 Fixed 的 Bug，然后验证 Bug 是否已解决，如解决，置 Bug 的状态为 Closed，如没有解决，置 Bug 状态为 Reopen。

13、写出 Bug 报告当中一些必备的内容。

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

Bug 报告优先级

Bug 状态

Bug 编号

发现人

提交人

指定处理人

概述

详细描述

严重程度

所属模块

附件

提交日期

14、画出软件测试的 V 模型图。

15、为什么要在一个团队中开展软件测试工作？

因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比 ISO 质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

16、您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系？

测试类型有：功能测试，性能测试，界面测试。

功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误猜错、因果图、流程分析等。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）。

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

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

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

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。单元测试是由程序员自己来完成，最终受益的也是程序员自己。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试) 系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

18、测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、 方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法。

19、你以前工作时的测试流程是什么？

公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我自己总结的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）—》 需求确定（出一份确定的需求文档）—》开发设计文档（开发人员在开始写代码前就能输出设计文档）—》想好测试策略，写出测试用例 —》发给开发人员、测试经理等相关人员（用例评审）—》接到测试版本 —》执行测试用例（中间可能会补充用例）—》提交 Bug（有些 Bug 需要开发人员的确定，严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进缺陷管理工具里）—》开发人员修改（可以在测试过程中快速的修改）—》回归测试（可能又会发现新问题，再按流程开始跑）。

20、当开发人员说不是 Bug 时，你如何应对？

有 2 种情况：

一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，三方商量确定好后再看要不要改。

二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是 Bug 的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。

21、简述什么是存储过程和触发器？

存储过程是数据库中的一个对象，Transact-SQL 语句的预编译集合，这些语句在一个名称下存储并作为一个单元进行处理。（可以理解为 C 语言中的函数，有参数、返回值等函数特性）

触发器是一种特殊类型的存储过程，当使用下面的一种或多种数据修改操作在指定表中对数据进行修改时，触发器会生效：UPDATE、INSERT 或 DELETE。

22、描述 TCP/IP 协议的层次结构，以及每一层中重要协议。

23、在 Linux 系统中，一个文件的访问权限是 755，其含义是什么？

755 表示该文件所有者对该文件具有读、写、执行权限，该文件所有者所在组用户及其他用户对该文件具有读和执行权限。

24、简述一下 C/S 模式和 B/S 模式？

C/S 模式:客户端/服务器模式。工作原理:Client 向 Server 提交一个请求；Server 则使用一些方法处理这个请求，并将效果返回给 Client。

B/S 结构，即 Browser/Server（浏览器/服务器）结构，是随着 Internet 技术的兴起，对 C/S 结构的一种变化或者改进的结构。在这种结构下，用户界面完全通过 WWW 浏览器实现。

以上是各个大厂的面试题合集，需要点这里进Q-q-u-n下载！