软件测试基础知识巩固（面试准备）
（以下内容是本人在准备面试时从相关网站整理出来的软件测试汇总，实际面试做题时果然有很多熟悉的题目，贴在这里供日后自己回顾和大家参考）
1、什么是软件测试？
从广义上说，软件测试是软件生命周期中的所有检查、评审和确认工作，包括在分析、设计阶段，以及完成开发后确认阶段的各类文档、代码的审查和确认。
从狭义上说，是识别软件缺陷的过程，即实际结果与预期结果不一致。
2、软件测试的目标？
最终目标是确保软件功能符合用户需求，在产品发布或交付前尽可能多的发现并改正缺陷。
3、软件测试的原则？
- Good-enough原则。一种权衡投入/产出比的原则。
- 保证测试的覆盖度，但穷举测试是不可能的。
- 所有测试都应追溯到用户需求。
- 越早测试越好，测试过程与开发过程应是相互结合的。
- 测试的规模由小到大，从单元测试到系统测试。
- 为了尽可能的发现错误，应由独立的第三方进行测试。
- 不能为了便于测试擅自修改程序。
- 既应该测试软件应该做什么，也应该测试软件不应该做什么。
- 测试只是展示缺陷。测试只能表明有缺陷存在，但不能证明没有缺陷，测试能降低未发现缺陷留存的概率，却不能证明软件是绝对正确的。
- 穷尽测试是不可能的。测试所有的输入和条件组合是不可能的，可以取而代之的是基于风险和优先级的测试。
- 缺陷簇生。要对缺陷发生率高的模块投入更多的测试。少量的模块往往隐藏了大部分的缺陷。缺陷发生率高的模块往往与需求不清、设计不当、编码复杂度高等内在原因关联，所以从风险的角度来看必然较高。
- 杀虫剂悖论。相同的测试再重复多次后就无法再找到缺陷了。测试用例要不断评审修改，不断添加新的和不同的测试，就有可能找到更多缺陷。
- 测试是上下文关联的。测试在不同上下文环境中的执行是不同的。
- 无错谬论。即使修改了系统中存在的大部分缺陷，但若系统本身背离了用户需求，那么发现和修复缺陷就毫无帮助了。
4、软件测试的度量？
- 测试覆盖率：有多少需求、代码已经被测试了。
- 缺陷发现率：缺陷是何时被发现，且有多少缺陷已经被发现，缺陷可以根据严重性来分类，需要记录的数据有：缺陷数量、缺陷的严重等级等。
- 测试成功率：有多少测试用例已经通过，且有多少运行正常的，需要记录的数据有：通过的测试用例数、未通过的测试用例数、已执行的测试用例数等。
5、多少测试才足够？
取决于风险程度（商业风险和技术风险）和项目约束条件（时间和经费）。
6、调试和测试的区别？
调试 for开发人员发现缺陷原因，修复代码并确认缺陷已经被修复；
测试 for 测试人员识别缺陷。
7、测试的主要步骤？
计划与控制；分析与设计；实施与执行；评估出口准则和报告；测试结束活动。
8、什么是回归测试？
回归测试是指修改了旧代码后，重新测试以确认修改没有引入新的错误或导致其他代码产生错误。
9、测试的标准是什么？
测试的标准是用户的需求。
10、为什么要避免测试自己的程序？
测试自己的程序时，容易顺着编写代码时的思路进行测试，很少从其他角度思考，基于这种思维定势，就难以发现潜在的错误。
由于心理因素，人们潜意识都不希望找到自己的错误。基于这种思维定势，人们难以发现自己的错误。一定程度的独立测试可以更加高效的发现软件缺陷和软件存在的失效。
11、软件测试的要素有哪些？
- 质量。软件质量是软件测试的目标，也是软件测试工作的中心。一切从质量出发，也就是一切从客户需求出发。任何违背质量的东西都是问题，测试就是要找出这些问题。
- 人员。人是决定的因素，测试人员的态度、素质、能力决定着测试的效果，对测试产品的质量也有很大的影响。测试人员因素包括测试组织结构、角色和责任的定义。
- 技术。软件测试技术，包括方法、工具。
- 资源。主要是指测试环境中所需要的硬件设备、网络环境，甚至包括测试数据。另一个重要因素就是测试时间，时间也是测试的资源。
- 流程。从测试计划和测试用例的创建、评审到测试的执行、报告，设定每个阶段的进出标准。
12、什么是软件质量？
软件特性的总和，软件满足规定或潜在用户需求的能力。
13、软件测试与软件质量保证的区别？
软件测试只是保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作。
从性质上看，软件测试属于技术性工作，而软件质量保证属于管理型工作；从对象上看，软件测试的对象是软件产品，而质量保证的对象是整个软件过程，覆盖公司层面的各个领域；从手段上看，软件测试以事后测试检验为主，而软件质量保证则强调缺陷的预防。
14、测试团队的基本责任？
- 发现软件程序、系统或产品中所有的问题
- 尽早的发现问题
- 督促和协助开发人员尽快地解决程序中的缺陷
- 帮助项目管理人员制定合理的开发计划
- 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人员能够及时、清楚地了解产品当前的质量状态
- 帮助改善开发流程、提高产品开发效率
- 促进程序编写的规范性、易读性、可维护性等
15、什么是缺陷发现率（DDP）？
DDP=Bugs(tester)/(Bugs(tester)+Bugs(customer))
测试人员发现的bug/（测试人员发现的bug+用户发现的bug）
16、什么是单元测试？
定义：又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作；可以从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试。
目的：发现模块内部可能存在的各种差错。
内容：模块接口测试（数据的流入流出）、局部数据结构测试、路径测试、错误处理测试、边界测试。
步骤：利用设计文档设计测试用例；创建被测试模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试。
17、什么是集成测试？
定义：又称组装测试或联合测试，在单元测试基础上，将所有模块按概要设计和详细设计进行组装。
目的：发现模块连接中的接口可能存在的各种差错。
内容：穿越模块之间的数据是否会丢失；一个模块组装后是否会对另一个模块或其他模块存在影响；各个子功能组装在一起是否会达到预期的父功能；全局数据结构是否有问题。
组装方法：一次性组装、增殖式组装。
完成标志：成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审。
18、什么是系统测试？
目的：验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。
测试内容：在真实或模拟系统运行环境下，检查完整的程序系统能否和系统（硬件、网络、软件）正确配置、连接，满足用户需求。
19、什么是验收测试？
目的：在用户环境中进行测试，以确定系统和产品是否能满足合同或用户所规定的需求。
内容：根据任务书或合同、供需双方约定的验收依据文档进行对整个系统的测试和评审，确认是否接收或拒绝系统。
20、什么是静态测试？
又称为静态分析技术，不执行被测试软件，对需求分析说明书、软件设计说明书、源程序做结构检测、流图分析、符号执行等找出软件的错误。
21、什么是动态测试？
通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程。
22、什么是自动化测试？
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
23、测试用例有哪些设计原则？
- 单个用例覆盖最小化原则。每个测试用例应该尽可能的简单，只验证你所要验证的内容。
- 测试用例替代产品文档功能原则。
- 单次投入成本和多次投入成本原则。
- 使测试结果分析和调试最简单化原则（针对自动化测试用例的扩展和延续）。
24、什么是Alpha测试？
是验收测试的一种，是由用户在开发者的场所来进行的，Alpha测试是在一个受控的环境中进行的。
25、什么是Beta测试？
是验收测试的一种，由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者。
26、如何进行单元测试？
内容有：接口测试、内部数据结构、全局数据结构、边界测试、路径测试、错误处理测试。
27、手工测试和自动测试的优缺点？
手工测试：缺点在于测试工作量大、重复多、回归测试难以实现。
自动测试：利用软件测试工具自动实现全部或部分测试工作，管理、设计、执行和报告，节省大量的测试开销，并且能够完成一些手工测试无法实现的测试。
手工完成测试的全部过程无法保证测试的科学性和严密性：
修改的缺陷越多，回归测试越困难；
没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率；
反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一；
测试花费的时间越长，测试的严格性也就越低。
自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析：
软件测试不可能完全自动化；
不能完成所有手工测试任务；
无创造性且灵活性差，不能改进测试的有效性；
过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时；
测试脚本的维护成本高。
28、测试用例设计有哪些方法？
等价类划分法；边界值分析法；场景法；正交试验法；因果图；决策表；错误推测法。
29、什么是测试计划？
根据项目相关文档制定的、用于指导整个测试过程的文档，需要定义测试范围、测试策略、人员分配、软硬件配置、进度表及测试过程每个阶段需要达到的目标。
30、测试用例包含哪些关键内容？
用例编号、用例描述、前提条件、输入数据、测试步骤、预期结果6项关键内容。
31、查找遗漏问题的方法有哪些？
说明书是基础和标准；相关变动邮件、讨论记录；不定期阅读别人的缺陷；多和开发人员沟通；有选择的重新验证以前的缺陷；关注变化；简单思维方式，以主线为主，减少大遗漏。
32、敏捷开发的理念？ 以人为核心、迭代、循序渐进的开发方式。
个体和交互 胜过 过程和工具；
可以工作的软件 胜过 面面俱到的文档；
客户合作 胜过 合同谈判；
响应变化 胜过 遵循计划。
33、敏捷开发遵循的原则？
通过尽早的、持续的交付有价值的软件来使客户满意；
即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势；
经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好；
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作；
围绕被激励起来的个体来构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作；
在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈；
工作的软件是首要的进度度量标准；
敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度；
不断地关注优秀的技能和好的设计会增强敏捷能力；
简单是最根本的；
最好的架构、需求和设计出自组织团队；
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应的对自己的行为进行调整。
34、什么是敏捷测试？
敏捷测试是适应敏捷开发方法而采用的新的测试流程、方法和实践。
简单的说，敏捷测试就是持续的对软件质量问题进行及时的反馈。
35、什么是软件缺陷（bug）？
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其应有功能的缺陷。如：
软件未实现产品说明书要求的功能；
软件出现产品说明书指明不应该出现的错误；
软件实现了产品说明书未说明的功能；
软件未实现产品说明书虽未明确提及但应该实现的目标；
软件难以理解，不易使用，运行速度慢，或者软件测试员认为最终用户会认为不好。
36、提交缺陷（bug）的要求？
Bug描述的基本要求：分类准确、叙述简洁、步骤清楚、实际结果描述清楚、复杂问题有据可依。
问题描述：模块或功能的—测试步骤—期望结果—实际结果—其他信息。
单一、简洁、再现、复杂问题、报告不允许使用抽象的词语。
37、白盒测试？
白盒测试又称结构测试、逻辑驱动测试或基于程序的测试。一般用来分析程序的内部结构。白盒测试要求对被测程序的结构特性做到一定程度的覆盖。
控制流测试：
- 语句覆盖准则：语句覆盖测试是最简单的结构性测试方法之一，要求在测试中，程序中的每条语句都得到运行。在控制流图中，要求所有语句都被运行的充要条件是覆盖图中的所有节点。
- 分支覆盖准则：分支测试要求在软件测试中，每个分支都至少获得一次“真”值和一次“假”值。 分支覆盖测试包含语句覆盖测试
- 谓词测试：一个分支的条件是由谓词组成的，单个谓词称为原子谓词，原子谓词可通过逻辑运算符（或、与、非）构成复合谓词。
- 原子谓词覆盖准则：要求在软件测试中，每个复合谓词所包含的每一个原子谓词都至少获得一次真值和一次假值。原子谓词覆盖准则和语句覆盖准则相互之间没有包含关系，和分支覆盖准则相互之间也没有包含关系。
- 分支--谓词覆盖准则：要求在软件测试中，不仅每个复合谓词所包含的每一个原子谓词都至少获得一次真值和一次假值，而且每个复合谓词本身也至少获得一次真值和一次假值。分支--谓词覆盖准则包含语句覆盖准则、分支覆盖准则、原子谓词覆盖准则。
- 复合谓词覆盖准则：要求在软件测试中，每个条件中谓词的各种可能都至少出现一次。复合谓词覆盖准则包含语句覆盖准则、分支覆盖准则、原子谓词覆盖准则、分支--谓词覆盖准则。
- 路径覆盖准则：要求观察程序运行的整个路径，要求程序的运行覆盖所有的完整路径。路径覆盖准则包含了分支覆盖准则，但与谓词测试之间没有包含关系。
38、TDD（Test-Driven Development测试驱动开发）？
TDD要求在编写某个功能的代码之前，先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
39、因果图法设计测试用例的步骤？
①分析需求，提取因果关系，并赋予标识符；②分析需求，提取输入与输出，并表示为因果图；③标明因果图上的约束条件；④将因果图转化为判定表；⑤根据判定表中每一列显示的情况设计测试用例。
40、决策表法设计测试用例的步骤？
①列出所有的条件桩和动作桩；②确定规则的个数；③填入条件项；④填入动作项；⑤简化决策表，合并类似的规则或动作。
41、自动化测试框架有哪些？
模块化框架、函数库框架、数据驱动框架、关键字驱动框架。
42、测试覆盖率分为哪几种统计方式？分别是什么？
代码覆盖率、功能模块覆盖率、需求覆盖率、数据库覆盖率。
43、什么是FMEA?
FMEA(failure mode and effects analysis)：失效模式与效应分析，是一种可靠性设计的重要方法，对各种风险进行评价、分析，以便在现有技术的基础上消除这些风险或将风险减少到可以接受的水平。
44、列举出你所了解的EMC测试和环境测试项目。？
45、请描述TCP/IP建立连接的过程？
46、调用一个DLL有哪几种方式？
47、白盒测试有哪些覆盖方法？
语句覆盖、分支覆盖、谓词覆盖、路径覆盖。
48、进程与线程的区别？
线程是进程的一个执行单元，也是进程的可调度实体。
49、软件的缺陷等级应如何划分？
1、致命错误，可能会导致本模块或其他相关模块异常、死机等问题；
2、严重错误，问题局限在本模块，导致模块功能失效或退出异常；
3、一般错误，模块功能部分失效；
4、建议问题，由问题提出人对测试对象的改进意见。
50、针对缺陷采取怎样的管理措施？
1、要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可；
2、根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理；
3、所有发现的缺陷都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理；
4、缺陷提交后，需要即时的指派给相应的开发人员，提交者需要密切注意缺陷的状态，帮助缺陷的尽快解决，缺陷解决后需要即时对缺陷的修复进行验证；
5、为更好地改进开发过程和测试过程，需要对缺陷进行分析总结，如缺陷的类别、缺陷的龄期分布等信息。
51、并发性能测试？
并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。
52、负载测试？
负载测试是确定在各种负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。
53、压力测试？
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能够提供的最大服务级别的测试。
54、疲劳测试？
疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
55、大数据量测试？
大数据量测试分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。
56、客户没给性能指数，怎么开展性能测试？
与项目经理、测试主管等人协商，根据惯例和经验设置、参考类似系统的性能指标、参考历史数据等方法确定性能指数。
57、测试过程中是如何来保证软件质量的？
①测试用例编写完成后要加强评审力度，确保测试用例覆盖所有需求点；②测试执行过程中要注意检查测试覆盖情况、审视所提交缺陷质量、复测时应注意相关模块的测试；③测试时间宽裕的话可以做交叉测试，用以确保测试质量。
58、测试方案都写什么内容？
概述；被测对象分析；应测试的特性；不被测试的特性；总体设计方法；
测试模型：测试组网图、结构/对象关系图、测试原理、操作规程；
测试需求：环境需求、被测对象需求、测试工具需求、测试代码需求、数据需求、其他需求；
测试设计：工具设计、测试代码设计、用例设计、设计原则、测试项目；
附录。
59、测试方案与测试计划的区别？
测试方案是技术性的；测试计划是管理性的。
测试计划主要要考虑测试的技术可行性、关键技术、资源投入、进度安排、风险管理、配置管理、输入输出等。测试计划更多地供高层管理者决策时做参考，同时对后续测试工作开展起指导作用。
在一些小项目中，可能只需要一个测试方案，测试计划内容相对较少，可以与测试方案合并；而在一些大项目中，可能要设计数十个测试方案，则就需要测试计划来提纲挈领。
60、单元测试和系统测试的侧重点？
单元测试侧重系统模块，包括子程序的正确性验证等；系统测试侧重整个系统的运行以及与其他软件的兼容性。
61、BUG流程？
提交缺陷-->分配缺陷-->确认缺陷-->推迟处理-->固定-->处理缺陷-->回归缺陷-->关闭缺陷。
62、请写出电脑的组成及有哪些操作系统？
计算机由硬件和软件两大部分组成。
硬件：输入设备、输出设备、存储器、运算器、控制器；
软件：系统软件、应用软件。
操作系统有：DOS（磁盘操作系统）、UNIX、XENIX、LINUX、Windows、Netware（网络操作系统）。
63、loadrunner的使用流程？
制定测试计划à创建测试脚本à创建场景à运行场景à监控测试场景à分析测试结果。
64、有什么是你觉得是bug而开发人员不认为是bug的经历？
在测试某个系统时，进行了删除操作后，系统未弹出相应的删除成功或失败的信息，只是刷新了数据列表，被执行删除操作的数据从列表中消失。开发人员认为这样就能体现删除操作成功了，但是对于用户而言，操作结果通过提示信息来表示会更直观。
65、软件测试的生命周期？
需求分析、测试计划、测试设计、测试开发、测试执行、测试评估。
66、BUG（指程序编码上的错误）的生命周期？
new、open、in process、check、resolved、closed、reopened。