文档介绍：1
第5章软件测试
软件测试的概念
软件测试技术
软件测试策略
测试的管理
软件调试
软件的可靠性和可用性
2
3、系统测试
有如下过程:
(1) 功能测试:
检查集成的系统在运行时是否满足需求中指定的功能。单元测试和集成测试的重点是构件及构件间的交互。这里的测试不必知道正在执行哪个构件,但必须知道系统是作什么的。与功能相关的活动集合称为线程( thread),因此这里的功能测试有时称为线程测试。
功能测试采用黑盒技术,测试用例从需求文档中产生。如,对一个文字处理系统的测试可以检查文档创建、文档修改、文档删除等功能。有时可分析需求的语义,用输入与输出之间或输入与转换之间的逻辑关系建立判定表来实现测试。
3
(2) 性能测试:
针对的是非功能性需求,即测试的类型由非功能性需求的定义来决定。
•强度测试(stress test)评价系统在短时间内到达其极限时的表现。
•容量测试(volume test) 检查系统对大量数据的处理。
•恢复测试(environmental test) 检查系统的容错(出错、故障、掉电等处理)能力,能否在指定时间内修正错误并重新启动系统。
•安全测试(security test) 测试系统的保护措施及数据与服务的完整性、保密性等。
还有许多方面的测试,如对用户的响应时间、执行某个功能的运行时间的计时测试,系统的可用性测试等。
以上是开发人员以需求规约为依据、采用黑盒技术,通过对系统及其目标的理解而进行的测试。开发人员的理解需要用户的认可,因此还要进行以下用户确认的测试。
4
(1)验收测试:
也称确认测试。指验收软件的有效性,使用户确信他们需要的就是这个系统。有时在实际环境中进行,有时在开发环境中进行。除了检查系统功能性能外,还要进行软件配置审查,包括文档的完整性、一致性、准确性的检查,是否具有维护阶段必需的细节。
(2)安装测试:在实际环境中进行的测试。测试系统的完备性及可能被现场条件影响的那些功能或非功能性特性。
还有2种系统测试策略:
(1)Alpha测试:软件交付用户后,用户在开发环境中由开发人员“指导”下进行的测试。
(2)Beta测试:用户在目标环境(实际使用环境)下进行的测试。
如微软的“Windows XP” Beta 2测试版由用户免费试用,半年后测试版作废。
5
4、测试的管理
(1)测试文档
为了控制测试的复杂性并提高测试效率,需建立测试文档:
•测试计划:目标,文档引用,系统输入/出及主要处理,主要测试,进度,所需材料等。
•测试说明:测试项标识,满足的需求,方法条件,测试用例,测试步骤等。
•问题报告和分析报告:记录每一个测试事件,给出测试结果的完整信息,分析实际测试结果和预期结果的差异及影响,并确定问题严重等级。
见下图:
6
7
(2)职责分配
单元测试可由开发人员自己测试。一个子系统开发小组同时可以作为其它子系统小组开发的构件的测试小组。
体系结构设计人员可以作为集成测试小组,同一个测试文档可以用于测试小组间的交流。
对于后期的测试(如功能测试和性能测试)或者是质量需求极高的软件应由另一个独立的控制质量小组负责。设计人员将模型、源代码和测试用例提供给该小组,由他们进行测试。他们将问题报告和分析报告发送给设计人员,以便对系统作必要的修改。修改后还应进行回归测试,确保没有引入新的错误。
8
(3)何时停止测试
“时间不够、资金不够的时候,就完成了测试。”
Musa提出了一个基于统计标准的答复:“在按照概率的方法定义的环境中,,就有95%的信心说我们已经进行了足够的测试。”
软件可靠性理论建立了一种基于执行时间的函数的软件故障(在测试过程中发现的错误)模型:
f(t)=(1/p)ln(l0pt+1) (参考教材1p349)
其中f(t)为软件在一定的测试时间t后可能会发生故障的预期累计数目,l0为测试开始时的初始故障密度(单位时间内的故障数),p为错误被发现和修正中的故障密度的呈递减的指数。
9
瞬时的故障密度l(t)可以使用f(t)的导数得出:
l(t)=l0/(l0pt+1)
使用上述公式,可预测测试进程中预期的故障密度,实
际的错误密度可以画在预测曲线上。如图所示:
如果在测试过程中
实际收集的数据与预测
曲线比较接近的话,就
可估算出为了达到低的
故障密度,整个测试过
程所需要的时间。
软件可靠性模型给
出了回答“测试什么时候
完成”这种问题的有意义
的指导。
10