软件质量保证过程SQA.docx

上传人:b****3 文档编号:11181488 上传时间:2023-05-29 格式:DOCX 页数:25 大小:88.42KB
下载 相关 举报
软件质量保证过程SQA.docx_第1页
第1页 / 共25页
软件质量保证过程SQA.docx_第2页
第2页 / 共25页
软件质量保证过程SQA.docx_第3页
第3页 / 共25页
软件质量保证过程SQA.docx_第4页
第4页 / 共25页
软件质量保证过程SQA.docx_第5页
第5页 / 共25页
软件质量保证过程SQA.docx_第6页
第6页 / 共25页
软件质量保证过程SQA.docx_第7页
第7页 / 共25页
软件质量保证过程SQA.docx_第8页
第8页 / 共25页
软件质量保证过程SQA.docx_第9页
第9页 / 共25页
软件质量保证过程SQA.docx_第10页
第10页 / 共25页
软件质量保证过程SQA.docx_第11页
第11页 / 共25页
软件质量保证过程SQA.docx_第12页
第12页 / 共25页
软件质量保证过程SQA.docx_第13页
第13页 / 共25页
软件质量保证过程SQA.docx_第14页
第14页 / 共25页
软件质量保证过程SQA.docx_第15页
第15页 / 共25页
软件质量保证过程SQA.docx_第16页
第16页 / 共25页
软件质量保证过程SQA.docx_第17页
第17页 / 共25页
软件质量保证过程SQA.docx_第18页
第18页 / 共25页
软件质量保证过程SQA.docx_第19页
第19页 / 共25页
软件质量保证过程SQA.docx_第20页
第20页 / 共25页
亲,该文档总共25页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

软件质量保证过程SQA.docx

《软件质量保证过程SQA.docx》由会员分享,可在线阅读,更多相关《软件质量保证过程SQA.docx(25页珍藏版)》请在冰点文库上搜索。

软件质量保证过程SQA.docx

软件质量保证过程SQA

软件质量保证过程之阿布丰王创作

时间:

二O二一年七月二十九日

软件质量保证过程作为一种独产的审查活动贯穿于整个软件开发过程.质量控制人员类似于软件开发过程中的过程警察,其主要职责是:

检查开发和管理活动是否与制定的过程战略、标准和流程一致;检查工作产物是否遵循模板规定的内容和格式.此文档从软件开发过程的各个阶段来描述软件质量保证过程.

1.计划阶段

目的和范围:

项目计划过程的目的是计划并执行一系列需要的活动,以便在不超越项目预算和日程安插的前提下,将优质的产物交付给客户.项目计划过程适用于公司的所有项目,但每个项目可以根据各自的分歧情况对该过程进行裁剪.

进入标准:

⏹项目启动会议已经结束;

⏹在项目的生命周期中,根据项目的跟踪结果,需要对项目计划进行修改和完善.

输入:

⏹项目启动陈说;

⏹项目提案书;

⏹项目相关文档;

⏹组织财富库中以往类似的经验文档.

退出标准:

项目计划已通过评审、批准并确立.

输出:

评审后的项目计划文档包括:

⏹软件开发质量计划;

⏹软件配置管理计划.

过程描述:

项目计划包括3个需要在项目中执行和管理的主要计划,如下:

⏹软件项目管理计划;

⏹软件项目质量管理计划;

⏹软件配置管理计划.

软件项目管理计划涉及项目中所有与项目管理相关的问题(从项目开始到结束).

软件项目质量管理计划涉及与质量相关的需求,这些需要在产物中实现,并保证用于构筑产物的项目过程.由于质量是产物创立的一部份,所以将软件项目管理计划和软件项目质量管理计划合成一个计划文档,称为软件开发质量计划.

软件配置管理计划用于管理与配置管理相关的需求,这些需求与工作产物和可交付产物有关.该计划的目的在于:

为执行软件工程相关活动提供依据,并在整个开发和维护过程中对软件项目进行管理.

可以使用分歧的检查表来制定软件开发质量计划和软件配置管理计划.如下每个计划都将包括以下3点:

⏹目标;

⏹执行方法;

⏹以后状态.

前两点不会经常变动,但第三点则被认为会在执行跟踪时被修改.因此,前两点通常被直接放到计划中,而第三点则以链接的方法放到计划中.

(1)制订软件开发质量计划

软件开发质量计划包括软件项目管理计划、软件项目质量管理计划.

①制订软件项目管理计划

软件项目管理计划的主要内容包括基础设施计划,进度计划(包括各种类型的估算)、风险管理计划、项目培训计划、执行计划、客户管理计划.

⏹基础设施计划

基础设施计划包括项目开始执行前必需到位的所有需求,它需要解决以下问题:

软件工程需求、基础设施需求、角色和职责、内外部接口、过程需求、知识和技能需求.

⏹进度计划

进度计划涉及制定合理可用的项目进度.

在制定项目进度时,需要进行下面的估算:

规模(Size)、工作量(effort).

项目进度需要描述以下内容:

执行的活动、估算的人时、投入的人员、责任人和时间线、里程碑事件的标识.

⏹风险管理计划

风险管理包括:

标识风险事件(与管理相关的风险、与执行相关的风险,与客户相关的风险等)、评估风险并设定风险优先级、制订风险缓解和应急计划并跟踪该计划.

⏹项目培训计划

根据项目及人员结构制订项目培训计划,包括业务领域知识、技术、工具等方面的培训计划.

⏹执行计划

项目执行计划包括了与执行以后项目关系最年夜的生命周期模型.该计划对组织级执行模型进行了裁剪.项目生命周期模型通常包括:

项目执行的阶段、各阶段的输入和输出、可交付的产物、需要迭代(反复)的阶段.

②制订软件项目质量管理计划

制订软件项目质量管理计划包括如下主要内容:

⏹项目设定的质量标准;

⏹同级评审计划:

同级评审计划中描述了在分歧的软件生命周期开发阶段,对分歧的工作产物所采纳的同级评审类型;

⏹测试计划:

测试计划包括对可执行文件/模块或整个系统将要进行的各种测试.根据项目测试过程来制定测试计划;

⏹怀抱管理计划:

通过裁剪组织级的怀抱过程来制定项目怀抱管理计划.

⏹缺陷预防计划:

管理、开发和测试人员互相配合制订缺陷预防计划,防止已识另外缺陷再次发生;

⏹过程改进计划:

项目级过程改进的机会要记录到过程改进计划中.这些机会主要来源于怀抱分析、缺陷预防分析和标识出的好的或可防止的实践.

(2)制订软件配置管理计划

软件配置管理计划主要包括以下内容:

⏹软件配置管理计划组织;

⏹角色和职责;

⏹开发/维护配置管理计划,包括可配置项的标识、命名约定、目录结构、访问控制、变动管理、基线库创立、放入/提取(Checkin/Checkout)机制、版本控制;

⏹产物配置管理,包括产物中部件的可跟踪性,产物的版本设定和发布、交付的配置管理(标识出要交付的产物构成)、需求配置管理(需求基线简直定、产物版本与划定基线的需求版本之间的关系)、配置审计.

验证:

同级评审人员和软件质量保证人员必需对项目计划进行评审,批准后项目才华付诸实施.

配置控制:

项目经理保管所有项目计划文档.对所有项目计划文档都要进行配置管理.项目结束后,所有的项目计划文档都要保管到组织财富库中,仍受配置控制.

QA检查清单:

QA检查清单包括:

⏹软件开发质量计划;

⏹软件配置管理计划.

该阶段要确保制定了软件开发质量计划和软件配置管理计划.

2.需求分析阶段

目的和范围:

需求说明和需求管理过程的目的是为了保证开发组在开发期间对项目目标和生产出最后产物的目的有一个清晰的理解.软件需求规格说明书将作为产物测试和验证是否适合需要的基础.对需求的变动,它可能在开发项目期间的任何时间点发生,需求的变动将要影响日程和许诺的变动,这些变动需要和客户所提出的要求相一致.

进入标准:

⏹计划已经被批准,而且项目整体的基础设施是可用的;

⏹软件的需求已经被需求收集小组捕捉;

⏹对已经形成了基线的软件需求规格说明书有变动的请求时.

输入:

⏹软件的需求说明书;

⏹变动需求的请求.

退出标准:

⏹软件需求规格说明书已经经过评审并形成了基线;

⏹对已经形成基线的软件需求的变动进行了处置;

⏹形成基线的软件说明书已经经过客户批准;

⏹验收标准已经完成;

⏹所有评审的问题都已经解决.

输出:

⏹经过批准并形成基线的软件需求规格说明书;

⏹对受影响组件的重新估算文档;

⏹验收测试标准和测试计划.

过程描述:

这个过程主要处置以下两种活动:

需求说明和需求管理.

需求说明指的是需求过程中形成基线的主体,它是以后进一步的设计和测试的基础.另外,在软件开发过程中,会经常遇到由于客户又有新需求或开发组自身对项目有了更清楚的理解或认识,要对需求进行变动.在对最初的需求说明书进行变动时,要用到需求管理过程.

(1)需求说明

需求说明过程主要包括以下任务:

⏹执行需求分析

⏹界说需求规格说明书

⏹界说验收标准

⏹评审说明书和验收标准.

①执行需求分析

分析收集到的需求和在提案中可用的需求.这个任务要求需求说明书应该在完整性、一致性、清晰性和可测试性上到达比力合理的法式.

②界说需求说明书

基于对需求的分析编写软件需求规格说明书.这个文档应清晰记录以下内容:

⏹目标和范围;

⏹功能需求;

⏹用户接口;

⏹输入输出;

⏹模块之间的接口;

⏹性能需求;

⏹特殊用户需求.

如果需求不清晰或模糊,就需要准备原型,通过评估原型来发生需求说明书.

③界说验收标准

基于对以前步伐收集的需求规格说明书,建立测试标准,验证的解决方案.所有的需求应该可能制定测试标准.这个测试标准将成为客户批准最终产物的依据,因此要求在制定客户标准时要经常紧密的与客户进行交流沟通.

④评审需求分析说明书和测试标准

因为是开发项目的基础,所以需求规格说明书和验收标准需要由项目组的同级人员进行评审.

(2)需求管理

需求管理过程包括以下6个任务:

⏹记录变动请求;

⏹分析受到影响的组件;

⏹估算需求变动本钱;

⏹重新估算所有产物的交付日期和时间;

⏹评审受影响组件;

⏹获得客户的批准.

①记录变动请求;

形成基线的需求说明书的变动可能是由客户提出的,也可能是由于设计或编码阶段开发人员根据一些限制或优化而提出的.所有需求变动必需经过客户的批准,而且必需是可行的.任务需求变动可以由组织自己界说开始时间,而且所有需求变动需要记录到变动挂号表中.

②分析受到影响的组件;

任何经过批准的变动需要在整个项目组范围内进行受影响组件分析.

③估算需求变动本钱;

项目本钱与需求变动有关.任何规模的变动对成原本讲都是一种损耗.如果一个受影响组件是非常重要的,那么可行性需要重新进行本钱估算.

④重新估算所有产物的交付日期和时间;

如果没有考虑有效的缓冲,本钱的变动可能会影响整个项目的交付时间.在交付时间内的任何实质的变动都需要再同用户商议决定.

⑤评审受影响组件;

在这个步伐中所有相关的受影响组件需要进行评审,项目负责人根执行此项任务.

⑥获得客户的批准.

这个过程的最后一项任务是获得客户的签字.客户应该同意已经形成基线的软件需求说明书、验收标准和已记录的受影响组件的变动.

验证:

⏹项目经理要按期的检查需求规格说明书和项目需求管理的各个方面;

⏹软件质量保证人员要按期的对需求分析过程执行自力的评估.

配置控制:

⏹软件需求规格说明书需要严格的配置控制;

⏹所有的变动请求需要被管理和控制;

⏹用于跟踪的怀抱文档需要管理和控制.

QA检查清单:

质量保证检查清单包括:

⏹软件需求规格说明书;

⏹变动需求跟踪记录;

⏹验收测试标准与测试计划.

该阶段要确保客户提出的需求是可行的,确保客户了解自己提出的需求的含义,而且这个需求能够真正到达他们的目标,确保开发人员和客户对需求没有误解或误会,确保依照需求实现的软件系统能够满足客户提出的需求.

3.设计阶段

目的和范围:

本过程所关注的是把需求(用户需求说明书和软件需求规格说明书)转酿成为如何实现这些需求的描述.主要包括以下两个阶段:

⏹概要设计;

⏹详细设计.

软件设计过程主要包括以下活动:

⏹体系结构设计;

⏹运算方法设计;

⏹类/函数/数据结构设计;

⏹建立测试标准.

进入标准:

⏹产物需求已经形成了基线;

⏹需要设计解决方案;

⏹新的或修改的需求需要改变以后的设计.

输入:

⏹形成基线的需求(用户需求说明书和软件需求规格说明书).

退出标准:

⏹设计文档已经评审并形成基线;

⏹测试标准、测试计划可行.

输出:

⏹概要设计文档;

⏹详细设计文档;

⏹测试计划;

⏹项目标准;

⏹选择的工具.

过程描述:

设计过程包括概要设计和详细设计两个阶段.

(1)概要设计

这个阶段包括以下的任务:

结构设计、逻辑设计、项目标准界说、系统/集成测试计划的创立,并要进行同级评审.概要设计模板、系统/集成测试计划模板在本阶段将被使用.

①结构设计

在这个步伐中,完成软件解决方案的基础规划设计.继软件规划设计之后,应用法式被分解成基础模块/组件,目的是为了实现在模块内的高聚合和模块之间的松耦合.通常情况下,模块的划分是基于概要设计中的功能需求而定的.

②运算方法设计

在这个步伐中,完成软件系统解决方案与应用法式的转换逻辑设计.设计模块接口和应用需求的主要逻辑.在决定通用算法之前,通常需要一些模型.

③界说项目标准

在这个步伐中,所有的项目开发标准被界说.详细设计/编码标准要同实际执行的一致.制定标准时还要考虑标准将来的扩展性、灵活性和方便性.

④创立系统/集成测试计划

基于对概要设计的理解,系统和集成测试计划被制定出来.验证最后生产的产物到达了设计要求,通常采纳基于黑盒的功能或性能检查.

⑤评审设计

作为所有开发阶段基础的概要设计是非常重要的,因此需要进行同级评审,由能力强的高级软件工程师组成的同级评审小组,以确保完成了合适的软件解决方案设计.

(2)详细设计

这个阶段包括以下任务:

详细设计和准备单位测试计划.在这个阶段,需要使用详细设计模板和单位测试计划模板.

①类/函数/数据结构设计

根据项目所采纳的设计方法(软件结构化设计方法/面向对象设计方法)进行类、函数及数据结构的设计.所有的用户界面、状态转换和相关的数据库详细描述在本阶段被建立.

②创立单位测试计划

测试计划应该包括要被测试的每一个模块的每一个元素,例如:

⏹与需求的完整一致性;

⏹与其它元素的一致性;

⏹在性能上的要求.

单位/功能测试采纳完全透明的白盒/玻璃盒测试方法,对测试者来讲,实际运行的代码是可见的.

③评审详细设计

详细设计阶段的输出是代码编写工作的基础,是非常重要的,因此需要在项目组中很好的进行评审.评审小组负责评审和清除那些在详细设计中与采纳的方法纷歧致的问题.

(3)选择有用工具

在详细设计完成之后,系统在解决方案已经非常清晰.这时,项目组需要选择用来提高软件质量的工具.这些工具要发生以下作用:

⏹提高质量;

⏹提高生产力;

⏹缩短开发周期.

验证:

⏹项目管理者分析概要设计满足需求的法式;

⏹项目管理者不按时的监督详细设计说明书的创立工作;

⏹项目管理者通过按期的分析在设计阶段收集的数据来验证设计过程执行的有效性;

⏹质量保证(QA)人员通过验证发生的工作产物和做自力的抽样检查来验证产物的有效性;

⏹质量保证(QA)人员通过分析项目的怀抱数据和对过程的走查来验证设计过程的效性.

配置控制:

⏹所有的概要设计文档、详细设计文档和系统/集成测试计划需要进行严格的配置控制;

⏹跟踪的怀抱数据需要进行管理和控制.

质量保证(QA)检查清单:

质量保证(QA)检查清单包括:

⏹概要设计文档;

⏹详细设计文档;

⏹测试计划(系统/集成/单位);

⏹项目标准.

在概要设计阶段,要确保规格界说能够完全符合、支持和覆盖前面描述的系统需求;可以采纳建立需求跟踪文档和需求实现矩阵的方式,确保规格界说满足系统需求的性能、可维护性、灵活性的要求;确保规格界说是可以测试的,而且建立了测试战略;确保建立了可行的、包括评审活动的开发进度表;确保建立了正式的变动控制流程.

在详细设计阶段,要确保建立了设计标准,而且依照该标准进行设计;确保设计变动被正确跟踪、控制、文档化;确保依照计划进行设计评审;确保设计依照评审准则评审通过并被正式批准之前,没有开始正式编码.

4.编码阶段

目的和范围:

编码过程的目的是为了实现详细设计中各个模块的功能,能够使用户要求的实际业务流程通过代码的方式被计算机识别并转化为计算机法式.

编码过程就是用具体的数据结构来界说对象的属性,用具体的语言来实现业务流程所暗示的算法.在对象设计阶段形成的对象类和关系最后被转换成特定的法式设计语言、数据库或者硬件的实现.

进入标准:

⏹设计文档已经形成基线;

⏹详细设计变动编写完毕并通过评审,而且代码需要变动时;

⏹对维护项目,维护需求分析已经形成基线,可进行代码的变动;

⏹用于编码的测试标准已经制定.

输入:

⏹详细设计文档;

⏹特定项目的编码规范;

⏹相关的软、硬件环境;

⏹维护分析文档;

⏹测试计划.

退出标准:

详细设计中所有模块的功能全部被实现,并通过自我代码审查,编译通过.

输出:

⏹已完成的、需要进行测试的代码;

⏹代码编写规范的更改建议.

过程描述:

编码过程是把详细设计中的各个模块功能转化为计算机可识别代码的过程,因此法式员在进行编码时,一定要仔细认真,切勿有半点疏忽.编码过程通常情况下占整个项目开发时间的20%左右,为了代码到达高质量、高标准,代码编写过程一定要合理规范.编码过程主要包括以下几项活动:

⏹制定编码计划;

⏹认真阅读开发规范;

⏹编码准备;

⏹专家指导,并填写疑问或问题表;

⏹理解详细设计书;

⏹编写代码;

⏹自我审查;

⏹提交代码;

⏹更改代码.

编码过程流程如下图所示.

(1)制定编码计划

在编码之前一周,项目经理要根据详细设计中的模块划分情况制定编码计划.编码计划的主要内容如下.

①本次编码的目的

在制定编码计划时,必需要明确编码目的.

②编码人员组成

在编码之前,要确定本次编码的人员组成:

选择编码人员时要考虑以下几点:

责任心、技术能力、服从意识、努力法式、编码效率、编码质量.

③编码任务分配

在编码之前,一定要为每个编码人员划分好自己所负责的模块,而且要规定各个模块的编码开始,结束日期.

(2)认真阅读开发规范

为了实现编码的规范统一,需要制定编码规范.有的项目,客户也会提供一些开发规范用来对本次编码进行约束.编码人员在编写代码之前一定要理解并掌握相关编码规范的所有内容.这样有助于以后编码工作的规范统一.

如果本次编码采纳的是公司自己的开发规范,编码人员在阅读的过程中,如果发现编码规范有缺乏或分歧理之处,可以编写开发规范建议书提交给项目经理,项目经理再和软件质量保证人员取得联系以决定是否要对目前的编码规范进行更改.

(3)编码准备

在进行编码之前还要进行一些相关的准备.

①软硬件环境配置:

包括编码工具、配置管理工具、数据库和一些需要的辅助工具.

②了解法式设计语言的特性,选择良好的法式设计风格:

法式设计风格是法式设计质量的一个重要方面,具有好的设计风格的法式更容易阅读和理解.

(4)理解详细设计书

由于项目模块功能的复杂性,即使再详细的设计也会有表达不够准确之处,因此在编写代码之前,一定要把每个模块的详细设计思路弄清楚.如果编码人员在理解详细设计时有疑惑,一定要询问详细设计人员.为了保证编码人员对详细设计的理解的正确性,采纳以下方法:

①详细设计同级评审时,让编码人员介入;

②让编码人员对详细设计进行讲解;

③让编码人员根据自己的理解画出流程图,由详细设计者确认.

如果编码人员在理解详细设计书的过程中存在疑问,应填写详细设计疑问列表提交给项目经理或详细设计人员.

(5)专家指导

在编码之前或编码过程中,为了保证编码工作的顺利进行以及代码质量,项目经理要根据目前编码人员的技术能力或开发进度情况邀请本项目组内部或外部专家对编码人员进行指导.指导的内容主要包括以下两方面的内容.

①对本次编码有关的业务进行指导:

对编码人员进行业务上的指导,有助于编码人员对详细设计的理解.

②对技术进行指导:

通过对编码人员的技术指导,可以解答编码人员在技术上的一些疑问.

(6)编写代码

在很多的软件开发中,客户为了便于法式的可维护性,往往会对法式代码编写过程做出一些规定,如变量的命名规则、书写规范和公共处置等,所以这就要求编码人员要熟悉这些要求和规范,并严格的遵守这些规范,如果客户没有规定,就要依照公司的规定执行.

①画出法式的流程图

法式的流程图又称法式框图,用来描述软件设计,是历史最长、使用最广泛的方法.在编码之前,一定要先画好法式的流程图,这对一个复杂的法式来说是非常需要的,这样做了以后,可以使你在编码阶段到达事半功倍的效果,而且对代码的正确性和质量都是一个很好的保证.

②代码的模块化

模块化是把系统分割成能完成自力功能的模块代码,明确规定各个模块代码及其输入输出规格,使模块代码的接口不会发生混乱.

③法式的注解

法式的注解对法式的阅读与理解起着重要的作用.注解主要分两部份.

法式块头的注解,主要是模块功能的说明、输入输出变量的说明、算法的说明、法式员姓名和法式完成以及变动的日期列表.这些主要是满足管理者的需要,管理者易于掌握哪些法式是由哪个编码人员负责的.

法式内部的注解,对法式中的一些难以理解的语句以上注释,以使阅读者容易理解设计者的意图,易于理解法式.

这样的法式具有很强的可读性和可维护性.

④数据类型/变量说明

⏹数据说明的次第应标准化,如按数据类型或者数据结构来确定命据说明的次第,次第的规则在数据字典中加以说明,以便在测试调试阶段和维护阶段可以方便的查找数据说明的情况;

⏹当对在同一个语句中的多个变量加以说明时,应按英文字母的顺序排列;

⏹在使用一个复杂的数据结构时,最好加注释语句;

⏹变量说明不要遗漏,变量的类型、长度、存储及其初始化要正确.

⑤语句构造

⏹不要为了节省空间把多个语句写在同一行;

⏹尽量防止复杂的条件;

⏹对多分支语句,应该把呈现可能性年夜的情况放在前面,把较少呈现的分支放在后面,这样可以加快运算时间;

⏹防止年夜量使用循环嵌套语句和条件嵌套语句;

⏹利用括号使逻辑表达式或算术表达式的运算次第清晰直观;

⏹每个循环要有终止条件,不要呈现死循环,也要防止不成能被执行的循环.

⑥法式效率

法式效率主要指处置工作时间和内存容量这两方面的利用率,在法式满足了正确性、可理解性、可测试性和可维护性的基础上,提高法式的效率也是非常需要的.

在编码过程中,一定要严格依照规定的开发规范进行编码,如果没有依照编码规范进行编码,再好的法式代码也不能被接受.另外,在编写代码时,如果认为开发规范有分歧理或有待弥补之处,应该填写开发规范建议书提交给项目经理;如果发现详细设计中有问题或对详细设计发生疑问,应该填写详细设计疑问列表并提交给项目经理.

(7)代码审查

在编码过程中,每个模块或法式的自我审查的关键环节是绝对不能缺少的.无论何等好的编码人员编写的代码,城市或多或少的存在缺陷,从而影响法式的运行.有的缺陷可以在很短的时间内流露出来;有的缺陷需要很长的时间才华显现出来.因此在代码审查过程中,一定要仔细认真,不要遗漏某个条件.编码人员切勿对自己编写的代码过于自信而不去自我审查.

在进行代码审查过程中,其实不是盲目地进行审查.而是要依照代码审查列表中的内容进行审查.审查之后还要把自己审查的内容以及发现的问题记录到代码审查记录中.代码审查记录不作为考核个人的依据.通过代码审查记录,管理人员可以掌握每个编码人员的代码审查工作情况以及自我审查的质量效率.

如果是比力重要的代码(如重要的算法、复杂的SQL法式段、要求性能比力高的模块等),可以让经验丰富的设计人员或编码人员来复查或进行同级评审.

(8)代码测试

为了进一步保证代码的正确性和合理性,编码人员还要对自己编写的代码进行测试.代码测试的依据是详细设计过程中的单位测试计划书.编码人员依照测试计划书中所提供的每个测试项目的测试用例进行测试.本次测试只是编码人员对自己所编写的代码进行自我测试,测试主要采纳白盒与黑盒结合的方法.在代码测试过程中,应该填写代码测试记录.

(9)提交测试

编码人员对自己编写的代码审查完毕,并认为代码不会有任何问题,就可以把代码提交给相应的测试人员.在提交代码时一定要注意自己所提交的代码是最新的版本.

(10)更改代码

更改代码的情况可以分为两种:

①在测试中发现代码有误或者逻辑分歧理.呈现这种情况的主要原因可能有两种:

一是编码人员自己的毛病而造成的缺陷;二是在需求、设计阶段的毛病没有被查出,被带到编码阶段而造成的缺陷.

②由于需求和设计的变动引起的代码变动.

在变动代码的过程中一定要注意对代码的版本管理.

验证:

⏹验证编码的规范性;

⏹验证是否进行了自我审查;

⏹验证代码的一致性和可跟踪性;

⏹通过测试验证代码的正确、合理性;

⏹验证每个编码人员的工作能力.

配置控制:

⏹通过相应的配置管理工具对分歧版本的代码进行管理;

⏹对编码规范进行管理;

⏹对项目开发质量计划进行管理.

QA检查清单:

⏹编码计划;

⏹开发规范建议书;

⏹详细设计疑问列表;

⏹代码审查检查列表;

⏹代码审查记录;

⏹代码测试记录.

该阶段要确保建立了编码规范、文档格式标准,而且依照该标准进行编码;确保代码被正确地测试和集成,代码的修改符合变动控制和版本控制流程;确保依照进度计划编写代码;确保依照进度计划进行代码评审.

5.测试阶段

目的

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 工程科技 > 信息与通信

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2