软件测试与验收管理制度.docx

软件测试与验收管理制度.docx

《软件测试与验收管理制度.docx》由会员分享，可在线阅读，更多相关《软件测试与验收管理制度.docx（9页珍藏版）》请在冰豆网上搜索。

软件测试与验收管理制度

XX信息安全管理体系文档

软件测试与验收管理制度

编号:

二。

XX年十月

版本控制信息

版本

日期

拟稿和修改

说明

A

初版发行

目录B

第一章总则1

第二章软件测试规范1

第三章软件项目投产运行规范4

第四章附则8

第一章总则

第一条为了规范信息技术部软件项目流程，减少风险，增加软件的可用性、安全性、可靠性制定本制度。

第二条软件的测试、投产采用项目经理负责制。

第二章软件测试规范

第三条本章节为软件测试提出可操作的、一致性的要求，为软件测试提供有效的方法，使涉及到的各部门就软件项目测试取得一致意见，检查软件的实现情况。

适用于网安公司软件项目的测试。

第四条岗位职责

（一）信息技术部经理负责软件测试管理规范的制泄、审批和修改

（二）项目经理就具体的软件项目制泄测试时间、测试范囤

（三）系统分析员负责软件测试的案例编写、测试环境搭建和测试过程跟踪

（四）测试操作人负责测试案例的执行、测试报告的编写

第五条政策与标准

（->软件编码完成以后，必须对软件进行测试。

（二）软件测试工作是由软件测试小组独立完成的。

（三）软件测试的设计是与软件需求分析同时进行的，并在概要设讣和详细设计时继续进行。

（四）在测试开始前首先应该制立本阶段的工作计划书以保证项目讣划的顺利进行。

工作讣划包括人员、进度和保障条件等的安排。

（五）软件测试设计•完成以后，生成软件测试计划，提交评审、审计和审批。

（六）测试小组按照测试计划进行测试，并完成测试报告。

（七）软件测试过程中所有原始记录、资料必须存档。

第六条软件测试的内容

（->单元测试

单元测试完成对最小的软件设汁单元，即模块的验证工作。

以详细设il•说明书为测试指南，对重要的控制路径进行测试以发现模块内的错误。

单元测试通常情况下是而向白盒的，而且这个步骤可以针对多个模块并行进行。

在编程过程中，一般单元测试工作由模块开发人员自己完成。

开发人员提交的软件模块必须经过单元测试，是自己确认无误的。

（-）集成测试

集成测试是通过测试发现和接口有关的问题。

测试的目的是把通过了单元测试的模块拼在一起，构造一个在详细设计中所描述的程序结构。

集成测试的目的是保证开发小组提交的代码是经过验证的。

（三）确认测试

按照软件需求规格说明书中的内容，测试软件是否达到了用户的要求。

确认测试通过一系列证明软件功能和需求一致的黑盒测试来实现。

测试汁划列岀要测试的详细内容。

（四）系统测试

系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运

行环境下，对计算机系统进行的一系列组装测试和确认测试。

系统测试是为了测试系统的性能，包括恢复测试、安全测试、压力测试、性能测试等。

第七条软件测试报告

无论是单元测试、集成测试、确认测试，还是系统测试，都要填写测试报告。

因此测试报告是多个层次级别的，包括单元测试报告、集成测试报告、确认测试报告和系统测试报告。

软件测试报告必须列岀每一项测试的结果，分析测试结果并给岀结论。

软件测试过程中所有的原始记录和资料属于软件测试报告的内容，在软件测试报告中必须全部列岀，作为评审的依据。

第八条软件测试的原则

软件测试设计应该开始于软件需求分析阶段，并延伸到软件测试阶段。

软件测试应该开始于模块层，而向对象的软件测试应该开始于类或对象的测试。

软件测试可以分为不同的阶段，不同的测试技术适用于不同的阶段。

除单元测试外，软件测试是由软件测试小组独立完成，软件设讣人员只能起辅助作用。

软件测试不同于软件调试，软件调试属于软件设讣的内容。

第九条软件测试计划

（一）测试计划内容

《软件测试汁划》是软件测试设计的文档，主要包括测试内容、需求跟踪、进度安排、测试方法、环境要求、通过准则等。

测试方法包括完成测试所需的方法描述、测试用例设计以及测试规程说明。

测试用例设汁包括测试用例的设计原则与方法，以及简要说明。

具体的用例可在《测试用例》文档中详细描述，包括用于输入的具体值以及预期的输岀结果，并规左在使用具体测试用例时，对测试规程的各种限制。

测试规程说明规泄对于运行系统和执行指左的测试用例来实现有关测试设汁所要求的所有步骤。

（二）测试计划分类

软件测试计划是多个层次级别的，包括单元测试汁划、集成测试计划、确认测试汁划和系统测试计划。

相应的测试用例也是多个层次级别的，分为单元测试用例、集成测试用例、确认测试用例和系统测试用例。

单元测试的实现相对宜接和简单，单元测试计划可以直接包含测试用例，可不编写单独的单元测试用例文档。

第三章软件项目投产运行规范

第十条项目投产运行是新项目开发的结朿，也是现有项目升级维护的开始。

项目投产运行规范提岀了项目投产运行前后，对新项目开发过程的总结与项目开发人员的评价及业务部门人员培训、现有项目系统升级维护方而的要求和方法。

为了保证公司软件项目投产之前能够确保达到软件产品质量体系的要求，满足业务需求，运行之后生产系统的正常运行，尽量减少因为维护开发系统中的错误对生产系统的影响，特制订本章节。

第十一条政策与标准

（一）在新的软件项目开发结束之后，正式投产上线之前，作为软件项目质量体系中确保软件产品符合规立要求的一种手段，软件项目的供方应编制覆盖质量管理和质量保证标准要求的质量手册。

质量手册应包括或引用质疑体系程序，并概述质量体系文件的结构。

（二）基于质量管理和质量保证标准的目的，作为质量体系的一部分的质量体系程序，英程序范围和详细程序可应取决于工作的复杂程序、所用的方法,以及开展这项活动涉及的人员所需的技能和培训。

（三〉对已投产运行的现有软件项目进行升级维护的开发过程中，应该执行以下标准：

>开发与生产系统的移植、更新应根据标准化程序进行：

>不同系统的开发人员与应用支持人员应明确界左清楚：

（四）开发人员的所有开发将在开发环境下进行，生产环境应独立于开发环境,考虑到人手和权限问题，生产环境可以由专人统一管理，也可以由开发人员管理。

第十二条岗位职责

（一）对于新开发的软件项目进入投产运行之前来说，主要涉及以下一些岗位:

>项目经理职责：

1.在进入系统安装联调阶段时，项目经理要保证项目组已完成系统的安装配置手册及各类技术手册，如《操作手册》与《用户手册》等。

2.项目投产运行后，项目经理需要对项目实施过程进行总结，填写《项目总结报告》。

项目总结主要针对以下几个方而：

>客观评价项目需求完成情况及业务部门满意度；

>项目的风险管理及项目决策；

>项目实施过程的质量控制、进度控制以及成本控制；

>系统遗留的问题及影响；

>项目开发过程中有待提高的方面。

3.项目经理编写《业务部门培训计划》，该计划需要得到业务部门的认可。

>项目培训人员职责：

1.培训结朿后根拯需要可以进行考核验证，考核的结果记录在《业务部门培训考核表》中，以对考核结果加以分析。

2.培训结束后请业务部门人员填写《培训结果反馈表》。

＞系统安装调试人员职责：

在进入系统安装联调阶段时，需要对该过程进行记录，系统安装调试人员需要根据实际情况填写以下相关表格：

《硬件设备安装记录表》、《系统软件安装记录表》、《环境配苣记录表》、《应用软件安装记录表》。

（二）对于已经投产运行的现有软件项目进入升级维护阶段来说,主要涉及以下一些岗位以及相应的职责：

1.信息技术部经理：

负责所有系统的管理：

2.系统分析员：

负责系统的分析设计；

3.系统开发员：

负责系统的具体编码实现：

4.应用支持员：

负责系统的测试、部署和维护；

5.系统管理员：

负责硬件系统和网络平台的管理；

6.业务部门负责人：

系统需求的提岀人、系统的最终使用者。

（三）信息技术部的每个系统分析员在不同的系统中可能是系统分析员、系统开发员、应用支持员，在一般情况下，系统分析员和系统开发员可以合二为一。

考虑到每个系统都需要有一左的熟悉时间，因此最好是两人以上互为对方系统的应用支持员。

第十三条方法与流程

（一）已投产运行的软件项目应用系统分类

按软件项目应用系统的内容来分，可以分为：

1.内部管理系统；

2.生产业务系统。

（二）对应用系统修改等级的划分

按对应用系统所作的修改的等级分，可以分为：

一级：

对系统重新开发：

二级：

对系统结构、流程作重大修改，对业务有重大影响；

三级：

对系统修改不大，但对业务有重大影响；

四级：

对系统作局部调整，对业务影响不大：

五级：

对系统作局部少量调整，对业务影响不大。

（三）生产系统升级维护的发布流程

1、由业务部门负责人根据生产系统中存在的问题提岀"应用需求"给系统分析员：

有时系统开发人员可能也会发现业务部门负责人尚未发现的问题，但是为了加强系统开发人员与业务部门负责人对生产系统维护内容的共同理解，还是需要系统开发人员与业务部门负责人进行沟通，统一由业务部门负责人提出;

2、系统分析员在收到需求报告后，需要根据需求的紧急程度，确左需求开发是紧急程序修改还是阶段性开发修改。

如果是紧急程序修改，可以暂时跳过以下流程中的测试审批步骤，直接在修改后交由应用支持人员，将所作修改直接发布到生产系统，并且要实时监测维护后生产系统的运行，确保维护的正确性。

当生产系统运行正确后，由于已经通过了生产系统的测试，所以只需要再补做审批步骤：

如果是阶段性开发修改，就需要系统分析员填写开发计划，将开发工作量分配给系统开发员：

3、系统开发员根据开发与生产环境相隔离的原则，按照版本控制的方法，在开发环境中进行系统修改开发：

开发并完成自测后，提交系统分析员进行代码复审；

4、系统分析员对系统修改完成代码复审之后，填写“信息技术部变更流程”通知应用支持员和业务部门负责人：

5、应用支持员在收到“信息技术部变更流程”后，根据“信息技术部变更流程”上的系统剑称、修改的文件或数据结构、功能修改（包括增加、修改和删除）等配巻测试环境，并通知业务部门做相关测试，并将测试结果通知系统开发人员。

如发现有错误则返回第3步。

应用支持员可以在最后测试通过后填写"信息技术部变更流程"的貝余部分。

6、测试完毕后，由业务部门确认测试结果后签字，然后检查各种所需文档是否齐全，并确左对系统所作修改的等级，以便进行不同的处理：

>如果对系统所作修改属于一级、二级、三级，则必须要交信息技术部经理/业务部门负责人签字审批：

>如果对系统所作修改属于四级、五级或者信息技术部经理和业务部门负责人审批通过，应用支持员可以修改发布到生产系统：

>如果修改对数据库结构和数据具有重大影响，应用支持员要通知系统管理员做好数据备份：

7、应用支持员将所作修改发布到生产系统，通知系统开发人员。

由系统开发员做好版本控制管理，并最终完成“信息技术部变更流程”由系统分析员最终在知识笛理系统中填写应用需求报告完成标识，知识管理系统将自动反惯给需求提出的业务部门负责人。

第四章附则

第十四条本制度网安公司信息技术部负责解释和修订。

第十五条本制度自下发之日起试行。