软件测试流程优化方案_第1页
软件测试流程优化方案_第2页
软件测试流程优化方案_第3页
软件测试流程优化方案_第4页
软件测试流程优化方案_第5页
已阅读5页,还剩19页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测评过程能力提高方案

1测评过程能力调研

方案制定前需对企业既有测试流程及管理工具开展调研工作,对企业测评过

程能力现实状况进行评估。现实状况H勺评估将从软件研发过程、软件测评过程、

及测试有关支撑过程(质量管理、配置管理等),以及软件测评团体、研发平台

及测试管理工具等方面,深入调研,并进行诊断。

测评过程能力需要通过项目测评过程来体现,其能力的提高需要在平时每件

工作当中不停积累,也需要测评团体中每位组员日勺努力,单单靠几种人不也许提

高一种团体日勺测评过程能力。因此汇报将着重对软件测评团体的I既有组员状态进

行评估,并对测评团体建设提出提议。在后续培训课程设计和实行上,也将针对

性进行安排,培训实行计划将充足考虑现实状况、客户目H勺,并力争兼顾个人意

愿。

测评过程能力提高课程将针面对全员开展,针对人员包括如下类型:系统应

用软件开发人员、嵌入式软件开发人员、系统应月软件测试人员、嵌入式软件测

试人员。通过本项目的详细实行,将会形成一套比较合理的软件测试体系和制度,

不仅让企业获得一定技术过程能力上日勺提高,更具有良好后续日勺自我提高平台。

在以上分析日勺基础上,征询团体将在对顾客现场深入调研、诊断其软件测评

流程、管理工具现实状况及综合需求,结合实际及软件测评专业发展日勺需要,出

具“软件测评现实状况评估及改善提议汇报:

1.调研对象

调研是现实状况评估的基础,而确定调研对象则是调研活动日勺基础。内部调

研将分别面向开发人员、测试人员、项目管理人员、配置管理人员、质量保证人

员等,从如下三个方面开展:

•软件测试过程能力:包括测试体系制度、测试质量管理、测试配置管理

等;

•测试团体和人的能力:包括测试基础知识和理论、对测试体系理解能力、

对测试流程的熟悉度、测试管理工具应用技术、团体协作能力、文档能

力、沟通技巧等;

•对RDP6.0研发控制流程和PLM管理平台的调研:为了完毕将软件测评

活动及过程文档模板固化在FLM管理平台上口勺目口勺,有必要对南车目前

实用的研发控制流程RDP6.0和PLM管理平台进行对应调研。

2.调研过程

调研的基本过程如下:

・调研准备:首先制定调研的计划,计划好所需的资源、调研的方式、成

果口勺记录等环节,并按照计划准备调研所需的资源包括:人力、物力、

资金、时间等;

•实际调查:根据制定日勺计划、依托准备的多种资源,开展实际调研工作;

•数据分析:对调研所得数据进行分析;

•成果记录:根据对调研数据口勺分析,记录得出结论。

3.调研措施

调研所采用的措施一般有:

•文案调查:通过规定项目配合方配合,以文献形式提供。对企业目前的

软件测评过程能力现实状况进行调查,包括软件测试体系文献完善程度、

软件测试流程管理能力等状况进行普查,并对试点单位时进行详细的摸

查;

•调查问卷:通过发放调查问卷,对软件研发和测试部门人员对软件测试

基础知识理解、对软件测试流程的理解、对软件测试体系的熟悉度等状

况进行深入的调研;

•现场访谈:随机走访企业软件研发与测试人员,对其软件测试过程能力

进行调查。

4.调研成果

输出“软件测评过程能力现实状况评估及改善提议汇报”。重要包括:

•测评体系现实状况:对企业软件测评体系的现实状况进行调研,调研内

容包括:测评体系文献、测评流程、实际项目中对测评体系的符合程度

等:

•测评团体现实状况:对企业软件测评团体的现实状况进行调研,调研内

容包括:测评团体组织架构、测评人员构成、测评人员技术能力、对软

件测评体系和过程的认知程度等;

•测评管理现实状况:对企业软件测评管理的现实状况进行调研,调研内

容包括:测评管理制度、质量管理现实状况、配置管理现实状况、测评

管理工具等;

•重要问题:根据以上调研成果,指出企业在软件测评过程能力中存在的

重要问题;

•改善提议:根据调研成果和存在日勺问题,提出提高企业软件测评过程能

力日勺针对性提议。

5.调研所需资源

调研所需资源如下:

・人力资源:除了我方征询人员外,还需企业有关人员配合;

・物力资源:包括本次调研活动所需的所有物力、资金。

•其他资源:调研所用时间等其他资源。

2软件测评过程能力建设方案

2.1软件研发过程

本项目需求中,软件的分类分级原则及软件需求管理属于软件研发过程。

建立软件的分类、分级原则

一、项目需求

本部分对应项目需求中软件测评流程体系(REQ01)中部分需求:

1.建立软件H勺分类、分级原则。

2.根据软件日勺分类、分级原则及软件测试需要,制定软件开发过程裁剪指

导书。

二、提高方案

根据我们的初步调研,企业日勺软件项目具有如下特点:

•软件多为嵌入式软件。嵌入式软件具有两个明显特点:一是软件和硬件结

合紧密,软件脱离特定系统往往无法运行,软件失效与硬件故障有时难以

辨别,甚至互相干。二是开发环境和运行环境不一样。

•软件实时性强C软件多是实时软件,不仅规定软件执行实时性强,并且规

定多种任务能协调执行。

•软件属于安全关键软件。软件的不可靠将带来劫难性H勺后果,因此对其可

靠性、安全性规定很高。

一般来讲,软件的分类从软件自身来讲可以从开发平台、开发语言等进行分

类,也可以根据软件的应用类型进行划分;软件分级可以从软件含量、软件安全

等级等进行划分,我们将在对企业项目进行充足的调研的基础,参照有关国际原

则/国标/国军标/行业原则,并结合我司在软件分类及分级原则的实践经验,制定

适合企业软件特点的分类及分级原则。并根据软件的分类、分级原则及软件则试

需要,制定软件开发过程裁剪指导书。

软件需求管理

一、项目需求

本部分对应项目招标书中的软件需求管理(REQ24),包括但不限于如下要

八占、、.•

1.结合集团企业目前的软件开发工作实际及发展需要,提出并制定科学、

合理的软件需求管理方式和规程。

2.提出需求管理工具H勺选择提议书(工具需满足与PLM系统接口的需要,

或整顿、提出需求管理的需求,由PLM系统实现),指导需求管理工具的选型(自

主研发、联合开发或直接购置成熟的工具等)。

3.指导、协助需求管理工具的实践应用,系统管理、控制软件口勺需求及有

效跟踪。

二、提高方案

需求管理指日勺是需求工程中的所有活动,它包括了一般意义上的需求开发和

需求管理阶段,涵盖了需求获取、需求分析、需求变更、需求跟踪等所有过程。

要处理需求管理过程中n勺问题,使用需求管理工具是一种很好的途径。

考察一种需求管理工具软件,可以从下面几点出发:

•需求信息与否完备

•需求的组织形式

•需求的评审及权限控制

•需求和版本、测试是怎样关联的

•需求变更的支持

由于企业面对的是机构客户,具有需求变更频繁的特性,因此采用工具对需

求进行有效管理非常重视。由于目前『'JPLM未实现(很大也许也无法实现)需

求管理,需寻求专业的管理工具实现对需求口勺高效管理不过由于需求管理贯穿

于研发全过程,因此需求管理工具最佳能与目前MJPLM集成,也许的方案包括

基于与PLM接口的定制化开发、或者退而求另一方面,需求原型当成文档管理

起来,后续日勺所有需求变更均当成缺陷并应用PLM中口勺缺陷管理模块进行统一

的管理。我们将在评估后为企业提出详细的处理方案。

我们将在对企业项目对软件需求管理的现实状况及需求进行充足口勺调研口勺

基础,提出并制定科学、合理的软件需求管理方式和规程,提出需求管理工具的

选择提议书,指导、协助需求管理工具内实践应用,系统管理、控制软件的需求

及有效跟踪。

2.2软件测评过程

对应项目需求REQ01软件测评流程体系、REQ13软件测试管理、REQ14

软件测试项目管理,包括但不限于如下内容:

1.在集团企业既有RDP开发体系下,制定软件测试流程和规范(包括软件

测试各个阶段,如:单元测试、集成测试、系统测试、验收测试;软件测试与软

件设计开发工作相配合和衔接的原则;规范每个阶段的参与角色及参与方式、进

入准则、业务活动、输出成果、退出准则,等等)。

2.制定软件测试管理总体规程(含:测试需求、测试计划、测试用例、测

试脚本、测试执行、测试成果、测试资源、测试度量,等等)。

3.制定软件测试顼目管理规程(含企业内部软件测试项目、企业外部软件

测试项目)。

4.我们将分别从怎样定义软件测评流程及测评规范进行论述。

测评流程

软件测评流程一般包括项目接受、软件测试需求分析、软件测试筹划、软件

测试设计、软件测试执行、软件测试成果分析、软件测试问题跟踪、软件回归测

试、软件测试汇报等活动,我们将分别针对内部测试和外部测试定制软件测评流

程,包括各项活动、准入/准出准则、活动产出、波及角色等。

表1软件测评流程一览表

测试过程活动描述活动产出波及规范

确定项目的等级;测试项目组员《被测件时接受和

项目接受

构成项目测试组,任命项目负责配置表保管程序》

测试过程活动描述活动产出波及规范

确定测试级别,测试类型'测试项测试需求规格《测试需求规格阐

测试需求分析

'测试优先级等阐明明编写规范》

根据测试需求分析成果,测试内

《软件测试计划编

测试筹划容、测试资源安排、测试进度安软件测试计划

写规范》

设订测试用例;《软件测试阐明编

软件测试阐明

测试设计与实编写测试脚本写规范》

现建立测试环境,对测试环境设备测试环境建立《测评过程配置管

进行标识记录理程序》

执行测试用例及测试脚本;对测《测试记录的编写

首轮测试记录

试中发现的问题进行分析,填写规范》《测试问题汇

测试测试问题汇报

问题汇报单;软件测试问题跟踪报的编写规范》

测试

对软件的更改状况作对应口勺影响

执行回归测试阐明

回归域的分析阐明,挑选、新增测试《回归测试阐明编

测试记录

测试用例,并确定回归测试用例集;写规范》

测试问题汇报

根据回归测试用例集执行测试

对测试记录及问题汇报单进行记《测试汇报的编写

测试总结测试汇报

录分析,出具测试汇报规范》

下面对重要过程的技术规定加以描述。

一、测试需求分析

1.测试人员应根据被测软件的需求规格阐明书、软件设计文档等,对被测

软件进行测试需求分析,测试需求分析一般包括:

•确定需要口勺测试类型及其测试规定并进行标识(编号),标识应清晰、便

于识别。测试类型包括功能测试、性能测试等类型;测试规定包括状态、

接口、数据构造、设计约束等规定。确定的测试类型和测试规定均应与

规定的测试阶段、测试类型匹配;

•确定测试类型中的各个测试项及其优先级;

•确定每个测试项日勺测试充足性规定。根据被测软件的重要性、测试目的

和约束条件,确定应覆盖日勺范围及范围所规定H勺覆盖程度;

•确定每个测试员测试终止的规定,包括测试过程正常终止的条件(如测

试充足性与否到达规定)和导致测试过程异常终止日勺也许状况。

2.测试人员应建立测试类型中日勺测试项与软件测评任务书、被测软件的需

求规格阐明、设计文档或其他根据文献时追踪关系。

3.测试人员应将测试需求分析成果,按所确定的文档规定形成测试需求规

格阐明。

4.测试需求规格阐明应通过评审,并应受到变更控制和版本控制。

5.测试需求规格阐明的I内部评审,重要对如下内容进行内部审核,保证测

试质量:

•测试级别和测试对象所确定的测试类型及其测试规定与否恰当;

•每个测试项与否进行了标识,并逐条覆盖了测试需求和潜在需求;

•测试类型和测试项与否充足;

•测试项与否包括了测试终止规定:

•文档与否符合规定口勺规定。

二、测试筹划

1.测试人员应根据被测软件的需求规格阐明书、软件设计文档等进行测试

筹划,筹划一般包括:

•确定测试方略;

•确定测试需要口勺技术或措施,如:测试数据生成与验证技术、测试数据

输入技术、测试成果获取技术等;

•确定受控的测试工作产品,并列出清单;

•确定用于测试日勺资源规定,包括:软硬件设备、环境条件、人员数量和

技能等规定;

•进行测试风险分析•,如:技术风险、人员风险、资源风险和进度风险等;

•根据被测软件的需求规格阐明书、软件设计文档利被测软件时特点,确

定测试任务的结束条件-;

•确定被测软件日勺评价准则和措施;

•应根据测试资源和测试项,确定测试活动的进度;

•应根据测试的规定,确定需采集H勺度量及采集规定,尤其是用例度量、

风险度量、缺陷度量等,并应明确对应日勺数据库测试需求度量;

2.测试人员应建立测试计划与测试需求规格阐明的追踪关系。

3.试验室应将测试筹划成果,按所确定的文档规定形成测试计划。

4.测试计划应通过内部的审核,并应受到变更控制和版本控制。

三、测试设计与实现

1.测试人员应根据测试需求规格阐明和测试计划进行测试的设计和实现,

应完毕如下工作:

•按需要分解测试项。将需测试的测试项进行层次化的分解并进行标识,

若有接口测试,还应有高层次日勺接口图阐明所有的接口和要测试的接口;

•阐明最终分解后的每个测试项。阐明测试用例设计措施的I详细应用、测

试数据的选择根据等;

•设计测试用例;

•确定测试用例的执行次序;

•准备和验证所有的测试用数据。针对测试输入规定,设计测试用的I数据,

如数据类型、输入措施等;

•准备并获取测试资源,如测试环境所必须的I软、硬件资源等;

•必要时,编写测试执行需要的程序,如开发部件测试的驱动模块、桩模

块以及测试支持软件等;

•建立和校核测试环境,记录校核成果,阐明测试环境的I偏差。

2.测试人员应将以上测试设计日勺工作成果,按照所确定日勺文档规定编写测

试阐明,测试阐明一般应包括:

•测试名称和项目的识;

•测试用例的追踪。阐明测试所根据的内容来源,并跟踪到对应口勺测试项

标识(编号);

•测试用例阐明。简要描述测试的对象、目的和所采用的测试措施;

•测试用例的初始化规定,包括硬件配置、软件配置(包括测试的初始条

件)、测试配置(如用于测试的模拟系统和测试工具)、参数设置(如测

试开始前对断点、指针、控制参数和初始化数据的设置)的那个的初始

化规定;

•测试用例的输入。每个测试用例输入的描述中包括:

>每个测试瑜入的名称、用途和详细内容(如确定的数值、状态或信

号等)及其性质(如有效值、无效值、边界值等)

>测试输入H勺来源(如测试程序产生、磁盘文献、通过网络接受、人

工键盘输入等),以及选择输入所使用日勺措施(如等价类划分、边界

值分析、猜错法、因果图以及功能图等);

>测试输入是真实的还是模拟欧J;

>测试输入口勺时间次序或事件次序。

・测试用例日勺期望测试成果。期望测试成果应有详细内容(如确定的数值、

状态或信号等),不应是不确切欧I概念或笼统日勺描述。必要时,应提供

中间的期望成果;

•测试用例口勺测试成果评估准则。评估准则用以判断测试用例执行中产生

的中间或最终成果与否对内。评估准则应根据不一样状况提供有关信息,

如:

>实际测试成果所需的精确度;

>容许口勺实际测试成果与期望成果之间差异口勺上、下限:

>时间的最大或最小间隔;

>事件数目口勺最大或最小值;

>实际测试成果不确定期,重新测试的条件;

>与产生测试成果有关日勺出错处理;

>其他有关准则。

•实行测试用例口勺执行环节。编写按照执行次序排列的一系列相对独立的

环节,执行环节应包括:

>每一步所需的测试操作动作、测试程序输入或设备操作等;

>每一步期望的)测试成果;

>每一步的评估准则;

>导致被测程序执行终止伴随时动作或指示信息;

>需要时,获取和分析中间成果日勺措施。

•测试用例的前提和约束。测试用例中还应阐明实行测试用例的前提条件

和约束条件,如尤其限制、参数偏差或异常处理等,并要阐明它们对测

试用例的影响;

•测试终止条件。阐明测试用例日勺测试正常终止和异常终止的)条件。

3.确定测试阐明与测试计划或测试需求规格阐明的追踪关系,给出清晰、

明确的追踪表。

4.测试阐明应通这内部审核,得到全体测试人员的认同,受到变更控制和

版本控制。根据测试实际状况,修订测试阐明。

5.测试阐明

•测试阐明与否完整、对的和规范;

•测试设计与否完整和合理;

•测试用例与否可行和充足。

6.测试就绪审核。再测试计划审核和测试阐明审核后,还必须进行测试就

绪审核,以确定能否开始执行测试。测试就绪审核应包括:

•通过比较测试环境与软件真实运行的软件、硬件环境的差异,审查测试

环境规定与否对的合理.、满足测试规定;

•审查测试活动的独立性和公正性;

•审查测试需求规格阐明、测试计划和测试阐明评审中的I遗留问题与否得

到了处理;

•审查与否存在影响测试执行的其他问题。

四、测试执行

1.测试人员应按照测试计划和测试阐明的内容和规定执行测试。

2.试验室应如实填写测试原始记录,当成果有量值规定期,应精确记录实

际日勺量值。原始记录应:

•受到严格管理;

•规范格式;

•至少包括测试用例标识、测试成果和发现的缺陷。

3.试验室应根据每个测试用例的期望测试成果、实际测试成果和评估准则,

鉴定测试用例与否通过。

4.当测试用例不通过时,试验室应根据不一样的缺陷类型,采用对应的措

施:

•对测试工作中的缺陷,如测试阐明口勺缺陷、测试数据的缺陷、执行测试

环节时的缺陷、测试环境中的缺陷等,记录到对应的表格中(如《问题

及变更汇报》),并实行对应的变更;

•对被测软件的缺陷应记录到软件问题汇报中;软件问题汇报的格式应规

范。

5.当所有的测试用例都执行完毕后,试验室应根据测试口勺充足性规定和有

关原始记录,分析测试工作与否充足,与否需要进行补充测试:

•当测试过程正常终止时,假如发现测试工作局限性,或测试未到达预期

规定期,应进行补充测试。补充测试应视状况按前面所述日勺测试需求分

析、测试筹划和测试设计与执行的规定进行;

•当测试过程异常终止时,应记录导致终止的条件、未完毕的测试或未被

修正的错误。

6.再执行测试的过程中,可根据测试日勺进展状况补充测试用例,但应留下

用例记录,并在执行测试后,变更测试阐明。

五、测试总结

1.测试人员应根据被测软件文档、测试需求规格说、测试计划、测试阐明、

测试记录、测试问题及变更汇报和被测软件问题汇报等,对测试工作和被测软件

进行分析和评价。

2.对测试工作的分析和评价应包括:

•总结测试需求规格阐明、测试计划和测试阐明的变化状况及其原因:

•在测试异常终止时,阐明未能被测试活动充足覆盖口勺范围及其理由;

•确定无法处理口勺软件测试事件并阐明不能处理的理由。

3.试验室对被测软件H勺分析和评价应包括:

•总结测试中所反应口勺被测软件与软件需求之间日勺差异;

•也许时,根据差异评价被测软件的设计与实现,提出改善的提议;

•当进行配置项测试或系统测试时,当需要时,测试总结中应对配置项或

系统的性能做出评估,指明偏差、缺陷和约束条件等对于配置项或系统

运行『、J影响。

4.分析本测评项目中的数据和文档,以供后来欧I测试合用。数据如:玦陷

数据(包括缺陷描述、类型、严重性等)、用例数据、管理数据(如生产率、工

作量、进度等);文档如:用例设计、需求规格阐明等。

5.测试人员应当根据软件测评任务书、协议(或其他等效文献)、被测软件

文档、测试需求规格阐明、测试计戈I]、测试阐明、测试记录和软件问题汇报单等

有关文档,对测试成果和问题进行分类和总结,按所确定的文档规定编写测试汇

报或测评汇报。测评汇报除了应包括对测试成果的分析,还应包括对被测软件的

评价和提议,测评汇报和测试汇报有时可以合并。

6.测试总结评审应在以上日勺各项工作完毕后进行,以确定与否到达测试目

的,给出审核结论。审核的详细内容和规定是:

•审查测试文档与记录内容向完整性、对的性和规范性;

•审查测试活动的独立性和有效性;

・审杳测试环境与否符合测试规定:

•审查软件测试汇报与软件测试原始记录和问题汇报n勺一致性;

•审查实际测试过程与测试计划和测试阐明的一致性;

•审查测试阐明评审口勺有效性,如与否评审了测试项选择的完整性和合理

性、测试用例日勺可行性和充足性;

•审查测试成果口勺真实性和对的性。

测评规范

测评规范的制定将覆盖如下内容:

1.规范对测评人员及测试环境的规定

2.规范对被测软件欧I状态规定

3.规范不一样软件等级欧I测试规定

・不一样软件等级对测试级别的规定

•不一样软件等级对某一测试级别中测试类型的规定

4.规范对每个过程的技术规定

5.规范不一样测试阶段测试所需文档和程序规定

6.规范每个阶段日勺参与角色及参与方式、进入准则、业务活动、输出成果、

退出准则

7.制定软件测试项目管理规程(含企业内部软件测试项目、企业外部软件

测试项目)

2.3软件测评支撑过程

2.3.1配置管理

一、项目需求

本部分对应项目需求测试管理(REQ13)中软件测试变更管理及软件配置管

理(REQ29)。

包括但不限于如下要点:

1.根据集团企业实际及软件测评规范化日勺需要,制定合适日勺配置管理措施

(至少包括:在配置管理中定义测试有关口勺配置公布流程和配置公布状

态汇报,支撑预测试、版本回退、临时版本、版本领故的处理等)。

2.制定软件数据包命名及管理规范。

3.制定软件版本命名及管理规范。

4.制定软件测试变更管理规程(如:测试方案变更、测试用例变更、测试

脚本变更,等等)。

二、提高方案

配置管理作为软件研发流程中一种重要支捏过程,同样合用于软件测试流程

管理,配置管理的目的是为了保证项目产品的安全性、机密性,保证软件产品的

完整性、有效性及可追性。软件配置管理重要包括五个重要方面,即配置项的标

识、对配置项修改日勺控制、配置管理状态汇报、配置管理活动审计和实现自动化

的构建与公布。

在软件配置管理的五个重要方面中,很明显,标识是基础,即首要日勺第一步

是要确定哪些对象需要纳入到配置管理时控制之卜;接卜来需要确定怎样控制对

这些配置项的修改,包括环境的搭建,顾客授权,开发流程等等;随即,要及时

向团体组员汇报软件配置管理的状态,履行告知的义务,以及进行审计,确认有

关n勺软件配置管理活动确实按照预定的计划高质量地完毕了。

这五个方面,软件配置管理工具都要进行强有力的支持,使得平常事务减至

至少,这是一种成熟的软件配置管理工具应具有的基本特性。企业要实行软件配

置管理常常面临日勺第一步就是要选择合适的工具,在此将列出一种成熟日勺软件配

置管理工具应当具有的特性:

配置项(对象)管理

>版本控制

>配置管理

>并行开发支持

>基线支持

构建与公布管理

>能运用流行的构建工具:ANT/MAKE

>支持多平台构建

>支持并行构建

>能自动处理构建依赖关系

>能搜集和维护重新产生之前构建所需要日勺信息

♦工作空间管理

>能自动跟踪工作空间中所有类型的变更

>能应用不一样配置填充工作空间

>工作空间既容许隔离又容许更新

♦:♦流程管理

>不一样类型的对象都应具有流程定制能力

>流程的范围可定制

>支持测试与公布流程

❖分布式开发的支持

>负载均衡

与其他工具的集成能力

>变更祈求工具

>开发工具

>其他CASE工具

>命令行,SDK

♦:♦易用性、易管理性

>汇报能力

>架构的弹性

我们将在对目前企业既有配置管理工具进行调研和诊断的基础上,选定适合

企业企业需要的I配置管理工具,并指定有关配置管理措施,包括软件版本命名及

管理规范、数据包命名及管理规范、软件测试配置项(如测试方案、测试用例、

测试脚本等)变更管理措施。

对于配置工具的使用,根据我们日勺实践经验,提议以PLM为统一的J产品管

理平台,将所有过程文档通过PLM进行版本管理。软件代码编写过程口勺版本管

理由于独立性较强,现阶段可在软件未定型时选用既有的操作较简朴的SVN进

行配置管理.,编译定型后统一提交到PLM进行管理。下一阶段提议试用PLM新

版本中新增的代码版本管理模块softwareLink,在成熟稳定期将软件配置管理统

一到PLM里。

23.2质量管理

本项目招标书中对质量管理日勺需求定义:

1.制定整个软件生命周期中的软件缺陷闭环管理机制(至少包括:缺陷分

类定义、属性定义、度量指标定义、完善口勺软件缺陷管理流程等),视状

况选择对应的缺陷管理工具(可提出对应口勺缺陷管理工具功能需求,由

PLM系统改善、完善实现缺陷管理功能,或者提供专业的缺陷管理工具,

但需考虑并实行与PLM系统IKJ接口、融合)。

2.制定软件测试质量日勺衡量准则。

3.制定软件产品质量度量准则。

4.培训、指导软件测试质量度量日勺技术与措施。

5.培训、指导软件度量及其过程、软件质量内度量、质量度量的记录措施,

守寺O

我们认为以上需求波及软件质量管理、未波及对测试自身怎样进行质量管理

与控制,我们将在软件测评过程能力提高方案中补充测试过程的评审、测试过程

质量保证、测试数据的核查与控制。

一、软件质量管理

针对项目需求,如下将从软件质量评价、软件测试质量评价及软件缺陷管理

进行论述:

1.软件质量评价

目前比较常用啊软件质量评价原则有:国际原则《ISO/IEC9126软件质量特

性》、国标《GB/T16260—1996软件产品评价、质量特性及其使用指南》,我们将

参照这些原则从软件产品的使用质量、外部质量及内部质量定义软件的质量特性

及子特性,结合南车项目H勺特点,分别明确不一样度量指标的权重范围,形成易

于操作日勺软件质量度量模型构建口勺指导书。基于确定的质量度量模型,根据搜集

测试缺陷的数量、等级、来源、等状况,针对不一样软件项目的性质,给出相对

客观的评价成果。

2.软件测试质量评价

至于软件测试工作的评价,则不能简朴地根据测试发现n勺缺陷来进行评价。

将一次完整日勺测试作为i种工程项目,其考核必须考虑到过程的规范性、活动的

有效性以及项目投入的状况。其中过程和项目投入日勺指标与一般工程项目是类同

时,评价指标重要是常规的投入人力、时间、测试规模等;活

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论