软件测试面试题
1、测试的定义
软件测试是软件工程过程的一个重要阶段，是在软件升级发布之前对软件开发各阶段产品的最终检查，是为了保证软件开发产品的正确性、完全性和一致性而检测软件错误、修正软件错误的过程。
软件测试是：
1) 程序测试是为了发现错误而执行程序的过程
2) 测试是为了证明程序有错，而不是证明程序无错误；
3) 一个好的测试用例是在于它能发现至今未发现的错误；
4) 一个成功的测试是发现了至今未发现的错误的测试。
软件开发的目的：
是开发出实现用户需求的高质量、高性能的软件产品，而软件测试是以检查软件功能和其他非功能特性为核心，是软件质量保证的关键，也是成功实现软件开发目标的重要保障。
2、测试的种类
2.1从测试方法角度分为：
2.1.1黑盒测试：
是功能测试、数据驱动测试或基于规格说明的测试。在不考虑程序内部结构和内部特性的情况下，测试者依据该程序功能上的输入输出关系，或是程序的外部特性来设计和选择测试用例，推断程序编码的正确性。
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
1.等价类划分
(1)划分等价类。
①如果某个输入条件规定了取值范围或值的个数。则可确定一个合理的等价类(输入值或数在此范围内)和两个不合理等价类(输入值或个数小于这个范围的最小值或大于这个范围的最大值)。
②如果规定了输入数据的一组值，而且程序对不同的输入值做不同的处理，则每个允许输入值是一个合理等价类，此处还有一个不合理等价类(任何一个不允许的输入值)。
③如果规定了输入数据必须遵循的规则，可确定一个合理等价类(符合规则)和若干个不合理等价类(从各种不同角度违反规则)。
④如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。
(2)确定测试用例。
①为每一个等价类编号。
②设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步，直到所有合理等价类被测试用例覆盖。
③设计一个测试用例，使其只覆盖一个不合理等价类。
2.边界值分析
使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。
(1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是[1，100]，可取0，1，100，101等值作为测试数据。
(2)如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如，一个输入文件可包括1--255个记录，则分别设计有1个记录、255个记录，以及0个记录的输入文件的测试用例。
(3)对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。如，一个学生成绩管理系统规定，只能查询95--98级大学生的各科成绩，可以设计测试用例，使得查询范围内的某一届或四届学生的学生成绩，还需设计查询94级、99级学生成绩的测试用例(不合理输出等价类)。
由于输出值的边界不与输入值的边界相对应，所以要检查输出值的边界不一定可能，要产生超出输出值之外的结果也不一定能做到，但必要时还需试一试。
(4)如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等)，则应选取集合的第一个元素和最后一个元素作为测试用例。
3.错误推测法
在测试程序时，人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例，这就是错误推测法。
4.因果图法
等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误。
5.判断表驱动法
6．正交试验设计法
7.功能图法
2.1.2白盒测试：
是结构测试、逻辑驱动测试或基于程序的测试。测试者熟悉程序的内部结构，依据程序模块的内部结构来设计测试用例，检测程序代码的正确性 白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。
白盒测试方法：总体上分为 静态方法和动态方法两大类。
静态测试方法：
不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试，关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。 动态测试方法：
是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。
动态测试方法分为以下几种：
1、逻辑覆盖
程序内部的逻辑覆盖程度，当程序中有循环时，覆盖每条路径是不可能的，要设计使覆盖程度较高的或覆盖最有代表性的路径的测试用例。
(1)语句覆盖。
为了个提高发现错误的可能性，在测试时应该执行到程序中的每一个语句。语句覆盖是指设计足够的测试用例，使被测试程序中每个语句至少执行一次。
(2)判定覆盖。
判定覆盖指设计足够的测试用例，使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，从而使程序的每一个分支至少都通过一次，因此判定覆盖也称分支覆盖。
(3)条件覆盖。
条件覆盖是指设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现一次。
(4)判定/条件测试。
该覆盖标准指设计足够的测试用例，使得判定表达式的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。
(5)条件组合覆盖。
条件组合覆盖是比较强的覆盖标准，它是指设计足够的测试用例，使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。
(6)路径覆盖。
路径覆盖是指设计足够的测试用例，覆盖被测程序中所有可能的路径。
在实际的逻辑覆盖测试中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标准。
2.循环覆盖
3.基本路径测试
其中运用最为广泛的是基本路径测试法。
基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。
2.1.3灰盒测试：
是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性， 同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，
有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，
因此需要采取这样的一种灰盒的方法。
2.2从测试发生的时间顺序分为：
2.2.1单元测试：
是对软件基本单元的测试
单元测试（模块测试）是：开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
单元测试的主要目的：是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。
2.2.2集成测试
对由个模块组装而成的系统进行测试，检查各模块间的接口和通信
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
集成测试主要目的：是针对详细设计中可能存在的问题，尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。
2.2.3系统测试
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
（常见的联调测试）
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
系统测试主要针对[b]概要设计[/b]，检查了系统作为一个整体是否有效地得到运行，例如在产品设置中是否达到了预期的高性能
2.2.4验收测试
验证软件的功能和性能及其它特性是否与用户的要求一致。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要(需求)。 验收测试分为非正式验收测试和正式验收测试两大类。其中非正式验收测试包括alpha测试和beta测试。
在MSF中，测试分为2大类：（其中MSF 是什么？）
1． 覆盖测试：找出程序中的缺陷，即是否该找的地方都找了。
2．使用测试：找出程序中的失败，即为什么使用不成功。
3、测试的执行过程
测试主要由下面6个相互关联、相互作用的过程组成：
3.1测试计划
确定各测试阶段的目标和策略。这个过程将输出测试计划，明确要完成的测试活动，评估完成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程的活动。
3.2测试设计
根据测试计划设计测试方案。测试设计过程输出的是各测试阶段使用的测试用例。测试设计也与软件开发活动同步进行，其结果可以作为各阶段测试计划的附件提交评审。测试设计的另一项内容是回归测试设计，即确定回归测试的用例集。对于测试用例的修订部分，也要求进行重新评审。
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。指对一项特定的软件产品进行测
试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例构成了设计和制定测试过程的基础。
编制测试用例的具体做法：
1) 测试用例文档
2) 测试用例的设置
3) 设计测试用例
测试用例在软件测试中的作用：
1) 指导测试的实施。测试用例主要适用于集成测试、系统测试和回归测试。
2) 规划测试数据的准备
3) 编写测试脚本的"设计规格说明书"
4) 评估测试结果的度量基准。完成测试实施后需要对测试结果进行评估，并且编制测
试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。
5) 分析缺陷的标准
3.3测试实施
使用测试用例运行程序，将获得的运行结果与预期结果进行比较和分析，记录、跟踪和管理软件缺陷，最终得到测试报告
3.4测试配置管理
测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括测试计划、测试方案（用例）、测试版本、测试工具及环境、测试结果等。一般会得到一个基线测试用例库。
3.5资源管理
包括对人力资源和工作场所，以及相关设施和技术支持的管理。如果建立了测试实验室，还存在其他的管理问题。
3.6测试管理
采用适宜的方法对上述过程及结果进行监视，并在适用时进行测量，以保证上述过程的有效性。如果没有实现预定的结果，则应进行适当的调整或纠正。
4、几种测试类型的介绍
4.1单元测试
4.1.1定义
单元测试是对最小的可测试软件元素（单元）实施的测试，它所测试的内容包括内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。侧重于单元内部结构的测试设计和实施依赖于对单元实施情况的了解（白盒方法）。为核实单元的可观测行为和功能而进行的测试设计和实施并不依赖于对实施情况的了解，因而被称为黑盒方法。
单元测试是一种非常高效的测试方法，并且是软件测试周期中第一个进行的测试。加强单元测试力度有利于降低缺陷定位和修复难度，从而降低缺陷解决成本，同时加强单元测试也减轻了后续集成测试和系统测试的负担。
单元测试一般是由开发工程师执行的。
4.1.2方法
单元测试一般要做以下三项工作
a.设计测试用例
b.编写测试代码
c.执行待测程序
其中测试用例的设计是很重要的一步，好的测试用例的原则是：
a.能够发现至今没有发现的错误
b.测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成
c.应当包含合理的输入条件和不合理的输入条件。
可以依照以下方法来设计测试用例：
1、程序中每一条可执行语句至少被执行一次。
2、程序中每一个分支判断的每一种可能结果(主要指switch-case情况)都至少被执行一次。
3、程序中每一个分支判断中的每一个条件的可能结果都至少被执行一次。
4、程序中每一个分支判断中的每一个条件的每一种可能组合结果都至少被执行一次。
5、程序中所有的可能路径都至少被执行一次。
4.1.3常用的工具
常用的单元测试工具有 NUnit 和 NUnitAsp 。
4.2回归测试
4.2.1定义
回归测试是指根据修复好了的缺陷再重新进行的测试。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。
回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。
当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因
此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。
回归测试一般是由测试工程师执行的。
4.2.2方法
一般进行回归测试的步骤如下：
1.建立测试基线,这是回归测试的前提。具体方式是将所有的测试用例放到配置库中，打上版本标记。
2.从基线测试用例库中提取合适的测试用例组成回归测试包，必要时进行开发和重新设计整理。
3.在后续开发过程中，每次测试之前先运行回归测试包。
保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。
4.2.3常用的工具
在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，为了提高回归测试的效率，我们可以使用些自动化回归测试工具。常用的工具有WinRunner等，具体的用法见相关的文档。
4.3性能测试
4.3.1目的
性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。
包括以下几个方面：
一．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
二．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的环节。
三．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
四．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
4.3.2定义
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
性能测试主要测试软件的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及竞争测试。
负载测试：负载测试是一种性能测试,指当数据在超负荷环境中运行时程序是否能够承担。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量
条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
强度测试：强度测试是一种性能测试，它在系统资源特别低的情况下测试软件系统运行情况。实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
数据库容量测试：数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
基准测试：基准测试是一种与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
竞争测试：软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上既安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？
4.3.3 方法
做性能测试一般可以通过一些三方的工具来实现
4.3.3常用的工具
性能测试一般都是通过工具来完成的，常用的工具有 Microsoft Application Center Test(ACT)。
5、测试计划的制定
5.1、制定的阶段
测试计划是与软件开发活动同步进行的。 在MSF的构想(Envisioning)阶段,要制定测试策略和测试的验收标准。在计划(Planning)阶段),要完成和评审测试计划及所用到的资源。在开发(Developing)阶段,要完成和评审单元测试计划。对于测试计划的修订部分，需要进行重新评审。
5.2、制定过程中要考虑的因素
1.应明确的在测试计划中确立好测试管理机制的关键事件,如。
a.汇报机制。确定好用周报制度还是日报制度，日报的反馈速度越快，定位解决问题越快，但信息处理工作量大。
b.例会制度。每周举行一次例会，根据实际情况，考虑测试计划的调整或滚动。 c.实施怎样的实验室管理制度，以做到责任明确。
d.在日报中的工作汇报。不仅要包括发现的问题，还应包括在测试时新创造的测试点，这些测试点应该补充到测试计划中作为一个测试项；
e.人员情绪如何调整。在测试周期过长时，影响测试效率的一个重要因素是测试人员的情绪，一个人反复测试一个模块，总是会出现厌倦情绪的。
2.应明确的在测试计划中确立数据的管理和分析体系的办法,如：专人对提交的过程文档,周报报告中的数据予以整理和管理，以便后期在系统测试评审时作为数据来分析。
现在往往是在系统测试结束后才来收集数据，可能会造成数据的不同程度失真或滞后。收集的数据可以按不同种类来划分。这可以依赖我们系统的CHECKLIST。有一种工具叫 SRES (软件可靠性专家系统) 是很有用的，我们可以按照它的输入数据来收集。
3.应明确的在测试计划中确立风险估计的引入,如：
制定测试计划时,就应该考虑好对系统测试工作量的估计，测试成本的估计,版本市场定位的估计等等,并且必要时可根据实际情况进行裁剪或补充。
5.3、计划的内容
1.概述
2.测试的目的
3.测试方案和假设
4.主要测试职责：参与测试过程的人
5.测试的特征和功能：要测试的功能和特殊
6.测试期望的结果
7.交付物：实施测试要用材料（文档和数据）
8.测试的规程和评审方法:为了确保测试的质量需要经过的测试步骤
9.跟踪和状态报告：定义在测试过程中，测试小组成员沟通的方式
10.测试资源需求：测试要用到的资源（人，软件工具，硬件环境）
11.Bug报告工具和方法：描述如何记录测试过程中发现的BUG
12.进度表：描述测试的周期，任务，里程碑和交付物
13.风险和依赖：描述测试的假设，风险和依赖性
6、负载测试，容量测试，强度测试和兼容测试的区别 负载测试：
在一定的工作负荷下，系统的负荷及响应时间。
强度测试：
在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试：
容量测试目的是通过测试预先分 析出反映软件 系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状 态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试 还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
兼容测试：
主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的。
7、alpha测试、beta测试 和gamma测试
测试有三个传统的称呼，alpha、beta、gamma，用来标识测试的阶段和范围。alpha 是指内测，即现在说的 CB，指开发团队内部测试的版本或者有限用户体验测试版本。beta 是指公测，即针对所有用户公开的测试版本。然后做过一些修改，成为正式发布的候选版本时（现在叫做 RC - Release Candidate），叫做 gamma。
7.1 Alpha测试 Alpha 测试是由一个用户在开发者的场所来进行的，软件在开发者对用户的“指导”下进行测试，开发者负责记录错误和使用中出现的问题，Alpha测试是在一个受控的环境中进行的。
Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部用户在模拟实际操作环境进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员进行分析和处理。目的是评论软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha可以从软件产品编码结束之后开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的可靠和稳定性之后开始，有关的手册（草稿）应该在Alpha测试之前准备好。
Alpha测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。
7.2 Beta测试
经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。 一般包括功能度、安全可靠性、易用性、可扩充性、兼容性、效率、资源占用率、用户文档八个方面。
Beta测试是由软件的多个用户在一个或多个实际使用环境下进行的测试，开发者通常不在现场，Beta测试不能由程序员和测试员完成。因此，Beta测试是在开发者无法控制的
环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的问题，包括真实的和主管确认的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beat测试注重于产品的支持性，包括文档、客户培训和支持产品的生产能力，只有当Alpha测试达到一定的可靠程序后才能进行Beta测试。由于Beta测试的主要目标是测试产品的可支持性，所以beta测试应尽可能由主持产品发行的人员来管理。
我们认为Beta测试就是由一部分受控制的客户进行的黑盒测试。
由于Alpha测试和Beta测试的组织难度大，测试费用高，测试的随机性强，测试周期跨度较长，测试质量和效率难于保证，所以，很多专业软件可能不进行Beta测试，随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软件的Beta测试外包给测试机构进行测试。
区别：
Alpha测试是:由用户或开发人员在开发环境下进行的测试.
Beta测试是:在实际应用环境中进行的测试,通常由用户来完成,开发人员不在现场. 两种测试最根本的区别是在于测试环境.
7.3 Gamma测试
Gamma测试是一个很少被提及的非正式测试阶段，该测试阶段对应的是对“存在缺陷”产品的测试。考虑到任何产品都可以被称为“存在缺陷”的产品（测试只能发现产品中存在的问题，不能说明产品不存在问题），因此这个概念存在一定不确定。
8、测试结束的标准是什么
用例全部测试。
覆盖率达到标准。
缺陷率达到标准。
其他指标达到质量标准
9、描述软件测试活动的生命周期
测试周期分为计划、设计、实现、执行、总结。
计划：对整个测试周期中所有活动进行规划，估计工作量、风险，安排人力物力资源，安排进度等；
设计：完成测试方案，从技术层面上对测试进行规划；
实现：进行测试用例和测试规程设计；
执行：根据前期完成的计划、方案、用例、规程等文档，执行测试用例。
总结：记录测试结果，进行测试分析，完成测试报告。
10、软件的缺陷等级应如何划分？
A类—严重错误：
1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误
操作导致的程序中断 5． 功能错误 6． 与数据库连接错误
7． 数据通讯错误
B类—较严重错误：
1． 程序错误 2． 程序接口错误
3． 数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般性错误，
1． 操作界面错误（包括数据窗口内列名定义、含义是否一致）
2． 打印内容、格式错误 3． 简单的输入限制未放在前台进行控制
4． 删除操作未给出提示 5． 数据库表中有过多的空字段
D类—较小错误，
1． 界面不规范 2． 辅助说明描述不清楚 3． 输入输出不规范
4． 长操作未给用户提示 5． 提示窗口文字未采用行业术语
6、可输入区域和只读区域没有明显的区分标志
11、当开发人员说不是BUG时,你如何应付？
开发人员说不是bug，有2种情况，
一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要 不要改。
二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？ 程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不 要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场， 让问题得到最后的确认
（ 首先你要正确理解出错误是bug，还是软件缺陷，如果是软件缺陷的话，最好直接找你的部门经理，然后由部门经理与开发部经理协调。
如果是bug，你应当理清bug出现的原因，然后整理成报告给相应的开发人员， 如果此人员不改正的情况下，交给部门经理负责。）
12.为什么一个团队中要开展软件测试工作？
答：软件测试在整个团队中占有非常重要的地位，具体来说就是测试是一个发现软件错误的过程，执行软件测试会以最少的人力和时间，系统要找到软件存在的缺陷和错误，
建立起开发人员和使用者对软件的信息。
13.您是否了解以往所工作的企业的软件测试过程？
如果了解，请叙述在这个过程中都有哪些工作要做？分别有哪些不同的角色来完成这些工作？
答：软件测试人员负责软件开发部门的新产品的升级测试，负责软件问题解决过程跟踪，
负责人软件开发文档开发工作的规范化及管理开发部门的产品文档，
制作用户手册及操作手册，负责产品的上线测试，监督软件开发过程的执行，提高产品质量。
14.您是否了解以往开发所工作的企业的开发过程？
如果了解，请叙述一个完整的开发过程需要完成那些工作？分别有哪些不同的角色来完成这些工作？
(对于软件测试部分，可以简述)
答：需求人员连同系统分析人员、测试人员开会讨论需求。系统分析人员写出需求分析说明书，并连同系统分析人员、测试人员、需求人员开会讨论可行性。
系统分析人员写出详细设计说明书，程式人员编码，给出系统流程图，交与测试人员，测试人员给出Bug统计表。
15.您在以前的测试工作中都曾经具体从事过哪些工作？其中最擅长哪些部分工作？
答：性能测试，编写测试工具，文档的管理等，比较擅长与写测试用例和进行测试功能测试。
16.您熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……） 答：有功能测试、性能测试、可靠测试、安全测试、负载测试、压力测试、安装/卸载测试，启动/停止测试、兼容性测试、互联测试、
文档测试、恢复测试、回归测试、可使用性测试、容量测试
功能测试只对软件的功能是否满足用户需求来做测试。性能测试需要和压力和负载测试联合起来。
17.请比较下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
答：黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和你内部性能，只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。
白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。
单元测试：白盒测试的一种，对软件设计中的单元格模块进行测试。
集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。
系统测试：在所有都考虑的情况下，对系统进行测试。
验收测试：第三方进行的确认软件满足需求的测试。
18.测试计划工作的目的是什么？测试计划的内容都包括什么？其中那些是最中要的？
答：测试计划工作是对测试工作内容的一个有效的组织和规划，能保证测试工作有效的进展。测试计划工作包括测试目标，测试范围的定义，
测试方法的选择，测试进度里程碑，测试资源的有效配置和管理。
测试计划工作也称为测试策略，主要描述测试工程的总体方法和目标，描述目前在进行那一阶段的测试（功能测试、性能测试等）确定测试范围，生成测试数据等。 其中软件计划中的测试目标最重要，他的软件测试是我组要达成的最终结果。
19. 你认为做好测试计划工作的关键是什么？
答：1.明确测试的目标、增强测试计划的实用性；
2.坚持“5W”规则，明确内容与过程，"what"、"why"、"when"、"where"、"how"
3.采用评审和更新机制，保证测试计划满足实际需求。
4.分别创建测试计划与测试详细规格、测试用例
（ 测试用例设计工作的关键是对可行的和不可行的都要考虑。）
20.你所熟悉的测试用例设计方案都有哪些？请分别以具体的例子来说明这个方法在测试用例设计工作中的应用。 答：有黑盒和白盒两种测试种类，黑盒有等价类划分法，便捷分析法，因果图法和错误猜测法则，首先利用等价类划分法，
可以一个或多个结果是ok的测试用例，然后确认多个NG的测试用例，然后利用边界值分析法，可以对结果分别是ok和NG的测试用例进行扩展和补充。
21什么是测试评估？测试评估的范围是什么？ 软件测试评估是指对未正式投入商业化使用的软件进行预先的小规模试验，又称小试。主要是由代码审查和合理性分析组成。
作用如下：
1. 开发人员若得知他们的代码会被测试评估，他们会更加努力工作。
2. 软件测试评估可以改进开发人员的编程技术
3. 软件测试评估有利于导师制度，程序员们会学到更多
4. 软件测试评估可以实现优质文化的传承
5. 软件测试评估可以激发团队凝聚力
评估的范围很广,例如功能，性能，美观，易用性的，健壮性的，安全性的，兼容性，效率等软件好坏的的衡量指标，可以参考需求
测试评估的范围：功能，性能，界面，实用性，速度，兼容性，易用性，各模块的完善性等