软件测试概论考点提要按章节.docx
《软件测试概论考点提要按章节.docx》由会员分享，可在线阅读，更多相关《软件测试概论考点提要按章节.docx（55页珍藏版）》请在冰豆网上搜索。
软件测试概论考点提要按章节
测试基础
软件测试：
用人工或自动的手段运行或测试某个系统的过程。
目的是检验系统是否满足规定的需求，或弄清预期结果和实际结果之间的差别。
1、软件测试的目的：
证明（表达软件能够工作）→检测（发现错误）→预防（管
理质量）
2、测试执行：
单元测试（UT执行）：
一个测试用例的测试执行；
集成测试（IT执行）：
一个测试用例集的测试执行；
系统测试（ST执行）：
不同测试阶段的测试执行。
3、回归测试的目的：
a.验证错误是否修复；
b.检测对代码的修改是否引入了新的错误。
5、软件测试的主要工作：
a.检视代码，评审开发文档；
b.进行测试设计，写作测试文档（测试计划、测试方案、测试用例等）；
c.执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修正；
d.通过测试度量软件质量。
6、软件危机的出现主要表现在：
a.由于缺乏大型软件开发经验和软件开发数据积累，开发工作计划很难制定；
b.开发早期需求分析不够明确，造成开发后期矛盾集中暴露；
c.不遵循开发规范，开发文档不完整，软件难以维护；
d.缺乏严密有效的软件质量检测手段，交付给用户的软件质量差。
7、软件危机的后果：
a.软件质量不高，很难稳定；
b.软件项目延期，进度无法控制；
c.成本增加，无法控制预算。
8、软件危机的根源：
a.根据摩尔定律，硬件发展很快，相应对软件系统的期望
越来越高；
b.软件系统复杂性提高，需多人合作；
c.软件开发是人的智力活动，无法用已有的产业工程方法来组织管理。
9、软件生命周期的各个阶段：
计划→需求分析→设计→编码→测试→运行→评价
10、设计：
概要设计（HLD）：
在设计阶段把各项需求转换成相应的体系结构，每一部分是功能明确的模块；
详细设计（LLD）：
对每个模块要完成的工作进行具体的描述。
11、软件研发相关要素：
人员、过程、工具。
12、软件项目组人员组成：
分析人员、设计人员、开发人员、测试人员、配置管理人员、SQA（质量保证人员）；
13、软件研发流程类型：
瀑布模型、螺旋模型、RUP流程、IPD流程。
14、软件研发中几个重要的过程：
需求管理；配置管理；缺陷管理；同行评审。
15、常见的引入缺陷的原因：
a.开发过程缺乏有效的沟通，或者没有进行沟通；
b.软件复杂度越来越高；
c.编程中产生错误；
d.需求不断变更；
e.项目进度的压力；
f.不重视开发文档；
g.软件开发工具本身隐藏的问题。
等等……
软件质量
1、软件质量的定义：
一个实体的所有特性，基于这些特性可以满足明显的或隐含的需求。
而质量就是实体基于这些特性满足需求的程度。
2、软件质量的三个层次：
a.符合需求规格；b.符合用户显示需求；
c.符合用户实际需求。
3、影响软件质量的因素：
流程、技术、组织。
流程：
一组活动（活动是否都是必须的；活动角色之间的关系）
过程：
一组将输入转化为输出的相关联或相互作用的活动。
4、八项质量管理原则：
a.以顾客为中心；b.领导作用；c.全员参与；
d.过程方法；e.管理的系统方法；f.持续改进；
g.基于事实的决策方法；h.互利的供方关系。
5、八项质量管理原则的意义：
a.是质量管理的理论基础；
b．用高度概括易于理解的语言所表述的质量管理的最基本，最通用的一般性规律；
c.为组织建立质量管理体系提供了理论依据；
d.是组织的领导者有效的实施质量管理工作必须遵循的原则。
6、CMM1：
初始级，Inltial，不可预测并且缺乏控制；
CMM2：
可重复级：
Repeatable，可重复以前的主要经验；
（关键过程区域：
需求管理；软件项目计划；软件项目跟踪和监督；软件子合同管理；软件质量保证；软件配置管理。
）
CMM3：
已定义级：
Defined，过程被描述，并得到良好理解；
（关键过程区域：
组织过程定义；组织过程焦点；培训大纲；集成软件管理；软件产品工程；组际协调；同行评审。
）
CMM4：
已管理级：
Managed，过程被测量并受控；
（关键过程区域：
定量的过程管理；软件质量管理。
）
CMM5：
优化级，Optimizing，关注过程改进。
（关键过程区域：
缺陷预防；技术变更管理；过程变更管理。
）
7、CMM的用途：
a.评估组用来识别组织中的强处和弱处；
b.评价组用来识别选择不同的业务承包商的风险和监督合同；
c.管理者用来了解其组织的能力，并了解为了提高其能力成熟度而进行软件过程改进所需进行的活动；
d.技术人员和过程改进组用来作为指南，指导他们在组织中定义和改进软件过程。
8、ISO9001和CMM的关系：
相似点：
强调管理、过程、规范化和文档化；
不同点：
CMM把焦点对准软件；ISO9001的范围包括：
硬件、软件、流程性材料和服务；
两者关系：
CMM2级与ISO9001强相关；CMM的每个关键过程域至少按某种解释与ISO9001弱相关。
9、软件质量模型:
功能性：
当软件在指定条件下使用时，软件产品提供满足明确和隐含需求的功能的能力。
包括：
适合性；准确性；互操作性；保密安全性；功能性的依从性。
可靠性：
在指定条件下使用时，软件产品维持规定的性能级别的能力。
包括：
成熟性；容错性；易恢复性；可靠性的依从性。
易用性：
在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
包括：
易理解性；易学性；易操作性；吸引性；易用性的依从性。
效率：
在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。
包括：
时间特性；资源利用性；效率依从性。
维护性：
软件产品可被修改的能力。
修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应。
包括：
易分析性；易改变性；稳定性；易测试性；维护性的依从性。
可移植性：
软件产品从一种环境迁移到另外一种环境的能力。
包括：
适应性；易安装性；共存性；易替换性；可移植性的依从性。
10、软件质量活动：
软件质量保证（SQA）和测试；SQA从流程方面保证软件的质量、测试从技术方面保证软件的质量、只进行SQA或者只进行测试活动不一定能产生好的软件质量。
11、SQA的主要工作范围：
·指导并监督项目按照过程实施；
·对项目进行度量、分析，增加项目的可视性；
·审核工作产品，评价工作产品和过程质量目标的复合度；
·进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参考，促进过程改进。
12、度量：
对事物属性的量化表示；
软件度量：
是指计算机软件中范围广泛的测度，包括对软件系统、构建或生命周期过程具有的某个给定属性的度的一个定量测量。
目的：
·提高软件生产率，缩短产品研发周期，降低研发成本、维护成本；
·提高软件产品质量，提高用户满意度；
·为组织持续改进提供量化的指标和反馈。
13、软件度量的作用：
理解；预测；评估；改进。
分类：
规模；工作量；进度；质量
如何将度量的知识应用于实际工作中：
建立测试工作的度量数据，目的是作为预测和改进的基础（a.熟悉需求：
进度、工作量、规模；b.设计用例：
工作效率、覆盖率；c.执行用例：
工作效率、缺陷密度；）
测试方法
1、什么是白盒测试：
·白盒测试是依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况；
·白盒测试是基于程序结构的逻辑驱动测试；
·白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试。
2、为什么进行白盒测试：
·一般在测试前期进行，通过达到一定的逻辑覆盖率指标，使得软件内部逻辑控制结构上的问难题能基本得到消除；
·能保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证；
·发现问题后解决问题的成本较低。
3、白盒测试的常用技术：
·静态分析：
控制流分析、数据流分析、信息流分析等；
·动态分析：
逻辑覆盖测试（分支测试、路径测试等）、程序插装等。
4、控制流相关概念：
程序元素、控制流关系、控制流图、控制流矩阵。
（步骤：
5）
5、控制流分析能发现的问题：
转向并不存在的标号；没有用的语句标号；从程序
入口进入后无法达到的语句；不能达到停机语句的
语句。
6、数据流相关概念：
数据的定义；数据的引用。
（步骤：
3）
7、数据流分析的左右：
分析代码中关于数据定义和引用方面的错误；进行代码优
化。
（赋值语句运算效率高）
8、信息流分析：
输入变量和语句关系；语句和输出变量关系；输入和输出变量管
理。
（步骤：
4）
9、覆盖率工具的作用：
·分析被测试代码控制结构，决定插装位置（分支的入口和出口）；·实施插装；·将插装代码重新编译；·执行被测对象，根据插装的监控哨信息统计覆盖率。
10、白盒测试的特点：
·测试人员需要了解软件的实现；·可以检测代码中的每条分支和路
径；·解释隐藏在代码中的错误；·对代码的测试比较彻底；·实现代
码结构上的优化；·白盒测试投入较大，成本高；·白盒测试不验证规
格的正确性。
11、什么是黑盒测试：
·黑盒测试把被测对象看成一个黑盒，只考虑其整体特性，不考虑其内部具体实现；
·黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块、一个函数等。
·黑盒测试又可以被称为基于规格的测试。
12、常见的黑盒测试类型：
功能性测试；容量测试；负载测试；恢复性测试。
13、系统测试的时候，如果没有SRS时，有两类BUG无法发现：
需求遗漏；
需求偏差。
14、黑盒测试的优点：
·对于更大的代码单元来说（子系统甚至系统级）比白
盒测试效率要高；·测试人员不需要了解实现的细节，
包括特定的编程语言；·从用户的视角进行测试，很容
易被大家理解和接受；·有助于暴露任何规格不一致或
有歧义的问题。
15、黑盒测试的缺点：
·没有清晰的和简明的规格，测试用例是很难设计
的；·不能控制内部执行路径，会有很多内部程序路径
没有被测试到；不能直接针对特定的程序段，这些程序
可能非常复杂（因此可能隐藏更多的问题）。
16、动态和静态测试的分类依据在于：
被测对象是否运行起来。
17、手工静态分析——同行评审：
正规检视；技术评审；走查。
评审对象：
计
划、需求文档、设计图、代码等。
18、自动化静态分析：
静态验证；语法分析器；符号执行器。
Ø自动化测试的限制（板书）：
·自动化测试不具备想象力，不能够检查脚本中给定的观察点之外的错误；
·自动化测试只能提高测试效率，不能提高测试效果，不能发现比人工测试更多的问题；如被测对象不稳定，存在变动性的话不适合开展自动化测试，否则脚本的编写和维护所耗费的时间可能远大于人工测试；
·只有手工测试积累到一定程度（提供更多的观察点），才能做好自动化测
试。
V&V模型（测试过程）
1、验证与确认V&V：
验证（VERIFICATION）强调过程；确认（VALIDATION）强调
结果。
2、V&V告诉我们：
·尽早测试（尽早准备、尽早执行）；
·全面测试（文档、代码）
·全过程测试（测试参与到开发过程中、对测试过程全称跟踪）
·测试是独立的、迭代的。
3、单元、集成、系统测试的比较：
测试方法不同；考察范围不同；评估基准不同。
4、回归测试策略：
完全重复测试；选择性重复测试（覆盖修改法；周边影响法；指标达成方法；选择重要级别高的测试用例）
5、其他测试阶段：
验收测试；a（ALPHA）测试；B（BETA）测试。
6、主要的测试文档：
测试计划；测试方案；测试用例；测试规程；测试报告；测试日报。
单元测试
1、单元测试的目的：
在于发现各模块内部可能存在的各种错误主要是基于白盒测试。
·验证代码是与设计相符合的；·发现设计和需求中存在的错误；
·发现在编码过程中引入的错误。
（和设计不相符/和设计相符，但是由于
编码疏漏引起）
2、孤立的测试策略：
·方法：
不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和
驱动模块。
每个模块进行独立的单元测试。
·优点：
该方法是最简单，最容易操作的。
可以达到高的结构覆盖率。
该方法是纯粹的单元测试。
·缺点：
桩函数和驱动函数工作量很大，效率低。
3、自顶向下的单元测试策略：
·方法：
先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块。
其
次对第二层进行测试，使用上面已测试的单元做驱动模块。
如此类
推直到测试完所有模块。
·优点：
可以节省驱动函数的开发工作量，测试效率较高。
·缺点：
随着被测单元一个一个被加入，测试过程将变得越来越复杂，并且
开发和维护的成本将增加。
4、自底向上的单元测试策略：
·方法：
先对模块调用层次图上最低层的模块进行单元测试，模拟调用该模
块的模块做驱动模块。
然后再对上面一层做单元测试，用下面已被
测试过的模块做桩模块。
以此类推，直到测试完所有模块。
·优点：
可以节省桩函数的开发工作量，测试效率较高。
·缺点：
不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产
生很大的影响。
5、单元测试的四个阶段：
·测试计划：
完成单元测试计划；
·测试设计：
完成单元测试方案；
·测试实现：
完成单元测试用例、单元测试规程、单元测试脚本及数据文件；
·测试执行：
执行单元测试用例，修改发现的问题并进行回归测试，提交单元测试报告。
✧单元测试：
桩&驱动举例：
无论是单元测试还是集成测试都涉及到以下三个函数：
主控函数：
intctrl（intx,inty）
加法函数：
intadd（intx,inty）
减法函数：
intsub（intx,inty）
注意：
进行单元测试时，设计用例时依据的是LLD；进行集成测试时，设计测试用例依据的是HLD。
下面给出来的是需要测试的实际的代码。
intctrl（intx,inty）
{
inttemp=0;
if（x>=y）
temp=add（x,y）;
else
temp=sub（x,y）;
returntemp;
}
intadd（intx,inty）
{
return（x+y）;
}
intsub（intx,inty）
{
return（x-y）;
}
✧自顶向下单元测试策略
不同测试步骤中的驱动可以写到一起，也可以分开写，这里是写到一起了。
✓测试ctrl函数
需要写一个驱动和两个桩。
Ø驱动函数
voiddriver（）
{
intret=0;
ret=ctrl（2,1）;//x>y
if（ret==3）
printf（“testcaseJISUAN_UT_CTRL_001pass”）;
else
printf（“testcaseJISUAN_UT_CTRL_001fail”）;
ret=ctrl（1,1）;//x=y
if（ret==2）
printf（“testcaseJISUAN_UT_CTRL_002pass”）;
else
printf（“testcaseJISUAN_UT_CTRL_002fail”）;
ret=ctrl（1,2）;//xif（ret==-1）
printf（“testcaseJISUAN_UT_CTRL_003pass”）;
else
printf（“testcaseJISUAN_UT_CTRL_003fail”）;
}
Ø桩函数
intstub_add（intx,inty）
{
if（x==2&&y==1）
return3;
if（x==1&&y==1）
return2;
return999999;
}
intstub_sub（intx,inty）
{
if（x==1&&y==2）
return-1;
return999999;
}
Ø修改代码
为了让桩能体现在测试过程中，需要修改ctrl函数：
intctrl（intx,inty）
{
inttemp=0;
if（x>=y）
temp=stub_add（x,y）;
else
temp=stub_sub（x,y）;
returntemp;
}
✓测试add函数
Ø驱动函数
同测试ctrl函数时的驱动
Ø桩函数
同测试ctrl函数时sub函数对应的桩
Ø修改代码
intctrl（intx,inty）
{inttemp=0;
if（x>=y）
{
temp=add（x,y）;
if（x==2&&y==1&&temp==3）
printf（“testcaseJISUAN_UT_ADD_001pass”）;
else
printf（“testcaseJISUAN_UT_ADD_001fail”）;
if（x==1&&y==1&&temp==2）
printf（“testcaseJISUAN_UT_ADD_002pass”）;
else
printf（“testcaseJISUAN_UT_ADD_002fail”）;
}
else
temp=stub_sub（x,y）;
returntemp;
}
✓测试sub函数
Ø驱动函数
同测试ctrl函数时的驱动
Ø桩函数
无
Ø修改代码
intctrl（intx,inty）
{
inttemp=0;
if（x>=y）
temp=add（x,y）;
else
{temp=sub（x,y）;
if（x==1&&y==2&&temp==-1）
printf（“testcaseJISUAN_UT_SUB_001pass”）;
else
printf（“testcaseJISUAN_UT_SUB_001fail”）;
}
returntemp;}
测试覆盖率
1、覆盖率概念：
·覆盖率是用来度量测试完整性的一个手段。
覆盖率是测试技术有效性的一个度量。
覆盖率=（至少被执行一次的item数）/item的总数；
·覆盖率大体可以划分为两大类：
逻辑覆盖和功能覆盖；
·测试用例设计不能一味追求覆盖率，因为测试成本虽覆盖率的增加而增加。
2、逻辑覆盖主要类型：
语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、路径
覆盖。
3、语句覆盖率：
（StatementCoverage），在测试时运行被测程序后，程序中被执
行到的可执行语句的比率；语句覆盖率=
（至少被执行一次的语句数量）/（可执行的语句总数）
4、分支覆盖率：
（BranchCoverage）也叫判定覆盖（DecisionCoverage），它的含
义是：
在测试时运行被测程序后，程序中所有判断语句的取真分
支和取假分支被执行到的比率；
判定覆盖率=（判定结果被评价的次数）/（判定结果的总数）
5、条件覆盖率：
（ConditionCoverage）的含义是，在测试时运行被测程序后，所
有判断语句中每个条件的可能取值（真值和假值）出现过的比率；
条件覆盖率=（条件操作数值至少被评价一次的数量）/（条件操作数值的总数）
6、分支-条件覆盖率：
（BranchConditionCoverage）也叫判定条件覆盖（Decision
ConditionCoverage），它的含义是，在测试时运行被测程序
后，所有判断语句中每个条件的所有可能值（为真为假）
和每个判断本身的判定结果（为真为假）出现的比率；
分支条件覆盖率=（条件操作树枝或判定结果至少被评价一
次的数量）/（条件操作数值总数+判定结果总数）
7、路径覆盖率：
（PathCoverage）的含义是，在测试时运行被测程序后，程序中
所有可能的路径被执行过的比率；
路径覆盖率=（至少被执行到一次的路径数）/（总的路径数）
8、其他覆盖率：
功能覆盖率；面向对象的覆盖率；函数覆盖；指令块覆盖；判定
路径覆盖。
测试用例举例
测试用例编号
BOSS_ST_MARKETING_NEW_01P
重要级别
高（还有“较高、中、较低、低”几个等级）
测试项目
新增营销记录
测试标题
新增10元的营销记录
用例类型
基本事件（对应还有“备选事件”、“异常事件”）
用例设计者
songfun
设计日期
2005-04-25
对应需求编号
REQ_MARKETING_NEW_01
对应UI
Marketing.htm
对应UC
UC_MARKETING_NEW_01
版本号
Buildv0.1
对应开发人员
Frank
预置条件
操作员登录营销管理系统
测试方法
等价类划分（对应还有“错误猜测法”、“边界值分析”等）
输入
用户名：
51testing性别：
男金额：
10元描述：
aaaaaaa
操作步骤
1.进入【营销下发】页面；
2.点击『增加』按钮；
3.输入相应数据；
4.点击『确定』按钮；
5.在后台数据库（test/test@testDB）输入查询语句验证：
select*fromMarketingTabwhereID='1001'
预期输出
1.执行步骤④后，页面弹出添加成功提示信息框；
2.执行步骤⑤后查询数据库，记录确实添加成功且数据无误
同行评审
1、同行评审：
（PeerReview）是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。
需要进行同行评审的特定产品在定义项目软件过程的时候被确定并且作为软件开发计划的一部分被安排了进度。
·需要前期准备、计划和时间进度表
·越早越好
3、同行评审的作用：
·早期发现缺陷；·去除缺陷；·降低成本；·提高质量。
4、同行评审的类型：
·正规检视：
（Inspection）最严格，要求有规范的流程，参
加者经过正式培训；
·技术评审：
（TechniqueReview）以技术方案的比较、裁决
为目的，严格程度介于正规检视和走读之间；
·走读：
（WalkThrough）最（自由）松散的形式，无流程要求，有评审团队，评审流程无要求。
5、通用评审流程步骤（正规检视流程）：
6、计划阶段：
·项目负责人指定组织者；·作者自检工作产品；·组织者规划本次评审；
·检查入口准则：
是否符合文档标准？
是否已用工具检查？
代码<=500行；
文档<=40页；……
·准备评审包：
工作产品（HLD）；参考资料（SRS-检查一致性）；评审表（ReviewForm）；查检表（Checklist）。
·指定评审专家（3-6人）；
·组织者将评审包、评审通知单发给相关人员。
7、介绍会议：
·被评审对象采用新技
升级会员 