α测试与β测试
alpha测试Beta测试都需要用户参加。但是，alpha测试是用户在开发环境或者是公司内部模拟实际操作环境的测试。Beta是由最终用户来测试。
区别：两者的主要区别是测试的场所不同。Alpha测试是指把用户请到开发方的场所来测试，beta测试是指在一个或多个用户的场所进行的测试。
Alpha测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中。而beta测试的环境是不受开发方控制的，谁也不知道用户如何折磨软件，用户数量相对比较多，时间不集中。一般地，alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试，测试周期比较长。如果产品通过了beta测试，那么就可以正式发行了。
SOW、HLD、LLD、UTC
SOW:statement of work，工作任务说明书
HLD: High Level Design,概要设计说明书
LLD: Low Level Design，详细设计说明书
UTC: Unit Testing Cases，单元测试用例
集成测试计划在需求分析阶段末提交。请判断这句话的正确与否
下列说法正确的是
1、单元测试对源程序中每一个程序单元进行测试，检查各个模块是否正确实现规定的功能，从而发现模块在编码中或算法中的错误。该阶段涉及编码和详细设计文档。
2、集成测试的主要目的是检查软件单位之间的接口是否正确，主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。
3、确认测试主要是检查已实现的软件是否满足需求规格说明书中确定了的各种需求。
4、系统测试是基于软件需求说明书的黑盒测试，是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确
测试设计员的职责有哪些？
设计测试用例
设计测试过程、脚本
制定测试计划是测试经理来做的；评估测试活动是测试经理组织开发人员来进行的。
单元测试主要技术手段有
驱动代码
Stub代码
Mock代码
GUI测试手段(系统测试的手段)
测试用例设计方法
1、等价类划分
2、边界值分析
3、因果图
4、功能图分析
5、错误推测
6、判定表驱动分析
7、正交实验设计
8、场景设计
Junit单元测试说法正确的是
Junit单元测试框架—基于java语言对的主流单元测试框架
@beforeClass—位于数据准备前期或者其他前期准备（测试类调用前）
–用于提取代码中的共用部分减少冗余，只能声明注解一次
–必须在public static void,方法名随意，，只运行一次。
@AfterClass—位于所有用例运行之后，处理测试后续工作。
--测试类被调用运行结束之前，只能声明注解一次。
--必须在public static void,方法名随意，，只运行一次。
@Test—在Junit3中通过对测试类和测试方法的命名来确定是否为测试
--在Junit4中，只要在方法前加@Test就行，此注解必为单元测试。
--在一个测试类可多次注解，每个只被执行一次，必须是public void
--可以抛异常
使用Assert断言
1、断言相等：assertEquals(100,x)，判断对象是否为同一个
断言不相等：assertNotEquals(100,x)，判断对象是否不为同一个
2、断言数组内容相等：assertArrayEquals({1,2,3},x)
3、断言浮点数相等：assertEquals(3.1416, x, 0.0001)（必须设置误差值）
4、断言为null：assertNull(x)
5、断言真伪性：assertTrue(x > 0)/assertFalse(x < 0)
6、
校准测试函数，使用操作符’=='比较实际和预期的是否重复
集成测试
集成测试的基础策略有很多，通常分为两种：非增量式集成测试策略和增量式集成测试策略
第一种：非增量式集成测试策略
非增量式集成测试策略也叫做大爆炸集成、一次性集成；
即在最短的时间内把所有的系统组件一次性集成到被测系统中，并通过最少的用例来验证整个系统，不考虑各组件之间的相互依赖性或者可能存在的风险。
优点：
容易理解，比较简单
可以多人并行工作，对人力物力资源的利用率较高。
缺点：
问题定位和修改都比较困难
即使被测系统能够被一次性集成，但是还会有许多接口上测试被遗漏，甚至会躲过测试遗留在系统中。
适用场景：
适用于维护型的项目，并且新增的项目只有少数的模块被增加或修改
适用于测试系统比较小，并且各个组件都经过了充分的单元测试。
第二种：增量式集成测试策略
增量式集成的策略有很多种：自顶向下集成，自底向上集成，三明治集成，基于功能集成，基于风险集成，基于分布式集成等。
该策略最大的特点就是：支持故障隔离、定位问题
1，自顶向下集成:(个人理解：随着底层不断增加，测试越来越难以全面。)
自顶向下集成首先要集成主控制模块，然后从软件控制层次结构向下逐步集成，可以采用深度优先或者广度优先进行集成测试，主要验证接口的稳定性。
优势：
能够较早的验证主要的控制点和判断点，如果主控制出现问题能够及时发现。
深度优先：首先实现并验证一个完整的功能需求的正确性
缺点：
桩的开发和维护是该方法的最大问题，底层模块增加，系统越来越复杂，底层模块从测试会越来越不充分。
使用场景：
接口变化比较小的项目并且控制结构比较清晰。
2.自底向上集成
对底层模型的行为进行较早的验证，早期可能出现并行的测试。
缺点：
对顶部的验证推迟了，设计上的错误不能被及时发现，随着顶层的集成，对产品底部的异常越来越难发现。
使用场景：
顶层接口变化比较复杂的，变化比较频繁的系统
3.三明治集成
三明治集成属于混合式集成，综合了自顶向下和自底向上集成的优缺点；测试的时候，将被测软件分成三份，中间一份为目标层，目标层的上部分采用自顶向下集成策略，下部分采用自底向上集成策略。最后在目标层进行会和。
缺点：
最大的缺点就是对中间层的测试不够充分；
使用场景：
适用于大多数项目。使用时要尽可能的减少驱动模块和桩模块的数量。
4.基于功能集成
基于功能角度出发，按照功能的关键程度对功能模块进行集成。
缺点：
对一些接口测试不充分。系统很复杂的时候，功能之间的相互联系很难分析清楚，会造成大量的冗余测试
5.基于风险集成
是一种假设，系统风险度较高的模块间的集成往往是错误集中的地方。
优点：
加速系统的稳定性。
关键点：
风险的识别和评估。
通常跟基于功能集成合用
6.基于分布式集成
主要是验证松散耦合的同级模块之间的交互稳定性。在一个分布式系统中，由于没有专门的控制轨迹，没有专门的服务层，所以构造测试包非常困难，主要验证远程主机之间的接口是否具有最低限度的可操作性。
使用场景：
主要用在分布式系统中。