09软件可靠性测试

合集下载

系统分析与设计考试试卷09(OK版)abc

《系统分析与设计》复习提纲.一. 判断题(每题1分，共15分).1,（√）文档是软件产品的一部分，没有文档的软件就不称其为软件。

.2,（×）企业管理的组织职能是为各级组织确定目标和拟定为达到此目标的行动方案,并制定各种计划。

.3,（×）需求规格说明书在软件开发中具有重要的作用，它也可以作为软件可行性分析的依据。

.4,（√）数据处理一般不涉及复杂的数学计算。

.5,（√）文件与数据库在数据组织中并非属于同一层次。

.6,（×）计划工作的首要任务是用计算机进行反复计算。

.7,（√）计划指标指的是在计划中规定的、用数字表示的企业生产技术经济活动的各方面的预期目标。

.8,（×）系统设计阶段的任务是按照系统分析阶段提出的逻辑模型的要求进行具体的逻辑设计。

.9,（√）为了达到系统灵活性的目的，在系统设计中应尽量采用模块化结构。

.10,（×）功能模块是程序的一个组成部分，所以它总是比程序小。

.11,（×）操作员在键盘上按单据输入数据,如发现单据上数据有错应立即改正后输入。

.12,（√）系统设计阶段的信息系统处理流程图是信息系统流程图的进一步具体化。

.13,（×）程序调试时应当用正常数据进行调试，不应用错误数据去调试。

.14,（×）一个成功的项目唯一提交的就是运行程序。

.15,（×）在软件开发的过程中，若能推迟暴露其中的错误，则为修复和改正错误所花费的代价就会降低。

.二单项选择题(每题1分, 共10分).1,数据（ B ）. A.就是信息B.经过解释成为信息 C..必须经过加工才成为信息 D.不经过加工也可以称作信息.2,通常高层管理提出的决策问题与基层管理提出的决策问题相比,在结构化程度上（B ）A. 高层管理的决策问题的结构化程度高于基层的. B. 高层管理的决策问题的结构化程度低于基层的. C. 两者在结构化程度上没有太大差别 D. 以上A，B，C.三种情况都可能出现。

HB6468-1990软件需求分析阶段基本要求

HB 6468-1990 软件需求分析阶段基本要求中华人民共和国航空航天工业部航空工业标准软件需求分析阶段基本要求 HB 6468-90内容与适用范围本标准规定了软件开发过程中需求分析阶段统一的基本要求。

本标准适用于大、中型软件开发的需求分析阶段。

2 引用标准GBjT11457 软件工程术语HB 6464 软件开发规范HB 6465 软件文档编制规范HB 6469 软件需求规格说明编制规定HB 6467 软件配置管理计划编制规定HB 6466 软件质量保证计划编制规定3 术语除下面给出的术语外，其他术语的定义见 GB!Tl1457 o3. 1 软件可靠性悟。

feware reliabilit川软件的吁靠性是指在规定的运行环境中、在规定的睡行时间内或规走的运行次数 f ，程序运行各种不同测试用例的成功概率。

3. 2 皇程碑(mil刷刷的设计人员或管理人员负责的 4个在时间 t预定的事件.用来测量王作进度，例如，正式的复审、规格说明的颁布、产品的交付e4 软件需求分析阶段的工作需求分析阶段工作是软件开发的墓础，需求分析阶段的工作成果应作为软件设计、测试、评宙和验收的依据。

在软件需求分析阶段，任务承办单位(简称承办单位)必须根据任务委托单位(简称委托单位)提出的技术要求和系统规恪说明、主要项目或关键项目规恪说明，对所展担ff发的供件，进行需求分析和定义。

承办单位在软件需求分析阶段必须进行下述工作。

4. 1 分析软件需求航空航天工业部 1990-09-18 发布1261991-02-01 实施HB 6468-904. ,. , 信息搜集4.'.'.' 承办单位必须搜集下列有关信息来确定软件需求za 系统总体设计要求，b 系统性能要求，C. 设备要求，d 接口设计要求，e 操作使用要求，f. 系统设计标准 s8 系统备份和维护要求。

4.'.'.2 在所搜集到的信息资料中，承办单位必须标明所有用于确定软件需求的文挡。

软件可靠性和安全性设计指南

GB/Txxx 软件工程术语GB/Txxxxxx 计算机软件质量保证计划规范GB/T xxxxx 计算机软件配置管理计划规范GB/T xxxxx 信息处理一一程序构造及其表示的约定GJBxxxx系统安全性通用大纲GJBxxxxx 系统电磁兼容性要求GBxxxx电能质量标准大纲GBxxxxx 电能质量标准术语3定义［此处加入定义］3 .1失效容限［此处加入失效容限］3 .2扇入［此处加入扇入］3 .3扇岀［此处加入扇岀］3 .4安全关键信息［此处加入安全关键信息］3 .5安全关键功能［此处加入安全关键功能］3 .6软件安全性［此处加入软件安全性］4设计准则和要求4 .1对计算机应用系统设计的有关要求4 .1.1 硬件软件功能的分配原则［此处加入硬件软件功能的分配原则］4 .1.2 硬件软件可靠性指标的分配原则［此处加入硬件软件可靠性指标的分配原则］4 .1.3 容错设计［此处加入容错设计］4 .1.4 安全关键功能的人工确认［此处加入安全关键功能的人工确认］4 .1.5 设计安全性内核［此处加入设计安全性内核］4 .1.6 记录系统故障［此处加入记录系统故障］4 .1.7 禁止回避检测岀的不安全状态［此处加入禁止回避检测岀的不安全状态］4 .1.8 安全性关键软件的标识原则［此处加入安全性关键软件的标识原则］4 .1.9 分离安全关键功能［此处加入分离安全关键功能］4 .2 对硬件设计的有关要求［此处加入对硬件设计的有关要求］4 .3软件需求分析4 .3.1 一般要求［此处加入一般要求］4 .3.2 功能需求［此处加入功能需求］4.3.2.1输入［此处加入输入］4.3.2.2处理［此处加入处理］432.3 输出［此处加入输岀］4.3.2.4 特殊要求［此处加入特殊要求］4 .3.3 性能需求［此处加入性能需求］4.3.3.1精度［此处加入精度］4.3.3.2容量［此处加入容量］4.3.3.3时间特性［此处加入时间特性］4.3.3.4灵活性［此处加入灵活性］4 .3.4 接口需求［此处加入接口需求］4.3.4.1与外部设备的接口［此处加入与外部设备的接口］4.3.4.2与其它系统的接口［此处加入与其它系统的接口］4.3.4.3人机接口［此处加入人机接口］4 .3.5 数据需求［此处加入数据需求］4 .3.6 环境需求［此处加入环境需求］4.3.6.1硬件［此处加入硬件］4.3.6.2软件［此处加入软件］4 .3.7 软件可靠性和安全性需求［此处加入软件可靠性和安全性需求］4 .3.8 其它需求［此处加入其它需求］4 .3.9 采样的确定原则［此处加入采样的确定原则］4 .4 软件设计4 .4.1 一般要求［此处加入一般要求］4 .4.2 功能设计与分配［此处加入功能设计与分配］4 43 控制流与数据流［此处加入控制流与数据流］4 .4.4 资源分配及余量［此处加入资源分配及余量］4 .4.5 设计限制［此处加入设计限制］4 .4.6 安全关键功能的设计［此处加入安全关键功能的设计］4 .4.7 冗余设计4.4.7.1恢复块［此处加入恢复块］4.4.7.2信息冗余［此处加入信息冗余］4 .4.8 接口设计4.4.8.1一般要求［此处加入一般要求］4.4.8.2人机界面设计［此处加入人机界面设计］4.4.8.3报警设计［此处加入报警设计］4.4.8.4软件接口设计［此处加入软件接口设计］4 .4.9 软件健壮性设计4.4.9.1电源失效处理4.4.9.2系统不稳定的处理［此处加入系统不稳定的处理］4.4.9.3接口故障处理［此处加入接口故障处理］4.4.9.4错误操作处理［此处加入错误操作处理］4 .4.10 简化设计4.4.10.1模块的单入口和单岀口［此处加入模块的单入口和单岀口］4.4.10.2模块的独立性［此处加入模块的独立性］4.4.10.3模块的扇入扇岀［此处加入模块的扇入扇岀］4.4.10.4模块的耦合方式［此处加入模块的耦合方式］4.4.10.5模块的内聚方式［此处加入模块的内聚方式］4 .4.11 数据设计4.4.11.1属性控制［此处加入属性控制］4.4.11.2数值运算范围控制［此处加入数值运算范围控制］4.4.11.3精度控制［此处加入精度控制］4.4.11.4合理性检查［此处加入合理性检查］4.4.11.5特殊问题［此处加入特殊问题］4 .5软件实现4 .5.1 语言要求［此处加入语言要求］4 .5.2 McCabe 指数McCabe指数为8。

《软件测试实战指南：功能和性能测试的技术和工具》

软件测试实战指南：功能和性能测试的技术和工具在当今数字化的世界中，软件已经成为各行各业的核心。

从日常生活中使用的手机应用程序到银行的在线系统，软件在我们的生活中无处不在。

然而，软件的质量和可靠性却经常使人担忧。

一个有缺陷的软件可能导致数据丢失、隐私泄露或者系统崩溃，给用户带来麻烦。

因此，软件测试成为了保证软件质量的关键步骤。

软件测试是通过检查软件是否满足预期需求和行为来评估软件质量的过程。

在软件测试中，主要有两个方面需要关注：功能测试和性能测试。

功能测试主要关注软件的功能是否按照设计要求正常运行；性能测试则关注软件在不同负载下的性能表现。

本文将为您介绍《软件测试实战指南：功能和性能测试的技术和工具》，以帮助您更好地理解这两个方面的测试工作。

什么是功能测试？功能测试是测试一个软件系统的各个功能是否按照预期进行运行的过程。

它主要关注软件系统是否满足需求和规范，并且能够在各种场景下正常运行。

功能测试可以分为手动测试和自动化测试两种类型。

手动测试手动测试是指通过人工操作来检查软件的各个功能是否正常运行的过程。

在手动测试中，测试人员将模拟用户的操作流程，测试软件是否按照预期工作。

手动测试通常需要测试人员具备较强的软件理解和系统操作能力，以及对用户行为的理解和把握。

手动测试的优势在于可以模拟真实用户的操作行为，捕捉到真实的问题和反馈。

然而，手动测试也存在一些问题，如测试过程较慢、易产生人为错误等。

自动化测试自动化测试是指使用专门的测试工具或脚本来执行测试过程的方式。

通过编写自动化测试脚本，测试人员可以自动执行大量的测试用例，提高测试效率。

自动化测试通常适用于一些重复性高、可预测的测试任务，如回归测试。

自动化测试的优势在于提高了测试的效率和准确性，同时可以在后续版本中重复使用。

然而，自动化测试也需要额外的资源和工具支持，并且在一些特定情况下可能不如手动测试效果好。

什么是性能测试？性能测试是测试软件在不同负载和压力下的性能表现的过程。

软件可靠性模型与评估方法

软件可靠性模型与评估方法软件可靠性是指在特定环境中，系统在规定时间内以满足用户需求的准确性、稳定性和可用性的概率。

在软件开发过程中，确保软件的可靠性是至关重要的。

本文将介绍软件可靠性模型与评估方法，以帮助开发人员提高软件的可靠性。

一、可靠性定义与重要性软件可靠性是指在特定条件下，软件系统在规定时间内以满足用户需求的准确性、稳定性和可用性的概率。

软件可靠性评估的主要目的是为了确定软件在特定条件下的可靠性水平，以评估软件系统的可信度和稳定性。

软件可靠性的提高将直接影响到用户对软件系统的满意度和信任度。

二、软件可靠性模型1. 静态模型静态模型是通过对软件设计和代码进行分析，检测潜在的软件错误，以预测软件系统的可靠性。

静态模型主要包括代码静态分析、软件结构分析和软件测试。

1.1 代码静态分析代码静态分析通过对源代码的分析，发现代码中的潜在错误和缺陷。

常用的代码静态分析工具包括Lint、FindBugs等，可以帮助开发人员提前发现代码中的潜在问题，从而减少软件系统的错误率。

1.2 软件结构分析软件结构分析主要是通过对软件系统的结构进行分析，检测系统的层次结构、调用关系、模块依赖等，以评估软件系统的可靠性。

软件结构分析常用的方法有层次分析法、结构方程模型等。

1.3 软件测试软件测试是通过执行一系列测试用例，检查软件系统的功能是否正常，以及是否存在潜在的错误和缺陷。

软件测试主要包括单元测试、集成测试、系统测试和验收测试等。

通过全面的软件测试，可以提高软件系统的可靠性和稳定性。

2. 动态模型动态模型是通过对软件系统运行状态进行监测和分析，以评估软件系统的可靠性。

常用的动态模型包括故障树分析、可靠性块图和Markov模型等。

2.1 故障树分析故障树分析通过将软件故障转化为逻辑关系，来描述故障的发生和传播过程。

故障树分析可以帮助开发人员识别和定位软件系统中的关键故障点，从而制定相应的改进和优化方案。

2.2 可靠性块图可靠性块图是通过将系统的可靠性表示为块和连接线的图形化表示方法，来描述系统的可靠性。

软件测试中的测试规范与标准

软件测试中的测试规范与标准在软件开发过程中，软件测试是非常重要的一个环节。

通过测试可以发现软件中的错误和缺陷，并对其进行修复和改进，以提高软件的质量和稳定性。

为了确保测试工作的有效性和规范性，各个组织和企业都制定了一系列的测试规范与标准。

本文将介绍软件测试中常用的测试规范与标准，以及它们的作用和实施方式。

一、测试计划与策略测试计划与策略是软件测试工作的基础，它们定义了测试的范围、目标、方法和资源等方面的内容。

测试计划和策略的编制需要考虑软件的特点、需求和风险等因素，以制定出合理和可行的测试方案。

1. 测试目标测试目标应明确指定测试的目的和期望达到的结果。

常见的测试目标有：发现软件中的错误和缺陷、验证软件的功能和性能、评估软件的可靠性和健壮性等。

2. 测试范围测试范围确定了测试的覆盖范围，包括测试的功能、模块和接口等。

测试范围需要根据软件的需求和关键功能来确定，以确保测试工作的有效性和效率。

3. 测试方法与策略测试方法与策略定义了测试的方法和策略，包括测试的技术、工具和流程等。

测试方法与策略的选择需要考虑软件的特点和需求，以提高测试的效果和效率。

二、测试用例设计与执行测试用例是测试工作的核心，它们描述了测试的输入、预期输出和执行步骤等内容。

测试用例设计与执行需要遵循一定的规范和标准，以确保测试工作的准确性和一致性。

1. 测试用例规范测试用例规范定义了测试用例的格式、结构和规范等。

测试用例规范需要包括用例编号、测试项、测试步骤、预期结果和执行状态等信息，以便于测试人员进行测试工作的管理和跟踪。

2. 测试用例设计方法测试用例设计方法包括黑盒测试、白盒测试和灰盒测试等。

不同的测试设计方法适用于不同的测试任务和目标，测试人员需要根据实际情况选择合适的设计方法。

3. 测试用例执行与管理测试用例执行与管理是测试工作的重要环节，它涉及到测试计划的执行、测试结果的记录和缺陷的管理等方面。

测试用例的执行需要按照测试计划和策略进行，并及时记录测试结果和缺陷信息，以便于后续的追踪和处理。

①软件测试判断题选择题30分

①软件测试判断题选择题30分1.软件调试的目的是？ AA. 找出错误所在并改正之B. 排除存在错误的可能性C. 对错误性质进行分类D. 统计出错的次数2.下列叙述中,哪一项是正确的？ D用黑盒法测试时，测试用例是根据程序内部逻辑设计的;测试是为了验证该软件已正确地实现了用户的要求;对面向对象程序来说,单元测试的最小单元是每条程序语句,即以分号结尾的程序;发现错误多的程序模块，残留在模块中的错误也多。

创建一个基于JUNIT的单元测试类，该类必须扩展? CA．T estSuite B. Assert C. TestCase D. JFCTestCase3.以下对单元测试，不正确的说法是? CA．单元测试的主要目的是针对编码过程中可能存在的各种错误；B．单元测试一般是由程序开发人员完成的C．单元测试是一种不需要关注程序结构的测试；D．单元测试属于白盒测试的一种。

4.测试驱动开发的含义是? BA．先写程序后写测试的开发方法B. 先写测试后写程序，即“测试先行”C. 用单元测试的方法写测试D. 不需要测试的开发5.用JUNIT断言一个方法输出的是指定字符串，应当用的断言方法是? C A．assertNotNull( ) B. assertSame()C. assertEquals()D. assertNotEquals()6.TestCase是junit.framework中的一个? CA．方法 B. 接口 C. 类 D. 抽象类7.TestSuite是JUNIT中用来? AA．集成多个测试用例 B. 做系统测试用的 C. 做自动化测试用的 D. 方法断言8.对于测试程序的一些命名规则，以下说法正确的一项是? C A．测试类的命名只要符合Java类的命名规则就可以了；B．测试类的命名一般要求以Test打头，后接类名称，如：TestPerson；C．测试类的命名一般要求以Test结尾，前接类名称，如：PersonTest；D．测试类中的方法都是以testXxx（）形式出现。

基于软件测试的软件可靠性评价技术研究

ｓｆｗａｅｉｒｄｏ．ｉｔｏａｅｈｅｄｏｓｉｔｇｓｆｒｅｉｂｌｙｉｈｉｆｒｎｏｔｒｓｗｏｋｅｕｔＴｈｓｍｅｈｄｃｎｍｅｔｔｅｎｅｆｅｔｍａｉｏｗａｅｒｌａｉｉｎｔｅｄｆｅｅｔｎｔｔ
２期
何雪慧：基于软件测试的软件可靠性评价技术研究
・６ｌ・
如果能够将软件测试的结果应用于软件可靠性
随机过程模型与非随机过程模型相比，随机非
评价，不仅能够度量软件测试是否充分，还能够利用
过程模型的软件失效具有重复性，复性是指同一重
ｏｏｔｒｓｉｇｎＳｆｗａｅＴｅｔｎ
ＨＥＸｕｅ—ｈｉｕ
（ｈｎｉｏｅｓｌＡａｅｙＬｏａｇ４１０，ｈｎ）ＣｉａＡｒｒｓｅｃｄｍ，ｕＹｎ７０９ＣｉａｂｎＭｉｉ
ＡｂｔａｔＴｈｅｔｃｎｑｎｅｈｄｈｗｏｕｅｔｅｒｓｌｏｏｔａｅｔｓｉｇｔｓｉｔｏｔｒｓｒｃ：ｅｈｉｕｅａｄｍｔｏｏｔｓｈｅｕｔｆｓｆｒｅｔｏｅｔｍａｅｓｆｗｎｗａｅ
ｓａｅｏｏｔｒｅｅｏｎｇｅｆｃｉｅｙｔｇｆｓｆｗａｅｄｖｌｐｉｆｅｔｖｌ．
Ｋｅｙｗｏｒｓ：ｏｔｒｅｔｎＳｆｒｅｉｂｌｙｅｔｔＲｅｉｂｉｔｄｌｄＳｆｗａｅｔｓｉｇ；ｏｔｅｒｌａｉｉｓｉｅ；ｌａｌｙｍｏｅｗａｔｍａｉ

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

P15
软件操作剖面生成过程
确定操作模式
确定操作的发起者
选择表格或图形表示法创建操作列表确定出现率确定出现概率
P16
步骤1——确定操作模式
操作模式
系统使用的不同模式
需要单独测试的环境条件的集合可能产生不同操作模式的因素
一周的某天或一天的某段时间（主要时间与次要时间）
一年的某段时间（金融系统的年末财政结算）业务量水平不同的用户类型（可能会以相同的方式使用系统的用户集合）用户的经验（专家和新手对系统的使用是不同的）
常规的软件测试结果不能直接用来评估软件的可靠性。软件操作剖面用来表示软件使用的统计规律，帮助分配开发和测试资源，提高开发和测试的效率。
操作剖面的构造包括确定操作模式、确定操作的发起者、选择表格或图形表示法、创建操作表、确定操作的出现率以及确定操作的发生概率。软件可靠性测试数据是按照软件操作剖面随机生成的。输入变量是任何存在于系统外部、同时影响此系统的数据元素。
P11
满足可靠性要求
功能/性能测试：需求覆盖100% 结构测试：语句覆盖100%、分支覆盖100%或满足其它结构覆盖要求
软件可靠性测试比传统测试更快接近目标值
失效率 / 失效率目标值
P12
百万次呼叫Mcalls
2、构造软件操作剖面
• • 软件操作剖面概念软件操作剖面生成过程：
P23
步骤4——创建操作列表
• 操作列表创建方法为每个操作发起者创建一张操作列表，然后再合并
•
参考依据
主要参考系统需求也可参考用户手册、系统原型以及以前的系统版本等
•
不同表示法的操作列表创建表格表示法：直接列出操作图形表示法：标出属性和属性值的方式间接列出操作
P24
创建操作列表示例——BBS系统
系统的成熟度（数据库总数据量）
P17
精简的系统能力（对所有操作，或只对特定操作）
操作模式示例——BBS系统
根据不同的用户类型可以确定四个操作模式：站务——负责整个BBS站点的管理工作，如开设版面、审核用户等。
版务——负责一个或多个版面的管理工作，如文章加精、置底、制作
合集等。用户——BBS注册用户，可执行发贴、投票、竞选版务/站务
P32
确定输入变量
• 分类方式： – 时间的相关性（相关、无关）时间相关性取值确定性取值范围数据特征
分类方式
– 取值的确定性（确定、不确定）相关无关确定不确定离散
连续
输入变量类型
时间相关确定离散型
√ √ √ – 取值范围数据特征（离散、连续）
√ √ √ 时间相关确定连续型 – 数据类型（整数型、实数型、字符型、逻辑型） √ √ √ √ √ √
•
P35
3.2数据生成过程
• • 如果根据操作剖面随机选取操作？步骤1——概率处理
•
• •
步骤2——操作选取
步骤3——变量取值步骤4——变量组合
P36
步骤1——概率处理
P37
步骤2——操作选取
P38
步骤3——变量取值
• 确定操作Oj中每个输入变量的具体取值
输入变量类型
时间相关确定离散型时间相关确定连续型由V(t)确定由V(t) 确定
表现形式
• 失效强度：单位时间内出现的失效数 • 累计失效数：某一时刻为止总共出现的失效数
P44
完全失效数据
P45
不完全失效数据（失效计数数据）
P46
要点总结
1. 软件可靠性测试是为了分析和验证软件的可靠性定量要求而对软件进行的测试，按测试目的的不同可分为软件可靠性增长和验证测试。
2.
3. 4.
P19
步骤2——确定操作的发起者
• 通过操作的发起者能够系统地得到软件的操作 • 操作的发起者系统用户外部系统
系统自身的控制程序
P20
发起者示例——BBS系统
• 根据用户类型可以确定BBS系统的操作发起者包括站务、版务、用户和游客。除此之外，BBS系统定期（每月或每季度一次）会进行数据库的备份操作，因此系统控制器也是一个操作发起者。
–
对软件可靠性进行
定量的评估与验证！
P7
软件可靠性测试
• 定义：
– 为了达到和/或验证软件的可靠性定量要求而对软件进行的测试
• 主要特征
– 按照用户实际使用软件的方式测试软件
P8
软件可靠性测试分类
软件可靠性增长测试
– 测试目的：发现程序中影响软件可靠性的故障，并排除故障实现软件可靠性增长 – 实施阶段：软件系统测试阶段的末期
审核用户信息新建版面仲裁删帖加精置底（或置顶）制作合集 50 0.02 0.04 15 10 2 0.1
发帖
发在线消息浏览文章
5
20 25
注册
备份数据库
P27
60
0.05 127.21
合计
步骤6——确定发生概率
发生概率：利用出现率计算不同表示法发生概率的确定
表格表示法
• 操作的发生概率=操作的出现率/所有操作的总出现率图形表示法 • 属性值的发生概率=每个属性值得出现率/该属性的总出现率
5.
失效数据可分为完全失效数据和不完全失效数据，其中完全失效数据是指由每一次失效发生的时间构成的失效数据，不完全失效数据是指由各时间段内发生的失效次数构成的失效数据。
设A、B、C是相互独立的元素，某一时刻其发生的概率分别
为：60%、30%、10%，则此时的剖面为： [A,0.6...B,0.3...C,0.1]
操作剖面：
Musa给出的定义：指一组操作及其发生的概率操作：是一个主要的系统逻辑任务，持续时间短，结束时将控制权交还给系统，并且它的处理与其它操作有显著不同
测试数据生成方法
数据收集数据分析
基于使用的测试，根据软件的使用状况构造操作剖面然后生成测试用例
需要收集测试输出结果和失效时间等数据通过失效数据进行可靠性分析
基于需求/结构的测试，根据软件的需求或结构生成测试用例
只需收集测试输出结果根据用例执行情况进行需求/结构覆盖分析
测试停止准则
软件可靠性验证测试
– 测试目的：验证在给定的统计置信度下，软件当前的可靠性水平是否满足用户的要求 – 实施阶段：软件验收阶段
P9
软件可靠性测试流程
• 软件可靠性增长测试
被测软件要求
构造操作剖面生成测试数据测试运行测试结果分析排错与回归测试
没达到要求
确定验证测试统计方案
最好使用真实的现场数据，例如通过系统日志得到相同或相似系统
的数据没有可直接使用数据时，可依据相关信息合理估计
无法估计操作的相对概率时，可假设所有操作的出现率相等
不同表示法出现率的确定表格表示法：确定操作的出现率图形表示法：确定属性值的出现率
P26
确定出现率示例 ——BBS系统操作出现率（每天发生次数）
备份数据库
P29
0.0003
1.0
合计
操作剖面示例
操作
标准外部拨号标准内部拨号缩位外部拨号缩位内部拨号
发生概率
0.56 0.24 0.02 0.18
P30
3、软件可靠性测试数据生成流程
P31
3.1输入变量分析
目的确定操作的输入空间
输入变量
任何存在于系统外部、同时影响此系统的数据元素分析步骤确定输入变量确定取值规律
P13
2、构造软件操作剖面
• • 软件操作剖面概念软件操作剖面生成过程：
– 步骤1——确定操作模式
– 步骤2——确定操作的发起者 – 步骤3——选择表格或图形表示法 – 步骤4——创建操作列表 – 步骤5——确定出现率 – 步骤6——确定发生概率
P14
构造软件操作剖面—概念
剖面：一组独立的称之为元素的可能情况和与之相关的发生概率，所有元素的概率和为1
等操作。
游客——未注册人员，仅能浏览BBS的公开版面，不能执行发帖等操作。
P18
操作模式示例——电话系统
• 根据主要时间与次要时间确定操作模式：
– 高峰时段
很大的呼叫和拨号通信量，不执行管理和检查操作
– 主要时段
一般的呼叫和拨号通信量，执行管理操作，但不执行检查操作
– 低谷时段
较低的呼叫和拨号通信量，较少的管理操作，大量执行检查操作
P42
失效严重程度
• 根据系统能力影响划分的失效严重程度
P43
失效数据类型
完全失效数据每一次失效发生的时间构成的失效数据，也称失效时间数据
表现形式
• 失效间隔时间：相邻两次失效出现的时间间隔 • 累计失效时间：将每次失效发生的时间相加得到的结果
不完全失效数据（失效计数数据）
由各时间段内发生的失效次数构成的失效数据，也称为失效计数数据
构造操作剖面生成测试数据测试运行测试结果分析接受、拒绝判决可靠性评估
可靠性评估
可靠性进展分析
达到要求
P10
停止测试
比较项目软件可靠性增长测试一般软件测试软件可靠性测试与一般测试的比较
测试目的
测试效率
评估软件可靠性水平有效实现软件可靠性增长
达到可靠性要求较快
发现软件的故障
达到可靠性要求较慢
软件可靠性测试
软件工程系
相关知识：测试公理
• • 测试只能证明错误的存在，而不能表明程序中没有错误。缺陷分布存在“二八原则”，即20%的模块占有80%的缺陷。
•
• • •
软件测试最困难的问题之一是知道何时停止测试(When to stop testing? )。