免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2020年下半年 信息系统项目管理师 下午试卷 案例
  第3题      
  知识点：   测试过程   策划   开发人员   敏捷开发   配置管理   配置管理员   配置库   系统测试

 
A公司是提供SaaS平台服务业务的公司，小张作为研发流程优化经理，他抽查了核心产品的配置管理和测试过程，情况如下：项目组共10人，产品经理小马兼任项目经理和配置管理员，还有7名开发工程师和2名测试工程师，采用敏捷开发的方法，2周为一个迭代周期，目前刚刚完成一个3.01版本的上线。
小张要求看一下配置管理库，小马回复：“我正忙着，让测试工程师王工给你看吧，我们10个人都有管理员权限”。小张看到配置库分为了开发库和产品库，产品库包括上线的3个大版本的完整代码和文档资料，而且与实际运行版本有偏差。小版本只能在开发库中找到代码，但没有相关文档，而且因为新需求迭代太快，有些很细微的修改，开发人员随手进行了修改，文档和代码存在一些偏差。
小张策划对产品做一次3.01版本的系统测试，以便更好的解决研发流程和系统本身的问题。
 
问题：3.1   （5分）
结合本案例，从配置管理的角度指出项目实施过程存在的问题。
 
问题：3.2   （10分）
结合本案例，请帮助测试工程师从测试目的、测试对象、测试内容、测试过程、测试用例设计依据、测试技术6个方面设计核心产品3.01版本的系统测试方案。
 
问题：3.3   （6分）
如果系统测试中需要采用黑盒测试、白盒测试和灰盒测试，请阐述三种测试的含义和用途。
 
问题：3.4   （4分）
从候选答案中选择正确选项，将该选项编号填入答题纸对应栏内。
配置项的状态通常可分为三种，配置项初建时其状态为（1)。配置项通过评审后，其状态变为（2)。此后若更改配置项，则其状态变为（3）。当配置项修改完毕并重新通过评审时，其状态又变为（4)。
A.送审稿
B.草稿
C.报批稿
D.征求意见
E.修改
F.正式
 
 
 

   知识点讲解    
   · 测试过程    · 策划    · 开发人员    · 敏捷开发    · 配置管理    · 配置管理员    · 配置库    · 系统测试
 
       测试过程
        软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。
        
        软件测试过程
               测试需求分析
               根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：
               （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）审查测试结果的真实性和正确性。
 
       策划
        目的：对运行维护服务能力进行整体策划并提供必要的资源支持，以确保供方有能力提供运行维护服务。
        供方应对运行维护服务能力进行策划，至少应：
        .根据自身业务定位和能力，策划运行维护服务对象的服务内容与要求，并形成服务目录。
        .依据组织的业务发展需要来建立组织结构和管理制度，支持服务目录的实施或实现。
        .对人员、资源、技术和过程进行规划，建立相适应的指标体系和服务保障体系。
        .策划如何管理、审核并改进服务质量，建立内部审核评估机制。
 
       开发人员
        ①多媒体软件：项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
        ②多媒体电子出版物：策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
 
       敏捷开发
        敏捷软件开发简称敏捷开发，是从20世纪90年代开始逐渐引起广泛关注的一些新型软件开发方法，以应对快速变化的需求。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重人的作用。
        敏捷开发的发展过程中出现了多个不同的流派，例如极限编程（Extreme Programming，XP）、自适应软件开发、水晶方法、特性驱动开发等。但其中的基本原则是一致的。从开发者的角度，主要的关注点有短平快会议（Stand Up）、小版本发布（Frequent Release）、较少的文档（Minimal Documentation）、合作为重（Collaborative Focus）、客户直接参与（Customer Engagement）、自动化测试（Automated Testing）、适应性计划调整（Adaptive Planning）和结对编程（Pair Programming）；从管理者的角度，主要的关注点有测试驱动开发（Test-Driven Development）、持续集成（Continuous Integration）和重构（Refactoring）。
        XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学且充满乐趣的软件开发方式，适用于小型或中型软件开发团队，并且客户的需求模糊或需求多变。与其他方法相比，其最大的不同如下：
        （1）在更短的周期内，更早地提供具体、持续的反馈信息。
        （2）迭代地进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断地发展它。
        （3）依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
        （4）依赖于口头交流、测试和源程序进行沟通。
        （5）倡导持续的演化式的设计。
        （6）依赖于开发团队内部的紧密协作。
        （7）尽可能达到程序员短期利益和项目长期利益的平衡。
        XP由价值观、原则、实践和行为4个部分组成，它们彼此相互依赖、关联，并通过行为贯穿于整个生命周期。XP的核心是其总结的4大价值观，即沟通、简单、反馈和勇气。它们是XP的基础，也是XP的灵魂。XP的5个原则是快速反馈、简单性假设、逐步修改、提倡更改和优质工作。而在XP方法中，贯彻的是“小步快走”的开发原则，因此工作质量决不可打折扣，通常采用测试先行的编码方式来提供支持。
        在XP中集成了12个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户和编码标准。
        敏捷方法主要适用于小规模软件的开发和小型团队的开发。这些方法所提出来的一些所谓的“最佳实践”并非对每个项目都是最佳的，需要项目团队根据实际情况决定。而且，敏捷方法的有些原则在应用中不一定能得到贯彻和执行。因此，在实际工作中，可以“取其精华，去其糟粕”，把敏捷方法和其他方法结合起来。
 
       配置管理
        随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
        信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
               配置管理计划
               根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。
               （1）该项目对配置管理的要求。
               （2）实施配置管理的责任人、组织及其职责。
               （3）需要开展的配置管理活动及其进度安排。
               （4）采用的方法和工具等。
               配置与配置项
               “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。
               为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。
               版本控制
               版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
               变更控制
               变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。
               配置审计
               配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。
               （1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。
               （2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。
               状态报告
               状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
 
       配置管理员
        配置管理员（Configuration Management Officer, CMO）负责在项目的整个生命周期中进行配置管理活动，包括：
        .编写配置管理计划。
        .建立和维护配置管理系统。
        .建立和维护配置库。
        .配置项识别。
        .建立和管理基线。
        .版本管理和配置控制。
        .配置状态报告。
        .配置审计。
        .发布管理和交付。
        .对项目成员进行配置管理培训。
 
       配置库
        配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多有关配置管理的问题，例如：
        .哪些客户已提取了某个特定的系统版本。
        .运行一个给定的系统版本需要什么硬件和系统软件。
        .一个系统到目前已生成了多少个版本，何时生成的。
        .某一特定的构件变更，会影响系统的哪些版本。
        .一个特定的版本曾提出过哪几个变更请求。
        .一个特定的版本有多少已报告的错误。
        使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
        配置库一般可以分为如下三种类型：
        .开发库：也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。
        .受控库：也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。可在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
        .产品库：也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
        配置库的建库模式有两种，即按配置项类型建库和按开发任务建库，如下表所示。
        
        配置库的建库模式
 
       系统测试
        系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据，在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试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）检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用，还意味着使得应用程序使用的所有分布式组件和资源受到保护。
               文档测试
               文档测试是指对软件开发、测试和维护过程中产生的所有文档的测试，包括对需求规格分析说明书、详细设计报告、系统设计报告、用户手册以及与系统相关的一切文档的审阅和评测。例如，系统需求分析和系统设计说明书中的错误将直接导致编码的错误，用户手册作为软件的一部分，将直接影响用户对系统的使用效果。
               文档测试强调文档的表述应该清楚、准确，主要包含：
               .正确地按照文档描述的方法使用系统。
               .测试每一个提示和建议信息。
               .使用文档作为测试用例的来源。
               .测试每一个在线帮助的超链接。
               .测试每条语句。
               .测试文档中提供的每一个样例。
               .把缺陷写入缺陷跟踪库。
               .检查所有的错误信息。
   题号导航      2020年下半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第3题    在手机中做本题