软件测试课复习资料(V0.9).doc

题型：
-客观题：选择题(10*1’)+填空题(10*2’ ) +判断题(10*1’ )共40分
-简答题: 4或5道，共20分
-分析题: 4或5道，共40分
#Chap 1
·1、软件测试的概念 (P9)
从一个通常是无限的执行域（集合）中选择合适的、有限的测试用例，对程序所期望的的行为进行动态验证的活动过程。
·2、软件测试正反2种观念的争辩。代表人物、他们的主要观念及存在的问题。 (P7~9)
1972年，软件测试领域的先驱BILL Hetzel博士（代表论著《软件测试完全指南》），在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。
观点：软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。
（1） 测试是试图验证软件是工作的，也就是验证软件功能执行的正确性。
（2） 测试的目的是验证软件是否符合事先定义的要求。
（3） 测试的活动是以人们的设想或预期的结果为依据。这里的设想或预期的结果指需求定义，软件设计的结果。
存在问题：
（1） 可能使软件测试的活动效率降低
（2） 甚至缺乏有效的方法进行测试活动。
Myers（代表论著《软件测试的艺术》）认为不应该着眼于验证软件是工作的，相反，应该用逆向思维去发现尽可能多的错误。
观点:测试是为了发现错误而执行的一个程序或者系统的过程。
一个成功的测试必须是发现了软件问题的测试否则测试就没有价值。这个定义引导人们证明软件是不工作的，以反向思维方式，不断思考开发人员理解的误区，不良的习惯，程序代码的边界，无效数据的输入以及系统的弱点，试图破坏系统摧毁系统，摧毁系统，目标就是发现系统中各式各样的问题。
存在问题：
（1） 如果只强调测试的目的是寻找错误，就可能是测试人员容易忽视软件产品的某些基本需求或者客户的实际需求，测试活动可能会存在一定的随意性和盲目性。
（2） 如果只强调测试的目的是寻找错误，使开发人员容易产生一个错误的印象，认为测试人员的工作就是挑毛病的。
（3） 除此之外还强调测试是执行一个程序或者系统的过程，也就是说测试活动是在代码完成之后进行，而不是贯穿整个软件开发过程的活动，及软件测试不包括软件需求评审，软件设计评审和软件代码静态检查等一系列活动，从而使软件测试的定义具有局面性和片面性。
总结：这正反两方面的观点是从不同的角度看问题，一方面通过测试来保证质量，另一方面又要改进测试方法和提高软件测试的效率，两者相辅相成。软件测试就是在这两者之间获得平衡，但对于不同的应用领域，二者的比重不一样。
·3、结合V模型谈谈开发与测试关系附录：V模型 (P10-P11)
V模型 ：能准确反映出开发活动和测试活动之间的关系，说明：
1） 测试活动与开发活动同时启动；
2） 每个开发活动都有相应级别的测试类型相对应。
3） 测试是分层的。只有完成单元测试、集成测试、系统测试、验收测试4个层次的测试，才是对软件产品的完整测试。

·4、请结合实例，谈谈为什么穷尽测试是不可能的。(开放题，从输入和路径穷尽来考虑)
通过测试并不能发现和修改测试对象中的全部的缺陷和问题，因此，不可避免有一些缺陷会遗漏到客户的使用现场，从而触发软件产品产生令用户不满意的失效或者各种问题。
即使是规模很小的软件或者软件产品，其逻辑路径和输入数据的组合也几乎是无穷的。假如测试人员想对测试对象进行完全的检查和覆盖，那基本上是不可能的.
测 试人员面临的测试时间和测试资源往往是非常有限的。多年的测试实践经验表明，测试团队往往很难获得测试计划中预留的测试时间，当软件开发和测试的时间发生 冲突的时候，测试团队常常被要求压缩测试时间；同时，测试过程中的测试资源限制，例如：测试平台、测试人员的限制，使得测试团队只能在有限的条件下开展测 试活动 
测试内容几乎是无穷的，而测试时间和测试资源非常有限，我们能做的就是采取合适的测试策略，在现有条件下如何做的更好。
测试的尽早介入。集中精力在缺陷刚刚被引入的阶段就发现它，避免缺陷向后续阶段转
移（不仅可以降低成本，同时也可避免缺陷的雪崩效应）；
基于风险的测试。确保测试高优先级的关键的功能首先被测试，尽早和尽量多的发现严
重程度的缺陷，而不是将有限的测试时间和资源浪费在无关紧要的地方；

·5、了解测试目的、测试驱动开发的概念 (P9 P13)
测试目的：验证软件是否符合事先定义的要求。
测试驱动开发：测试在先，编码在后的开发方法。它要求在编写
某个功能的代码之前先编写测试代码，然后只编写使测试通过的
功能代码，通过测试来推动整个开发的进行。

6、了解SQA质量保证的概念、与软件测试的关系 P11-P12
SQA质量保证：通过对软件产品有计划地进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。
与软件测试的关系：相辅相成，既存有包含又存有交叉的关系。
（1）SQA指导、监督软件测试的计划和执行，督促软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程 的改进。
（2）软件测试是SQA重要手段之一，为SQA提供所需的数据，作为质量评价的客观依据。
（3）它们的相同点在于二者都是贯穿整个软件开发生命周期的流程。
（4）它们的不同之处在于SQA是一项管理工作，侧重于对流程的评审和监控，而测试是一项技术性的工作，侧重于对产品进行评估和验证。
#Chap 2
·1、软件质量的概念
软件质量定义：软件产品满足规定的和隐含的与需求能力有关的全部特征和特性。它包括：1软件产品质量满足用户要求的程度；2软件各种属性的组合程度3用户对软件产品的综合反映程度4软件在使用过程中满足用户要求的程度 （P15）
·2、ISO9126软件质量模型（一层6个即可），并分别说明各个质量属性的含义 (P17)
Iso9126模型：高层：软件质量需求评价标准（SQRC）属性：功能性、可靠性、可用性、效率、可移植性、可维护性
中层：软件质量设计标准（SQDC） 属性： 安全性、、成熟性、可理解性、时间表现、可分析性、适应性
低层：软件质量度量标准（SQMC）
·3、软件缺陷的定义，常见缺陷的辨识
软件缺陷：是指计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵，其结果会导致软件产品在某种程度上不能满足用户的需求
表现形式：1运行出错，包括 运行中断、系统崩溃、界面混乱2数据计算错误，导致结果不正确3功能、特性没有实现或部分实现4在某种特点条件下没能给出正确或准确的结果5计算的结果没有满足所需要的精度6用户界面不美观7需求规格说明书的问题8设计不合理，存在缺陷9实际结果与预期结果不一致10用户不能接收的其他问题 （P18）
·4、软件测试的分类：按阶段、按目标、按方法。
目的分类：集成测试、功能测试、回归测试、性能测试、可靠性测试、安全测试、兼容性测试
阶段分类：需求评审、设计评审、单元测试、集成测试、系统测试、验收测试、α测试、β测试
方法分类：静态测试、动态测试、黑盒测试、白盒测试
-静态测试和动态测试、黑盒测试和白盒测试的划分原则
根据测试过程中被测软件是否被执行，软件测试可分为静态测试和动态测试。
根据是否针对系统的内部结构和具体实现算法来完成测试，软件测试可分为白盒和黑盒
-非功能测试：性能测试、可靠性测试、安全性测试，及常见非功能缺陷P22
性能测试：测试系统在不同负载条件下的系统具体的性能指标
可靠性测试：检验系统能否保持长期稳定，正常的运行，如确定系统平均故障间隔时间，包括强壮性测试和异常处理测试。
安全性测试测试系统在应对非授权的内外部访问，有意攻击时的系统防护能力。
-5、什么是黑盒测试和白盒测试，它们各自的局限性是什么。P26~P28
黑盒测试：不关注软件内部结构，着眼于程序外部用户界面，关注软件的输入和输出，关注用户的需求，从用户的角度验证软件的功能，实现端到端的测试。 缺陷：1是否不正确或遗漏了功能2能否正确地接收输入数据，能否产生正确的输出信息3功能操作逻辑不合理4界面是否出错、是否不美观5安装过程中出现问题，安装步骤不清晰、不够方便灵活6系统初始化问题
白盒测试：按照程序内部的结构测试程序，测试程序内部的变量状态、逻辑结构、运行路径等 缺陷：试图列举所有路径测试，是不可能的，企图遍历所有的路径是很难做到的，即使每条路径都测试了，覆盖率得到100%，程序也可能出错。
-6、按阶段：单元测试、集成测试、系统测试、验收测试，它们的概念与不同。附录：测试阶段定义 P28
类别
对象
目的
测试依据
测试方法
单元测试
模块内部程序
消除局部模块逻辑和功能上的错误和缺陷
详细设计文档
API说明
白盒测试
集成测试
模块间的接口和调用关系
找出与软件设计相关的程序结构，模块调用关系、接口方面的问题
概要设计文档
接口设计说明
灰盒测试
系统测试
整个系统，包括系统软硬件等
对整个系统进行一系列的功能、非功能测试，发现功能或非功能问题。
系统需求规格说明文档
黑盒测试
验收系统
整个系统，包括系统软硬件等，采用真实用户环境
对整个系统按用户环境和用户使用场景进行一系列整体的解决方案级测试, 确认系统与用户需求的匹配程度
用户需求
黑盒测试
·7、验证与确认（V&V）的概念及两者区别V&V (P25)
验证：检验软件是否已正确实现了产品规格说明书所定义的系统功能和特性
确认：确认软件是否真正满足用户需求，一切从客户出发，理解客户的需求。
Verification：是否正确构造了软件？即是否正确的做事，验证开发过程是否遵守已经定义好的内容。
Validation：是否够早了正确的软件？即是否做正确的事，即正在构建用户需要的功能？
区别：验证是检验开发出来的软件产品和设计规格说明书的一致性，即是否满足软件厂商的生产要求。但设计规格说明书本身就可能存在错误，所以即使软件产品中某个功能实现的结果和设计规格书完全一致，但可能并不是用户所需要的，因为设计规格说明书很可能一开始就对用户的某个需求理解错了，所以仅进行验证测试还是不充分的，还要进行确认测试。确认就是检验产品功能的有效性，即是否满足用户的真正需求。

#Chap 3
·1、采用错误推测法进行测试。例：针对打开文件失败你考虑测试哪些情况？（开放题）P38
·2、黑盒测试的用例设计方法及应用：重点掌握等价类、边界值、判定表、Pairwise方法。应用参见附录：黑盒测试方法。 (P39-P47、作业)
（1）等价类
对输入用户密码进行验证
输入：
1）用户密码为6到8位。
2）必须含有字母和数的组合。
输出： 如正确，输出正确的信息。
否则，输出相应的错误信息。
要求：
（1）分析程序的规格说明，列出输入域等价类（包括有效和无效等价类）
（2）根据（1）中的等价类，设计能覆盖所有等价类的测试用例，要求包括输入数据和预期输出，并指出各个测试用例所覆盖的等价类编号

输入条件
有效等价类
编号
无效等价类
编号
用户密码
6<=位数<=8
（1）
位数<6
（3）
位数>8
（4）
包含字母和数字
（2）
不包含数字
（5）
不包含字母
（6）

序号
输入参数
覆盖等价类
输出信息
1
1234abcd
（1）（2）
输入正确
2
ab1234
（1）（2）
输入正确
3
1234a
（3）
输入错误
4
123456789df
（4）
输入错误
5
abcdedf
（1）（5）
输入错误
6
1234567
（1）（6）
输入错误

（2）判定表
假设中国某航空公司规定：
中国去欧美的航线所有座位都有食物供应。每个座位都可以播放电影。
中国去非欧美的国外航线都有食物供应，只有商务仓可以播放电影。
中国国内的航班的商务仓有食物供应，但是不可以播放电影 。
中国国内的航班的经济仓除非飞行时间大于2小时就有食物供应，但是不可以播放电影。 
请使用判定表方法进行测试设计。

1
2
3
4
5
6
条件
A:航班
（A1=国内；A2=国外欧美，A3=国外非欧美）
A1
A1
A1
A2
A3
A3
B 航位等级
（ B1=经济仓, B2=商务仓,B3=其它）
B1
B1
B2/B3
-
B1
B2/B3
C飞行时间（C1:>2小时；C2:<=2小时）
C1
C2
-
-
-
-
动作
播放电影

√

√
食物供应
√

√
√
√
√

（3）Pairwise组合测试
对于系统，有A，B，C三因子，每个因子取值为A={A1,A2}, B={B1,B2},C={C1,C2}
n 如果是完全组合测试：则有2*2*2=8 个用例
T1: A1 B1 C1
T2: A1 B1 C2
T3: A1 B2 C1
T4: A1 B2 C2
T5: A2 B1 C1
T6: A2 B1 C2
T7: A2 B2 C1
T8: A2 B2 C2
n 如果是Pairwise二维组合，则有4个用例。
ü 所有的二二因子组合有：
A和B的组合(A1,B1),(A1,B2),(A2,B1),(A2,B2)
B和C的组合(B1,C1),(B1,C2),(B2,C1),(B2,C2)
A和C的组合(A1,C1),(A1,C2),(A2,C1),(A2,C2)

ü 覆盖这些2因子组合，共需要的用例有：
T1： A1 B1 C1
T2： A2 B1 C2
T3： A1 B2 C2
T4： A2 B2 C1
n 如果是一维组合，则有2个用例。
覆盖A1,A2，B1,B2，C1,C2各个单因子即可。
共需要的用例
T1：A1 B1 C1
T2：A2 B2 C2

黑盒测试的方法：1等价类划分法：借助数据的输入输出来判断功能能否正常运行（是否可以用一组有限的数据去代表近似无限的数据）
2边界值分析法：对输入的条件进行分析并找出其中的边界值条件，通过这些边界值的测试来发现更多的错误
3判定表方法：采用一种适合于多种条件的组合，相应地产生多个动作（结果）的方法来进行测试用例的设计
·3、白盒测试的逻辑覆盖用例设计方法及应用：重点掌握语句、判定、条件组合、路径覆盖。应用参见附录：白盒测试。
白盒测试常用的逻辑覆盖：语句覆盖：运行被测程序，是程序中的每个可执行语句至少被执行一次 判定覆盖：设计若干个用例，运行被测程序，使得程序中每个判断的取真分支和假分支至少经历一次，及判断真假是否均被满足 条件覆盖：执行被测程序，使判断中每个条件的可能取值至少被满足一次 判定-条件覆盖：使所有条件的可能取值至少被执行一次，所有判断的可能结果至少执行一次 条件组合覆盖：使判断中每个条件的所有可能至少出现一次，且每个判断本身的判定结果也至少出现一次 路径覆盖：覆盖程序中所有可能的执行路径 基本路径测试法5步骤（1）程序的流程控制图（2）计算程序环路复杂度（3）确定基本路径（4）准备测试用例，确保基本路径组中的每一条路径被执行一次（5）图形矩阵
使用白盒测试的逻辑覆盖方法测试如下程序段。要求：
（1） 画出程序控制流图
（2） 分别以语句覆盖、判定覆盖、条件组合覆盖、路径覆盖方法设计用例，并写出每个用例的执行路径

1 If (A>1 && B==0) then
2 X=X/A
3 If (A>2|| X>1) then
4 X=X+1

测试用例
A，B，X
执行路径
语句覆盖
2，0，3
ace
判定覆盖
2，0，3
ace
1，0，1
abd
条件组合覆盖
2，0，3
ace
2，1，1
abe
1，1，1
abd
1，0，3
abe
路径覆盖
2，0，3
ace(L1)
1，0，1
abd(L2)
2，1，1
abe(L3)
3，0，3
acd(L4)

·4、基本路径(独立路径)的概念及环路复杂度（圈复杂度）的计算、确定基本路径的方法。应用参见附录：基本路径测试。 (P53-P55、作业)
使用基本路径测试如下程序段。要求：
（1） 出控制流图
（2） 求出程序圈复杂度
（3） 导出测试路径
void sort(int irecordnum,int itype)
1 {
2 int x=0;
3 int y=0;
4 while(irecordnum-->0)
5 {
6 if(itype==0)
7 break;
8 else
9 if(itype==1)
10 x=x+10;
11 else
12 y=y+20;
13 }
14 }
答：
1）

2）V(G)=10-8+2，其中10是控制流图G中边的数量，8是控制流图中节点的数目。（ 边数-节点数+2）
3）可得出程序的基本路径集中有4条独立路径：
i. 路径1：4->14
ii. 路径2：4->6->7->14
iii. 路径3：4->6->9->10->13->4->14
iv. 路径4：4->6->9->12->13->4->14

·5、模糊测试的概念，及对其测试方法的辨析 (P60)
模糊测试，就是通过一个自动产生数据的模版或框架来构造或自动产生大量的、具有一定随机性的数据作为系统的输入，从而检验系统在各种数据情况下是否会出现问题
辨析：模糊测试方法可以模拟黑客来对系统发动攻击测试，在安全性测试上发挥作用之外，还可以用于对服务器的容错性测试。模糊测试方法缺乏严密的逻辑，不去推倒哪个数据会造成系统破坏，而是设定一些基本框架，在这个框架内产生尽可能多的杂乱数据进行测试，发现一些意想不到的系统缺陷。由于要产生大量数据，模糊测试方法一般不能通过手工测试，而是通过工具来自动执行。

#Chap 5
·1、单元测试的定义和主要任务 (P96-P97)
单元测试：是对软件组成单元进行的测试，而且软件单元是在与程序的其他部分相隔离的情况下进行独立的测试
单元测试的主要任务：包括逻辑、功能、数据和安全性等各方面的测试，包括单元中所有
·2、什么叫驱动和桩？画出单元测试模型图 (P106 图5-1)
驱动：驱动程序，驱动模块，用于模拟被测模块的上级模块，能够调用被测模块，并在测试过程中，驱动模块接受测试数据，调用被测模块并把相关的数据传送给被测模块
桩：桩程序，桩模块，用于模拟被测模块工作过程中所调用的下层模块。

驱动模块

被测试单元

桩模块1
桩模块2

·3、代码评审中常见缺陷模式的识别。参见附录：代码缺陷模式。 (P109~P112)
//非法计算
double dosomething(double a, b)
{
c = a/b
...
}

//数组越界
Int MAX_LEN=4;
void foo()
{
int[] array = new int[MAX_LEN];
for (int i = 0; i<= MAX_LEN; i++) {
array[i]=0;
}
}
//死循环
void f1()
{
int i = 0;
while ( i < 10){
i--;
}
｝
//空指针
boolean typeEquals(Object a, Object b)
{
if (a.getClass() == b.getClass())
return true;
else
return false;
}
·4、JUNIT工具使用，给你一个函数原型，可以写出它的测试函数 (P123、实验4)
·5、集成测试的模式及各自优缺点 P133
1非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要求的程序，如大棒模式
2渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完再把下一个应该测试的模块结合进来测试
各自优缺点：
渐增式测试模式：需要编写的软件较多，工作量较大，而非渐增式测试模式测试开销小
渐增式测试模式：发现模块间接口错误早，而非渐增式测试模式晚
渐增式测试模式：测试更彻底
渐增式测试模式：需要较多的机器时间
非渐增式测试模式：发现错误较难诊断，而使用渐增式测试模式，如果发现错误则往往和最近加进来的那个模块有关
使用非渐增式测试模式：可以并行测试
·6、混合策略及三明治集成方法的概念及方法应用。给个模块结构图，写出它的集成图。（P135）

三明治：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序，因为在测试初自底向上集成已经验证了底层模块的正确性。

#Chap 6
·1、系统测试的概念与测试目的
系统测试是将经过集成测试后的软件，作为计算机系统的一个部分，与计算机硬件。某些支持软件、数据、平台等系统元素结合起来，在真实运行环境中对计算机系统进行一系列严格有效的测试来发现软件潜在的问题，保证系统的正常运行。
目的：充分运行系统，验证整个系统是否满足功能和非功能性的质量需求。（P137）
·2、回归测试的目的、过程及选取用例的策略 (P150~P151)
回归测试的目的是在程序有修改的情况下保证原有功能正常的一种测试策略和方法，因为这时的测试不需要进行全面测试，从头到尾测一遍，而是根据修改的情况进行有效测试
修改的两层含义：1所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；2不影响软件原有功能的正确性。
回归测试过程：（1）识别出软件中被修改的部分（2）从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0（3）依据一定的策略从T0中选择测试用例测试被修改的软件（4）如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。（5）用T1执行修改后的软件
选取用例的策略：应该兼顾效率和有效性两个方面。方法：（1）再测试全部用例（2）基于风险选择测试（3）基于操作刨面选择测试（4）再测试修改的部分
·3、常见的系统性能指标，及性能指标估算方法。参见附录：性能指标28原则估算方法。P151
常见的有：
（1） 请求响应时间：客户端浏览器向WEB服务器提交一个请求到收到相应之间的时间间隔。
（2） 事务响应时间：事务可能由一系列的请求组成，事务的响应时间就是这些请求完成处理花费的时间。
（3） 数据吞吐量单位时间内对客户端和服务器之间网络上传输的数据量。
某系统的事务数约100万笔。假设每年交易量集中在10个月，每个月24个工作日，每个工作日6小时，试采用80～20原理估算系统的每秒事务数TPS
答： 100 0000 *80% / (10*24*6*3600 *20%)
·4、系统负载包括哪些方面？什么在线用户、并发用户、虚拟用户、常见的负载模式有哪些(P153-P154)
系统负载：可以看做是“并发用户并发数量+思考时间+每次请求发送的数据量+负载模式”
具体分为：1在线用户：通过浏览器访问登录Web应用系统后并且还没有退出该系统的用户2虚拟用户：模拟浏览器向Web服务器发送请求并接受响应的一个进程或线程3并发用户：这些用户在同一时刻做同一件事情或同样的操作4用户并发数量：近似于同时在线用户数量，但不一定等于在线用户数量，因为有些在线用户不进行操作，或前后操作之间的间隔时间很长5思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间6负载模式：加载的方式。
·5、什么叫拐点，如何确定系统的性能瓶颈？给你一个性能测试结果数据，可以进行简要的分析。参见附录：性能测试结果分析示例 (P155)
某业务系统由客户端、应用服务器和数据库服务器三个节点组成。该系统的性能测试结果如下表：
并发用户数
数据吞吐量平均值
事务响应时间平均值(s)
数据库服务器CPU平均利用率
应用服务器CPU
平均利用率
10
1.12
0.57
37.50%
13.58%
20
4.3
1.16
57.32%
24.02%
30
7.74
3.66
70.83%
39.12%
50
8.04
6.63
97.59%
53.06%

1） 请简述并发用户数、数据吞吐量和事务响应时间的概念。
2） 随着并发用户数增加，当吞吐量不再递增时，响应时间是否会递增？并说明理由。
3） 判断系统服务器资源使用情况是否合理？系统服务器的性能瓶颈主要位于哪个节点?
答：
1） 概念略，参见教科书。
2） 会增加。当吞吐量不增加，意味着饱和，消息在排队，响应时间一定会增长。
3） 不合理。一般来说，当系统的正常工作时，CPU资源占用应不超过75%。当并发用户数达到50时，数据库CPU资源占用超过了95%，由此可以判断系统主要性能瓶颈在数据库。
·6、向前兼容、向后兼容的含义。
向前兼容是指可以使用以前版本的软件
向后兼容指的是可以使用未来版本的软件（P180）
·7、兼容性测试的含义，包括软件、数据共享、硬件兼容性及应用示例。 (P180)
·8、针对某新产品(例：手机/一次性杯子等)，你打算开展哪些类型的测试？请至少列举出5种以上（开放题）
#Chap 7
·1、α测试和β测试
α测试是指软件开发公司组织内部人员模拟各类用户对即将面市的软件产品（称为α版本）进行测试，试图发现错误并改正。α测试的关键在于尽可能的逼真地模拟实际运行环境和用户对软件产品的操作并尽最大的努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善 （P188）
·2、了解验收测试概念及特点(用户参与、真实场景、满足用户需求等)

#Chap 9
·1、自动化测试的定义，可由自动化测试完成的工作内容
自动化测试是把人为驱动的测试行为转化为机器执行的一种过程，即模拟手工测试步骤，通过执行由程序语言编制的测试脚本，自动地完成软件的单元测试、功能测试、负载测试或性能测试等全部工作。 P213 P214
·2、自动化测试的四种脚本类型及相应含义、如何用QTP实现数据驱动 (P219-P221、实验6)
·3、测试工具的分类及代表性工具的名称及应用场景。例：QTP, Selenium, xUnit, EMMA, Jmeter, LoadRunner,Appscan, Wirshark, SoapUI, Mantis, Bugzilla, JIRA等。
根据测试方法不同：分为白盒测试工具和黑盒测试工具，或者分为静态测试工具和动态测试工具等。
根据测试的对象和目的不同，分为单元测试工具，功能测试工具，负载测试工具或性能测试工具，管理测试工具等。
静态测试工具：Compuware公司的CodeReview，Telelogic公司的Logiscope软件，PR公司的PRQA软件。
动态测试工具：Compuware公司的DevPartner软件，IBM公司的Rational Purify系列。
CUG功能测试：QTP，WebKing，SilkTest
性能测试：LoadRunner，IBM rational performance tester

#Chap 14
·1、基于需求的测试覆盖的评估方法 (P319-P320)
方法：1对于需求的估算2基于需求的测试覆盖评估3基于代码的测试覆盖评估。

·2、基于缺陷分析的产品质量评估方法：经典的种子公式、基于缺陷清除率的估算方法 (P321)
附录：基于缺陷分析的质量评估方法示例
（1）经典种子公式
两个独立测试同一个程序，第一组发现25个缺陷，第二组发现30个缺陷，在两个小组发现的缺陷有15个是共同的，估计程序中缺陷个数。
答：可以采用缺陷注入法的思路。
　　1）第一组测试出25个缺陷，有15个缺陷与第二组是相同的。假设将第1组25个看作是注入缺陷给第二组去测试，意味着注入的25个总缺陷数有15个被发现， 由此得到缺陷被测试出的概率为 15/25
　　2）第二组测试出30个缺陷；由于系统中的缺陷被测试出的概率相同的；
用公子公式来估算总缺陷数，15/25=30/X
（2）缺陷清除率
n D1：软件开发过程中发现的所有缺陷数；
n D2：软件发布后发现的缺陷数；
n D为发现的总缺陷数。因此，D=D1+D2。
整体缺陷清除率=D1/D；
缺陷源
已发生缺陷(Ｄ1)
交付后的缺陷(D2)
缺陷清除率(%)
需求报告
77
23
77
设计
106
19
85
编码
166
9
95
文档
48
12
80
错误修改
24
12
70
合计
500
75
85