免费智能真题库 > 历年试卷 > 系统集成项目管理工程师 > 2015年下半年 系统集成项目管理工程师 下午试卷 案例
  第3题      
  知识点:   项目过程   项目验收   质量保证   测试过程   开发人员   维护   系统测试   项目收尾   验收报告   硬件

 
(20分)
阅读下列说明,回答问题1至问题3,将解答填入答题纸的对应栏内。
【说明】
在某系统集成项目收尾的时候,项目经理小张和他的团队完成了以下工作:
工作一:系统测试。项目组准备了详尽的测试用例,会同业主共同进行系统测试测试过程中为了节约时间,小张指派项目开发人员小李从测试用例中挑选了部分数据进行测试,保证系统正常运行。
工作二:试运行。项目组将业主的数据和设置加载到系统中进行正常操作,完成了试运行工作。
工作三:文档移交。小张准备了项目最终报告、项目介绍、说明手册、维护手册、软硬件说明书、质量保证书等文档资料直接发送给业主。
工作四:项目验收。经过业主验收后,小张派小李撰写了项目验收报告,并发送给双方工作主管。
工作五:准备总结会。小张总结了项目过程文档以及项目组各技术人员的经验,并列出了项目执行过程中的若干优点。
工作六:召开总结会。小张召集参与项目的一些人员参加了总结会,并就相关内容进行了讨论,形成了总结报告。
 
问题:3.1   工作六中,项目组召开了总结会,以下哪一项不是项目总结会讨论的内容? (从候选答案中选择一个正确选项,将该选项编号填入答题纸对应栏内)
候选答案:
A.项目绩效 B.项目审计 c.经验总结 D.进度计划绩效
 
问题:3.2   项目经理小张在验收活动完成后,还需要针对系统集成项目进行后续的支持工作,以下哪一项不属于系统集成项目的后续工作?(从候选答案中选择一个正确选项,将该选项编号填入答题纸对应栏内)
候选答案:
A 信息系统日常维护工作 B.硬件产品的更新
C.业主针对新员工的培训需求 D.信息系统的新需求
 
问题:3.3   (12分)
请指出本案例的六项工作中哪些工作存在问题并具体说明。
 
 
 

   知识点讲解    
   · 项目过程    · 项目验收    · 质量保证    · 测试过程    · 开发人员    · 维护    · 系统测试    · 项目收尾    · 验收报告    · 硬件
 
       项目过程
        过程是为创建预定的产品、服务或成果而执行的一系列相互关联的行动和活动。每个过程都有各自的输入、工具和技术及相应输出。项目经理在每个过程中都需要考虑组织过程资产和事业环境因素,即使它们在过程规范中没有被明确列为输入。组织过程资产为裁剪组织的过程提供指南和准则,以满足项目的特定要求,事业环境因素则可能限制项目管理的灵活性。
        一般来说,要把一个项目管好,至少需要四种过程:
        .技术类过程(或工程类过程):解决研制特定产品、完成特定成果或提交特定服务的具体技术过程,和项目所在行业有关。
        .管理类过程:保证项目在整个生命周期中顺利进行,包括启动、计划、执行、监控和收尾过程组。
        .支持类过程:配置管理等支持项目顺利进行的过程。
        .改进类过程:总结经验教训、部署改进等过程。
        本节将重点介绍管理类过程,即项目管理过程。
 
       项目验收
        项目验收是项目收尾管理中的首要环节。项目的正式验收包括验收项目产品、文档及已经完成的交付成果。
        系统集成项目的验收依据是项目前期所签署的合同内容以及对应的技术工作内容,如果在项目执行过程中发生了合同变更,还应将变更内容也作为项目验收的评价依据。对于软件类型的系统集成项目而言,验收依据除了项目前期的合同内容,还包括甲乙双方签署或认可的软件需求规格说明书。
        系统集成项目在验收阶段主要包含以下四方面的工作内容,分别为:
        .验收测试:对信息系统进行全面的测试,依照双方合同约定的系统环境,以确保系统的功能和技术设计满足建设方的功能需求和非功能需求,并能正常运行。验收测试阶段应包括编写验收测试用例,建立验收测试环境,全面执行验收测试,出具验收测试报告以及验收测试报告的签署。
        .系统试运行:信息系统通过验收测试后,可以开通系统试运行。系统试运行期间主要包括数据迁移、日常维护以及缺陷跟踪和修复等方面的工作内容。
        .系统文档验收:系统经过验收测试后,系统的文档应当逐步、全面地移交给客户。客户也可按照合同或者项目工作说明书的规定,对所交付的文档加以检查和评价;对不清晰的地方可以提出修改要求。系统集成项目所涉及的文档一般包括:
        系统集成项目介绍。
        系统集成项目最终报告。
        信息系统说明手册。
        信息系统维护手册。
        软硬件产品说明书、质量保证书等。
        .项目终验:在系统经过试运行以后的约定时间,例如三个月或者六个月,双方可以启动项目的最终验收工作。最终验收的工作包括双方对验收测试文件的认可和接受、双方对系统试运行期间的工作状况的认可和接受、双方对系统文档的认可和接受、双方对结束项目工作的认可和接受。
        项目最终验收合格后,应该由双方的项目组撰写验收报告提请双方工作主管认可。这标志着项目组开发工作的结束和项目后续活动的开始。
 
       质量保证
        质量保证是审计质量要求和质量控制测量结果,确保采用合理的质量标准和操作性定义的过程,其主要作用为促进质量过程改进。
               输入
                      质量管理计划
                      质量管理计划描述了项目质量保证和持续过程改进的方法。
                      过程改进计划
                      项目的质量保证活动应该支持并符合执行组织的过程改进计划。
                      质量测量指标
                      质量测量指标提供了应该被测量的属性和允许的偏差。
                      质量控制测量结果
                      质量控制测量结果是质量控制活动的结果,用于分析和评估项目过程的质量是否符合执行组织的标准或特定要求。质量控制测量结果也有助于分析这些测量结果的产生过程,以确定实际测量结果的正确程度。
                      项目文件
                      项目文件可能影响质量保证工作,应该放在配置管理系统内监控。
               工具与技术
                      质量管理与控制工具
                      质量保证过程使用制订质量管理计划和质量控制过程的工具和技术。除此之外,其他可用的工具包括:
                      .亲和图:与心智图相似,针对某个问题,产生出可联成有组织的想法模式的各种创意。在项目管理中,使用亲和图确定范围分解的结构,有助于WBS的创建。
                      .过程决策程序图(PDPC):用于理解一个目标与达成此目标的步骤之间的关系。PDPC有助于制订应急计划,因为它能帮助团队预测那些可能破坏目标实现的中间环节。
                      .关联图:关系图的变种,有助于在包含相互交叉逻辑关系(可有多达50个相关项)的中等复杂情形中创新性地解决问题。可以使用其他工具(如亲和图、树形图或鱼骨图)产生的数据来绘制关联图。
                      .树形图:也称系统图,可用于表现WBS、RBS(风险分解结构)和OBS(组织分解结构)的层次分解结构。在项目管理中,树形图依据定义嵌套关系的一套系统规则,用层次分解形式直观地展示父子关系。
                      .优先矩阵:用来识别关键事项和合适的备选方案,并通过一系列决策,排列出备选方案的优先顺序。先对标准排序和加权,再应用于所有备选方案,计算出数学得分,对备选方案排序。
                      .活动网络图:过去称为箭头图,包括AOA(活动箭线图)和最常用的AON(活动节点图)两种格式的网络图。活动网络图连同项目进度计划编制方法一起使用,如计划评审技术(PERT)、关键路径法(CPM)和紧前关系绘图法(PDM)。
                      .矩阵图:使用矩阵结构对数据进行分析。在行列交叉的位置展示因素、原因和目标之间的关系强弱。
                      以上七种质量管理和控制工具如下图所示。
                      质量审计
                      质量审计是用来确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化的、独立的过程。质量审计的目标是:
                      .识别全部正在实施的良好及最佳实践。
                      .识别全部违规做法、差距及不足。
                      .分享所在组织或行业中类似项目的良好实践。
                      .积极、主动地提供协助,以改进过程的执行,从而帮助团队提高生产效率。
                      .强调每次审计都应对组织经验教训的积累做出贡献。
                      质量审计还可确认已批准的变更请求(包括更新、纠正措施、缺陷补救和预防措施)的实施情况。
                      过程分析
                      过程分析是指按照过程改进计划中概括的步骤来识别所需的改进。它也要检查在过程运行期间遇到的问题、制约因素,以及发现的非增值活动。过程分析包括根本原因分析(用于识别问题、探究根本原因,并制订预防措施的一种具体技术)。
                      
                      七种质量管理和控制工具示意图
               输出
                      变更请求
                      可以提出变更请求,并提交给实施整体变更控制过程,以全面考虑改进建议。可以为采取纠正措施、预防措施或缺陷补救而提出变更请求。
                      项目管理计划更新
                      项目管理计划中可能需要更新的内容包括质量管理计划、范围管理计划、进度管理计划和成本管理计划。
                      项目文件更新
                      可能需要更新的项目文件包括质量审计报告、培训计划和过程文档。
                      组织过程资产更新
                      可能需要更新的组织过程资产包括组织的质量标准和质量管理系统。
 
       测试过程
        软件测试过程一般包括:测试需求分析、测试策划、测试设计和实现、测试执行、测试总结(包括评价过程和总结),如下图所示。
        
        软件测试过程
               测试需求分析
               根据被测软件的需求规格说明或设计文档,进行测试需求分析,包括:
               (1)确定需要的测试类型及其测试要求并进行标识(编号),标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型;测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试级别(单元测试、部件测试、配置项测试、系统测试)、测试类型相匹配。
               (2)确定每个测试项的优先级。
               (3)确定每个测试项的测试充分性要求。
               (4)根据被测软件的重要性、测试目标和约束条件,确定每个测试项应覆盖的范围及范围所要求的覆盖程度。
               (5)确定每个测试项测试终止的要求,包括测试过程正常终止的条件(如测试充分性是否达到要求)和导致测试过程异常终止的可能情况。
               (6)确定测试项与软件需求规格说明或设计文档的追踪关系。
               将测试需求分析结果按所确定的文档要求,形成测试需求规格说明或写入测试计划。
               应对测试需求规格说明或测试需求分析结果进行评审,评审内容如下:
               (1)测试级别和测试对象所确定的测试类型及其测试要求是否恰当。
               (2)每个测试项是否进行了标识,并逐条覆盖了测试需求和潜在需求。
               (3)测试类型和测试项是否充分。
               (4)测试项是否包括了终止要求。
               (5)文档是否符合规定的要求。
               测试策划
               根据软件需求规格说明或设计文档等进行测试策划,策划一般包括:
               (1)确定测试策略,如部件或配置项测试策略。
               (2)确定测试需要的技术或方法,如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。
               (3)确定要受控制的测试工作产品,列出清单。
               (4)确定用于测试的资源要求,包括软硬件设备、环境条件、人员数量和技能等要求。
               (5)进行测试风险分析,如技术风险、人员风险、资源风险和进度风险等。
               (6)确定测试任务的结束条件。
               (7)确定被测软件的评价准则和方法。
               (8)确定测试活动的进度。应根据测试资源和测试项,确定进度。
               应将测试策划结果,按所确定的文档要求形成测试计划。
               测试设计和实现
               应根据测试需求规格说明和测试计划进行测试设计和实现,应完成如下工作:
               (1)按需要分解测试项。将需要测试的测试项进行层次化的分解并进行标识,若有接口测试,还应有高层次的接口图说明所有接口和要测试的接口。
               (2)说明最终分解后的测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。
               (3)设计测试用例。
               (4)确定测试用例的执行顺序。
               (5)准备和验证所有的测试用数据。针对测试输入要求,设计测试用的数据,如数据类型、输入方法等。
               (6)准备并获取测试资源,如测试环境所必须的软、硬件资源等。
               (7)必要时,编写测试执行需要的程序,如开发部件测试的驱动模块和桩模块以及测试支持软件等。
               (8)建立和校核测试环境,记录校核结果,说明测试环境的偏差。
               应将测试设计与实现的工作结果,按照所确定的文档要求编写测试说明,测试说明一般应包括:
               (1)测试名称和项目标识。
               (2)测试用例的追踪。说明测试所依据的内容来源,并跟踪到相应的测试项的标识(编号)。
               (3)测试用例说明。简要描述测试的对象、目的和所采用的测试方法。
               (4)测试用例的初始化要求,包括硬件配置、软件配置(包括测试的初始条件)、测试配置(如用于测试的模拟系统和测试工具)、参数设置(如测试开始前对断点、指针、控制参数和初始化数据的设置)等的初始化要求。
               (5)测试用例的输入。每个测试用例输入的描述中应包括的内容:
               ①每个测试输入的名称、用途和具体内容(如确定的数值、状态或信号等)及其性质(如有效值、无效值、边界值等)。
               ②测试输入的来源(如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等),以及选择输入所使用的方法(如等价类划分、边界值分析、猜错法、因果图以及功能图等)。
               ③测试输入是真实的还是模拟的。
               ④测试输入的时间顺序或事件顺序。
               (6)测试用例的期望测试结果。期望测试结果应有具体内容(如确定的数值、状态或信号等),不应是不确切的概念或笼统的描述。必要时,应提供中间的期望结果。
               (7)测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息,如:
               ①实际测试结果所需的精确度。
               ②允许的实际测试结果与期望结果之间差异的上、下限。
               ③时间的最大或最小间隔。
               ④事件数目的最大或最小值。
               ⑤实际测试结果不确定时,重新测试的条件。
               ⑥与产生测试结果有关的出错处理。
               ⑦其他有关准则。
               (8)实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤,执行步骤应包括:
               ①每一步所需的测试操作动作、测试程序输入或设备操作等。
               ②每一步期望的测试结果。
               ③每一步的评估准则。
               ④导致被测程序执行终止伴随的动作或指示信息。
               ⑤需要时,获取和分析中间结果的方法。
               (9)测试用例的前提和约束。在测试用例中还应说明实施测试用例的前提条件和约束条件,如特别限制、参数偏差或异常处理等,并要说明它们对测试用例的影响。
               (10)测试终止条件。说明测试用例的测试正常终止和异常终止的条件。
               (11)确定测试说明与测试计划或测试需求规格说明的追踪关系,给出清晰、明确的追踪表。
               (12)测试说明应经过评审,得到相关人员的认同,测试说明评审内容如下:
               ①测试说明是否完整、正确和规范。
               ②测试设计是否完整和合理。
               ③测试用例是否可行和充分。
               测试执行
               应按照测试计划和测试说明的内容和要求执行测试,主要完成下列工作:
               如实填写测试记录,当结果有量值要求时,应准确记录实际的量值。
               (1)测试记录应受到严格管理,并规范格式,至少包括测试用例标识、测试结果和发现的缺陷。
               (2)应根据每个测试用例的期望测试结果、实际测试结果和评估准则,判定测试用例是否通过。
               (3)当测试用例不通过时,应根据不同的缺陷类型,采取相应的措施:
               ①对测试工作中的缺陷,如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等,记录到相应的表格中,并实施相应的变更。
               ②对被测软件的缺陷应记录到软件问题报告中。
               ③软件问题报告的格式应规范。
               (4)当所有的测试用例都执行完毕后,实验室应根据测试的充分性要求和有关记录,分析测试工作是否充分,是否需要进行补充测试:
               ①当测试过程正常终止时,如果发现测试工作不足,或测试未达到预期要求时,应进行补充测试。
               ②当测试过程异常终止时,应记录导致终止的条件、未完成的测试或未被修正的错误。
               测试总结
               应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录、测试问题及变更报告和软件问题报告等,对测试工作和被测软件进行分析和评价,主要完成下列工作:
               (1)对测试工作进行分析和评价,分析和评价内容应包括:
               ①总结测试需求规格说明、测试计划和测试说明的变化情况及其原因。
               ②在测试异常终止时,说明未能被测试活动充分覆盖的范围及其理由。
               ③确定无法解决的软件测试事件并说明不能解决的理由。
               (2)对被测软件进行分析和评价,分析和评价内容应包括:
               ①总结测试中所反映的被测软件与软件需求(或软件设计)之间的差异。
               ②可能时,根据差异评价被测软件的设计与实现,提出改进的建议。
               ③当进行配置项测试或系统测试时,当需要时,测试总结中应对配置项或系统的性能做出评估,指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。
               (3)分析测评项目中的数据和文档,以供以后的测试使用。数据如:缺陷数据(包括缺陷描述、类型、严重性等)、用例数据、管理数据(如生产率、工作量、进度等);文档如:好的用例设计、好的需求规格说明等。
               (4)应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录和软件问题报告等有关文档,对测试结果和问题进行分类和总结,按所确定的文档要求编写测试报告。测试报告除了应包括对测试结果的分析,还应包括对被测软件的评价和建议。
               测试总结评审应在测试报告编制工作完成后进行,以确定是否达到测试目的,给出评审结论。评审的具体内容和要求包括:
               (1)审查测试文档与记录内容的完整性、正确性和规范性。
               (2)审查测试活动的独立性和有效性。
               (3)审查测试环境是否符合测试要求。
               (4)审查软件测试报告与软件测试原始记录和问题报告的一致性。
               (5)审查实际测试过程与测试计划和测试说明的一致性。
               (6)审查测试说明评审的有效性,如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性。
               (7)审查测试结果的真实性和正确性。
 
       开发人员
        ①多媒体软件:项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
        ②多媒体电子出版物:策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
 
       维护
        维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来,作为正式的文档资料加以保存。
 
       系统测试
        系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来,以需求规格说明为依据,在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试3个阶段,系统测试一般要完成功能测试、性能测试、恢复测试、安全测试、强度测试以及其他限制条件的测试。
        系统测试由独立测试小组在测试组长的监督下进行,测试组长主要负责保证在质量控制和监督下使用测试技术执行系统测试。系统测试过程由一个独立的测试观察员来监控测试工作。
               负载测试
               负载测试是通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
               负载测试的加载方式通常有如下几种。
               (1)一次性加载。一次性加载某个数量的用户,在预定的时间段内持续运行。例如,在早晨上班的时间访问网站或登录网站的时间非常集中,基本属于扁平负载模式。
               (2)递增加载。有规律地逐渐增加用户,每几秒增加一些新用户,交错上升。借助这种负载方式的测试,容易发现性能的拐点,即性能瓶颈。
               (3)高低突变加载。某个时间用户数量很大,突然降到很低,过一段时间,又突然加到很高,反复几次。借助这种负载方式的测试,容易发现资源释放和内存泄露等问题。
               (4)随机加载方式。由随机算法自动生成某个数量范围内变化的、动态的负载,这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬时高峰期,但可以模拟系统长时间的运行过程的状态。
               压力测试
               压力测试又称为强度测试,是在强负载(加大数据量、大量并发用户等)下的测试,用于查看应用系统在峰值使用情况下的操作行为,目的是发现系统的功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
               微软测试实践经验表明,如果软件产品通过72小时压力测试,则在72小时后出现问题的可能性微乎其微。所以,72小时成为微软产品压力测试的时间标志。
               负载测试与压力测试是两个很容易混淆的概念。负载测试是通过逐步增加系统负载,测试其变化,看最后在满足性能的情况下,系统最多能接受多大负载的测试。压力测试是在满足性能的情况下,能使系统处于失效的状态,通俗来说,就是发现在什么条件下,系统的性能会变得不可接受。
               压力测试的一般步骤如下:
               ①进行简单多任务测试。
               ②简单压力缺陷修正后,增加系统的压力直到系统崩溃。
               因此,负载压力测试的主要目的是度量应用系统的性能和扩展性。在实施并发负载过程中,通过实时性能监测来确认和查找问题,并针对所发现的问题对系统性能进行优化。负载压力测试工具能够对整个企业架构进行测试,通过这些测试,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。
               可靠性测试
               软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会(IEEE)将软件可靠性定义为:系统在特定的环境下,在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性,以及可维护性等多方面特性,是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。
               可靠性测试一般伴随着强壮性测试,是评估软件在运行时的可靠性,通过测试确认平均无故障时间(Mean Time to Failure,MTTF)、故障发生前平均工作时间(Mean-Time-To-First-Failure,MTTFF)或因故障而停机的时间(Mean Time To Repairs,MTTR)在一年中应不超过多少时间。可靠性测试强调随机输入,并通过模拟系统实现,很难通过实际系统的运行来实现。
               安全性测试
               安全性测试是测试系统在应付非授权的内部/外部访问、非法侵入或故意的损坏时的系统防护能力,检验系统有能力使可能存在的内/外部的伤害或损害的风险限制在可接受的水平内。可靠性通常包括安全性,但是软件的可靠性不能完全取代软件的安全性。安全性还涉及到数据加密、保密和存取权限等多个方面。
               安全性测试需要设计一些测试用例试图突破系统的安全保密措施,检验系统是否有安全保密漏洞,验证系统的保护机制是否能够在实际中不受到非法的侵入。在安全测试过程中,测试者扮演成试图攻击系统的角色,尝试获取系统密码,利用能够瓦解任何防守的客户软件攻击系统;或者把系统“制服”,使别人无法访问。
               安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞。破坏系统保护机构的主要方法有以下几种:
               (1)正面攻击或从侧面、背面攻击系统中易受损坏的那些部分。
               (2)以系统输入为突破口,利用输入的容错性进行正面攻击。
               (3)申请和占用过多的资源压垮系统,以破坏安全措施,从而进入系统。
               (4)故意使系统出错,利用系统恢复的过程,窃取用户口令及其他有用的信息。
               (5)通过浏览残留在计算机各种资源中的垃圾(无用信息),以获取如口令、安全码和译码关键字等信息。
               (6)浏览全局数据,期望从中找到进入系统的关键字。
               (7)浏览那些逻辑上不存在,但物理上还存在的各种记录和资料等。
               一般情况下,网络软件的安全评估包括以下情况;
               (1)检验和测试网络软件中涉及数据传输各部分的配量对安全的影响。
               (2)会话跟踪是否足够。
               (3)是否正确使用了加密技术。
               (4)变量限制的设定。
               (5)在服务器端执行程序中的安全漏洞。
               (6)HTML源码中是否有敏感的信息或没有必须出现的信息。
               兼容性/配置测试
               兼容性/配置测试用于测试软件与先前发布过的版本、有依赖关系的外部软件、运行的系统的各种版本和硬件平台的不同配置的兼容情况。
               可以从如下几个方面进行兼容性测试。
               (1)检查版本是否兼容。检查新版本操作习惯与老版本是否兼容,目的是使老版本的用户很快地适应新版本的变化。
               (2)检查数据格式是否兼容。数据格式有许多种形式,如文件格式、网络协议和共享数据等。例如,通信协议软件版本升级后,检查升级版本和老版本的通信协议是否一致等。
               (3)检查系统调用的兼容性。检查系统的哪些功能依赖于系统调用,是否属于某个平台或版本独有,是否在不同平台上有差异。
               (4)检查是否支持操作系统、数据库系统、硬件和软件平台。配置测试用例设计主要指软硬件环境配置的测试用例,检查计算机系统内各个设备或各种资源之间的相互关联和功能分配中的错误。
               容错性测试
               容错性测试是检查软件在异常条件下自身是否具有防护性措施或者灾难恢复手段。如当系统出错时,能否在指定时间间隔内修正错误并重新启动。可以把容错性测试看作是由系统异常处理测试和恢复测试组成的。
               可用性测试
               可用性是指系统正常运行的能力和用户接受的程度,一般用如下公式表示。
               可用性=平均正常工作时间/(平均正常工作时间+平均修复时间)
               影响可用性的因素有如下几个:
               (1)不充分的测试。
               (2)更改管理问题。
               (3)缺少在线监视和分析。
               (4)操作错误。
               (5)弱编码。
               (6)与外部服务或应用程序的交互。
               (7)不同的操作条件(使用级别更改、峰值重载)。
               (8)异常事件(安全性失败、广播风暴)。
               (9)硬件故障(硬盘、控制器、网络设备、服务器、电源、内存和CPU)。
               (10)环境问题(电源、冷却、火、洪水、灰尘、自然灾害)。
               下面给出提高系统可用性的一些办法。
               (1)使用集群。集群是指将至少两个系统连接到一起,像一个系统那样工作。当某一系统出现失效时,集群提供即时故障转移服务。
               (2)使用网络负载平衡。当检测某服务器失败后,网络负载平衡自动将通信量重新分发给仍然运行的服务器。
               (3)使用服务级别协议。可用性指标的期望服务级别要求达到4个或5个“9”。例如,“该应用程序应每周运行7天,每天24小时,年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟,不足1个小时。
               (4)提供实时的监视。监视系统的工作负荷和失败数据,实时监视对于发现趋势和改善服务至关重要。
               (5)使用数据备份,保证数据安全。
               (6)检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用,还意味着使得应用程序使用的所有分布式组件和资源受到保护。
               文档测试
               文档测试是指对软件开发、测试和维护过程中产生的所有文档的测试,包括对需求规格分析说明书、详细设计报告、系统设计报告、用户手册以及与系统相关的一切文档的审阅和评测。例如,系统需求分析和系统设计说明书中的错误将直接导致编码的错误,用户手册作为软件的一部分,将直接影响用户对系统的使用效果。
               文档测试强调文档的表述应该清楚、准确,主要包含:
               .正确地按照文档描述的方法使用系统。
               .测试每一个提示和建议信息。
               .使用文档作为测试用例的来源。
               .测试每一个在线帮助的超链接。
               .测试每条语句。
               .测试文档中提供的每一个样例。
               .把缺陷写入缺陷跟踪库。
               .检查所有的错误信息。
 
       项目收尾
        项目收尾的内容
        项目收尾过程根据项目管理计划的收尾部分执行。在多阶段的项目中,项目收尾过程对项目的部分范围以及相应的活动进行收尾。如果项目在完成前就被终止,要对采取这一举措的原因进行分析和记录。
        .管理收尾
        管理收尾涉及到项目干系人的所有活动,重点在于收集项目记录、分析项目得失、收集经验教训,以及对项目归档供未来参考之用。
        .合同收尾
        包括产品验证(所有的工作已正确完成并且客户满意)和合同管理收尾(更新合同记录的内容并将信息归档供将来参考之用)两部分工作内容。
        输入
        1.项目管理计划
        2.合同
        合同文件包括合同本身、合同变更和其他文件(如技术方法、产品说明书、可交付物验收准则与程序)。
        3.企业环境因素
        4.组织过程资产
        5.工作绩效信息
        6.交付物
        工具与技术
        1.项目管理方法论
        2.项目管理信息系统
        3.专家判断
        输出
        1.管理收尾规程
        本规程包含参与执行项目或阶段性管理收尾程序的所有项目团队成员的活动及相关角色和职责。该规程制订了将项目产品或服务移交生产或运营的程序,处理的对象有:
        .确定干系人批准变更和所有级别可交付物要求的行动与活动。
        .确认项目已满足所有赞助人、顾客和其他干系人的要求,核实所有可交付物都已经提供并验收,确认完成与出口准则已经遵循所需要的行动与活动。
        .满足项目完成与出口准则所需要的行动与活动。
        2.合同收尾规程
        本规程为逐步进行合同收尾提供了一种方法,它包括确定合同条款和相关条件,以及所需的退出准则,涉及到项目团队成员、客户以及参与合同收尾过程的其他干系人的所有活动与有关的责任。
        3.最终产品、服务或成果
        4.组织过程资产(更新)
        收尾包括利用配置管理系统为项目文件编制一份索引指明其存储位置。
        .正式验收文件:表明客户或项目发起人已经正式验收了项目交付物。
        .项目档案:项目活动产生的文件,如项目管理计划、范围、进度、成本、质量基准。
        .项目收尾文件:包括表明项目已经完成,完成的项目交付物已移交的正式文件。若项目提前终止,该文件需要说明项目终止的原因,并履行正式程序,将取消项目的已完成与未完成交付物移交他人。
        .历史信息:历史信息和经验教训要转移到经验知识库,以便未来项目使用。
 
       验收报告
        验收报告的主要内容包括验收的各项内容、评价与验收结论、验收委员会全体成员签字及验收委员会主任的意见。
        如果验收未通过,则需要重新验收或进入合同争议。如果验收通过,则监理需要审查承建单位的项目资料清单、协助建设单位和承建单位交接项目资料、确保软件文档和软件的一致性,同时将开发软件做好备份,保管在安全的地方,文件材料归档。
 
       硬件
        硬件是计算机物理设备的总称,也称为硬件设备,通常是电子的、机械的、磁性的或光的元器件或装置,一般分为中央处理器、存储器和输入、输出设备。
   题号导航      2015年下半年 系统集成项目管理工程师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第3题    在手机中做本题