logo资料库

软件质量保证过程 (SQA) 标准 软件测试.doc

发布时间：2022-06-09 发布人：admin 分类：说明书 资料大小：0.31M 资料格式：doc 举报 版权申诉
第1页 / 共15页
第2页 / 共15页
第3页 / 共15页
第4页 / 共15页
第5页 / 共15页
第6页 / 共15页
第7页 / 共15页
第8页 / 共15页
资料共15页，剩余部分请下载后查看
    软件质量保证(SQA)过程
    1.计划阶段
    2.需求分析阶段
    3.设计阶段
    4.编码阶段
    5.测试阶段
    6.系统交付和安装阶段
    软件质量保证(SQA)过程 软件质量保证过程作为一种独产的审查活动贯穿于整个软件开发过程.SQA 人员类似于 软件开发过程中的过程警察,其主要职责是:检查开发和管理活动是否与制定的过程策略、标 准和流程一致；检查工作产品是否遵循模板规定的内容和格式。此文档将从软件开发过程的 各个阶段来描述软件质量保证过程。 1. 计划阶段 目的和范围： 项目计划过程的目的是计划并执行一系列必要的活动，以便在不超出项目预算和日程安 排的前提下，将优质的产品交付给客户。项目计划过程适用于组织中的所有项目，但每个项 目可以根据各自的不同情况对该过程进行裁剪。 进入标准：  项目启动会议已经结束；  在项目的生命周期中，根据项目的跟踪结果，需要对项目计划进行修改和完善。 输入：  项目启动报告（PIN）；  项目提案书；  项目相关文档；  组织财富库中以往类似的经验文档。 退出标准： 项目计划已通过评审、批准并确立。 输出： 评审后的项目计划文档包括：  软件开发质量计划；  软件配置管理计划。 过程描述： 项目计划包含 3 个需要在项目中执行和管理的主要计划，如下：  软件项目管理计划；  软件项目质量管理计划；  软件配置管理计划。 软件项目管理计划涉及项目中所有与项目管理相关的问题（从项目开始到结束）。 软件项目质量管理计划涉及与质量相关的需求，这些需要在产品中实现，并保证用于构 筑产品的项目过程。由于质量是产品创建的一部分，所以将软件项目管理计划和软件项目质 量管理计划合成一个计划文档，称为软件开发质量计划。 软件配置管理计划用于管理与配置管理相关的需求，这些需求与工作产品和可交付产品 有关。该计划的目的在于：为执行软件工程相关活动提供依据，并在整个开发和维护过程中 对软件项目进行管理。 可以使用不同的检查表来制定软件开发质量计划和软件配置管理计划。如下每个计划都 将包含以下 3 点：
     目标；  执行方法；  当前状态。 前两点不会经常变更，但第三点则被认为会在执行跟踪时被修改。因此，前两点通常被 直接放到计划中，而第三点则以链接的方法放到计划中。 （1）制订软件开发质量计划 软件开发质量计划包括软件项目管理计划、软件项目质量管理计划。 ①制订软件项目管理计划 软件项目管理计划的主要内容包括基础设施计划，进度计划（包括各种类型的估算）、 风险管理计划、项目培训计划、执行计划、客户管理计划。  基础设施计划 基础设施计划包括项目开始执行前必须到位的所有需求，它需要解决以下问题：软件工 程需求、基础设施需求、角色和职责、内外部接口、过程需求、知识和技能需求。  进度计划 进度计划涉及制定合理可用的项目进度。 在制定项目进度时，需要进行下面的估算：规模（Size）、工作量（effort）。 项目进度需要描述以下内容：执行的活动、估算的人时、投入的人员、责任人和时间线、 里程碑事件的标识。  风险管理计划 风险管理包括：标识风险事件（与管理相关的风险、与执行相关的风险，与客户相关的 风险等）、评估风险并设定风险优先级、制订风险缓解和应急计划并跟踪该计划。  项目培训计划 根据项目及人员结构制订项目培训计划，包括业务领域知识、技术、工具等方面的培训 计划。  执行计划 项目执行计划包含了与执行当前项目关系最大的生命周期模型。该计划对组织级执行模 型进行了裁剪。项目生命周期模型通常包括：项目执行的阶段、各阶段的输入和输出、可交 付的产品、需要迭代（反复）的阶段。 ②制订软件项目质量管理计划 制订软件项目质量管理计划包含如下主要内容：  项目设定的质量标准；  同级评审计划：同级评审计划中描述了在不同的软件生命周期开发阶段，对不同的 工作产品所采用的同级评审类型；  测试计划：测试计划包括对可执行文件/模块或整个系统将要进行的各种测试。根 据项目测试过程来制定测试计划；  度量管理计划：通过裁剪组织级的度量过程来制定项目度量管理计划。  缺陷预防计划：管理、开发和测试人员互相配合制订缺陷预防计划，防止已识别的 缺陷再次发生；  过程改进计划：项目级过程改进的机会要记录到过程改进计划中。这些机会主要来 源于度量分析、缺陷预防分析和标识出的好的或可避免的实践。 （2）制订软件配置管理计划 软件配置管理计划主要包括以下内容：  软件配置管理计划组织；  角色和职责；
     开发/维护配置管理计划，包括可配置项的标识、命名约定、目录结构、访问控制、 变更管理、基线库创建、放入/提取（Check in/Check out）机制、版本控制；  产品配置管理，包括产品中部件的可跟踪性，产品的版本设定和发布、交付的配置 管理（标识出要交付的产品构成）、需求配置管理（需求基线的确定、产品版本与 划定基线的需求版本之间的关系）、配置审计。 验证： 同级评审人员和软件质量保证人员必须对项目计划进行评审，批准后项目才能付诸实 施。 配置控制： 项目经理保管所有项目计划文档。对所有项目计划文档都要进行配置管理。项目结束后， 所有的项目计划文档都要保存到组织财富库中，仍受配置控制。 QA 检查清单： QA 检查清单包括：  软件开发质量计划；  软件配置管理计划。 该阶段要确保制定了软件开发质量计划和软件配置管理计划。 2. 需求分析阶段 目的和范围： 需求说明和需求管理过程的目的是为了保证开发组在开发期间对项目目标和生产出最 后产品的目的有一个清晰的理解。软件需求规格说明书将作为产品测试和验证是否适合需要 的基础。对于需求的变更，它可能在开发项目期间的任何时间点发生，需求的变更将要影响 日程和承诺的变化，这些变化需要和客户所提出的要求相一致。 进入标准：  计划已经被批准，并且项目整体的基础设施是可用的；  软件的需求已经被需求收集小组捕获；  对已经形成了基线的软件需求规格说明书有变更的请求时。 输入：  软件的需求说明书；  变更需求的请求。 退出标准：  软件需求规格说明书已经经过评审并形成了基线；  对已经形成基线的软件需求的变更进行了处理；  形成基线的软件说明书已经经过客户批准；  验收标准已经完成；  所有评审的问题都已经解决。 输出：  经过批准并形成基线的软件需求规格说明书；  对受影响组件的重新估算文档；  验收测试标准和测试计划。 过程描述： 这个过程主要处理以下两种活动：需求说明和需求管理。 需求说明指的是需求过程中形成基线的主体，它是以后进一步的设计和测试的基础。另
    外，在软件开发过程中，会经常遇到由于客户又有新需求或开发组自身对项目有了更清楚的 理解或认识，要对需求进行变更。在对最初的需求说明书进行变更时，要用到需求管理过程。 （1）需求说明 需求说明过程主要包括以下任务：  执行需求分析  定义需求规格说明书  定义验收标准  评审说明书和验收标准。 ①执行需求分析 分析收集到的需求和在提案中可用的需求。这个任务要求需求说明书应该在完整性、一 致性、清晰性和可测试性上达到比较合理的程序。 ②定义需求说明书 基于对需求的分析编写软件需求规格说明书。这个文档应清晰记录以下内容：  目标和范围；  功能需求；  用户接口；  输入输出；  模块之间的接口；  性能需求；  特殊用户需求。 如果需求不清晰或模糊，就需要准备原型，通过评估原型来产生需求说明书。 ③定义验收标准 基于对以前步骤收集的需求规格说明书，建立测试标准，验证的解决方案。所有的需求 应该可能制定测试标准。这个测试标准将成为客户批准最终产品的依据，因此要求在制定客 户标准时要经常紧密的与客户进行交流沟通。 ④评审需求分析说明书和测试标准 因为是开发项目的基础，所以需求规格说明书和验收标准需要由项目组的同级人员进行 评审。 （2）需求管理 需求管理过程包括以下 6 个任务：  记录变更请求；  分析受到影响的组件；  估算需求变更成本；  重新估算所有产品的交付日期和时间；  评审受影响组件；  获得客户的批准。 ①记录变更请求； 形成基线的需求说明书的变更可能是由客户提出的，也可能是由于设计或编码阶段开发 人员根据一些限制或优化而提出的。所有需求变更必须经过客户的批准，并且必须是可行的。 任务需求变更可以由组织自己定义开始时间，并且所有需求变更需要记录到变更登记表中。 ②分析受到影响的组件； 任何经过批准的变更需要在整个项目组范围内进行受影响组件分析。 ③估算需求变更成本； 项目成本与需求变更有关。任何规模的变更对于成本来讲都是一种损耗。如果一个受影
    响组件是非常重要的，那么可行性需要重新进行成本估算。 ④重新估算所有产品的交付日期和时间； 如果没有考虑有效的缓冲，成本的变化可能会影响整个项目的交付时间。在交付时间内 的任何实质的变更都需要再同用户商议决定。 ⑤评审受影响组件； 在这个步骤中所有相关的受影响组件需要进行评审，项目负责人根执行此项任务。 ⑥获得客户的批准。 这个过程的最后一项任务是获得客户的签字。客户应该同意已经形成基线的软件需求说 明书、验收标准和已记录的受影响组件的变更。 验证：  项目经理要定期的检查需求规格说明书和项目需求管理的各个方面；  软件质量保证人员要定期的对需求分析过程执行独立的评估。 配置控制：  软件需求规格说明书需要严格的配置控制；  所有的变更请求需要被管理和控制；  用于跟踪的度量文档需要管理和控制。 QA 检查清单： 质量保证检查清单包括：  软件需求规格说明书；  变更需求跟踪记录；  验收测试标准与测试计划。 该阶段要确保客户提出的需求是可行的，确保客户了解自己提出的需求的含义，并且这 个需求能够真正达到他们的目标，确保开发人员和客户对于需求没有误解或误会，确保按照 需求实现的软件系统能够满足客户提出的需求。 3. 设计阶段 目的和范围： 本过程所关注的是把需求（用户需求说明书和软件需求规格说明书）转变成为如何实现 这些需求的描述。主要包括以下两个阶段：  概要设计；  详细设计。 软件设计过程主要包括以下活动：  体系结构设计；  运算方法设计；  类/函数/数据结构设计；  建立测试标准。 进入标准：  产品需求已经形成了基线；  需要设计解决方案；  新的或修改的需求需要改变当前的设计。 输入：  形成基线的需求（用户需求说明书和软件需求规格说明书）。 退出标准：
     设计文档已经评审并形成基线；  测试标准、测试计划可行。 输出：  概要设计文档；  详细设计文档；  测试计划；  项目标准；  选择的工具。 过程描述： 设计过程包括概要设计和详细设计两个阶段。 （1）概要设计 这个阶段包括以下的任务：结构设计、逻辑设计、项目标准定义、系统/集成测试计划 的创建，并要进行同级评审。概要设计模板、系统/集成测试计划模板在本阶段将被使用。 ①结构设计 在这个步骤中，完成软件解决方案的基础布局设计。继软件布局设计之后，应用程序被 分解成基础模块/组件，目的是为了实现在模块内的高聚合和模块之间的松耦合。通常情况 下，模块的划分是基于概要设计中的功能需求而定的。 ②运算方法设计 在这个步骤中，完成软件系统解决方案与应用程序的转换逻辑设计。设计模块接口和应 用需求的主要逻辑。在决定通用算法之前，通常需要一些模型。 ③定义项目标准 在这个步骤中，所有的项目开发标准被定义。详细设计/编码标准要同实际执行的一致。 制定标准时还要考虑标准将来的扩展性、灵活性和方便性。 ④创建系统/集成测试计划 基于对概要设计的理解，系统和集成测试计划被制定出来。验证最后生产的产品达到了 设计要求，通常采用基于黑盒的功能或性能检查。 ⑤评审设计 作为所有开发阶段基础的概要设计是非常重要的，因此需要进行同级评审，由能力强的 高级软件工程师组成的同级评审小组，以确保完成了合适的软件解决方案设计。 （2）详细设计 这个阶段包括以下任务：详细设计和准备单元测试计划。在这个阶段，需要使用详细设 计模板和单元测试计划模板。 ①类/函数/数据结构设计 根据项目所采用的设计方法（软件结构化设计方法/面向对象设计方法）进行类、函数 及数据结构的设计。所有的用户界面、状态转换和相关的数据库详细描述在本阶段被建立。 ②创建单元测试计划 测试计划应该包括要被测试的每一个模块的每一个元素，例如：  与需求的完整一致性；  与其它元素的一致性；  在性能上的要求。 单元/功能测试采用完全透明的白盒/玻璃盒测试方法，对于测试者来讲，实际运行的代 码是可见的。 ③评审详细设计 详细设计阶段的输出是代码编写工作的基础，是非常重要的，因此需要在项目组中很好
    的进行评审。评审小组负责评审和清除那些在详细设计中与采用的方法不一致的问题。 （3）选择有用工具 在详细设计完成之后，系统在解决方案已经非常清晰。这时，项目组需要选择用来提高 软件质量的工具。这些工具要产生以下作用：  提高质量；  提高生产力；  缩短开发周期。 验证：  项目管理者分析概要设计满足需求的程序；  项目管理者不定时的监督详细设计说明书的创建工作；  项目管理者通过定期的分析在设计阶段收集的数据来验证设计过程执行的有效性；  质量保证（QA）人员通过验证产生的工作产品和做独立的抽样检查来验证产品的有 效性；  质量保证（QA）人员通过分析项目的度量数据和对过程的走查来验证设计过程的效 性。 配置控制：  所有的概要设计文档、详细设计文档和系统/集成测试计划需要进行严格的配置控 制；  跟踪的度量数据需要进行管理和控制。 质量保证（QA）检查清单： 质量保证（QA）检查清单包括：  概要设计文档；  详细设计文档；  测试计划（系统/集成/单元）；  项目标准。 在概要设计阶段，要确保规格定义能够完全符合、支持和覆盖前面描述的系统需求；可 以采用建立需求跟踪文档和需求实现矩阵的方式，确保规格定义满足系统需求的性能、可维 护性、灵活性的要求；确保规格定义是可以测试的，并且建立了测试策略；确保建立了可行 的、包含评审活动的开发进度表；确保建立了正式的变更控制流程。 在详细设计阶段，要确保建立了设计标准，并且按照该标准进行设计；确保设计变更被 正确跟踪、控制、文档化；确保按照计划进行设计评审；确保设计按照评审准则评审通过并 被正式批准之前，没有开始正式编码。 4. 编码阶段 目的和范围： 编码过程的目的是为了实现详细设计中各个模块的功能，能够使用户要求的实际业务流 程通过代码的方式被计算机识别并转化为计算机程序。 编码过程就是用具体的数据结构来定义对象的属性，用具体的语言来实现业务流程所表 示的算法。在对象设计阶段形成的对象类和关系最后被转换成特定的程序设计语言、数据库 或者硬件的实现。 进入标准：  设计文档已经形成基线；  详细设计变更编写完毕并通过评审，并且代码需要变更时；
     对于维护项目，维护需求分析已经形成基线，可进行代码的变更；  用于编码的测试标准已经制定。 输入：  详细设计文档；  特定项目的编码规范；  相关的软、硬件环境；  维护分析文档；  测试计划。 退出标准： 详细设计中所有模块的功能全部被实现，并通过自我代码审查，编译通过。 输出：  已完成的、需要进行测试的代码；  代码编写规范的更改建议。 过程描述： 编码过程是把详细设计中的各个模块功能转化为计算机可识别代码的过程，因此程序员 在进行编码时，一定要仔细认真，切勿有半点疏忽。编码过程通常情况下占整个项目开发时 间的 20%左右，为了代码达到高质量、高标准，代码编写过程一定要合理规范。编码过程主 要包括以下几项活动：  制定编码计划；  认真阅读开发规范；  编码准备；  专家指导，并填写疑问或问题表；  理解详细设计书；  编写代码；  自我审查；  提交代码；  更改代码。 编码过程流程如下图所示。
    分享到：
    赞 收藏

    相关推荐

    资料库

    课程资源

    共收录17145份资料，累计13个分类，关注成员有19位，主要包括：PHP,网络管理,网页制作,Java,.Net,数据库,3G/移动开发,C/C++,游戏开发,嵌入式,讲义,软件测试,专业指导

    热门标签

    PHP 网络管理 网页制作 Java .Net 数据库 3G/移动开发 C/C++ 游戏开发 嵌入式 讲义 软件测试 专业指导

    最新资料