1、什么是 黑盒测试？
解答：黑盒测试就是测试人员把软件产品看做是一个黑盒。在测试过程中测试人员只关心对这个软件黑盒进行操作会得到什么样的结果，而不必深入的去了解它的内部实现机制所进行的测试活动。
这样的操作可以是字符串的输入、图片的输入、视频流的输入、甚至是事件输入，而不同的输入进入这个黑盒子进行处理之后通常能得到不同的结果。
例子：例如我们在Windows命令行中输入字符串dir就可以得到当前目录下的子目录以及文件的列表。而输入tasklist后就可以得到一张正在系统中运行的任务列表。
在以上的操作中我们都不必考虑命令行解析器如何解析输入的字符串，也不必考虑系统如何获取我们想要的信息并如何把它显示在屏幕上，这就是黑盒处理机制。
我们只需关心输入和想要得到的输出，如果在初始条件确定的情况下确定输入数据经过黑盒进行处理后并没有得到想要的输出结果，则说明此时发现了一个软件的缺陷。
2、为什么要做黑盒测试？换一种问法：软件测试的目的是什么？
解答：
验证软件产品是否符合需求文档的设计；
证实软件产品符合终端用户的需求。
例子：我们把字符串dir输入到其他软件中可能毫无意义，但在Windows命令行中就能被解析为获得当前目录下的子目录以及文件的列表，并且在初始条件确定的情况下得到我们想要的输出结果。
这样的输出在软件设计阶段就被定义下来以保证开发人员编写的程序有章可循。另外在黑盒测试中，测试人员只按业务逻辑测试而不需要考虑内部实现，这就很好的模拟了终端用户的行为，但终端用户
的行为并不会在软件需求文档中定义。
3、你在软件生命周期中的哪些测试阶段用到过黑盒测试？
解答：单元测试、集成测试、系统测试、用户验收测试。
通常来说，软件生命周期中的测试阶段按时间顺序分为单元测试、集成测试、系统测试、用户验收测试，在各个测试阶段之间还会设置通过条件和准入条件。
例子：拿单元测试作为例子，单元测试有的公司采用白盒测试方法，而非黑盒。其实不然，黑盒测试在单元测试阶段中是一种行之有效的方法，运用好的话可以减少很多软件缺陷遗漏给其他测试阶段的机会。在单元测试中，一个函数一般分为四个部分：函数名、形参表、函数体、返回值。函数名是识别标志，函数体是函数核心部分，决定了这个函数是否做了正确的事，是否用例最少得运行时间，是否占用了最少得代码空间和运行空间。可以这样说，函数体就是这个黑盒，形参和返回值就是这个函数的输入和输出。利用黑盒测试用例设计的方法对其输入值域和输出值域进行分析可以极大地保证函数的质量。当多个函数被封装成类，进而被组装成一个组件时，把一个小小的函数黑盒组装成一个大黑盒，那就是组件测试了，这个组件即使不能完成一个完整的功能，通过编写驱动函数或桩函数方法去测试它。
4、什么叫打桩，什么叫驱动？
解答：驱动函数：在测试被测函数时，一般需要在一个函数中准备测试数据作为被测函数的实参，然后再在该函数中调用被测函数，之后检验测试结果。这样的函数被称为驱动函数（一般是main函数）。桩函数：在测试被测函数时，被测函数可能要调用一个未被实现功能的函数；这时候可以写一个简单的函数（也就是桩函数）来模拟被调函数部分行为。
通过组件暴露的公共接口分析它的输入值域，根据输入值域编写测试数据，之后在驱动函数调用组件的公共接口，并把测试数据作为参数传给被测组件，最终获得该组测试数据处理后所产生的输出。然后分析这些输出结果来确定该组件是否有缺陷。之后将多个测试过的组件被集成，成为更大的组件，这个过程就是集成测试了。直到成为功能齐全的应用程序，这时候系统测试就开始了，系统测试完成，后面就是用户验收测试阶段了。
5、什么是白盒测试？
解答：白盒测试也叫结构测试或逻辑驱动测试，通过分析被测组件内部工作原理，通过测试来检测被测组件内部运行是否符合产品规格说明书的规定。
白盒测试要求测试人员打开软件黑盒去了解开发人员的代码实现细节，这些细节包括数据流和控制流。
数据流方面：进出组件的数据能否被正确处理、组件中用于计算使用的数据或作为谓词使用的数据是否被正确使用、是否有冗余、其数据类型是否运用得当。
控制流方面：程序中每一条代码是否都有意义、程序中是否有无法被执行到的语句、程序中的判定是否正确、程序中的各条路径是否正确。
白盒测试通常用于单元测试阶段。
6、白盒测试与黑盒测试有什么区别？
解答：黑盒测试完全不考虑程序内部结构和内部特性，检查程序是否适当的接收输入数据而产生正确的输出信息，多用于软件界面、软件功能、性能、安全性等方面进行测试。
黑盒测试是穷举输入测试，只有把所有可能得输入都作为测试情况使用，适用于软件测试的各个阶段（单元测试、组件测试、集成测试、系统测试以及用户验收测试）。
白盒测试需要全面了解程序内部逻辑结构、对所有逻辑路径进行测试，对程序的数据流和所有分支、路径进行覆盖，多用于软件内部实现机制的正确性、有效性进行检查。
白盒测试是穷举路径测试，多用于软件测试的单元测试阶段。
7、为什么要对程序进行单元测试？
解答：a 保证被测代码有正确的行为，可以验证代码是否与详细设计一致。
在编写代码时，通常在每次实现一个功能或完成一个函数时会反复调试确保编译通过证明代码语法没有问题，但仍要对代码语义的正确性进行测试，这种简单测试行为就是一种单元测试。
单元测试就是对软件最基本组成单元进行测试，可以是一个函数或过程，也可以是一个类或类中的成员函数。
b 窥探软件内部的实现机制。可以发现其他测试阶段难以发现的软件缺陷
c 充分的单元测试可以极大地降低软件的开发成本
8、由谁来做单元测试？
解答：单元测试通常由软件开发人员来完成，其单元测试活动中所产生的所有文档、测试用例、工具代码以及测试结果等都要一一存档以备测试部门审核；
当然不排除一些公司专有的单元测试团队来完成单元测试。
9、什么时候开始做单元测试？
解答：在软件编码阶段进行，该阶段一般是软件开发团队已经给出了软件详细软件设计文档并通过了相关人员的审核之后；
在编码阶段，开发人员一般先设计好各单元之间的接口，然后再实现单元的内部代码，最后对各个单元进行测试。
10、怎么做单元测试？
解答：在编码阶段，开发人员一般先设计好各单元之间的接口，然后再实现单元的内部代码，最后对各个单元进行测试。
对于每一个被测单元，应该首先知道对外部暴露的接口（全局变量、类的公有成员、函数的形参、返回值、函数名等），通过组件暴露的公共接口分析它的输入值域，然后编写测试数据，可以使用黑盒测试方法有等价类划分、边界值分析、语法测试等方法。
之后对被测单元的内部进行白盒测试，去了解开发人员的代码实现细节如数据流和控制流，可以使用白盒测试方法有语句测试、分支-判定测试、条件测试、基本路径测试以及线性代码序列与跳转测试及数据流测试等。
测试被测单元时，还可以编写驱动函数或桩函数来模拟被测单元的被调用和调用。
11、单元测试的测试策略？
解答：自顶向下（不用编写驱动模块，可能需要编写桩模块）、自底向上（不用编写桩模块，可能需要编写驱动模块）、独立测试（自行编写驱动模块和桩模块）
12、在编码阶段，开发人员一般先设计好各单元之间的接口，此时函数单元测试的入口条件和出口条件是什么？
解答：
（1）入口条件：单元测试之前做一些准备工作包括：
被测单元编码已完成；
代码编译通过；
通过了静态代码检查工具的检测；
至少完成一轮代码检视或走读，并通过；
测试用例已被检视通过；
工具代码已完成并被检视通过。
（2）出口条件：
所有的测试用例已被执行；
测试覆盖率达到了预定要求；
被测模块的缺陷率低于预定要求。
13、为什么要对程序进行集成测试？通常大量使用黑盒测试方法，也会结合白盒测试特点，被归类为“灰盒测试”。
解答：
a 可以发现在单元测试阶段难以发现的缺陷
集成测试就是对软件已测试完成的单元或组件之间的接口进行测试，也叫组装测试或子系统测试。
b结合白盒测试和黑盒测试的特点对被测组件进行测试
c可以有效定位软件因为集成新的组件所引入的缺陷
d可以有效评估被集成的新模块对原系统的影响
e可以降低软件的开发成本
14、集成测试是为了验证哪个文档？
解答：软件开发过程中，开发人员需要将软件需求文档转化为软件概要设计文档指明各个模块之间的接口，也有的会开发一个软件接口说明文档来说明各基本单元或模块之间的接口关系。
15、什么时候开始做集成测试？
解答：在被测组件的编码完成之后进行。
16、怎么做集成测试？
解答：（1）自顶向下集成法。（不用编写驱动函数，可能需要编写桩函数）
（2）自底向上集成法（不用编写桩函数，可能需要编写驱动函数）
（3）三明治集成法，从两端向中间集成（现实生活中十分常用的方法）
（4）大爆炸式集成法，等到系统的所有模块都完成了单元测试之后，将所有模块放到一起做集成测试。这种集成方式首先需要将集合到一起的所有模块调通，让系统“跑”起来。（不需要编写驱动函数和桩函数）
17、集成测试的入口条件和出口条件是什么？
解答：入口条件：在集成测试之前需要做一些准备工作包括：
被测模块的单元测试结果已通过并被检视；
集成测试策略已被检视并通过；
集成测试用例已开发完成并被检视通过；
所需的工具代码已完成并被检视通过。
出口条件：
所有的集成测试用例都被执行；
集成测试测试覆盖率达到了预定要求；
被测模块的缺陷率低于预定上限。
18、什么是系统测试？
解答：所有模块或子系统都完成集成测试之后，测试人员对整个软件系统按照软件产品需求规格说明书进行的功能验证测试，这个阶段还会对产品进行其他方面的专项测试，如：西能测试、压力测试、健壮性测试和用户易用性测试等。
额外补充说明：
单元测试阶段，测试人员主要工作是对软件详细设计文档的验证；
集成测试阶段，测试人员主要工作是对软件接口说明文档的验证；
系统测试阶段，测试人员主要工作是对软件产品需求规格说明书的验证。
例子：
被测产品是网站，必须将该网站的运行环境准备好，包括web服务器的种类、版本，数据库的种类、版本，操作系统的种类、版本。以及服务器硬件的配置（内存、处理器、硬盘、网卡等），除此之外还必须考虑到用户端客户机的配置情况包括用户所使用的操作系统和浏览器种类和版本。
被测产品是手机软件等嵌入式系统，必须将被测软件对应的硬件系统准备好，并且已经经过需求、设计、实施、测试等过程一系列的测试。
19、为什么要对软件进行系统测试？
解答：a 系统测试与单元测试、集成测试的测试目的不同。单元测试是为了保证被测单元代码有正确的行为以及验证代码是否与详细设计文档一致；而集成测试是对软件已测试完成的单元或组件之间的接口进行测试。这些接口属于软件的内部接口，而系统测试中的功能测试通常都是测试软件的用户接口。
b系统测试的测试范围更加广泛。系统测试阶段包括一些专项测试如性能测试、压力测试、健壮性测试和用户易用性测试等，这些专项测试都必须等到系统集成完成之后进行的。
c系统测试是在模拟真实环境下的测试。系统测试阶段测试出来的结果更具有现实意义。
d某些特殊的常量数据只能在系统测试阶段来验证，例如用户界面友好程度、UI的美观程度、字体的大小以及字体的类型等。
20、系统测试是为了验证哪一个文档？
解答：软件开发过程中，开发人员需要将软件市场需求说明转化为软件产品需求规格说明书，书中会指明该软件产品要实现哪些功能、不需要实现哪些功能、要处理哪些特殊的异常、产品的各项性能指标以及产品工作的软硬件环境等。
21、什么时候开始做系统测试？
解答：在产品所有组成模块都集成之后进行。
22、怎么做系统测试？
解答：软件产品需求规格说明书通常包括对产品功能的需求描述，除此之外，还会有对产品性能、安全、健壮性及用户易用性等要求。
功能测试：测试产品各项功能的正确性，以及验证产品各项功能是否与产品需求规格说明书描述的一致。
性能测试：测试产品的各项性能是否达标。
例子：手机测试中，测试手机在睡眠待机、非睡眠待机、屏幕亮起等情况下的电流安培数及手机待机时间等指标是否达到预定值。
网站测试中，系统能并发处理用户请求的数量等是否达到预定值。
健壮性测试：指软件产品正常运行时在遇到某些突发异常事件的系统保持与恢复的能力。
例子：网站服务器在突然断电或电缆被切断的情况下备用服务器是否能正常启动并接受用户请求。
兼容性测试：软件产品的新旧版本之间的兼容以及软件产品与软件和硬件环境之间的兼容。
用户易用性测试：软件产品是否为用户提供了友好的界面及易操作的接口。
安装测试：测试软件在各种软硬件环境组合下是否正常进行安装、卸载。测试安装时包括取消安装时的回滚操作是否彻底、是否清除了文件系统和注册表中的内容以及在安装过程中出现异常如断电，系统崩溃等，待系统重启之后软件产品是否可以重新安装等。
23、系统测试的入口条件和出口条件是什么？
解答：入口条件：在系统测试之前需要做一些准备工作包括：
软件产品的集成测试结果已通过并被检视；
系统测试计划已被检视并通过；
系统测试策略已被检视并通过；
系统测试用例已开发完成并被检视通过；
所需的工具代码已完成并被检视通过。
出口条件：
所有的系统测试用例都被执行；
系统测试测试覆盖率达到了预定要求；
软件产品的缺陷率低于预定上限。
24、什么是用户验收测试？
解答：就是交付给用户，让用户执行产品验收所进行的测试，因此也叫交付测试。用户验收测试是产品上市之前的最后一个正式的测试阶段。
用户验收测试所要做的通常是在用户环境中对产品规格说明书进行测试和验证，另外还需要对用户文档进行测试包括：帮助文档、用户手册、安装配置指南、多媒体演示资料、授权使用提示、软件包装及广告等。
25、为什么要对软件进行用户验收测试？
解答：
a 每个产品都是为最终用户设计和开发的，因此让用户参与测试是获取用户产品反馈的重要途径。
b 可以实现用户环境中对产品规格说明书进行验证。
c可以实现用户环境中对产品的用户文档进行验证。
d可以降低产品中的缺陷数量。
e可以获取用户关于产品功能、性能的反馈，有利于产品团队在产品上市之前对产品用户印象产生一定认识。
26、如何开展用户验收测试？
解答：
（1）用户群体是企业内部人员，在企业内部挑选参与测试的人员、搭建测试环境、分配测试用例，然后对测试执行情况进行跟踪。
（2）用户群体是其他企业或团体，挑选参与测试的人员、搭建测试环境、分配测试用例，然后对测试执行情况进行跟踪，另外安排公司内部测试人员对用户体验测试的参与者给与一定的帮助，并对用户提出的反馈和报告的软件缺陷进行整理。
（3）用户群体是大众型，例如手机、免费邮箱等，其用户体验测试就扩展为Alpha测试和 Beta测试。
Alpha测试：产品上市之前公司内部进行的用户体验测试。测试任务可以分配给有经验的测试人员、产品设计、开发部门、市场部门，以及售后支持部门、培训部门等，对参与测试的专业测试人员可以指定专门的测试用例，以方便了解在童虎环境下这些测试用例的执行情况，其他参与测试人员可以在使用过程中对其进行随机测试。
Beta测试：产品上市之前让用户或企业的合作伙伴进行用户体验测试。测试任务是对参与测试的用户进行挑选，搭建测试环境和建立有效的用户反馈收集渠道，参与测试的人员在产品使用过程中大多进行随机测试和提供用户角度的意见。
27、用户验收测试验证的是哪个文档？
解答：用户环境中对产品规格说明书进行验证。
28、如何开展用户验收测试？
解答：
挑选参与用户体验测试的用户；
搭建测试环境；
分发被测产品；
建立用户与测试团队、产品团队的沟通渠道。
29、用户验收测试的入口条件和出口条件是什么？
解答：
解答：入口条件：在用户验收测试之前需要做一些准备工作包括：
软件产品的系统测试结果已通过并被检视；
用户验收测试计划已被检视并通过；
用户验收测试策略已被检视并通过；
用户验收测试用例已开发完成并被检视通过；
参与测试的用户已确定；
测试环境已按照用户需求搭建；
产品已分发到参与测试的人员手中；
已建立产品参与测试用户的信息反馈渠道。
出口条件：
所有的用户验收测试用例都被执行；
用户验收测试覆盖率达到了预定要求；
产品的行为方式符合产品规格说明书的要求；
产品的用户文档的质量达到了预定要求；
软件产品的缺陷率低于上市限制的上限。
30、什么是软件的基线版本？
解答：软件基线版本就是软件开发过程中某一个时刻的快照，是一个稳定的版本，可以继续在其上做开发的依据，软件开发人员在基线版本中拉出一条分支，继续开发新的功能，
等新的功能开发完成并且测试稳定后，经过项目管理人员、开发团队负责人、测试团队负责人、软件配置管理人员检视通过之后形成新的基线版本且是稳定的。
31、为什么要做回归测试？
解答：回归测试就是对软件产品的基线版本的改变所做的测试。
验证开发人员所承诺修复的软件缺陷是否已被正确修复；
验证新的软件修改是否影响了原有稳定模块的正确性和稳定性；
验证新的软件修改是否引入了新的缺陷；
验证新的软件版本是否文档，从而成为新的基线版本，以备后续开发使用。
32、什么时候开始做回归测试？
解答：软件产品必须形成了基线版本，另外，必须要有对基线版本的修改。
这时候软件配置管理人员会将修改后的代码编译成新的版本，然后分发给测试部门进行回归测试。
33、怎么做回归测试？
解答：回归测试是贯穿于集成测试、系统测试和用户验收测试等测试阶段的一种测试行为。
以系统测试阶段的回归测试为例：软件产品进入系统测试阶段之后，软件配置管理人员会为这个可以进行系统测试的版本打上系统测试阶段的基线版本标签，测试部门就可以开展系统测试了。
第一种，测试人员按照测试用例以及测试脚本对此基线版本进行测试，发现软件缺陷进行复查和确认，并且根据优先级进行跟踪，确定所有缺陷的修改进入软件新版本的日程。
第二种，需求人员、测试人员、开发人员可能提出新的软件功能需求，这些新的需求描述也被记录在一个跟踪系统中，这时候需要需求人员、测试人员、开发人员、项目管理人员和软件质量管理人员进行讨论并评估其中风险，若讨论和评估通过，则开发人员可以对新的功能进行开发，待新的功能模块经过测试稳定后就可以集成入原有的软件系统中。
以上两者情况的修改都确定要进入新的软件版本时，测试人员就要对这些修改设计新的回归测试计划。
回归测试计划的策略：
（1）在设计新的回归测试计划时，可以用覆盖上一基线版本的所有测试用例加入到新的回归测试计划中，之后加入新功能模块开发的新测试用例。这种策略优点是用例覆盖率高，缺点是测试工作量巨大。
（2）另一种策略是在新的回归测试计划中只包括对所有软件缺陷修复的验证以及对新加入功能的验证。这种策略优点是测试工作量最小，缺点是测试用例覆盖率最低。
（3）最后一种策略是在新的回归测试计划中包括对所有因软件缺陷修复而产生的修改的覆盖。除了验证软件缺陷的修复对原有稳定模块的影响，还加入验证与被修复缺陷有密切关系的模块稳定性的一些测试用例，这些用例可以是部分原有的测试用例，也可以是新开发的测试用例。同理，对新加入的功能，除了验证其本身还要对可能被影响到的模块进行再一次的验证。这种策略优点是测试工作量较小，测试用例覆盖率高，缺点是新的回归测试计划质量和测试覆盖率受开发该计划人员的经验、能力的影响较大，开发新的回归测试计划所需要的工作量也较大。
之后，测试人员又回到了测试的执行阶段。待测试完成之后，测试负责人给出测试报告以反映软件的质量。当软件质量趋于稳定就可以检视确定软件是否符合系统测试的出口要求以进入软件测试的下一阶段。