免费智能真题库 > 历年试卷 > 系统架构设计师 > 2026年上半年 系统架构设计师 下午试卷 论文
  第2题      
  知识点：   开发过程   可靠性   可靠性测试   可靠性数据的收集   评估   软件可靠性测试   软件可靠性评价   软件系统   生命周期   系统运行   预测

 
论软件可靠性评价
软件可靠性评价是指选用和建立合适的可靠性数学模型，运用统计技术和其他手段，对软件可靠性测试和系统运行期间的软件失效数据（也可能包含软件生命周期内其 他可靠性数据）进行处理，并评估和预测软件可靠性的过程。
软件可靠性评价是软件可靠性活动的重要组成部分，既可在软件开发过程实施，也可针对最终软件系统实施。软件可靠性评价的难点在于软件可靠性模型的选择和软件可靠性数据的收集与处理。
 
问题：2.1   请围绕“软件可靠性评价”论题，依次从以下三个方面进行论述。
1. 简要概述你参与实施的软件开发项目以及你承担的主要工作。
2. 说明你在项目实施过程中所选择的软件可靠性模型，并论述在软件可靠性模型选择时应该考虑的主要因素。
3. 收集软件可靠性数据时经常遇到的问题有哪些？简述你收集软件可靠性数据时所遇到的具体问题及解决的方法。
 
 
 

   知识点讲解    
   · 开发过程    · 可靠性    · 可靠性测试    · 可靠性数据的收集    · 评估    · 软件可靠性测试    · 软件可靠性评价    · 软件系统    · 生命周期    · 系统运行    · 预测
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。
        ：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
        最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
 
       可靠性
        （1）完备性。完备性评价指标及测量，如下表所示。
        
        完备性评价指标及测量
        （2）连续性。连续性评价指标及测量，如下表所示。
        
        连续性评价指标及测量
        
        （3）稳定性。稳定性评价指标及测量，如下表所示。
        
        稳定性评价指标及测量
        （4）有效性。有效性评价指标及测量，如下表所示。
        
        有效性评价指标及测量
        （5）可追溯性。可追溯性评价指标及测量，如下表所示。
        
        可追溯性评价指标及测量
        
 
       可靠性测试
        软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会（IEEE）将软件可靠性定义为：系统在特定的环境下，在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性，以及可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。
        可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间（Mean Time to Failure，MTTF）、故障发生前平均工作时间（Mean-Time-To-First-Failure，MTTFF）或因故障而停机的时间（Mean Time To Repairs，MTTR）在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。
 
       可靠性数据的收集
        面向缺陷的可靠性测试产生的测试数据经过分析后，可以得到非常有价值的可靠性数据，是可靠性评价所用数据的一个重要来源，这部分数据取决于定义的运行剖面和选取的测试用例集。可靠性数据主要是指软件失效数据，是软件可靠性评价的基础，主要是在软件测试、实施阶段收集的，在软件工程的需求、设计和开发阶段的可靠性活动，也会产生影响较大的其他可靠性数据，因此，可靠性数据的收集工作是贯穿于整个软件生命周期的。
        由于软件开发过程中的特殊复杂性及许多潜在因素的影响，可靠性数据收集工作会极为困难，目前，关于数据的收集工作，存在许多有待解决的问题。
        . 可靠性数据的规范不统一。对软件进行度量的定义混乱不清。例如，时间、缺陷、失效、模型结构等的定义，就相当含糊，缺乏统一的标准。这样就使得在进行软件可靠性数据的收集时，目标不明确，甚至无从下手。
        . 数据收集工作的连续性不能保证。可靠性数据的收集是连续的长期的过程，而且需要投入一定的资金、人力、时间，往往这些投入会在软件的开发计划中被忽略，以至于不能保证可靠性数据收集工作的正常进行。
        . 缺乏有效的数据收集手段。进行数据收集同样需要方便实用的工具，然而除了在可靠性测试方面有了一些可用的数据收集工具外，其他方面的工具还十分缺乏。
        . 数据的完整性不能保证。即使可靠性活动计划作得再周密，收集到的数据仍有可能是不完全的，而且遗漏的数据往往会影响到可靠性评价的结果。
        . 数据质量和准确性不能保证。不完全的排错及诊断，使收集的数据中含有不少虚假的成分，它们不能正确反映软件的真实状况。使用不准确的可靠性数据进行的可靠性评价，误差有可能会比利用可靠性模型进行预测产生的误差大一个数量级，这说明数据质量的重要性。
        为了给软件可靠性评价提供一套准确、有效的可靠性数据，有必要在软件工程中重视软件可靠性数据的收集工作，采取一些措施尽量解决上述问题。在现有条件下，可行的一些办法如下。
        . 及早确定所采用的可靠性模型，以确定需要收集的可靠性数据，并明确定义可靠性数据规范中的一些术语和记录方法，如时间、失效、失效严重程度类的定义，制定标准的可靠性数据记录和统计表格等。
        . 制定可实施性较强的可靠性数据收集计划，指定专人负责，抽取部分开发人员、质量保证人员、测试人员、用户业务人员参加，按照统一的规范收集记录可靠性数据。
        . 重视软件测试特别是可靠性测试产生的测试数据的整理和分析，因为这部分数据是用模拟软件实际运行环境的方法，模拟用户实际操作的测试用例测试软件系统产生的数据，对软件可靠性评价和预测有较高的实用价值。
        . 充分利用数据库来完成可靠性数据的存储和统计分析。一方面减少数据管理的混乱，一方面提高数据处理的效率。
 
       评估
        评估测试不只针对物理设备，更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统（如路由器）和网络技术（如ATM或FDDI等）的评估。评估测试不适用于全局网络，因为全局网络拓扑负载、网络设备太多，不好准确定位引起问题的原因和位置，不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商，如路由器、集线器或交换机的供应商，通常很少再做设备比较测试，但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题，所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时，除了使用专用于待测设备或技术的工程负载外，有经验的程序员也使用真实负载，使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较，可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能／特征测试一样，用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础，评估测试中对几种设备或技术进行比较；衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划／设计阶段进行测试是非常好的方法，最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试，在设备选型、技术选型，以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形（工程负载）和真实负载模式进行测试，两种方式都提供了唯一的、重要的检测结果，测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果，因此不能在真实运行环境里显示它们的运行性能；真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能，但无法预测设备的总容量。如果时间允许，两种测试都要做。通常测试人员只有时间进行一种测试，一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形（工程负载）下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置，任何有效、公正的测试配置都能对被测产品进行很好的比较。然而，测试配置和负载越接近运行网络的配置和负载，测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意：要确保配置中所有测试组件都是最新版本，使测试尽可能地公正和统一，以取得最好的测试结果。在测试非正式版时一定要小心，因为发布日期经常有错误。测试配置中安装了非正式版后，它还可能会变，所以非正式版的测试结果和正式版的测试结果经常不一致，分析非正式版的设备经常会延误项目的进行。
        进行评估测试时，除了被测设备，测试配置中的所有网络组件都要保持不变。这一点非常重要，只有这样才能保证被测设备可以进行公平比较。对于子网，这一点很容易做到（一个网络设备很容易被另一个设备所替代）。
        网络技术评估要比较各种网络技术，因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换，路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务，逐步完成测试、数据收集和数据解释。在评估测试中，各测试进行的先后次序没有关系，因为它们不是线性关系，而是多次重复进行的。当在测试中发现了新的信息时，以前所做的测试可能要重新进行以确定它的测试结果，或要对以前的测试稍作改变以检验网络运行的其他方面。此外，在评估期间设备提供商经常发布新的版本或非正式的版本，所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时，不仅要参考评估测试所得的测试结果数据，还要综合考虑其他一些信息，如各设备的性能价格比，但由于没有运行网络的持续和峰值负载要求，所以缺少比较基准，往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估，并撰写网络系统评估报告。
 
       软件可靠性测试
               软件的可靠性测试概述
               软件测试者可以使用很多方法进行软件测试，如按行为或结构来划分输入域的划分测试，纯粹随机选择输入的随机测试，基于功能、路径、数据流或控制流的覆盖测试等。对于给定的软件，每种测试方法都局限于暴露一定数量和一些类别的缺陷。通过这些测试能够查找、定位、改正和消除某些缺陷，实现一定意义上的软件可靠性增长。但是，由于它们都是面向错误的测试，测试所得的结果数据不能直接用于软件可靠性评价，必须经过一定的分析处理后方可使用可靠性模型进行可靠性评价。
               软件可靠性测试由可靠性目标的确定、运行剖面的开发、测试用例的设计、测试实施、测试结果的分析等主要活动组成。
               软件可靠性测试还必须考虑对软件开发进度和成本的影响，最好是在受控的自动测试环境下，由专业测试机构完成。
               软件可靠性测试是一种有效的软件测试和软件可靠性评价技术。尽管软件可靠性测试也不能保证软件中残存的缺陷数最少，但经过软件可靠性测试可以保证软件的可靠性达到较高的要求，对于开发高可靠性与高安全性软件系统很有帮助。
               软件可靠性测试要在工程上获得广泛应用，还有许多实际问题需要解决。
               定义软件运行剖面
               定义运行剖面首先需要为软件的使用行为建模，建模可以采用马尔可夫链来完成。用马尔可夫链将输入域编码为一个代表用户观点的软件使用的状态集。弧用来连接状态并表示由各种激励导致的转换。这些激励可能由硬件、人机接口或其他软件等产生。将转换概率分配给每个弧，用来代表一个典型用户最有可能施加给系统的激励。这种类型的马尔可夫链是一个离散的有限状态集。这类模型可以用有向图或转换矩阵表示。
               定义运行剖面的下一步是开发使用模型，明确需要测试的内容。软件系统可能会有许多用户和用户类别，每类用户都可能以不同的方式使用系统。开发使用模型涉及到将输入域分层。有两种类型的分层形式：用户级分层和用法级分层。用户级分层依赖于谁或什么能激励系统。用法级分层依赖于在测试状态下系统能做什么。换句话说，用户级分层考虑各种类型的用户以及他们如何使用系统，用法级分层则要求考虑系统能够提供的所有功能。一旦用户和用法模型被开发出来，弧上的概率将被分配。这些概率估计主要是基于如下几个方面。
               . 从现有系统收集到的数据；
               . 与用户的交谈或对用户进行观察获得的信息；
               . 原型使用与测试分析的结果；
               . 相关领域专家的意见。
               定义使用概率的最佳方法是使用实际的用户数据，如来自系统原型、前一版本的使用数据；其次是由该软件应用领域的用户和专家提供的预期使用数据；在没有任何数据可用的情况下，只能是将每个状态现有的弧分配相同的概率，这是最差的一种方法。
               由于软件可靠性行为是相对于软件实际的运行剖面而言的，同一软件在不同运行剖面下其可靠性表现可能大不相同，所以用于可靠性测试准备的运行剖面的开发与定义必须充分分析和考虑软件的实际运行情况。
               软件可靠性测试假设每个操作的数据输入都有同样的发生错误的概率，这样最频繁出现的操作和输入将表现出最高的故障率。对于特定的操作环境这是正确的，但无法贯穿系统的全部操作集合。典型的例子是飞机的飞行控制软件，在正常飞行、起飞、降落、地面运动和地面等待这五个状态中，尽管起飞和降落在运行剖面上只占有很小的百分比，但是它们却占有很大的故障比例。对于高安全性要求的软件，一个看起来很少使用的代码路径也可能带来灾难性的后果。因此，对于边界、跃迁情况和关键功能不应该用简单的运行剖面来对待，应该构造专门的运行剖面，补充统计模型之外的测试用例。在覆盖率水平不够时，可根据具体空白，进行适当的补充测试，如果补充测试发现了错误，就可分析这些错误，估计其对可靠性产生的影响。
               一个产品有可能需要开发多个运行剖面，这取决于它所包含的运行模式和关键操作，通常需要为关键操作单独定义运行剖面。
               可靠性测试用例设计
               为了对软件可靠性进行良好的预计，必须在软件的运行域上对其进行测试，首先定义一个相应的剖面来镜像运行域，然后使用这个剖面驱动测试，这样可以使测试真实地反映软件地使用情况。
               由于可能的输入几乎是无限的，测试必须从中选择出一些样本，即测试用例。测试用例要能够反映实际的使用情况，反映系统的运行剖面。将统计方法运用到运行剖面开发和测试用例生成中去，并为在运行剖面中的每个元素都定量地赋予一个发生概率值和关键因子，然后根据这些因素分配测试资源，挑选和生成测试用例。
               在这种测试中，优先测试那些最重要或最频繁使用的功能，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障，以保证软件的按期交付。
               设计测试用例就是针对特定功能或组合功能设计测试方案，并编写成文档。测试用例的选择既要有一般情况，也应有极限情况以及最大和最小的边界值情况。因为测试的目的是暴露应用软件中隐藏的缺陷，所以在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据，结合复杂的运行环境，在所有可能的输入条件和输出条件中确定测试数据，来检查应用软件是否都能产生正确的输出。
               一个典型的测试用例应该包括下列组成部分。
               . 测试用例标识；
               . 被测对象；
               . 测试环境及条件；
               . 测试输入；
               . 操作步骤；
               . 预期输出；
               . 判断输出结果是否符合的标准；
               . 测试对象的特殊需求。
               由于可靠性测试的主要目的是评估软件系统的可靠性，因此，除了常规的测试用例集仍然适用外，我们还要着重考虑和可靠性密切相关的一些特殊情况。在测试中，可以考虑进行“强化输入”，即比正常输入更恶劣（合理程度的恶劣）的输入。
               下表给出一些参考例子：
               
               可靠性测试用例设计时重点考虑的一些特殊情况
               可靠性测试的实施
               在进行应用软件的可靠性测试前有必要检查软件需求与设计文档是否一致，检查软件开发过程中形成的文档的准确性、完整性以及与程序的一致性，检查所交付程序和数据以及相应的软件支持环境是否符合要求。
               这些检查虽然增加了工作量，但对于在测试早期发现错误和提高软件的质量是非常必要的。
               软件可靠性测试必须是受控测试，在运行此类测试时，为了保证统计数据的有效性，测试过程中的每个测试用例必须施加于相同的软件版本，新的软件版本意味着新测试的开始。
               在有些情况下，不能进行纯粹的可靠性测试。因为客户的要求、合同的规定或者标准的约束，需要补充其他形式的非统计测试。这时的最佳选择是既执行可靠性测试，也执行非统计测试（如覆盖测试）。如果非统计测试在可靠性测试之前完成，由统计测试产生的统计数据仍然有效。但是在可靠性测试之后执行非统计测试，可能会影响软件可靠性评估的准确性。
               软件可靠性测试同样依赖于软件的可测试性。可靠性测试难点就在于判断测试用例的运行是成功还是失败。在控制系统及类似的软件中，失效由详细说明、时间（通常是CPU时间或时钟时间）来客观地定义。而在一般应用系统中，失效的定义更主观些，它不仅依赖于程序是否符合规格说明的要求，也取决于指定的性能是否能够达到用户的期望，但是否达到期望没有确定的标准。在一些科学计算中，计算结果只能由计算机给出，在这种情况下，如果软件只是输出了错误的结果而不是整个系统发生失效，错误就不可能被发现。此时可以将测试分成两个阶段进行。第一阶段运行较少量的测试用例，并对照规范进行仔细检查。第二阶段再运行大量测试用例。第二阶段不用人工检查输出的每项内容，而是找失效现象，包括错误信息、断电、崩溃和死机。也可把输出记录到文件中，采用搜索或过滤方法进行处理。如果软件有足够的可测试性，这种方法不会漏掉很多的严重失效。如果计算的正确性无法验证，就需要对软件进行一些形式化的证明。
               开发方交付的任何软件文档中与可靠性质量特性有关的部分、程序以及数据都应当按照需求说明和质量需求进行测试。在项目合同、需求说明书和用户文档中规定的所有配置情况下，程序和数据都必须进行测试。
               软件可靠性数据是可靠性评价的基础。为了获得更多的可靠性数据，应该使用多台计算机同时运行软件，以增加累计运行时间。应该建立软件错误报告、分析与纠正措施系统。按照相关标准的要求，制定和实施软件错误报告和可靠性数据收集、保存、分析和处理的规程，完整、准确地记录软件测试阶段的软件错误报告和收集可靠性数据。
               用时间定义的软件可靠性数据可以分为4类，具体如下。
               . 失效时间数据，记录发生一次失效所累积经历的时间；
               . 失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；
               . 分组时间内的失效数，记录某个时间区内发生了多少次失效；
               . 分组时间的累积失效数，记录到某个区间的累积失效数。
               这4类数据可以互相转化。
               在测试过程中必须真实地进行记录，每个测试记录必须包含如下信息。
               . 测试时间；
               . 含有测试用例的测试说明或标识；
               . 所有与测试有关的测试结果，包括失效数据；
               . 测试人员。
               测试活动结束后要编写《软件可靠性测试报告》，对测试用例及测试结果在测试报告中加以总结归纳。编写时可以参考GJB 438A-97中提供的《软件测试报告》格式，并应根据情况进行剪裁。测试报告应具备如下内容。
               . 软件产品标识；
               . 测试环境配置（硬件和软件）；
               . 测试依据；
               . 测试结果；
               . 测试问题；
               . 测试时间。
               把可靠性测试过程进行规范化，有利于获得真实有效的数据，为最终得到客观的可靠性评价结果奠定基础。
               对于软件可靠性测试用例的设计，有关更详细的内容可以参照本书中“黑盒测试用例设计”部分。
 
       软件可靠性评价
               软件可靠性评价概述
               软件可靠性评价是软件可靠性活动的重要组成部分，既适用于软件开发过程，也可针对最终软件系统。在软件开发过程中使用软件可靠性评价，可以使用软件可靠性模型，估计软件当前的可靠性，以确认是否可以终止测试并发布软件，同时还可以预计软件要达到相应的可靠性水平所需要的时间和工作量，评价提交软件时的软件可靠性水平。对于最终软件产品，软件可靠性评价结合可靠性验证测试，确认软件的执行与需求的一致性，确定最终软件产品所达到的可靠性水平。
               这一节阐述的软件可靠性评价工作是指选用或建立合适的可靠性数学模型，运用统计技术和其他手段，对软件可靠性测试和系统运行期间收集的软件失效数据进行处理，并评估和预测软件可靠性的过程。这个过程包含3个方面：
               ①选择可靠性模型；
               ②收集可靠性数据；
               ③可靠性评估和预测。
               怎样选择可靠性模型
               在前面我们讨论了软件的可靠性模型以及一个举例，一些可靠性研究者试图寻找一个最好的模型，能适用于所有的软件系统，但这样的工作是徒劳的。因为对于不同的软件系统，出于不同的可靠性分析目的，模型的适用性是不一样的。但究竟怎样来为可靠性评价选用不同的模型，却又是一个不小的难题。
               针对可靠性模型的构成以及我们使用模型来进行可靠性评价的目的，可以从以下几个方面进行比较和选择。
                      模型假设的适用性
                      模型假设是可靠性模型的基础，模型假设要符合软件系统的现有状况，或与假设冲突的因素在软件系统中应该是可忽略的。例如，有的模型假定检测或发现的软件缺陷是立即排除掉的，而且排除时间忽略不计，如果现有的软件系统对于严重程度类较低的软件缺陷不进行立即排错，那么这个模型显然是不适用的。
                      往往一个模型的假设有许多条，我们需要在选用模型的时候对每一条假设进行细致的分析，评估现有的软件系统中不符合假设的因素对可靠性评价的影响如何，以确定模型是否适合软件系统的可靠性评价工作。
                      预测的能力与质量
                      预测的能力与质量是指模型根据现在和历史的可靠性数据，预测将来的可靠性和失效概率的能力，以及预测结果的准确程度。显然模型预测的能力与质量是比较难于评价的，但任何一个模型只有在实践中加以实验和不断改善，才能得到认可。所以，我们在满足其他条件的前提下，应尽量选用比较成熟、应用较广的模型作为分析模型。
                      模型输出值能否满足可靠性评价需求
                      我们使用模型进行可靠性评价的最终目的，是想得到软件系统当前的可靠性定量数据，和预测一定时间后的可靠性数据，我们可以根据可靠性测试目的来确定哪些模型的输出值满足可靠性评价需求。一般说来，最重要的几个需要精确估计的可靠性定量指标包括如下内容。
                      . 当前的可靠度；
                      . 平均无失效时间（MTTF）；
                      . 故障密度；
                      . 期望达到规定可靠性目标的日期；
                      . 达到规定的可靠性目标的成本要求。
                      模型使用的简便性
                      模型使用的简便性一般包含三层含义。
                      . 模型需要的数据在软件系统中应该易于收集，而且收集需要投入的成本不能超过可靠性计划的预算。
                      . 模型应该简单易懂，进行可靠性分析的软件测试人员不会花费太多的时间去研究专业的数学理论，他们只需要知道哪些假设适用，需要收集哪些数据，能够得到哪些分析结果就可以了。
                      . 模型应该便于使用，最好能用工具实现数据的输入。也就是说，测试人员除了输入可靠性数据外，不需要深入模型内部进行一些额外的工作。
                      尽管这样，由于可靠性研究理论在软件工程领域发展的限制，可供选择的可靠性模型极其有限，这已在相当大的程度上制约了可靠性测试的开展。
               可靠性数据的收集
               面向缺陷的可靠性测试产生的测试数据经过分析后，可以得到非常有价值的可靠性数据，是可靠性评价所用数据的一个重要来源，这部分数据取决于定义的运行剖面和选取的测试用例集。可靠性数据主要是指软件失效数据，是软件可靠性评价的基础，主要是在软件测试、实施阶段收集的，在软件工程的需求、设计和开发阶段的可靠性活动，也会产生影响较大的其他可靠性数据，因此，可靠性数据的收集工作是贯穿于整个软件生命周期的。
               由于软件开发过程中的特殊复杂性及许多潜在因素的影响，可靠性数据收集工作会极为困难，目前，关于数据的收集工作，存在许多有待解决的问题。
               . 可靠性数据的规范不统一。对软件进行度量的定义混乱不清。例如，时间、缺陷、失效、模型结构等的定义，就相当含糊，缺乏统一的标准。这样就使得在进行软件可靠性数据的收集时，目标不明确，甚至无从下手。
               . 数据收集工作的连续性不能保证。可靠性数据的收集是连续的长期的过程，而且需要投入一定的资金、人力、时间，往往这些投入会在软件的开发计划中被忽略，以至于不能保证可靠性数据收集工作的正常进行。
               . 缺乏有效的数据收集手段。进行数据收集同样需要方便实用的工具，然而除了在可靠性测试方面有了一些可用的数据收集工具外，其他方面的工具还十分缺乏。
               . 数据的完整性不能保证。即使可靠性活动计划作得再周密，收集到的数据仍有可能是不完全的，而且遗漏的数据往往会影响到可靠性评价的结果。
               . 数据质量和准确性不能保证。不完全的排错及诊断，使收集的数据中含有不少虚假的成分，它们不能正确反映软件的真实状况。使用不准确的可靠性数据进行的可靠性评价，误差有可能会比利用可靠性模型进行预测产生的误差大一个数量级，这说明数据质量的重要性。
               为了给软件可靠性评价提供一套准确、有效的可靠性数据，有必要在软件工程中重视软件可靠性数据的收集工作，采取一些措施尽量解决上述问题。在现有条件下，可行的一些办法如下。
               . 及早确定所采用的可靠性模型，以确定需要收集的可靠性数据，并明确定义可靠性数据规范中的一些术语和记录方法，如时间、失效、失效严重程度类的定义，制定标准的可靠性数据记录和统计表格等。
               . 制定可实施性较强的可靠性数据收集计划，指定专人负责，抽取部分开发人员、质量保证人员、测试人员、用户业务人员参加，按照统一的规范收集记录可靠性数据。
               . 重视软件测试特别是可靠性测试产生的测试数据的整理和分析，因为这部分数据是用模拟软件实际运行环境的方法，模拟用户实际操作的测试用例测试软件系统产生的数据，对软件可靠性评价和预测有较高的实用价值。
               . 充分利用数据库来完成可靠性数据的存储和统计分析。一方面减少数据管理的混乱，一方面提高数据处理的效率。
               软件可靠性的评估和预测
               软件可靠性的评估和预测的主要目的，是为了评估软件系统的可靠性状况和预测将来一段时间的可靠性水平。下面是一些常见的需要利用软件可靠性评价进行解答的问题。
               . 判断是否达到了可靠性目标，是否达到了软件付诸使用的条件，是否达到了中止测试的条件。
               . 如未能达到，要再投入多少时间、多少人力和多少资金，达到可靠性目标或投入使用。
               . 在软件系统投入实际运行一年或若干时间后，经过维护、升级、修改，软件能否达到交付或部分交付用户使用的可靠性水平。
               目前有不少支持软件可靠性估计的软件工具，我们只要将收集的失效数据分类并录入，选择合适的可靠性模型就可以获得软件可靠性的评价结果。
               然而，对于那些可靠性要求很高的系统，必须进行很多测试才能预计出高置信度的可靠性结果，即便如此，仍然可能没有任何失效发生。没有失效就无法估计可靠性，不能认为程序的可靠性是1.0。除非我们已经进行了完全的测试，否则程序不失效我们就无法做出估计，而完全的测试几乎总是不可能的。如果在测试期间没有失效发生，我们可以简单地假设测试是基于二项式分布的，这样就可以对可靠性作保守估计，也可以凭经验，根据无故障运行的测试用例的数量，在一定的置信度水平上，估计可靠性的等级。
               软件可靠性评价技术和方法主要依据选用的软件可靠性模型，其来源于统计理论。软件可靠性评估和预测以软件可靠性模型分析为主，但也要在模型之外运用一些统计技术和手段对可靠性数据进行分析，作为可靠性模型的补充、完善和修正。这些辅助方法如下。
               . 失效数据的图形分析法。
               运行图形处理软件失效数据，可以直观地帮助我们进行分析。图形指标如下。
               ①累积失效个数图形；
               ②单位时间段内的失效数的图形；
               ③失效间隔时间图形。
               . 试探性数据分析技术（EDA）。
               对于失效数据图形进行一定的数字化分析，能发现和揭示出数据中的异常。对可靠性分析有用的如下。
               ①循环相关；
               ②短期内失效数的急剧上升；
               ③失效数集中的时间段。
               这种分析方法常可以发现因排错引入新的缺陷、数据收集的质量问题及时间域的错误定义等问题。
               还有其他一些分析方法，这里就不一一赘述了。
 
       软件系统
        网络系统软件包括网络操作系统和网络协议等。网络操作系统是指能够控制和管理网络资源的软件，是由多个系统软件组成，在基本系统上有多种配置和选项可供选择，使得用户可根据不同的需要和设备构成最佳组合的互联网络操作系统。网络协议是保证网络中两台设备之间正确传送数据的约定。
 
       生命周期
        IT服务生命周期由规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision）5个阶段组成，简称“PIOIS”。
        （1）规划设计：从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务。
        （2）部署实施：在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案。
        （3）服务运营：根据IT服务部署情况，依据ITSS，采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营的全面融合。
        （4）持续改进：根据IT服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量。
        （5）监督管理：本阶段主要依据ITSS对IT服务质量进行评价，并对IT服务供方的服务过程、交付结果实施监督和绩效评估。
 
       系统运行
               系统管理分类
               IT系统管理工作主要是优化IT部门的各类管理流程，并保证能够按照一定的服务级别，为业务部门（客户）高质量、低成本地提供IT服务。IT系统管理工作可以按照以下两个标准予以分类。
                      按系统类型分类
                      （1）信息系统，企业的信息处理基础平台，直接面向业务部门（客户），包括办公自动化系统、企业资源计划（ERP）、客户关系管理（CRM）、供应链管理（SCM）、数据仓库系统（Date Warehousing）、知识管理平台（KM）等。
                      （2）网络系统，作为企业的基础架构，是其他方面的核心支撑平台。包括企业内部网（Intranet）、IP地址管理、广域网（ISDN、虚拟专用网）、远程拨号系统等。
                      （3）运作系统，作为企业IT运行管理的各类系统，是IT部门的核心管理平台。包括备份／恢复系统、入侵检测、性能监控、安全管理、服务级别管理、帮助服务台、作业调度等。
                      （4）设施及设备，设施及设备管理是为了保证计算机处于适合其连续工作的环境中，并把灾难（人为或自然的）的影响降到最低限度。包括专门用来放置计算机设备的设施或房间。
                      对IT资产（计算机设备、通信设备、个人计算机和局域网设备）的恰当的环境保护；有效的环境控制机制：火灾探测和灭火系统、湿度控制系统、双层地板，隐藏的线路铺设、安全设置水管位置，使其远离敏感设备、以及不间断电源和后备电力供应等。
                      按流程类型分类
                      （1）侧重于IT部门的管理，从而保证能够高质量地为业务部门（客户）提供IT服务。这一部分主要是对公司整个IT活动的管理，包括IT财务管理、服务级别管理、IT资源管理、能力管理、系统安全管理、新系统转换、系统评价等职能。
                      （2）侧重于业务部门的IT支持及日常作业，从而保证业务部门（客户）IT服务的可用性和持续性。这一部分主要是业务部门IT支持服务，包括IT日常作业管理、帮助服务台管理、故障管理及用户支持、性能及可用性保障等。
                      （3）侧重于IT基础设施建设，主要是建设企业的局域网、广域网、Web架构、Internet连接等。
               系统管理规范化
               系统管理的规范化涉及到人员职责、操作流程等方面标准的制定，并进行有效的标准化。企业IT部门除了IT部门组织结构及职责之外，还应该详细制定各类运作管理规章制度，主要包括：日常作业调度手册、系统备份及恢复手册、性能监控及优化手册、输出管理手册、帮助服务台运作手册、常见故障处理方法、终端用户计算机使用制度等与用户息息相关的IT支持作业方面的规范制度。此外，还包括服务级别管理手册、安全管理制度、IT财务管理制度、IT服务计费及成本核算、IT资源及配置管理、新系统转换流程、IT能力规划管理等由IT部门执行的以提供高质量IT服务为目的的管理流程。
               系统运作报告
               系统运行过程中的关键操作、非正常操作、故障、性能监控、安全审计等信息，应该实时或随后形成系统运作报告，并进行分析以改进系统管理水平。
               是否有流程保证对所有不属于标准操作的操作性问题给予记录（在问题管理系统内）、分析和及时处理？
                      系统日常操作日志
                      系统日志应该记录足以形成数据的信息，为关键性的运作提供审核追踪记录，并且保存合理的时间段。利用日志工具定期对日志进行检查，以便监控例外情况并发现非正常的操作、未经授权的活动、作业完成情况、存储状况、CPU、内存利用水平等。
                      性能／能力规划报告
                      企业需要了解其IT能力能否满足其业务需要，因此它需要了解系统性能、能力和成本的历史数据，定期形成月度、年度性能报告，并进行趋势分析和资源限制评估，在此基础之上增加或调整其IT能力。
                      性能监控工具应该主动地监控、测量和报告系统的性能，包括平均响应时间、每日交易数、平均无故障时间、CPU、存储器等的使用状况、网络性能等，从而可以有预见性地响应变化的业务需求。
                      故障管理报告
                      企业应定期产生有关问题的统计数据，这些统计数据包括：事故出现次数、受影响的客户数、解决事故所需时间和成本、业务损失成本等，可以供管理层对反复发生的问题进行根本原因的分析，并寻找改进的机会。
                      另外，对于每次故障处理应该进行数据记录、归类，作为基础，它应包括以下内容。
                      .目录，确定与故障相关联的领域，比如硬件、软件等。
                      .影响度，故障对业务流程的影响程度。
                      .紧迫性，故障需要得到解决的紧急程度。
                      .优先级，综合考虑影响度、紧迫性、风险和可用资源后得出的解决故障的先后顺序。
                      .解决方法，故障解决的流程、处理方法。
                      这样有利于使用知识管理系统来协助解决问题。
                      安全审计日志
                      为了能够实时监测、记录和分析网络上和用户系统中发生的各类与安全有关的事件（如网络入侵、内部资料窃取、泄密行为等），并阻断严重的违规行为，就需要安全审计跟踪机制来实现在跟踪中记录有关安全的信息。审计是记录用户使用计算机网络系统进行所有活动的过程，它是提高安全性的重要工具。
                      审计记录应包括以下信息：事件发生的时间和地点；引发事件的用户；事件的类型；事件成功与否。常见的审计记录可能包括：活动的用户账号和访问特权；用户的活动情况，包括可疑的行为；未授权和未成功的访问企图；敏感命令的运行等。
                      系统运作报告使对IT的整个运行状况的评价得以实现，IT报告应具备涵盖所有IT领域的关键业绩指标，例如风险及问题、财务状况、系统利用率、系统性能、系统故障时间、服务级别执行情况、安全审计等，这也为IT运作绩效的改进提供了基础。
 
       预测
        随着项目进展，项目团队可根据项目绩效，对完工估算（EAC）进行预测，预测的结果可能与完工预算（BAC）存在差异。如果BAC已明显不再可行，则项目经理应考虑对EAC进行预测。预测EAC是根据当前掌握的绩效信息和其他知识，预计项目未来的情况和事件。预测要根据项目执行过程中所提供的工作绩效数据来产生、更新和重新发布。工作绩效信息包含项目过去的绩效，以及可能在未来对项目产生影响的任何信息。
        有关预测的相关计算会在15.4节中详细说明。
   题号导航      2026年上半年 系统架构设计师 下午试卷 论文   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第2题    在手机中做本题