面试总结-测试篇

测试基础知识

1、软件测试的含义和目的

含义：软件测试是使用人工或自动手段来运行或测试某个系统的过程，目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别
目的：

1、验证软件是否满足各类文档说明书规定的软件质量要求
2、找出软件缺陷
3、为软件产品的质量测量和评价提供依据
4、帮助开发改进开发流程

2、软件质量要求有哪些？

功能要求和非功能要求
功能要求 ：能做什么？需要做什么？怎么做是正确的？
非功能要求 ：
1、性能要求（负载测试、压力测试、容量测试、可靠性测试）：反映软件运行的速度和效率，占用资源的多少。
负载测试：测试软件本身最大所能承受的性能测试。逐步增加用户数量或用户请求来对用户加压
压力测试：是一种破坏性的性能测试，测试故障恢复能力。长时间运行的稳定性
容量测试：确定系统可处理同时在线的最大用户数
2、界面测试：布局是否合理、控件位置是否恰当、文字有没有乱码、字体大小、颜色使用是否恰当、图片表格恰当、舒适美观
3、兼容性测试：表示一个软件与其所在运行环境的依赖程度，包括与硬件、操作平台、其他软件的依赖
4、易用性测试：软件产品在指定条件下运行时，被理解、学习、使用和吸引客户的能力
5、可维护性：易改变、稳定、易测试的
7、可扩展性：
8、安全性测试：软件产品保护信息和数据的能力
9、灾难恢复测试

3、测试分为几个阶段，每个阶段的测试目的是啥？

测试分为 单元测试、集成测试、系统测试、验收测试 四个阶段。前三个阶段的目的是尽可能多的发现缺陷。而验收测试是要验证软件满足了用户需求，帮助用户建立系统可以正常使用的信心，发现缺陷不是此阶段的目标。

4、分别介绍一下单元测试、集成测试、系统测试、验收测试、回归测试，哪个阶段最重要

单元测试：

最小的软件单元的验证。目的是检验软件基本组成单位的正确性。
白盒居多，黑盒少。比如对java中的类和方法的测试。
单元测试由开发人员或懂开发的测试人员完成。

集成测试：

在单元测试的基础上，把软件单元组装成模块、子系统或系统的过程。对模块间的接口及集成后的功能进行测试。
把通过了单元测试的模块拿来，构造一个程序结构
目的：检验软件单位之间的接口是否正确
白盒居多，黑盒少。先做黑盒，再做白盒
避免一次性集成。采用增量集成
集成测试的策略：
自顶向下：首先集成主模块，然后按照层次结构向下进行集成。
自底向上：首先验证底层组件、子模块。

系统测试：

在集成测试的基础上，将通过集成测试的模块，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境中进行一系列严格有效的测试。
针对整个产品的全面测试，测试需求规格说明书中提到的功能是否有遗漏，是否正确的实现，要严格以 需求规格说明书 为标准
黑盒
目的：为了检查软件是否满足需求

集成测试和系统测试的比较

1、测试内容：集成测试是测试各个单元模块之间的接口；系统测试是测试整个系统的功能和性能
2、测试角度：集成测试偏重于技术的角度；系统测试偏重于业务的角度
3、测试计划和用例的先后顺序：在需求阶段就要制定系统测试计划和用例，HLD（概要设计说明）的时候做集成测试计划和用例。先系统，再集成

验收测试：

也称交付测试。是针对用户需求、业务流程进行的正式的测试，以确保系统是否满足验收标准，由用户、客户决定是否接受系统
验收测试包括alpha测试和beta测试。alpha测试（α测试）由用户在开发者的场所进行的软件测试，在一个受控的环境中进行。beta测试（β测试）是由用户在脱离开发环境下进行的软件测试，用户记录问题并报告给开发者。

回归测试

发生修改之后重新测试先前的测试用例以保证修改的正确性。
理论上，软件产生新版本，都需要进行回归测试。
目的：为了验证以前出现过但已经修复好了的缺陷不再重复出现。

这几个阶段缺一不可。我认为其中最重要的是系统测试，此时单元测试和集成测试已经完成，系统测试此时可以对软件所有功能进行测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义。

5、软件测试的目的？为什么要进行软件测试？

软件测试就是发现缺陷的过程；
①验证软件符不符合各类文档说明书等规定的软件质量要求
②找出软件缺陷
③为软件产品的质量测量和评价提供依据
④帮助开发改进开发流程

6、软件测试的原则？

①所有的测试都应该追溯到用户需求
②尽早做测试计划、尽早启动测试工作
③穷尽测试是不可能的；当测试时间不够用时，使用风险分析，确定测试的重点和优先级，制定最低测试标准和测试内容，然后具体问题具体分析
④Good-enough原则：既不要做过多的测试，也不要做不充分的测试
⑤pareto法则、帕累托法则、28原则、82原则：一般情况下80%的缺陷集中在20%的关键核心业务模块，重点分析测试这20%的核心业务
⑥尽可能使用分阶段测试：单元->集成->系统->验收
⑦为保证测试的有效性和高效性，测试必须是破坏性、系统化的
⑧最好是独立的第三方人员做测试【不参与程序开发】
⑨群集效应：在找到缺陷的地方要继续找缺陷，发现缺陷的地点，证明存在的缺陷多；
杀虫剂怪事：软件测试越多，其对测试免疫力越强。测试时，应该尝试不同的新方法、不同的测试程序，对程序进行测试；
木桶原理：全面质量管理。取决于短板。

7、给你一个网站，怎么测试（测试的基本过程）？

①分析测试需求：查找需求说明、网站设计等相关文档
②编写测试计划：确定测试范围和测试策略，一般包括：功能性测试、界面测试、性能测试、数据库测试、安全性测试、兼容性测试
③设计和编写测试用例：

功能性测试包括：：
链接测试：链接是否正确跳转，是否出现空页面和无效页面，是否有不正确的出错信息返回
提交功能测试
多媒体元素是否可以正确加载和显示
多语言支持是否能够正确显示选择的语言
界面测试包括：：
页面是否风格统一、美观
页面布局是否合理，重点内容和热点内容是否突出
控件使用是否正常
对于必须但未安装的控件，是否提供自动下载并安装的功能
文字检查
性能测试包括：
压力测试、负载测试。不断增加访问网站的用户数量，看对网站造成什么影响，网站正常使用时的最大用户承受量
数据库测试要具体决定是否需要开展
数据库一般需要考虑连接性，对数据的存取操作，数据内容的验证等方面
安全性测试：
基本的登录功能的检查
是否存在溢出错误，导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如SQL注入等
兼容性测试，根据需求说明的内容，确定支持的平台组合：
浏览器的兼容性
操作系统的兼容性
软件平台的兼容性
数据库的兼容性

④执行测试：合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例：需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）
⑤定期评审，对测试进行评估和总结，调整测试的内容

8、什么是灰盒测试？

灰盒测试是介于白盒测试与黑盒测试之间的一种测试，不仅关注输入输出的正确性，同时也关注程序内部的情况。多用于继承测试阶段，目前互联网的测试大多数都是灰盒测试。
灰盒测试不像白盒测试那样详细完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

9、黑盒与白盒测试的方法有哪些

黑盒测试：也称功能测试，基于规格说明书的测试，关注输入数据到程序中，输出结果是否正确，不关注内部逻辑结构。侧重于测试软件能做什么。针对功能测试和界面测试

常用的方法：
等价类划分法：将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类。
边界值分析法：对等价类划分法的补充，因为大多数错误都发生在输入输出的边界值上。如果边界附件取值不会导致程序错误，那么其他取值出错的可能性也就很小。
因果图法：即决策表，利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
大纲法 ：主要用于对软件进行功能拆分
场景法：模拟用户操作软件时的情景，主要用于测试系统的业务流程
错误推测法 ：在测试程序时，根据经验推测程序中可能存在的错误，从而有针对性地编写检查这些错误的测试方法
正交试验法 ：正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。
分类：输入数据测试方面、输出数据测试方面、数据结构测试方面、文件系统方面

白盒测试：也称结构测试、逻辑驱动测试。是对程序内部逻辑结构进行测试。

白盒测试遵循的原则是：
1、保证一个模块中的所有独立路径至少被测试一次
2、所有逻辑值均需要测试真和假两种情况
3、检查程序的内部数据结构，保证其结构的有效性
4、在上下边界及可操作范围内运行所有循环

白盒测试的方法：
语句覆盖：程序中的每个可执行语句至少被执行一次。能发现语句逻辑，不能发现逻辑错误
判定覆盖：也称分支覆盖，程序中的每个判定的取真分支和取假分支至少被执行一次。能发现逻辑错误，但不能发现组合判断中的条件错误
条件覆盖：程序每个判定中的每个条件的可能取值至少被满足一次。能发现条件错误，但不能发现逻辑错误
判定-条件覆盖：每个条件中的所有可能取值至少被执行一次，同时，每个判定的可能结果至少被执行一次。判定+条件
条件组合覆盖：每个判定中的所有条件取值组合被执行一次
路径覆盖：用例覆盖程序中的所有可能的执行路径。如果路径数很多，会变得不切实际

10、自动化测试和手动测试的优缺点

自动化测试的优点：
1、自动化测试可以重复执行、能执行更多、更频繁的测试
2、能执行一些手动测试比较困难或不可能进行的测试
3、能更好的利用资源、可以利用晚上或空闲的设备执行自动化测试
4、可以让测试人员腾出时间和精力，投入更多的精力设计出更多、更好的测试用例，提供测试准确性和测试人员的积极性
5、能够保证测试更客观，提供软件的信任度
自动化测试的缺点：
1、不能完全代替人工测试，不是所以的测试用例都可以自动化，工具本身不具备思维能力。比如设计用例、界面和用户体验测试、正确性检查
2、不能保证100%的测试覆盖率
3、需要更长时间去分析和隔离所发现缺陷
4、自动化测试对软件质量依赖性较大
5、如果测试人员不熟悉某些测试工具，测试工作的进度就有可能受到影响
6、不能立即降低测试投入，提供测试效率
手工测试的缺点：
1、重复的手工回归测试，代价昂贵、容易出错
2、依赖于软件测试人员的能力
手工测试的优点：
1、测试人员具有经验和用对错误的猜测能力
2、测试人员具有主观思维和体验感受
3、测试人员具有是非判断和逻辑推理能力

11、测试开发需要具备的能力

11.1需要的知识：

软件测试基础理论知识：如黑盒测试、白盒测试等
编程语言基础：如java、Python等
自动化测试工具：Selenium
计算机基础知识：数据库、Linux、计算机网络
测试框架：JUnit

11.2具备的能力

1、业务分析能力、分析整体业务流程、分析被测业务数据、分析被测系统架构、分析被测业务模块、分析测试所需资源、分析测试完成目标
2、缺陷洞察能力、一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力
3、团队协作能力、合理进行人员分工、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目整体进度、出现问题勇于承担
4、逻辑思考能力，判断逻辑的正确性、对可行性逻辑分析、站在客观角度思考
5、问题解决能力，技术上的问题、工作中的问题、沟通问题
6、沟通表达能力，和技术人员、产品人员、上下级的沟通
7、宏观把控能力，有效控制测试时间、有效控制测试成本、有效制定测试计划、有效进行风险评估、有效控制测试方向
三心二意(细心、耐心、信心、缺陷预防意识、沟通意识)

12、如果测试提交的缺陷开发人员不认可，该怎么办？

1、首先分析或与开发沟通不认可的原因
2、如果原因是提交的不是缺陷，而且自己分析后，的确不是缺陷，则应该反思自己，并且注意之后的测试要做好复现，认真研读需求，提高自己找缺陷的能力
3、如果自己分析后认为缺陷应该是存在的，则再次研读需求并做好复现，拿出确实是缺陷的证据，然后再与开发沟通
4、如果拒绝原因是认可缺陷，但不予修复，如果自己觉得必须修复，则拿出充分理由和证据证明如果不进行修复产生的不利影响和影响范围，再与开发沟通
5、注意沟通技巧、合理的论述，向开发说明自己判断的理由，注意客观、严谨、不掺杂个人情绪
6、把问题交给测试经理，等待测试经理做出最终决定，如果仍然存在争议，可通过公司政策所提供的渠道，向上级反映，并由上级做出决定。

13、什么是兼容性测试

兼容性测试是指检查软件在不同软件平台、硬件平台上是否可以正常运行的测试。主要检查在不同操作系统、浏览器、数据库中运行是否正常

14、什么是功能、性能、兼容性

1、功能：代表一个软件能做什么
2、性能：反映软件运行的速度或效率、占用资源的多少等指标
3、兼容性：表示一个软件与其所在运行环境的依赖程度，包括与硬件、操作平台、其他软件的依赖

15、说一下3-5年的规划

从执行测试用例或运行测试脚本，记录测试日志或结果，提交缺陷报告开始做起
在做好本职工作的前提下
首先我会巩固自己的测试基础知识，提高研读理解需求文档的能力，不断提高测试需求分析、设计测试用例等能力，达到可以熟练进行测试分析和设计的能力。
学习自动化测试工具，并将它熟练的运用。
·在测试技术达到一定程度后，要学会如何带领一个测试团队，争取达到测试经理的水平。

16、软件测试的过程

1、测试人员分析测试需求

测试人员对用户的需求进行分析，了解软件要做什么，怎么做，软件做出来是给谁用的，进而确定将来怎么做测试

2、测试负责人编写测试计划

测试计划的内容：包含产品概述、测试范围/测试区域/测试项、测试目标/被测特征、测试优先级、测试配置/测试资源(硬件、软件、人力、技术等)、测试周期、进度安排(测试任务、人员安排)、测试策略、测试方法/途径、测试交流、风险分析、测试标准、需交付文档等内容

3、测试人员设计和编写测试用例

设计用例主要反映在编写测试点上
根据公司格式或选择一些模板编写测试用例

4、测试人员执行测试

搭建测试环境
执行测试用例，记录测试事件
提交和跟踪缺陷

5、评估与总结

分析实际测试与计划的偏差
== 收集并提交各种测试文档和数据，对数据进行分析
== 给出是否继续测试还是终止测试结论
总结经验教训

17、软件评审一般由哪些人参加，其目的是什么？

含义：
评审就是对产品进行静态检查，确定与计划的结果所存在的误差，并提供改进建议。评审能在缺陷发生前发现这些缺陷。
目的：查看软件在未正式投入运行前是否还存在问题。查找与需求、标准、或规定的不符之处。评审的目的不在于解决问题
参与人员：同行评审。客户、项目经理、开发人员、测试人员
分类：文档审查、代码审查、代码走查