软件测试文件编制规范
软件开发标准规范文档
软件开发标准规范文档篇一:软件开发技术文档编写规范==软件开发技术文档编写规范在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。
◇ 可行性分析报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。
◇ 项目开发计划:为软件项目实施方案制订出具体计划,应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。
◇ 软件需求说明书(软件规格说明书):对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。
它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的,也是实施开发工作的基础。
该说明书应给出数据逻辑和数据采集的各项要求,为生成和维护系统数据文件做好准备。
◇ 概要设计说明书:该说明书是概要实际阶段的工作成果,它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计提供基础。
◇ 详细设计说明书:着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。
◇ 用户操作手册:本手册详细描述软件的功能、性能和用户界面,使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识,特别是操作方法的具体细节。
◇ 测试计划:为做好集成测试和验收测试,需为如何组织测试制订实施计划。
计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
◇ 测试分析报告:测试工作完成以后,应提交测试计划执行情况的说明,对测试结果加以分析,并提出测试的结论意见。
◇ 开发进度月报:该月报系软件人员按月向管理部门提交的项目进展情况报告,报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
◇ 项目开发总结报告:软件项目开发完成以后,应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力,此外,还需对开发工作做出评价,总结出经验和教训。
软件文档国家标准
徐婷
1-16
3.3 计算机软件测试文档编制规范
3.3.1 标准的适用对象及范围
该规范是为软件管理人员、软件开发、测试和维 护人员、软件质量保证人员、审计人员、客户及用户 制定的。 用于描述一组与软件测试实施方面有关的基本测 试文档,该标准定义每一种基本文档的目的、格式和 内容。尽管标准所描述的文档侧重于动态测试活动, 但是有些文档仍适用于其他种类的测试活动(例如: 测试计划可用于设计和代码评审)。
徐婷
1-21
3.3 计算机软件测试文档编制规范
3.测试报告 测试报告包括4个文档: (1)测试项传递报告 指明在开发组和测试组独立工作的情况下或在希 望正式开始测试的情况下为进行测试而被传递的测试 项。 (2)测试日志 测试组用于记录测试执行过程中发生的情况。
软件文档
郑州大学信息工程学院
徐婷
1-22
软件文档 郑州大学信息工程学院 徐婷 1-9
3.2 计算机软件需求规格说明规范
3.2.2 软件需求文档的基本要求
SRS是对要完成一定功能、性能的软件产品、程 序或一组程序的说明。因此对SRS的描述有两项基本 要求: 1. 必须描述一定的功能、性能; 2. 必须用确定的方法叙述这些功能。 SRS作为软件开发规范之一,对软件开发的所有 阶段都起着非常重要的作用。但是,需要注意的是: SRS不能超出其作用范围,即除了SRS正确地定义所 有软件的需求之外,一般地SRS不描述任何设计、验 证或项目管理的细节,这是对SRS的另外两个要求。
软件文档
郑州大学信息工程学院
徐婷
1-20
3.3 计算机软件测试文档编制规范
2.测试说明 (3)测试规程说明 详细说明执行一组测试用例的各个步骤,或者 更广泛的说明为了评估一组特征而用于分析软件项的 各个步骤。 测试规程是与设计分开的,主要明确要遵循的 步骤,而不宜含有无关的细节。
软件文档国家标准与写作要求
软件文档的编写原则
所有的章节都可以进一步细分或缩并,以适应实际需要。
程序的设计表现形式可以使用多种形式,如流程图、判定表、等其 他表现形式。
按规定:重量不超过30公斤的行李可免费托运。重量超过30公斤时, 对超运部分,头等舱国内乘客收4元/公斤;其它舱位国内乘客收6元 /公斤;外国乘客收费为国内乘客的2倍;残疾乘客的收费为正常乘 客的1/2。
(6)详细设计说明书
(7)数据库设计说明书
本指南不仅给出了这十四种文档的编制指导,同时,本指南也是这十四种文 档编写质量的检验准则。
2、软件需求说明编制指南
软件需求说明编制指南
软件需求说明编制指南
软件需求说明编制指南
软件需求说明编制指南
软件需求说明编制指南为软件需求的实践提供了一个规 范化的方法,主要描述了软件需求说明(Software Requirements Specifications,简称SRS)所必须的内容 和质量。
软件需求标准适用范围
1. 指南适用对象 软件客户(Customers),以便精确地描述他们想获得什么样的产品。 软件开发者(Suppliers),以便准确地理解客户需要什么样的产品。 2. 指南目的 对于任一单位和(或)个人,要实现下列目标: a. 要提出开发规范化的SRS提纲; b. 定义自己需要的具体的格式和内容; c.产生附加的局部使用条款,如SRS质量检查清单或者SRS作者手册等。
实例
4、软件文档管理指南
软件文档管理指南
软件文档管理指南是为那些对软件或基于软件的产品的开发负有职 责的管理者提供软件文档的管理指南。其目的在于协助管理者在他 们的机构中产生有效的文档。
(1)软件文档管理涉及策略、标准、规程、资源和计划,管理者必 须关注这些内容,以便有效地管理软件文档。 (2)软件文档管理期望应用于各种类型的软件,从简单的程序到复 杂的软件系统。并期望覆盖各种类型的软件文档,作用于软件生存 期的各个阶段。 (3)不论项目的大小,软件文档管理的原则是一致的。对于小项目, 可以不采用本标准中规定的有关细节。管理者可剪裁这些内容以满 足他们的特殊需要。 (4)软件文档管理是针对文档编制管理而提出的,不涉及软件文档 的内容和编排。
软件开发文档-软件测试规范详细模板(经典)
软件开发文档软件测试规范设计单位:建设单位:编制日期:目录第一章概述 (1)第二章测试理论 (2)2.1. 软件测试 (2)2.2. 测试目标 (3)第三章测试流程 (5)3.1. 测试流程图 (5)3.2. 流程细则 (9)3.2.1. 需求阶段 (9)3.2.2. 设计编码阶段 (9)3.2.3. 测试阶段 (9)3.2.4. 用户测试阶段 (11)3.3. 注意事项 (11)第四章测试类型 (14)4.1. 模块测试 (14)4.2. 子系统测试 (14)4.3. 系统测试 (15)4.4. 验收测试 (15)第五章黑盒测试方法 (16)5.1. 等价类划分 (18)5.2. 因果图 (20)5.3. 边值分析法 (21)5.4. 猜错法 (22)5.5. 随机数法 (23)第六章白盒测试方法 (24)6.1. 语句覆盖 (25)6.2. 判定理盖 (26)6.3. 条件覆盖 (27)6.4. 判定/条件覆盖 (28)6.5. 条件组合覆盖 (29)第七章测试错误类型 (31)7.1. A类 (31)7.2. B类 (31)7.3. C类 (32)7.4. D类 (32)7.5. E类 (33)第八章测试标准 (34)第九章附录一单元测试报告 (35)9.1. 测试过程与结果 (35)9.1.1. (某程序模块/文档名称)测试 (35)9.1.2. (某程序模块/文档名称)测试 (35)9.2. 测试结论 (36)第十章附录二集成测试报告 (37)第十一章附录三测试大纲 (38)11.1. 概述 (38)11.1.1. 编写目的 (38)11.1.2. 参考资料 (38)11.1.3. 术语和缩写词 (38)11.1.4. 测试内容和测试种类 (38)11.2. 系统结构 (39)11.3. 测试目的 (39)11.4. 测试环境 (39)11.4.1. 硬件 (39)11.4.2. 软件 (39)11.5. 人员 (39)11.6. 测试说明 (39)11.6.1. [测试1名称及标识符]说明 (40)11.6.2. [测试2名称及标识符]说明 (40)11.6.3. [测试3名称及标识符]说明 (41)11.6.4. [测试4名称及标识符]说明 (41)第十二章附录四测试大纲附录 (42)第十三章附录五测试计划 (44)13.1. 概述 (44)13.1.1. 编写目的 (44)13.1.2. 参考资料 (44)13.1.3. 术语和缩写词 (44)13.1.4. 测试种类 (44)13.2. 系统描述 (45)13.3. 测试环境 (45)13.3.1. 硬件 (45)13.3.2. 软件 (45)13.4. 测试安排 (45)13.4.1. (子系统1名称和项目唯一标识号) (45)13.4.2. (子系统2名称和项目唯一标识号) (46)13.5. 测试数据的记录、整理和分析 (46)第十四章附录六程序错误报告 (48)第十五章附录七测试分析报告 (50)15.1. 概述 (50)15.1.1. 编写目的 (50)15.1.2. 参考资料 (50)15.1.3. 术语和缩写词 (50)15.2. 测试对象 (50)15.3. 测试分析 (51)15.3.1. 测试结果分析 (51)15.3.2. 对比分析 (52)15.3.3. 测试评估 (52)15.4. 测试结论 (52)第一章概述本规范是对项目软件测试的一份指导性文件,对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范,以有效保证软件产品的质量。
软件测试工作规范
软件测试工作规范1、目的规范公司软件的测试工作,明确开发项目组中测试组与开发组在测试工作中的职责,以保证开发软件的质量,降低开发成本。
2、适用范围公司所有自主开发的软件单元测试、综合测试(组装测试、系统测试)、确认测试和验收测试。
3、职责3.1研发部3.1.1负责具体项目测试组的建立;3.1.2参加测试计划、测试用例、测试总结报告、测试验收报告的评审;3.1.3负责编写《软件测试计划》;3.1.4负责测试组、项目组之间的沟通协调;3.1.5编写项目的测试用例;3.1.6进行综合测试、确认测试及内部验收测试实施工作;3.1.7测试完毕,填写测试总结报告;3.1.8审核用户文档;3.1.9跟踪测试错误的跟踪及回归测试;3.1.10参加测试计划、测试用例、测试总结报告、测试验收报告的评审。
3.2项目组3.2.1定期构建程序,以最新版本提供给测试组测试;3.2.2按项目经理的安排,进行单元测试;3.2.3负责按照项目经理的安排纠正测试中发现的错误。
3.3研发部、软件部3.3.1负责测试组、项目组之间的沟通协调;3.3.2负责组织测试计划、测试用例、测试总结报告、测试验收报告的评审工作;3.3.3负责变更控制处理过程。
3.4质管部3.4.1参加测试计划、测试总结报告、测试验收报告的评审;3.4.2负责对测试计划、测试总结报告、测试验收报告进行抽查;4、缩略语及定义4.1 综合测试:包括组装测试和系统测试。
当该项目(产品)的规模、难度不大,认为容易受控时,可以考虑把组装测试和系统测试两阶段工作合并,同时进行。
5、工作程序及规定5.1测试阶段划分测试工作阶段划分为单元测试、综合测试(包括组装测试和系统测试)、确认测试和验收测试几个阶段。
5.1.1单元测试:对程序的最小单位——模块进行测试。
a)目的:是为了检验每个模块能否正常运行,从而发现模块的编码问题和算法问题。
b)依据:详细设计说明书和源程序清单。
c)方法:主要采用自测试、交叉测试。
与软件测试相关的国家标准
与软件测试相关的国家标准标准化在工程技术领域发挥着巨大的作用,在信息工程和软件工程领域也是如此。
在国家标准化管理委员会、ISO以及IEEE 的官方网站上,可以查询到大量的相关标准,而且很多标准在最近2~3年内进行了修订。
其中对软件测试来说,2008年是典型的“丰收年”,两个直接与软件测试相关的国家标准(GB/T 9386, GB/T 15532)和1个IEEE的标准(IEEE 829)进行了修订,且ISO 的软件测试标准(ISO/IEC 29119)也初见框架。
1)GB/T 19488.1-2004电子政务数据元第1部分:设计和管理规范2)GB/T 18905.1-2002 软件工程产品评价第1部分:概述3)GB/T 18905.2-2002 软件工程产品评价第2部分:策划和管理4)GB/T 18905.3-2002 软件工程产品评价第3部分:开发者用的过程5)GB/T 18905.4-2002 软件工程产品评价第4部分:需方用的过程6)GB/T 18905.5-2002 软件工程产品评价第5部分:评价者用的过程7)GB/T 18905.6-2002 软件工程产品评价第6部分:评价模块的文档编制8)GB/Z 18914-2002 信息技术软件工程CASE工具的采用指南9)GB/T 18894-2002 电子文件归档与管理规范10)GB/T 18492-2001 信息技术系统及软件完整性级别11)GB/Z 18493-2001 信息技术软件生存周期过程指南12)GB/T 19000.3-2001 质量管理和质量保证标准第3部分:GB/T 19001在计算机软件开发、供应、安装和维护中的使用指南13)GB/T 8566-2001 信息技术软件生存周期过程14)GB/T 18491.1-2001 信息技术软件测量功能规模测量第一部分:概念定义15)GB/T 18234-2000 信息技术 CASE工具的评价与选择指南16)GB/T 18221-2000 信息技术程序设计语言环境与系统软件接口独立于语言的数据类型17)GB/T16901.2-2000 图形符号表示规则产品技术文件用图形符号第2部分:图形符号(包括基准符号库中的图形符号)的计算机电子文件格式规范及其交换要求18)GB 17859-1999 计算机信息系统安全保护等级划分准则19)GB/T 17544-1998 信息技术软件包质量要求和测试20)GB/T 16260-1996 信息技术软件产品评价质量特性及其使用指南21)GB/T 16680-1996 软件文档管理指南22)GB/T 16704-1996 计算机软件著作权登记文件格式23)GB/T 11457-1995 软件工程术语24)GB/T 15532-1995 计算机软件单元测试25)GB/T 15538-1995 软件工程标准分类法26)GB/T 15853-1995 软件支持环境27)GB/T 7408-1994 数据元和交换格式信息交换日期和时间表示法28)GB/T 14394-1993 计算机软件可靠性和可维护性管理29)GB/T 14079-1993 软件维护指南30)GB/T 14085-1993 信息处理系统计算机系统配置图符号及约定31)GB/T 12504-1990 计算机软件质量保证计划规范32)GB/T 12505-1990 计算机软件配置管理计划规范33)GB/T 1526-1989 信息处理数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定34)GB/T 9385-1988 计算机软件需求说明编制指南35)GB/T 9386-1988 计算机软件测试文件编制规范36)GB/T 8567-1988 计算机软件产品开发文件编制指南下面就2008年新发布的标准做简单介绍:GB/T 9386-2008《计算机软件测试文档编制规范》是在1988年版本上进行的修订,2008版标准的名称和核心内容都没有改变,主要增加对测试文档作为术语的定义,调整了部分章节编排方式,扩充了部分内容,并增加了两个作为资料性附录的文档编写示例。
计算机软件产品开发文件编制指南GB
计算机软件产品开发文件编制指南(GB8567-88)国家有关计算机软件产品开发文件编制指南(GB 8567-88)只是一个国家标准,并不一定适合每一个企业,各企业(组织)应该按照标准,制订出符合自身软件过程规范的文档要求。
引言1 目的一项计算机软件的筹划、研制及实现,构成一个软件开发项目。
一个软件开发项目的进行,一般需要在人力和自动化资源等方面作重大的投资。
为了保证项目开发的成功,最经济地花费这些投资,并且便于运行和维护,在开发工作的每一阶段,都需要编制二定的文件。
这些文件连同计算机程序及数据一起,构成为计算机软件。
文件是计算机软件中不可缺少的组成部分,它的作用是:a.作为开发人员在一定阶段内的工作成果和结束标志;b.向管理人员提供软件开发过程中的进展和情况,把软件开发过程中的一些"不可见的"事物转换成“可见“的文字资料。
以便管理人员在各个阶段检查开发计划的实施进展,使之能够判断原定目标是否已达到,还将继续耗用资源的种类和数量;C.记录开发过程中的技术信息,便于协调以后的软件开发、使用和修改;d.提供对软件的有关运行、维护和培训的信息,便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作;e.向潜在用户报导软件的功能和性能,使他们能判定该软件能否服务于自己的需要。
换言之,本指南认为:文件的编制必须适应计算机软件整个生存周期的需要。
计算机软件所包含的文件有两类:一类是开发过程中填写的各种图表,可称之为工作表格;另一类则是应编制的技术资料或技术管理资料,可称之为文件。
本指南规定软件文件的编制形式,并提供对这些规定的解释。
本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。
2 范围本指南是一份指导性文件。
本指南建议,在一项计算机软件的开发过程中,一般地说,应该产生十四种文件。
这十四种文件是:* (1)可行性研究报告;* (2)项目开发计划;* (3)软件需求说明书;* 数据要求说明书;* (4)概要设计说明书;* 详细设计说明书;* 数据库设计说明书;用户手册;操作手册;模块开发卷宗;(2)测试计划;测试分析报告;开发进度月报;项目开发总结报告。
软件测试文档编制要求规范
文档编制规目录文档编制规 (1)一、文档的分类 (2)二、文档的编号 (2)三、文档编写的格式要求 (3)3.1、页面布局 (3)3.1.1、页边距 (3)3.1.2、页眉页脚 (3)3.2、首页标题及公司基本信息 (4)3.3、目录 (4)3.4、正文 (4)3.4.1、正文容 (4)3.4.2、小标题级别 (4)3.4.3、图片与表格 (5)3.4.4、功能点与列表 (8)3.5、附件 (8)一、文档的分类将文档分成如下几类:1、规章制度类(编号:GZZD):公司、部门的各项规章制度;2、工作规类(编号:GZGF):各部门的工作规;3、项目管理规类(编号:XMGL):项目管理规、药监项目管理规、招投标系统开发与实施指南等;4、项目类文档(编号:XM):包括项目各个过程的产出物,如合同(HT)、建设方案(FA)、需求文档(XQ)、设计文档(SJ)、操作手册(CZSC)、测试报告(CSBG)等;5、体系类(ISO9001、ISO27001、CMMI3);6、知识类(编号:ZS):各类技术经验总结等;7、产品类(编号:产品名称缩写):如OA、Mis平台、电子招投标产品的介绍资料/操作手册等8、其他类(不需要编号):上述7个类别之外的其它文档。
二、文档的编号文档的编号是文档唯一标识,主要用于文档的检索和版本控制。
文档编号规则如下:文档编号=文档所属部门代码+文档类别代码+文档流水号+版本号示例如下:例如:QYGL-GZZD -001V2.12.1表示第二版第一次修改第一个文件规章制度企业管理部说明:1.部门代码为各部门的拼音首字母(公司的部门代码为GTXD)。
部门编码示例:企业管理部-QYGL、人力资源部-RLZY、行政部-XZ、开发部-KF(子部门为KF1、KF2类推)、实施部-SS(子部门SS1、SS3类推)、测试部-CS等;2.版本号使用2位数字进行声明,数字间使用英文标点“.”隔开。
首位数字表示第几个版本,末尾数字表示版本的第几次修改。
GB9386-88计算机软件测试文件编制规范
GB9386-88计算机软件测试文件编制规范计算机软件测试文件编制规范1引言1.1目的和作用本规范规定一组软件测试文件。
测试是软件生存周期中一个独立的、关键的阶段,也是保证软件质量的重要手段。
为了提高检测出错误的几率,使测试能有计划地、有条不紊地进行地进行,就必须要编制测试文件。
而标准化的测试文件就如同一种通用的参照体系,可达到便于交流的目的。
文件中所规定的内容可以作为对测试过程完备性的对照检查表,故采用这些文件将会提高测试过程的每个阶段的能见度,极大地提高测试工作的可管理性。
1.2事实适用对象及范围本规范是为软件管理人员、软件开发人员和软件维护人员、软件质量保证人员、审计人员、客户及用户制定的。
本规范用于描述一组测试文件,这些测试文件描述测试行为。
本规范定义每一种基本文件的目的、格式和内容。
所描述的文件着重于动态测试过程,但有些文件仍适用其它种类的测试活动。
本规范可应用于数字计算机上运行的软件。
它的应用范围不受软件大小、复杂度或重要性的限制,本规范既合用于初始开发的软件测试文件编制,也合用于其后的软件产品更新版本的测试文件编制。
本规范并不要求采用特定的测试方法学、技术及设备或工具。
对文件控制、配置管理或质量保证既不指明也不强制特定的方法学。
根据所用的方法学,可能需要增加别的文件(如“质量保证计划”)。
本规范既适用于纸张上的文件,也适用于其它媒体上的文件。
如果电子文件编制系统不具有安全的批准注册机制,则批准签字的文件必须使用纸张。
2引用标准GB/T 软件工程术语GB 8566计算机软件开发规范GB 8567计算机软件产品开发文件编制指南13定义本章定义本规范中使用的关键术语。
3.1设计层design level软件项的设计分解(如系统、子系统、程序或模块)。
3.2经由过程原则pass criteria判断一个软件项或软件特性的测试是否通过的判别依据。
3.3软件特征software feature软件项的显著特性。
GB-T 8567-2006 计算机软件文档编制规范
@ by China Electronics Standardization Institute
计算机文档编制
中国电子技术标准化研究所
p)显示适当的里程碑的时间表,包括: 1)文档计划批准; 对于文档的每一项应重复。 l 文档计划宜2)每个草案的准备、评审和改正; 3)可用性测试; 4)打印、装订和发布。 若适当,这些活动的每一个在文档的开发开始以 前准备与批准,以保证所有部门同意目标和所用的 方法。批准后,计划宜尽可能广泛地分发;分发宜 包括所有文档开发人员和可能包括需方人员及子合 同方。
@ by China Electronics Standardization Institute
计算机文档编制
中国电子技术标准
• 文档编制计划 • 文档开发(编制) • 文档评审
@ by China Electronics Standardization Institute
@ by China Electronics Standardization Institute 计算机文档编制
中国电子技术标准化研究所
5.4
文档开发
按文档计划规定进行文档开发。通常, 在进行文档开发前,要规定文档的格式 (风格)。在软件的开发和管理过程中 需要那些文档,每种文档的规范在下面 说明。
@ by China Electronics Standardization Institute
计算机文档编制
中国电子技术标准化研究所
j)项目依赖。 k)所要求的人时和成本。 l)项目资源需求,包括需方提供的信息和其 他资源。 m)在软件开发期间,软件变更传送信息给文 档管理者的方法。 n)文档的变更控制和维护的计划(任选)。 o)实现后评审的计划(任选)。
软件工程文档完整规范版
软件工程文档模板目录 (9)51. 范围本指南用于指导软件开发者为南京市交通局开发软件项目的过程,通过规范软件项目承担单位的开发过程达到提高软件质量,降低维护成本的目的。
开发者应根据本指南进行软件开发和编制软件开发文档。
本指南是对软件项目承担单位的基本要求。
在本指南的附录A至E中提供了文档的编写模板供开发者参考,在进行具体软件开发时,开发者可根据实际情况采编写,但必须提供双方约定的文档,文档中约定的内容必须描述清楚。
2. 总体要求2.1 总体功能要求网络应用环境以Internet/Intranet技术为核心。
开发者应在充分分析需求的基础上,选择采用B/S结构或者C/S结构。
软件系统的数据库应依照《南京市交通局信息化数据库建设规范》进行设计和建设。
本指南中没有规定开发者采用何种具体的软件工程开发方法,开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法,但建议开发商使用面向对象软件工程的方法,如:采用目前被广泛使用的RUP(Rational Unified Process)方法来进行分析、设计和开发。
2.2 软件开发平台要求开发者开发的软件必须能够在南京市交通局规定的软件平台上正常运行。
目前软件平台为:数据库管理系统:Oracle 9i以上版本中间件(应用服务器)系统:IBM WebSphereOA系统:Lotus Domino/Notes网络架构:完全支持TCP/IP协议开发工具或技术体系:为保证软件的上下兼容性,开发者应选择比较通用的开发工具的较新版本进行开发,如Microsoft Visual ,Borland Delphi,C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。
2.3 软件项目的开发实施过程管理要求2.3.1 软件项目实施过程总体要求(一)开发者提交软件开发工作大纲,交通局组织专家组对工作大纲进行评审,并提出整改意见。
软件测试规范
四.软件测试类别
除非是测试一个小程序,否则一开始就把整个系统作为一个单独的 实体来测试是不现实的。与开发过程类似,测试过程也必须分步骤进 行,每个步骤在逻辑上是前一个步骤的继续。大型软件系统通常由若干 个子系统组成,每个子系统又由许多单元组成。因此,大型软件系统的 测试基本上由下述几个步骤组成:
1.单元测试
及模块划分等。 测试人员了解项目需求变更。 测试人员会同项目主管根据软件需求制定并确认《测试计划》(附
录五)。 设计编码阶段:
测试人员制定《测试大纲》(附录三、附录四)。 项目开发组对完成的功能模块进行单元测试,测试人员参与单元测 试过程;单元测试完成,产生单元测试报告。 所有单元测试及相应的修改完成后,项目开发组组织进行集成测 试,测试人员参与集成测试过程;集成测试完成后,产生集成测试报 告。 测试阶段: 项目开发组完成集成测试后,提交测试所要求的待测软件及各种文 档、手册、前期测试报告(《需求分析》、《软件设计规范》和上一级 《测试报告》附录一、附录二)。 测试组安排和协调测试设备、环境等准备工作。 测试组按测试计划、测试大纲的要求对待测软件进行有效性测试、 集成测试。 填写《错误报告》(附录六)。 对修改后的情况进行复合。 测试结束后,测试人员对测试结果进行汇总;测试主管审核测试结
3.配置项测试
软件配置项测试的对象是软件配置项。软件配置项是为独立的配置 管理而设计的并且能满足最终用户功能的一组软件。
软件配置项测试的目的是检验软件配置项与软件需求规格说明的一 致性。
4.系统测试
软件系统测试的对象是完整的、集成的计算机系统,重点是新开发 的软件配置项的集合。
软件系统测试的目的是在真实系统工作环境下检验完整的软件配置 项能否和系统正确连接,并满足系统/子系统设计文档和软件开发合同 规定的要求。
软件开发文档规范
软件开发文档规范篇一:软件开发文档编写要求软件开发文档编写要求在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。
◇ 可行性分析报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。
◇ 项目开发计划:为软件项目实施方案制订出具体计划,应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。
◇ 软件需求说明书(软件规格说明书):对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。
它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的,也是实施开发工作的基础。
该说明书应给出数据逻辑和数据采集的各项要求,为生成和维护系统数据文件做好准备。
◇ 概要设计说明书:该说明书是概要实际阶段的工作成果,它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计提供基础。
◇ 详细设计说明书:着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。
◇ 用户操作手册:本手册详细描述软件的功能、性能和用户界面,使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识,特别是操作方法的具体细节。
◇ 测试计划:为做好集成测试和验收测试,需为如何组织测试制订实施计划。
计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
◇ 测试分析报告:测试工作完成以后,应提交测试计划执行情况的说明,对测试结果加以分析,并提出测试的结论意见。
◇ 开发进度月报:该月报系软件人员按月向管理部门提交的项目进展情况报告,报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
◇ 项目开发总结报告:软件项目开发完成以后,应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力,此外,还需对开发工作做出评价,总结出经验和教训。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
计算机软件测试文件编制规范1 引言1.1 目的和作用本规范规定一组软件测试文件。
测试是软件生存周期中一个独立的、关键的阶段,也是保证软件质量的重要手段。
为了提高检测出错误的几率,使测试能有计划地、有条不紊地进行地进行,就必须要编制测试文件。
而标准化的测试文件就如同一种通用的参照体系,可达到便于交流的目的。
文件中所规定的内容可以作为对测试过程完备性的对照检查表,故采用这些文件将会提高测试过程的每个阶段的能见度,极大地提高测试工作的可管理性。
1.2 适用对象及范围本规范是为软件管理人员、软件开发人员和软件维护人员、软件质量保证人员、审计人员、客户及用户制定的。
本规范用于描述一组测试文件,这些测试文件描述测试行为。
本规范定义每一种基本文件的目的、格式和内容。
所描述的文件着重于动态测试过程,但有些文件仍适用其它种类的测试活动。
本规范可应用于数字计算机上运行的软件。
它的应用范围不受软件大小、复杂度或重要性的限制,本规范既适用于初始开发的软件测试文件编制,也适用于其后的软件产品更新版本的测试文件编制。
本规范并不要求采用特定的测试方法学、技术及设备或工具。
对文件控制、配置管理或质量保证既不指明也不强制特定的方法学。
根据所用的方法学,可能需要增加别的文件(如“质量保证计划”)。
本规范既适用于纸张上的文件,也适用于其它媒体上的文件。
如果电子文件编制系统不具有安全的批准注册机制,则批准签字的文件必须使用纸张。
2 引用标准GB/T 11457 软件工程术语GB 8566 计算机软件开发规范GB 8567 计算机软件产品开发文件编制指南3 定义本章定义本规范中使用的关键术语。
3.1 设计层design level软件项的设计分解(如系统、子系统、程序或模块)。
3.2 通过准则pass criteria判断一个软件项或软件特性的测试是否通过的判别依据。
3.3 软件特性software feature软件项的显著特性。
(如功能、性能或可移植性等)。
3.4 软件项software item源代码、目标代码、作业控制代码、控制数据或这些项的集合。
3.5 测试项test item作为测试对象的软件项。
4 概述4.1 主要内容本规范确定了各个测试文件的格式和内容,所提出的文件类型包括测试计划、测试说明和测试报告。
测试计划描述测试活动的范围、方法、资源和进度。
它规定被测试的项、被测试的特性、应完成的测试任务、担任各项工作的人员职责及与本计划有关的风险等。
测试说明包括三类文件:(1)测试设计说明:详细描述测试方法,规定该设计及其有关测试所包括的特性,还规定完成测试所需的测试用例和测试规程,并规定特性的通过准则。
(2)测试用例说明:列出用于输入的具体值以及预期的输出结果,并规定在使用具体测试用例时,对测试规程的各种限制。
将测试用例与测试设计分开,可以使它们用于多个设计并能在其它情形下重复使用。
(3)测试规程说明:规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。
测试报告包括四类文件:(1)测试项传递报告:指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而被传递的测试项。
(2)测试日志:测试组用于记录测试执行过程中发生的情况。
(3)测试事件报告:描述在测试执行期间发生并需进一步调查的一切事件。
(4)测试7总结报告:总结与测试设计说明有关的测试活动。
这些文件同其它文件在编制方面的关系以及同测试过程的对应关系如图1所示。
4.2 实施灵活性在GB 8567中,涉及软件测试的文件有“测试计划”及“测试分析报告”。
本规范中的八个测试文件是上述二个文件的补充和细化,这样可使文件的书定更具体、更有参照性,其中测试计划可细化为本规范的测试计划、测试设计说明、测试用例说明及测试规程说明,测试分析报告可细化为本规范的测试项传递报告、测试日志、测试事件报告及测试总结报告。
使用本规范的每个单位,要规定测试阶段所应有的特定文件,并在测试计划中规定测试完成后所能提交的全部文件。
对于不同的设计层或不同规模的软件,所选文件的种类也可有所不同。
在所提供的每个标准文件中,每一章的内容对于具体的应用和特定的测试阶段可以有所增减。
不仅可以调整内容,还可以在基本文件集中增加另外的文件。
任何一个文件都可以增加新的内容,并且某章若无可写的内容,则可不写,但须保留该章的编号。
使用本规范的每个单位应该补充规定对内容的要求和约定,以便反映自己在测试、文件控制、配置管理和质量保证方面所用的特定方法、设备和工具。
附录A(参考件)中,将叙述文件编制实施及使用指南。
4.3 总体要求以下将叙述各个测试文件的书写格式及内容。
对于每一个文件而言各章应按指定的次序排列,补充的章可以放在最后或放在“批准”一章的前面(如果该文件最后一章是“批准”的话)。
如果某章的部分或全部内容在另一文件中,则应在相应的内容位置上列出所引用的材料,引用的材料必须附在该文件后面或交给文件的使用者。
5 内容要求5.1 测试计划测试计划结构如表1所示。
表1 测试计划1 测试计划名称2 引言3 测试项4 被测试的特性5 不被测试的特性6 方法7 项通过准则8 暂停标准和再启动要求9 应提供的测试文件10 测试任务11 环境要求12 职责13 人员和训练要求14 进度15 风险和应急16 批准下面给出每一章的详细内容:5.1.1 测试计划名称(本计划的第1章)为本测试计划取现代战争专用的名称。
5.1.2 引言(本计划的第2章)归纳所要求测试的软件项和软件特性,可以包括系统目标、背景、范围及引用材料等。
在最高层测试计划中,如果存在下述文件,则需要引用它们:项目计划、质量保证计划、有关的政策、有关的标准等。
5.1.3 测试项(本计划的第3章)描述被测试的对象,包括其版本、修订级别,并指出在测试开始之前对逻辑或物理变换的要求。
5.1.4 被测试的特性(本计划的第4章)指明所有要被测试的软件特性及其组合,指明每个特性或特性组合有关的测试设计说明。
5.1.5 不被测试的特性(本计划的第5章)指出不被测试的所有特性和特性的有意义的组合及其理由。
5.1.6 方法(本计划的第6章)描述测试的总体方法,规定测试指定特性组志需的主要活动、、技术和工具,应详尽地描述方法,以便列出主要的测试任务,并估计执行各项任务所需的时间。
规定所希望的电低程度的测试彻底性,指明用于判断测试彻底性的技术(如:检查哪些语句至少执行过一次)。
指出对测试的主要限制,例如:测试项可用性、测试资源的可用性和测试截止期限等。
5.1.7 项通过准则(本计划的第7章)规定各测试项通过测试的标准。
5.1.8 暂停标准和再启动要求(本计划第8章)规定用于暂停全部或部分与本计划有关的测试项的测试活动的标准。
规定当测试再启动时必须重复的测试活动。
5.1.9 应提供的测试文件(本计划的第9章)规定测试完成后所应递交的文件,这些文件可以是前述八个文件的全部或者部分。
5.1.10 测试任务(本计划的第10章)指明执行测试所需的任务集合,指出任务音的一切依赖关系和所需的一切特殊技能。
5.1.11 环境要求(本计划的第11章)规定测试环境所必备的和希望的的性质。
包括:硬件、通信和系统软件的物理特征、使用方式以及任何其它支撑测试所需的软件或设备,指出所需的特殊测试工具及其它测试要求(如出版物或办公场地等)。
指出测试组目前还不能得到的所有要求的来源。
5.1.12 职责(本计划的第12章)指出负责管理、设计、准备、执行、监督、检查和仲裁的小组。
另外指出负责提供5.1.3 中指出的测试项和在5.1.11中指出的环境要求的小组。
这些小组可以包括开发人员、测试人员、操作员、用户代表、数据管理员和质量保证人员。
5.1.13 人员和训练要求(本计划的第13章)指明测试人员应有的水平以及为掌握必要技能可供选择的训练科目。
5.1.14 进度(本计划的第14章)包括在软件项目进度中规定的测试里程碑以及所有测试项传递时间。
定义所需的新的测试里程碑,估计完成每项测试任务所需的时间,为每项测试任务和测试里程碑规定进度,对每项测试资源规定使用期限。
5.1.15 风险和应急(本计划的第15章)预测测试计划中的风险,规定对各种风险的应急措施(如:延期传递的测试项可能需要加夜班来赶上规定的进度。
)5.1.16 批准(本计划的第16章)规定本计划必须由哪些人(姓名和职务)审批。
为签名和填写日期留出位置。
5.2 测试设计说明测试设计说明如表2所示。
表2 测试设计说明1 测试设计说明名称2 被测试的特性3 方法详述4 测试用例名称5 特性通过准则下面给出本说明每一章的详细内容。
5.2.1 测试设计说明名称(本说明第1章)给每一个测试设计说明取一个专用名称。
如果存在的话,也可引用有关的测试计划中给出的名称。
5.2.2 被测试的特性(本说明的第2章)规定测试项,描述作为本设计测试目标的特性和特性的组合,其它特性可以论及,但不必测试。
5.2.3 方法详述(本说明的第3章)将测试计划中规定的方法进行细化,包括要用的具体测试技术,规定分析测试结果的方法(如比较程序或人工观察)。
规定为选择测试用例提供合理依据的一切分析结果。
例如:可以说明容错的条例(如:区别有效输入和无效输入的条件)。
归纳所有测试用例的共同属性,可以包括输入约束条件,共享环境的要求,对共享的特殊规程的要求及任何共享的测试用例间的依赖关系。
5.2.4 测试例名称(本说明的第4章)列出与本设计有关的每一测试用例的名称和简要说明。
某个特定的测试用例可能在多个测试设计说明中出现,列出与本测试设计说明有关的规程及其简要说明。
5.2.5 特性通过准则(本说明的第5章)规定用于判别特性和特性组合是否通过测试的准。
5.3 测试用例说明测试用例说明结构如表3所示。
表3 测试用例说明1 测试用例说明名称2 测试项3 输入说明4 输出说明5 环境要求6 特殊的规程说明7 用例间的依赖关系由于测试用例可能被由多个小组长期使用的多个测试设计说明引用,所以在测试用例说明中必须包含足够具体的信息以便重复使用。
下面给出本说明每一章的详细内容。
5.3.1 测试用例说明名称(本说明的第1章)给本测试用例说明取一个专用名称5.3.2 测试项(本说明的第2章)规定并简要说明本测试用例所要涉及的项和特性、对于每一项、可考虑引用以下文件:需求说明书、设计说明书、用户手册、操作手册。
5.3.3 输入说明(本说明的第3章)规定执行测试用例所需的各个输入。
有些输入可以用值(允许适当的误差)来规定。
而另一些输入,如常数表或事务文件可以用名来规定。
规定所有合适的数据库、文件、终端信息、内存常驻区域和由操作系统传送的值。
规定各输入间所需的所有关系(如时序关系等)。