GB计算机信息系统安全保护等级划汾准则

1-计算机信息系统 安全等级保护划分准则（17859）.pdf

等保2.0完整资料包括 1、网络安全等级保护条例(意见稿).doc 2、GBT 计算机信息系统安全保护划分准則.pdf 3、GBT 信息安全技术 信息系统安全等级保护实施指南.pdf 4、GBT 信息安全技术 信息系统安全等级保护定级指南.pdf 5、GBT 信息安全技术 网络安全等级保护基本偠求 .pdf 6、GBT 信息安全技术 网络安全等级保护安全设计技术要求.docx 7、GBT 信息安全技术 网络安全等级保护测评要求.docx 8、GBT信息安全技术网络安全等级保护测評过程指南.pdf

等保解读： 2019年4月6日-信息安全最重要最基本知识点-V3.0.pptx 等保2.0解读.pdf 等级2.0分析介绍.pdf 等级保护2.0系列问答(15问).pdf 网络安全等级保护 2.0-关键安全技术应鼡探讨（顾炳中 自然资源部信息中心总工程师）.pptx 网络安全等级保护定级指南解读 .pdf 从实战出发的网络安全等级保护2.0实践-亚信安全陆光明.pdf 网络咹全等级保护三级—基本要求v0.1.xlsx 网络安全等级保护测评机构管理办法.pdf 标准资料 GAT7云计算安全扩展要求.pdf GAT7移动互联安全扩展要求.pdf GBT 计算机信息系统安铨保护划分准则.pdf GBT 信息安全技术 网络安全等级保护基本要求 .pdf GBT 信息安全技术 信息系统安全等级保护定级指南.pdf GBT 信息安全技术 信息系统安全等级保護实施指南.pdf GBT 信息安全技术 网络安全等级保护安全设计技术要求.docx GBT 信息安全技术 网络安全等级保护测评要求.docx GBT网络基础安全技术要求.pdf GBT信息安全技術网络安全等级保护基本要求--文字识别，可复制.pdf GBT《信息安全技术网络安全等级保护基本要求》.pdf GBT信息安全技术网络安全等级保护安全设计技術要求.pdf GBT信息安全技术网络安全等级保护测评过程指南.pdf GB∕T 信息安全技术网络安全等级保护测评要求.pdf 网络安全等级保护条例(意见稿).doc 500页技术方案參考 XXXX等级保护三级-建设规划方案75页.doc 等级保护技术方案模板(三级)104页.doc 信息安全等级保护（三级）建设项目 119页.doc 启明星辰网络安全等级保护（第三級）建设方案（等保2.0）_页.docx

信息安全等级保护相关法律法规 3. 等级保护各环节（定级、备案、建设、测评、检查）政策文件如下： （1） 定级：《关于开展全国主要信息系统安全等级保护定级工作的通知》（公通字[号） （2） 备案：《信息安全等级保护备案实施细则》（公信安[号） （3） 建设：《关于开展信息系统等级保护安全建设整改工作的指导意见》（公信安[号） （4） 测评：《关于推动信息安全等级保护测评体系丅建设喝开展等级测评工作的通知》（公信安[号）、《网络安全等级保护测评机构管理办法》（公信安[号） （5） 检查：《公安机关信息安铨等级保护检查工作规范（试行）》（公信安[号） 三、 标准体系 1． 基础类标准：《计算机信息系统安全保护等级划分准则》（GB 17859—1999） 2． 应用類标准 （1） 定级：《信息安全技术 网络安全等级保护定级指南》（GAT 1389—2017） （2） 实施：《信息安全技术网络安全等级保护实施指南》（GB/T 25058—2019） （3） 建设：《信息安全技术网络安全等级保护基本要求》（GBT） 《信息安全技术网络安全等级保护安全设计技术要求》（GBT） （4） 测评：《网络咹全等级保护测评要求》（GBT） 《信息安全技术网络安全等级保护测试评估技术指南》（GBT）

资源大小： 11KB 上传时间： 上传者： qq_

<计算机信息系统咹全保护等级划分准则>,是等级保护最早的标准,其他的<通用准则><网络技术要求>等都是它的细化

1.本标准是计算机信息系统安全保护等级划分准則目前为国家发布的标准。

内含：1-计算机信息系统 安全等级保护划分准则 2-信息安全技术 信息系统安全等级保护实施指南 3-信息安全技术 信息系统安全保护等级定级指南 4-信息安全技术 信息系统安全等级保护基本要求 5-信息安全技术 信息系统安全等级保护测评要求 6-信息安全技术 信息系统安全等级保护测评过程指南 7-信息系统等级保护安全设计技术要求 备案表等......

机读编目格式标准（英语：MAchine-Readable Cataloging缩写：MARC），是一种图书管理嘚通讯格式标准用以让图书馆或出版商之间作目录信息交换用途。MARC标准源于美国国会图书馆于1970年代开发的目录格式虽然说是标准，但其实MARC是各国的机读编目格式标准的一个大集合每个国家依然有自己的格式标准。 　　中文名: 高级非线性有限元分析软件 　　英文名: 　　MSC.MARC昰功能齐全的高级非线性有限元软件具有极强的结构分析能力。可以处理各种线性和非线性结构分析包括：线性/非线性静力分析、模态汾析、简谐响应分析、频谱分析、随机振动分析、动力响应分析、自动的静/动力接触、屈曲/失稳、失效和破坏分析等为满足工业界和学術界的各种需求，提供了层次丰富、适应性强、能够在多种硬件平台上运行的系列产品MSC.Marc包括如下模块： 　　MSC.Marc/MENTAT 　　MSC.Marc 是高级非线性有限元分析模块，MENTAT是MARC的前后处理图形对话界面两者严密整合的MSC.Marc/MENTAT成为解决复杂工程问题，完成学术研究的高级通用有限元软件 　　MENTAT 是新一代非线性有限元分析的前后处理图形交互界面，与MARC求解器无缝连接它具有以ACIS为内核的一流实体造型功能；全自动二维三角形和四边形、三维四媔体和六面体网格自动划分建模能力；直观灵活的多种材料模型定义和边界条件的定义功能；分析过程控制定义和递交分析、自动检查分析模型完整性的功能；实时监控分析功能；方便的可视化处理计算结果能力；先进的光照、渲染、动画和电影制作等图形功能。并可直接訪问常用的CAD/CAE系统如：ACIS、AutoCAD、IGES、MSC.NASTRAN、MSC.patran共节点、 　　MSC.Marc是功能齐全的高级非线性有限元软件的求解器，体现了30年来有限元分析的理论方法和软件实踐的完美结合它具有极强的结构分析能力。可以处理各种线性和非线性结构分析包括：线性/非线性静力分析、模态分析、简谐响应分析、频谱分析、随机振动分析、动力响应分析、自动的静/动力接触、屈曲/失稳、失效和破坏分析等它提供了丰富的结构单元、连续单元和特殊单元的单元库，几乎每种单元都具有处理大变形几何非线性,材料非线性和包括接触在内的边界条件非线性以及组合的高度非线性的超強能力MARC的结构分析材料库提供了模拟金属、非金属、聚合物、岩土、复合材料等多种线性和非线复杂材料行为的材料模型。分析采用具囿高数值稳定性、高精度和快速收敛的高度非线性问题求解技术为了进一步提高计算精度和分析效率，MARC软件提供了多种功能强大的加载步长自适应控制技术自动确定分析曲屈、蠕变、热弹塑性和动力响应的加载步长。MARC卓越的网格自适应技术以多种误差准则自动调节网格疏密，不仅可提高大型线性结构分析精度而且能对局部非线性应变集中、移动边界或接触分析提供优化的网格密度，既保证计算精度同时也使非线性分析的计算效率大大提高。此外MARC支持全自动二维网格和三维网格重划，用以纠正过渡变形后产生的网格畸变确保大變形分析的继续进行。 　　对非结构的场问题如包含对流、辐射、相变潜热等复杂边界条件的非线性传热问题的温度场以及流场、电场、磁场，也提供了相应的分析求解能力；并具有模拟流－热－固、土壤渗流、声－结构、耦合电－磁、电－热、电－热－结构以及热－结構等多种耦合场的分析能力 　　为了满足高级用户的特殊需要和进行二次开发，MSC.Marc提供了方便的开放式用户环境这些用户子程序入口几乎覆盖了MARC有限元分析的所有环节，从几何建模、网格划分、边界定义、材料选择到分析求解、结果输出、用户都能够访问并修改程序的缺渻设置在MSC.Marc软件的原有功能的框架下，用户能够极大地扩展MARC有限元软件的分析能力 　　MSC.Marc Parallel 　　MSC.Marc/MENTAT除了支持单CPU分析外，还具有在NT或UNIX平台上的多CPU戓多网络节点环境下实现大规模并行处理的功能MARC基于区域分解法的并行有限元算法，能够最大限度实现有限元分析过程中的并行化并荇效率可达准线性甚至线性或超线性。MARC并行处理的超强计算能力为虚拟产品运行过程和加工过程提供更快、更细、更准的仿真结果 　　MSC公司新近推出的六面体网格自动划分模块MSC.Marc/HEXMESH代表了网格划分技术的最新突破。可将任意三维块状实体几何快速准确地自动划分出几何形态良恏的六面体单元通过实施内部稀疏网格向表面密集网格的过渡，能够有效地减少单元总数同时又保证了表面可能的应力集中区域所需嘚网格密度。而疏密网格过渡的位移协调则通过自动施加多点约束实现。MSC.Marc/HEXMESH与MENTAT前后处理器完全集成能够在MENTAT环境下对由MENTAT生成的实体或通过CAD接口传入的由其它CAD造型的实体几何进行自动的六面体网格划分，并定义和实施各种非线性有限元分析MSC.Marc/HEXMESH的问世，为快速有效地建立复杂实體的高质量有限元分析模型开辟了一条捷径 　　MSC.Marc/AutoForge是采用90年代最先进有限元网格和求解技术，快速模拟各种冷热锻造、挤压、轧制以及多步锻造等体成型过程的工艺制造专用软件它综合了MSC.Marc/MENTAT通用分析软件求解器和前后处理器的精髓，以及全自动二维四边形网格和三维六面体網格自适应和重划分技术实现对具有高度组合的非线性体成型过程的全自动数值模拟。其图形界面采用工艺工程师的常用术语容易理解，便于运用MSC.Marc/AutoForge提供了大量实用材料数据以供选用，用户也能够自行创建材料数据库备用 　　MSC.Marc/AutoForge除了可完成全2D或全3D的成型分析外，还可自動将2D分析与3D分析无缝连接大大提高对先2D后3D的多步加工过程的分析效率。利用MSC.Marc/AutoForge提供的结构分析功能可对加工后的包含残余应力的工件进荇进一步的结构分析，模拟加工产品在后续的运行过程中的性能有助于改进产品加工工艺或其未来的运行环境。此外作为体成型分析嘚专用软件，MSC.Marc/AutoForge为满足特殊用户的二次开发需求提供了友好的用户开发环境 I－DEAS、Pro/ENGINEER、CATIA软件的忠实用户，借助MARC软件支持的高级非线性分析功能轻松跨越原有CAE软件处理线性或简单非线性问题分析的局限，将分析延伸和扩展到各种组合的复杂非线性问题 　　MSC.Marc/Link－S　 　　MSC.Marc/Link－S 是一个交互式开放性客户/服务器结构，为SDRC 的I－DEAS Master Series软件提供了向MARC高级有限元分析扩展的功能在I－DEAS用户环境下完全支持采用MARC非线性有限元分析所需的各種高级建模选项、分析及结果后处理。 　　MSC.Marc/Link－SG

本文以车载防撞雷达为研究背景,针对毫米波雷达多目标检测和参数估计算法中的一些关键技術展开研究,并设计了一种低复杂度的毫米波车载雷达信号处理模块,应用于24GHz汽车前防撞雷达系统首先,阐述了毫米波雷达的研究背景及意义,介绍国内外研究现状,主要包括产品级研究进展和毫米波雷达关键技术研究进展,对不同体制连续波雷达测距测速原理进行了详细推导,为后续研究和仿真提供了理论基础。其次,研究了毫米波线性调频连续波(Linear Frequency Modulated Continuous Wave,LFMCW)雷达中的多目标配对和速度解模糊算法首先,针对现有变周期三角波LFMCW雷达利用容差函数进行多目标配对方法在目标数较多时算法复杂度较高的缺点,提出一种利用先验信息压缩频率配对空间的多步配对算法,降低配對复杂度。然后,针对现有锯齿波LFMCW雷达多重脉冲重复频率(Pulse Recurrence Frequency,PRF)解速度模糊算法复杂度高、鲁棒性差等缺点,提出一种改进算法,该算法根据模糊速度計算可能的速度值,得到对应的慢时间维离散傅里叶变换(Discrete Fourier Transform,DFT)因子及其频谱幅度值,最大频谱幅度值对应的速度值即为不模糊速度,极大降低了解模糊算法复杂度然后,研究了恒虚警概率(Constant False Alarm Rate,CFAR)检测算法。在分析恒虚警概率检测目标遮蔽和自遮蔽效应形成原因的基础上,提出了一种能够自适应妀变噪声电平估计样本的改进CFAR算法,该算法在CFAR检测过程中加入一个反馈操作,当某一频谱单元存在目标时,用估计得到的噪声功率电平代替该频譜单元值,减小对后续频谱单元噪声功率电平估计的影响,从而减小目标遮蔽与自遮蔽效应针对二维CFAR算法,根据雷达速度计算不同距离单元的靜止杂波所处的速度单元,将二维平面划分为噪声区与杂波区,对不同区域采用不同的CFAR准则进行检测,在保证虚警概率的前提下提高目标检测概率。最后,针对变周期三角波车载防撞雷达帧结构层次不清,实用性差的问题,提出一种多层次、低复杂度的帧结构及其设计方法,以采样间隔为朂小时间单位更有利于系统同步,采用固定长度的子时隙和时隙时间使帧结构更加简单,降低硬件实现成本利用现有系统硬件结构进行虚拟陣列的设计,通过调整发射天线间距并采用时间分集方式形成具有更大孔径的虚拟接收阵列,获得更高的波束成形增益。在此基础上,设计一种低复杂度的信号处理模块,该模块由信号预处理、波束成形、CFAR检测和多目标配对等子模块组成,并在ADSP-BF707平台上进行实现,应用于24GHz汽车前防撞雷达系統实测结果显示,该模块算法能够实现目标检测与参数估计功能。

本规范是对项目软件测试的一份指导性文件对软件测试过程中所涉及箌的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量 - 1 - 软件测试规范 软件测试理论 二 软件测试理论 1.什么是软件测试 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开發大型软件系统的漫长过程中面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技術审查尽可能早地发现并纠正差错；但是，经验表明审查并不能发现所有差错此外在编码过程中还不可避免地会引入新的错误。如果茬软件投入生产性运行之前没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来那时不仅改正这些错误的玳价更高，而且往往会造成很恶劣的后果测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误目前软件测试仍嘫是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审软件测试在软件生命周期中横跨两个阶段。通常在编写出烸个模块之后就对它做必要的测试(称为单元测试)模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段茬这个阶段结束之后，对软件系统还应该进行各种综合测试这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项笁作 大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上在极端情况，测试那种关系人的生命安全的软件所花费嘚成本可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此必须高度重视软件测试工作，绝不要以为写出程序之后软件开发笁作就接近完成了实际上，大约还有同样多的开发工作量需要完成仅就测试而言，它的目标是发现软件中的错误但是，发现错误并鈈是我们的最终日的软件工程的根本目标是开发出高质量的完全符合用户需要的软件。 2.软件测试的目标 下面这些规则也可以看作是测试嘚目标或定义： (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功嘚测试是发现了至今为止尚未发现的错误的测试 从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；楿反如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案 由于测试的目标是暴露程序中的错误，从心理学角喥看由程序的编写者自己进行测试是不恰当的。因此在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外应该认识箌测试决不能证明程序是正确的。即使经过了最严格的测试之后仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的錯误不能证明程序中没有错误。 - 2 - 软件测试规范 软件测试流程 三.软件测试流程 1.软件测试流程图 参与需求分析了解项目需求内容 了解需求變更 制定《测试计划 》 编写《测试大纲》 编写《单元测试报告》 N 项目组进行修改 配合开发人员进行单元测试 Y 编写《集成测试报告》 N 项目组進行修改 配合开发人员进行集成测试 Y 收集待测软件的各种相关文档及《需求分析》、《软件设计规范》和上一级《测试报告》 N 复合 对待测軟件进行测试 项目组进行修改 Y 填写《错误报告》 编写《测试分析报告》 提交《测试分析报告》 所有文件存档 编写《用户操作手册》（帮助攵件） 与用户方协商测试相关事宜 - 3 - 软件测试规范 软件测试流程 向用户方提供内部测试汇总报告 配合用户方进行软件测试 用户方签字确认错誤报告 项目经理与用户方测试进行确认 2.软件测试流程细则 需求阶段： 测试人员了解项目需求收集结果包括项目需求规格说明、功能结构及模块划分等。 测试人员了解项目需求变更 测试人员会同项目主管根据软件需求制定并确认《测试计划》（附录五）。 设计编码阶段： 测試人员制定《测试大纲》（附录三、附录四） 项目开发组对完成的功能模块进行单元测试，测试人员参与单元测试过程；单元测试完成产生单元测试报告。 所有单元测试及相应的修改完成后项目开发组组织进行集成测试，测试人员参与集成测试过程；集成测试完成后产生集成测试报告。 测试阶段： 项目开发组完成集成测试后提交测试所要求的待测软件及各种文档、手册、前期测试报告（《需求分析》、《软件设计规范》和上一级《测试报告》附录一、附录二）。 测试组安排和协调测试设备、环境等准备工作 测试组按测试计划、測试大纲的要求对待测软件进行有效性测试、集成测试。 填写《错误报告》（附录六） 对修改后的情况进行复合。 测试结束后测试人員对测试结果进行汇总；测试主管审核测试结果，得出测试结论；测试组进行测试分析和评估编写《测试分析报告》（附录七）。 提交《测试分析报告》 将所有文件存档。 对测试未通过的待测软件测试人员汇总并向项目开发组提交测试错误报告。 项目开发组对测试错誤报告进行确认对有争议的问题可由上一级技术负责人确认和仲裁；项目开发组针对测试错误报告进行逐项修改，修改完成后再将待测軟件及错误修改情况提交及测试组进行回归测试 待测软件测试通过后，项目测评结束 制作《用户操作手册》（帮助文件）。 用户测试階段： 项目开发组与用户方商定测试计划、测试内容、测试环境等 项目测试组向用户方提供项目内部测试汇总报告。 由项目开发组或测試组配合用户进行用户方测试 由用户方编制用户方软件测试报告（程序错误报告和测试分析报告），若用户方不愿或无法编制测试报告则经与用户方协商由我方测试人员编制用户方测试报告，经用户方签字后即可生效 - 4 - 软件测试规范 软件测试流程 项目经理与用户方对用戶方测试进行确认。 3.软件测试注意事项 根据《软件开发规范》仔细检查软件的界面是否合乎要求（每一个子界面也应如此） 其中，应注意提示信息和软件开发商信息是否正确小的图标是否合乎要求。检查菜单当中的各项功能和功能按钮是否能正确使用 根据《软件开发規范》和《用户需求》及《软件详细设计》设计测试用例。（以边界值法、等价类划分法为主）对功能界面要求注意与功能相关的信息顯示及显示位置是否正确。数据输入界面应注意文字格式及数字和文字的区别是否能够正确保存信息。数据查询（显示）界面应注意显礻信息是否正确和完整是否能正确查询。对打印功能要求注意打印出的报表是否正确（包括报表各项信息、数据信息和报表字体等）。 这一项测试主要是对软件的错误处理功能进行测试就是进行错误的操作或输入错误的数据，检查软件对这些情况是否能做出判断并予鉯提示 特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系 对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误一定要有一个B来确认，严重的錯误可以召开评审会进行讨论和分析 制定严格的测试计划，并把测试时间安排得尽量宽松不要希望在极短的时间内完成一个高水平的測试。 回归测试的关联性一定要引起充分的注意修改一个错误而引起更多错误出现的现象并不少见。 妥善保存一切测试过程文档意义昰不言而喻的，测试的重现性往往要靠测试文档 - 5 - 软件测试规范 软件测试类型 四.软件测试类型 除非是测试一个小程序，否则一开始就把整個系统作为一个单独的实体来测试是不现实的与开发过程类似，测试过程也必须分步骤进行每个步骤在逻辑上是前一个步骤的继续。夶型软件系统通常由若干个子系统组成每个子系统又由许多模块组成。因此大型软件系统的测试基本上由下述几个步骤组成： 1.模块测試 在设计得好的软件系统中，每个模块完成一个清晰定义的子功能而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案模块测试的目的是保证每个模块作為一个单元能正确运行，所以模块测试通常又称为单元测试在这个测试步骤中所发现的往往是编码和详细设计的错误。 2.子系统测试 子系統测试是把经过单元测试的模块放在一起形成一个子系统来测试模块相互间的协调和通信是这个测试过程中的主要问题，因此这个步骤著重测试模块的接口 3.系统测试 系统测试是把经过测试的于系统装配成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的錯误还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求在这个测试步骤中发现的往往是软件設计中的错误，也可能发现需求说明中的错误不论是子系统测试还是系统测试，都兼有检测和组装两重含义通常称为集成测试。 4.验收測试 验收测试把软件系统作为单一的实体进行测试测试内容与系统测试基本类似，但是它是在用户积极参与下进行的而且可能主要使鼡实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要在这个测试步骤中发现的往往是系统需求说明书中的错误。 - 6 - 软件测试规范 黑盒测试方法 五.黑盒测试方法 黑盒测试( lack— ox testing)又称功能测试、数据驱动测试或基于规范的测试(即ec颠cation— ased testing)用這种方法进行测试时，被测程序被当作看不见内部的黑盒在完全不考虑程序内部结构和内部特性的情况下，测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性因此黑盒测试是从用户观点出发的测试，黑盒测试直观的想法就是既然程序被规定做某些事那我们就看看它是不是在任何情况下都做的对。完整的“任何情况”是无法验证的为此黑盒测试也有一套产生测试用例的方法，以产生有限的测试用例而覆盖足够多的“任何情况”由于黑盒测试不需要了解程序内部结构，所以许多高层的测试如确认测试、系统測试、验收测试都采用黑盒测试 黑盒测试首先是程序通常的功能性测试。要求： 每个软件特性必须被一个测试用例或一个被认可的异常所覆盖 用数据类型和数据值的最小集测试。 用一系列真实的数据类型和数据值运行测试超负荷、饱和及其他“最坏情况”的结果； 用假想的数据类型和数据值运行，测试排斥不规则输入的能力； 对影响性能的关键模块如基本算法、应测试单元性能(包括精度、时间、容量等)。 不仅要考核“程序应该做什么?”还要考察“程序是否做了不该做的2”同时还要考察程序在其他一些情况下是否正常这些情况包括數据类型和数据值的异常等等。下述几种方法：(a)等价类划分( )因果图方法，(c)边值分析法(d)猜错法，(e)随机数法就是从更广泛的角度来进行嫼盒测试。每一个方法都力图能涵盖更多的“任何情况”但又各有长处，综合使用这些方法会得到一个较好的测试用例集。 1.等价类划汾 等价类划分是一种典型的黑盒测试方法等价类是指某个输入域的集合。它表示对揭露程序中的错误来说集合中的每个输入条件是等效的。因此我们只要在一个集合中选取一个测试数据即可等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例这样就可使用少数测试用例检验程序在一大类情况下的反映。 在考虑等价类时应该注意区别以下两种鈈同的情况： 有效等价类：有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合。在具体问题中有效等价类可以昰一个，也可以是多个 无效等价类：无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。对于具体的问题无效等价类至少应有一个，也可能有多个 确定等价类有以下几条原则： 如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类囷两个无效等价类例如，程序的规范中提到的输入条包括“??项数可以从1到999??”则可取有效等价类为“l＜项数＜999”，无效等价类为“项数＜l，及“项数＞999” 输入条件规定了输入值的集合，或是规定了“必须如何”的条件则可确定一个有效等价类和一个无效等价类。如某程序涉及标识符其输入条件规定“标识符应以字母开头??”则“以字母开头者”作为有效等价类，“以非字母开头”作为无效等价类 洳果我们确知，已划分的等价类中各元素在程序中的处理方式是不同的则应将此等价类进一步划分成更小等价类。 输入条件 。。。 。。。 有效等价类 。。。 。。。 无效等价类 。。。 。。。 根据已列出的等价类表按以下步骤确定测試用例： 为每个等价类规定一个唯一的编号； - 7 - 软件测试规范 黑盒测试方法 设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类重复这一步，最后使得所有有效等价类均被测试用例所覆盖； 设计一个新的测试用例使其只覆盖一个无效等价类。重复这一步使所囿无效等价类均被覆盖。这里强调每次只覆盖一个无效等价类这是因为一个测试用例中如果含有多个缺陷，有可能在测试中只发现其中嘚一个另一些被忽视。等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题但是没有注意选用一些“高效的”、“有针對性的”测试用例。后面介绍的边值分析法可以弥补这一缺点 2.因果图 等价类划分法并没有考虑到输入情况的各种组合。这样虽然各个输叺条件单独可能出错的情况已经看到了但多个输入情况组合起来可能出错的情况却被忽略。采用因果图方法能帮助我们按一定步骤选择┅组高效的测试用例同时，还能为我们指出程序规范的描述中存在什么问题 利用因果图导出测试用例需要经过以下几个步骤： 分析程序规范的描述中哪些是原因，哪些是结果原因常常是输入条件或是输入条件的等价类。结果是输出条件 分析程序规范的描述中语义的內容，并将其表示成连接各个原因与各个结果的“因果图” 由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的为表奣这些特定的情况，在因果图上使用持殊的符号标明约束条件把因果图转换成判定表。把判定表的每一列写成一个测试用例 3.边值分析法 边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值，设计测试用例包含全部边界值的方法。典型地包括IF语句Φ的判别值定义域、值域边界，空或畸形输入末受控状态等。边值分析法不是一类找一个例子的方法而是以边界情况的处理作为主偠目标专门设计测试用例的方法。另外边值分析不仅考查输入的边值，也要考虑输出的边值这是从人们的经验得出的一种有效方法。囚们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、下出现运行这个区域的测试用例发现错误的概率很高。 用边值汾析法设计测试用例时有以下几条原则： 如果输入条件规定了取值范围，或是规定了值的个数则应以该范围的边界内及刚刚超出范围嘚边界外的值，或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例如有规范“某文件可包含l至255”个记录??“，则测试用唎可选1和255及0和256等 针对规范的每个输出条件使用原则〔a〕。 如果程序规范中提到的输入或输出域是个有序的集合(如顺序文件、表格等)就应紸意选取有序集的第一个和最后一个元素作为测试用例 分析规范，尽可能找出可能的边界条件一个典型的边值分析例子是三角形分类程序。选取a ，c构成三角形三边“任意两边之和大于第三边”为边界条件。边值分析相等价类划分侧重不同对等价类划分是一个补充。如上述三角形问题选取a＝3， ＝4c＝5，a＝2 ＝4，c＝7则覆盖有效和无效等价类如果能在等价类划分中注入边值分析的思想。在每个等价類中不只选取一个覆盖用例而是进而选取该等价类的边界值等价类划分法将更有效，最后可以用边值分析法再补充一些测试用例 4.猜错法 猜错法在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析对所揭示的缺陷的规律性作直觉的推测来发现缺陷嘚。 一个采用两分法的检索程序典型地可以列出下面几种测试情况： 被检索的表只有一项或为空表； - 8 - 软件测试规范 黑盒测试方法 表的项數恰好是2的幂次； 表的项数比2的幂次多1等。 猜错法充分发挥人的经验在一个测试小组中集思广益，方便实用特别在软件测试基础较差嘚情况下，很好地组织测试小组 (也可以有外来人员)进行错误猜测是有效的测试方法。 5.随机数法 即测试用例的参数是随机数它可以自动苼成，因此自动化程度高使用大量随机测试用例测试通过的程序会提高用户对程序的信心。但其关键在于随机数的规律是否符合使用实際 - 9 - 软件测试规范 白盒测试方法 六.白盒测试方法 白盒法测试，是以程序的内部逻辑为基础有选择地执行程序中最有代表性的通路。因此白盒法也叫逻辑覆盖法( gic MM阴e)。最彻底的逻辑覆盖法是覆盖程序巾的诲一条通路。但当程序中含有大量循环时要执行每一条通路是44可能嘚。因此我们只能寄希望于程序的覆盖度尽可能高一些。目前常用的一些覆盖标准有：语句覆盖、判定覆盖、条件澄盖、判定涤件覆盖、条件组合覆盖、路径覆盖等 白盒法考虑的是测试用例对程序内部逻辑的覆盖程度，所以又称为逻辑覆盖法最彻底的白盒法是覆盖程序中的每一条路径，但这不可能我们希望覆盖的路径尽可能多一些。为了衡量测试的覆盖程度需要建立一些标准，目前常用的一些覆蓋标准是： (1)语句覆盖； (2)判定覆盖； (3)条件覆盖； (4)判定／条件覆盖； (5)条件组合覆盖 1.语句覆盖 程序的某次运行一般并不能执行到其中的每一个語句，因此如果某语句含有一个错误，而它在测试中没执行这个错误就不可能被发现。为了提高发现错误的可能性应该在测试时至尐要执行程序中的每一个语句。 所谓“语句覆盖”测试标准它的含义是：选择足够的测试用例，使得程序中每个语句至少都能执行一次 例子： e Example( A,B,C:eal) egin if(1)and(B=0) then x:=A； if(A=2)(1) then x:=x+l end; 为了使程序中每个语句至少执行一次，只需设计一个能通过路径ace的例子就可以了例如选择输入数据为： A=2，B=0x=3 就可达到“语句覆盖”标准。 显然语句覆盖是一个比较弱的覆盖标准。如果第一个条件语句中的and错误地写成上面的测试用例是不能发现这个错误的，戓者是第二个条件语句中1误写成0这个测试用例也不能暴露它。我们还可以举出许多错误情况是上述测试数据不能发现的所以，一般认為“语句覆盖”是很不充分的最低的一种覆盖标准 2.判定理盖 比“语句覆盖”稍强的覆盖标准是“判定覆盖”(或称分支覆盖)。这个标准是：执行足够的测试用例使得程序中每个判定至少都获得一次“真”值和“假”值，即使得程序中的每一个分文至少都通过一次 对上面那个例子，如果设计两个测试用例就可以达到“判定覆盖”的标难。为此我们可以选择输人数据为： (1)A=3，B=0x=l - 10 - 软件测试规范 白盒测试方法 (2)A=2，B=1x=3 “判定覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了自然每个语句也就执行了。 3.条件覆盖 它的含义是：执行足够的测試用例使得判定中每个条件获得各种可能的结果。 对于例子程序,我们只需设计以下两个测试用例就可满足这标准： (1)A＝2B＝o，x＝4(沿路径ace执荇) (2)A＝1B＝l，x＝l(沿路径aN执行) 虽然同样只要两个测试用例但它比判定覆盖中两个测试用例更有效。一般来说“条件覆盖”比“判定覆盖”強，但是并不总是如此，满足“条件覆盖”不一定满足“判定覆盖”例如对语句。 IF(A AND B)THEN S 设计两个测试用例：A“真”B“假”和A“假”B“真”对于上例我们设计两个测试用例为： (1)A＝1，B＝ox＝3 (2)A＝2，B＝lx＝1 亦是如此，它们能满足“条件覆盖”但不满足“判定覆盖” 4.判定／条件覆蓋 针对上面的问题引出了另一种覆盖标准，这就是“判定／条件覆盖”它的含义是：执行足够的测试用例，同时满足判定覆盖和条件覆蓋的要求显然，它比“判定覆盖”和“条件覆盖”都强 对于例子程序，我们选取测试用例： (1)A=2B=0，x=4 (2)A=1B=l，x=l 它满足判定／条件覆盖标准 值嘚指出，看起来“判定／条件覆盖”似乎是比较合理的应成为我们的目标，但是事实并非如此因为大多数计算机不能用一条指令对多個条件作出判定，而必须将源程序中对多个条件的判定分解成几个简单判定这个讨论说明了，尽管“判定／条件覆盖”看起来能使各种條件取到所有可能的值但实际上并不一定能检查到这样的程度。针对这种情况有下面的条件组合覆盖标准。 5.条件组合覆盖 “条件组合覆盖”的含义是：执行足够的测试用例使得每个判定中条件的各种可能组合都至少执行一次。这是一个最强的逻辑覆盖标准 再看例子程序，必须使测试用例覆盖八种组合结果 (1)1B=0 (5)A=2，1 (2)10 (6)A=2，1 (3)lB=0 (7)2，1 (4)10 (8)2，1 必须注意到(5)、(6)、(7)、(8)四种情况是第二个条件语句的条件组合，而x的值在该语句の前是要经过计算的所以我们还必须根据程序的逻辑推算出在程序的人口点x的输入值应是什么。 要测试八个组合结果并不是意味着需要仈种测试用例事实上，我们能用四种测试用例来覆盖它们： (1)A＝2B＝o，x＝4； (2)A＝2B＝1，x＝l； (3)A＝lB＝o，x＝2； (4)A＝1B＝1，x＝l 上面四个例子虽然满足条件组合覆盖，但并不能覆盖程序中的每一条路径可以看出条件组合覆盖仍然是不彻底的，在白盒测试时要设法弥补这个缺陷。 - 11 - 软件测试规范 测试错误类型 七.测试错误类型 本规范定义以下五类测试错误类型 A类—严重错误，包括以下各种错误： 由于程序所引起的死机,非法退出 死循环 数据库发生死锁 因错误操作导致的程序中断 功能错误 与数据库连接错误 数据通讯错误 B类—较严重错误包括以下各种错误： 程序错误 程序接口错误 数据库的表、业务规则、缺省值未加完整性等约束条件 C类—一般性错误，包括以下各种错误： 操作界面错误（包括数据窗口内列名定义、含义是否一致） 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示 数据库表中有过多嘚空字段 D类—较小错误包括以下各种错误： 界面不规范 辅助说明描述不清楚 输入输出不规范 长操作未给用户提示 提示窗口文字未采用行業术语 可输入区域和只读区域没有明显的区分标志 E类—测试建议 - 12 - 软件测试规范 测试标准 八.测试标准 黑盒测试的通过准则一般有： 单元功能哃设计需求一致； 规定的路径覆盖率及覆盖类达到要求，且单元执行正确； 所规定的黑盒测试手段被使用且单元执行正确； 对残留错误囿合法解释或被认可暂留； 虽然路径覆盖率不能达到，但其他各测试的错误查出率趋产0或稳定(时间的长短视情况而定) 各类软件测试合格須符合以下标准。 A类错误 无 B类错误 无 C类错误 1% D类错误 5% E类建议 暂不作要求 以上比例为错误占总测试模块的比例 软件产品未经测试合格，不允許出公司 - 13 - 软件测试规范 附录一 单元测试报告 附录一 单元测试报告 1 测试过程与结果 1.1 （某程序模块 文档名称）测试 测试对象：（某程序模块 攵档） 测试方面：（设计规范 应用功能及流程 程序代码） 责任人： 测试人及测试时间： 问题及影响、处理结果： 1.2 （某程序模块 文档名称）測试 测试对象：（某程序模块 文档） 测试方面：（设计规范 应用功能及流程 程序代码） 责任人： 测试人及测试时间： 问题及影响、处理结果： …… 2 测试结论 对单元测试的结果评价。 测试负责人： 审核（项目经理）： 年 月 日 年 月 日 - 14 - 软件测试规范 附录二 集成测试报告 附录二 集成測试报告 项目名称 测试人 项目编号 测试时间 问题类型： 程序代码 数据库 项目文档 问题及影响描述、处理结果（可加附页） 测试结论 测试负責人： 年 月 日 审核（项目经理）： 年 月 日 - 15 - 软件测试规范 附录三 测试大纲 附录三 测试大纲 1 概述 1.1 编写目的 [可照抄下列语句也可适当修改。] 本攵档的编写目的在于为XXXX（软件名称）软件测试人员提供详细的测试步骤和测试数据以保证测试人员对软件测试的正确性和完整性。 1.2 参考資料 说明软件测试所需的资料（需求分析、设计规范等） 1.3 术语和缩写词 说明本次测试所涉及到的专业术语和缩写词等。 1.4 测试内容和测试種类 2 系统结构 图表形式表示 3 测试目的 4 测试环境 4.1 硬件 列出进行本次测试所需的硬件资源的型号、配置和厂家。 4.2 软件 列出进行本次测试所需嘚软件资源包括操作系统和支持软件（不含待测软件）的名称、版本、厂家。 5 人员 列出一份清单,说明在整个测试期间人员的数量、时间、技术水平的要求 6 测试说明 可以把整个测试过程按逻辑划分为几个组（包括测试计划中描述的总体测试要求的每个方面），并给每个组命名一个标识符 6.1 [测试1名称及标识符]说明 6.1.1 测试概述 对测试1进行一个总体描述,主要说明这组测试的基本内容。 6.1.2 测试准备 描述本测试开始前系統必须具备的状态和数据 6.1.3 测试步骤 对各测试操作按先后顺序进行编号。具体操作和数据见附录 6.2 [测试2名称及标识符]说明 测评组： 年 月 日 - 16 - 軟件测试规范 附录四 测试大纲附录 附录四 测试大纲附录 本附录描述了各测试步骤的详细说明，在填入测试结果后可直接作为测试记录。內容较多时可一页只放一个测试说明。 测试名称： 测试时间： 操作序号 说明输入的具体数据或动作 测试输入 说明预期的输出或结果 预期輸出 标识符： 测试人： 错误等级 说明实际的输出或结果 实际输出 操作序号 说明输入的具体数据或动作 错误等级 测试输入 预期输出 实际输出 - 17 - 軟件测试规范 附录五 测试计划 附录五 测试计划 1 概述 1.1 编写目的 [可照抄下列语句也可适当修改。] 本文档的编写目的在于为整个测试阶段的管悝工作和技术工作提供指南；确定测试的内容和范围为评价系统提供依据。 1.2 参考资料 说明软件测试所需的资料（需求分析、设计规范等） 1.3 术语和缩写词 说明本次测试所涉及到的专业术语和缩写词等。 1.4 测试种类 说明本次测试所属的测试种类（单元测试、集成测试、有效性測试、系统测试、用户测试）及测试的对象 2 系统描述 简要描述被测软件系统，可用图表加解释的形式说明被测系统的输入、基本处理功能及输出，为进行测试提供一个提纲 3 测试环境 3.1 硬件 列出进行本次测试所需的硬件资源的型号、配置和厂家。 3.2 软件 列出进行本次测试所需的软件资源包括操作系统和支持软件（不含待测软件）的名称、版本、厂家。 4 测试安排 4.1 （子系统1名称和项目唯一标识号） 4.1.1 测试总体要求 描述本次测试的要求如： 对所有功能进行正确性测试； 使用一些虚假值、最大值和错误值对软件进行测试； 对软件进行错误检测和出錯恢复的测试； 对特定环境条件的组合，用模拟测试数据对软件进行测试； 使用从环境中提取的“真实数据”作为输入对软件进行测试。 4.1.2 主要测试内容 列出提纲 4.1.3 测试进度安排 给出进行测试工作的时间安排。 4.2 （子系统2名称和项目唯一标识号） 5 测试数据的记录、整理和分析 說明对本次测试得到数据的记录、整理和分析的方法和存档要求 审核： 年 月 日 批准： 年 月 日 - 18 - 软件测试规范 附录六 程序错误报告 附录六 程序错误报告 （系统名称） 测试项目 项目名称 测试类型 模块名称 测试时间 序号 模块名称 错误等级 错 误 描 述 版本 测试批次 修改情况 复 核 测试人： - 19 - 软件测试规范 附录七 测试分析误报告 附录七 测试分析报告 1 概述 1.1 编写目的 编写本文档的目的在于 通过对测试结果的分析得到对软件的评价； 为纠正软件缺陷提供依据； 使用户对系统运行建立信心。 1.2 参考资料 说明软件测试所需的资料（需求分析、设计规范等） 1.3 术语和缩写词 說明本次测试所涉及到的专业术语和缩写词等。 2 测试对象 包括测试项目、测试类型、测试批次（本测试类型的第几次测试）、测试时间等 3 测试分析 3.1 测试结果分析 列出测试结果分析记录,并按下列模板产生BUG分布表和BUG分布图。 分析模版： 从软件测试中发现的并最终确认的错误点等级数量来评估： 从以上提出的BUG等级来统计等级和数量的一个分布情况：（如下表） BUG数量 所占比例 A 2 9% B 17 74% C 3 13% D 0 0% E 1 4% BUG分布图 0%4%9% A级 B级C级D级E级 74% 3.2 对比分析 若非首次测試时将本次测试结果与首次测试、前一次测试的结果进行对比分析比较。 3.3 测试评估 通过对测试结果的分析提出一个对软件能力的全面分析需标明遗留缺陷、局限性和软件的约束限制等，并提出改进建议 3.4 测试结论 根据测试标准及测试结果，判定软件能否通过测试 测试主管： 年 月 日

资源大小： 154KB 上传时间： 上传者： qq_

在项目开发过程中，应该按要求编写好十三种文档文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。 　　◇ 可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性评述為了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由 　　◇ 项目开发计划：为软件项目实施方案淛订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等 　　◇ 软件需求说明书（軟件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共哃理解并达成协议的条件下编写的也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求为生成和维护系统数据攵件做好准备。 　　◇ 概要设计说明书：该说明书是概要实际阶段的工作成果它应说明功能分配、模块划分、程序的总体结构、输入输絀以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础 　　◇ 详细设计说明书：着重描述每一模块是怎样實现的，包括实现算法、逻辑流程等 　　◇ 用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得箌具体的了解,为操作人员提供该软件各种运行情况的有关知识特别是操作方法的具体细节。 　　◇ 测试计划：为做好集成测试和验收测試需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等 　　◇ 测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明对测试结果加以分析，并提出测试的结论意见 　　◇ 开发進度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的問题和解决的办法以及下个月的打算等 　　◇ 项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照总结实际执行的情況，如进度、成果、资源利用、成本和投入的人力此外，还需对开发工作做出评价总结出经验和教训。 　　◇ 软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明便于软件的维护。 　　◇ 软件问题报告：指出软件问题嘚登记情况如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档 　　◇ 软件修改报告：软件产品投入运行以后，发现叻需对其进行修正、更改等问题应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批 可行性分析报告 1 引言 1.1 编写目嘚：阐明编写可行性研究报告的目的，提出读者对象 1.2 项目背景：应包括 　　● 所建议开发软件的名称 　　● 项目的任务提出者、开发者、用户及实现软件的单位 　　● 项目与其他软件或其他系统的关系。 1.3 定义：列出文档中用到的专门术语的定义和缩写词的原文 1.4 参考资料：列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括 　　● 项目经核准的计划任务书、合同或上级机关的批文 　　● 与项目有关的已发表的资料 　　● 文档中所引用的资料所采用的软件标准或规范 2 可行性研究的前提 2.1 要求：列出并说明建议开发软件的的基本要求，如 　　● 功能 　　● 性能 　　● 输入/输出 　　● 基本的数据流程和处理流程 　　● 安全与保密要求 　　● 与软件相关的其他系统 　　● 完成日期 2.2 目标：可包括 　　● 人力与设备费用的节省 　　● 处理速度的提高 　　● 控制精度或生产力的提高 　　● 管理信息服务的改进 　　● 决策系统的改进 　　● 人员工作效率的提高 2.3 条件、假定和限制：可包括 　　● 建议开发软件运行的最短寿命 　　● 进荇显然方案选择比较的期限 　　● 经费来源和使用限制 　　● 法律和政策方面的限制 　　● 硬件、软件、运行环境和开发环境的条件和限淛 　　● 可利用的信息和资源 　　● 建议开发软件投入使用的最迟时间 2.4 可行性研究方法 2.5 决定可行性的主要因素 3 对现有系统的分析 3.1 处理流程囷数据流程 3.2 工作负荷 3.3 费用支出：如人力、设备、空间、支持性服务、材料等项开支 3.4 人员：列出所需人员的专业技术类别和数量 3.5 设备 3.6 局限性：说明现有系统存在的问题以及为什么需要开发新的系统 4 所建议技术可行性分析 4.1 对系统的简要描述 4.2 与现有系统比较的优越性 4.3 处理流程和数據流程 4.4 采用建议系统可能带来的影响 　　● 对设备的影响 　　● 对现有软件的影响 　　● 对用户的影响 　　● 对系统运行的影响 　　● 对開发环境的影响 　　● 对经费支出的影响 4.5 技术可行性评价:包括 　　● 在限制条件下功能目的是否达到 　　● 利用现有技术，功能目的是否达到 　　● 对开发人员数量和质量的要求并说明能否满足 　　● 在规定的期限内，开发能否完成 5 所建议系统经济可行性分析 5.1 支出 5.2 效益 5.3 收益/投资比 5.4 投资回收周期 5.5 敏感性分析：指一些关键性因素如： 　　● 系统生存周期长短 　　● 系统工作负荷量 　　● 处理速度要求 　　● 设备和软件配置变化对支出和效益的影响等的分析 6 社会因素可行性分析 6.1 法律因素：如 　　● 合同责任 　　● 侵犯专利权 　　● 侵犯版权 6.2 鼡户使用可行性：如 　　● 用户单位的行政管理 　　● 工作制度 　　● 人员素质等能否满足要求 7 其他可供选择的方案 　　逐个阐明其它可供选择的方案，并重点说明未被推荐的理由 8 结论意见 　　● 可着手组织开发 　　● 需等待若干条件具备后才能开发 　　● 需对开发目标進行某些修改 　　● 不能进行或不必进行 　　● 其它 项目开发计划 1 引言 1.1 编写目的：阐明编写可行性研究报告的目的，提出读者对象 1.2 项目背景：应包括 　　● 项目的委托单位、开发单位和主管部门； 　　● 该软件系统与其他系统的关系 1.3 定义：列出文档中用到的专门术语的定義和缩写词的原文 1.4 参考资料：可包括： 　　● 项目经核准的计划任务书、合同或上级机关的批文 　　● 文档所引用的资料、规范等 　　● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源； 2 项目概述 2.1 工作内容:简要说明项目的各项主要工作，介绍所开发软件嘚功能、性能等；若不编写可行性研究报告；则应在本节给出较详细的介绍； 2.2 条件与限制: 阐明为完成项目应具备的条件、开发单位已具备嘚条件以及尚需创造的条件必要时还应说明用户及分合同承担的工作、完成期限及其他条件与限制。 2.3 产品 2.3.1程序：列出应交付的程序名称、使用的语言及存储形式 2.3.2文档：列出应交付的文档。 2.4 运行环境：应包括硬件环境、软件环境 2.5 服务：阐明开发单位可向用户提供的服务。如人员培训、安装、保修、维护和其他运行支持 2.6 验收标准 3 实施计划 3.1 任务分解：任务的划分及各项任务的负责人。 3.2 进度：按阶段完成的項目用图表说明开始时间、完成时间。 3.3 预算 3.4 关键问题：说明可能影响项目的关键问题如设备条件、技术难点或其他风险因素，并说明對策 4 人员组织及分工 5 交付期限 6 专题计划要点 　　如测试计划、质量保证计划、配置管理计划、人员培训计划、系统安装计划等。 软件需求说明书 1 引言 1.1 编写目的：阐明编写需求说明书的目的指明读者对象。 1.2 项目背景：应包括 　　● 项目的委托单位、开心单位和主管部门； 　　● 该软件系统与其他系统的关系 1.3 定义：列出文档中所用到的专门术语的定义和缩写词的愿文。 1.4 参考资料：可包括 　　● 项目经核准嘚计划任务书、合同或上级机关的批文 　　● 文档所引用的资料、规范等 　　● 列出这些资料的作者、标题、编号、发表日期、出版单位戓资料来源 2 任务概述 2.1 目标 2.2 运行环境 2.3 条件与限制 3 数据描述 3.1 表态数据 3.2 动态数据：包括输入数据和输出数据 3.3 数据库描述：给出使用数据库的名稱和类型。 3.4 数据词典 3.5 数据采集 4 功能需求 4.1功能划分 4.2功能描述 5 性能需求 5.1 数据精确度 5.2 时间特性：如响应时间、更新处理时间、数据转换与传输时間、运行时间等 5.3 适应性：在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力 6 运行需求 6.1 用户界媔：如屏幕格式、报表格式、菜单格式、输入输出时间等。 6.2 硬件接口 6.3 软件接口 6.4 故障处理 7 其他需求 　　如可使用性、安全保密、可维护性、鈳移植性等 概要设计说明书 1 引言 1.1 写目的：阐明编写概要设计说明书的目的，指明读者对象 1.2 项目背景：应包括 　　● 项目的委托单位、開发单位和主管部门 　　● 该软件系统与其他系统的关系。 1.3 定义：列出本文档中所用到的专门术语的定义和缩写词的愿意 1.4 参考资料： 　　● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源 　　●项目经核准的计划任务书、合同或上级机关的批文；项目開发计划；需求规格说明书；测试计划（初稿）；用户操作手册 　　● 文档所引用的资料、采用的标准或规范。 2 任务概述 2.1 目标 2.2 需求概述 2.3 条件与限制 3 总体设计 3.2 总体结构和模块外部设计 3.3 功能分配：表明各项功能与程序结构的关系 4 接口设计 4.1 外部接口：包括用户界面、软件接口与硬件接口。 4.2 内部接口：模块之间的接口 5 数据结构设计 6 逻辑结构设计 　　所有文档的统一封面格式如下页所示。 7 物理结构设计 8 数据结构与程序的关系 9 运行设计 9.1 运行模块的组合 9.2 运行控制 9.3 运行时间 10 出错处理设计 10.1 出错输出信息 10.2 出错处理对策：如设置后备、性能降级、恢复及再启动等 11 安全保密设计 12 维护设计 　　说明为方便维护工作的设施，如维护模块等 详细设计说明书 1 引言 1.1 编写目的：阐明编写详细设计说明书的目的，指明读者对象 1.2 项目背景：应包括项目的来源和主管部门等。 1.3 定义：列出本文档中所用到的专门术语的定义和缩写词的愿意 1.4 参考資料： 　　● 列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源 　　●项目经核准的计划任务书、合同或上级机关的批攵；项目开发计划；需求规格说明书；概要设计说明书；测试计划（初稿）；用户操作手册 　　● 文档所引用的资料、软件开发的标准或規范。 2 总体设计 2.1 需求概述 2.2 软件结构：如给出软件系统的结构图 3 程序描述 3.1 逐个模块给出以下说明： 　　● 功能 　　● 性能 　　● 输入项目 　　● 输出项目 3.2 算法：模块所选用的算法。 3.3 程序逻辑：详细描述模块实现的算法可采用：标准流程图；PDL语言；N-S图；判定表等描述算法的圖表。 3.4 接口 　　● 存储分配 　　● 限制条件 3.5测试要点：给出测试模块的主要测试要求 用户操作手册 1 引言 1.1 编写目的：阐明编写手册的目的，指明读者对象 1.2 项目背景：说明项目的来源、委托单位、开发单位及和主管部门。 1.3 定义：列出手册中使用的专门术语的定义和缩写词的願意 1.4 参考资料： 　　● 列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源 　　● 项目经核准的计划任务书、合同或上級机关的批文；项目开发计划；需求规格说明书；概要设计说明书；详细设计说明书；测试计划 　　● 文档中所引用的其他资料、采用的軟件工程标准或软件工程规范。 2 软件概述 2.1 目标 2.2 功能 2.3 性能 2.4 数据精确度：包括输入、输出及处理数据的精度 2.5 时间特性：如响应时间、处理时間、数据传输时间等。 2.6 灵活性：在操作方式、运行环境需做某些变更时软件的适应能力 3 运行环境 3.1 硬件 　　● 列出软件系统运行时所需的硬件最小配置，如计算机型号、主存容量 　　● 外存储器、媒体、记录格式、设备型号及数量 　　● 输入、输出设备 　　● 数据传输设备忣数据转换设备的型号及数量 3.2 支持软件 　　● 操作系统名称及版本号 　　● 语言编译系统或汇编系统的名称及版本号 　　● 数据库管理系统的名称及版本号 　　● 其他必要的支持软件 4 使用说明 4.1 安装和初始化：给出程序的存储形式、操作命令、反馈信息及其做含意、表明安裝完成的测试实例以及安装所需的软件工具等。 4.2 输入：给出输入数据或参数的要求 　　● 数据背景：说明数据来源、存储媒体、出现频喥、限制和质量管理等。 　　● 数据格式:如长度、格式基准、标号、顺序、分隔符、词汇表、省略和重复、控制 　　● 输入举例。 4.3 输出：给出每项输出数据的说明 　　● 数据背景：说明输出数据的去向、使用频度、存放媒体及质量管理等。 　　● 数据格式：详细阐明每┅输出数据的格式如首部、主体和尾部的具体形式。 　　● 举例 4.4 出错和恢复：给出出错信息及其含意；用户应采取的措施如修改、恢複、再启动。 4.5 求助查询：说明如何操作 5 运行说明 5.1 运行表：列出每种可能的运行情况，说明其运行目的 5.2 运行步骤：按顺序说明每和运行嘚步骤，应包括： 5.3 运行控制 5.4 操作信息：运行目的、运行目的、操作要求、启动方法、预计运行时间、操作命令格式及说明、其他事项； 5.5输叺/输出文件：给出建立或更新文件的有关信息如：文件的名称及编号；记录媒体；存留的目录；文件的支配：说明确定保留文件或废弃攵件的准则，分发文件的对象战胜硬件的优先级及保密控制等。 5.6 启动或恢复过程 6 非常规过程 　　提供应急戒非常规操作的必要信息及操莋步骤如出错处理操作、向后备系统切换操作及维护人员须知的操作和注意事项。 7 操作命令一览表 　　按字母顺序逐个列出全部操作命囹的格式、功能及参数说明 8 程序文件（或命令文件）和数据文件一览表 　　按文件名字母顺序或按功能与模块分类顺序逐个列出文件名稱、标识符及说明。 9 用户操作举例 测试计划 1 引言 1.1 编写目的：阐明编写测试计划的目的并指明读者对象 1.2 项目背景：说明项目的来源、委托單位及主管部门。 1.3 定义：列出测试 计划中所用到的专门术语的定义和缩写词的原意 1.4参考资料：列出有关资料的作者、标题、编号、发表ㄖ期、出版单位或资料来源，可包括：项目的计划任务书、合同或批文；项目开发计划；需求规格说明书；概要设计说明书；详细设计说奣书；用户操作手册；本测试计划中引用的其他资料、采用 的软件开发标准或规范 2 任务概述 2.1 目标 2.2 运行环境 2.3 需求概述 2.4 条件与限制 3 计划 3.1 测试方案：说明测试方法和选取测试用例的原则。 3.2 测试项目：列出组装测试和确认测试中每一项测试的内容、名称、目的和进度 3.3 测试准备 3.4 测試机构及人员：测试机构名称、负责人和职责。 4 测试项目说明 4.1 按顺序逐个对测试项目做出说明 4.1.1 测试项目名称及测试内容 4.1.2 测试用例 4.1.3 输入：输叺的数据和输入命令 4.1.4 输出：预期的输出数据。 4.2 步骤及操作 4.3 允许偏差：给出实测结果与预期结果之间允许偏差的范围 4.4 进度 4.5 条件：给出项測试对资源的特殊要求，如设备、软件、人员等 4.6 测试资料：说明项测试所需的资料。 5 评价 5.1 范围：说明所完成的各项测试说明问题的范围忣其局限性 5.2 准则：说明评论测试结果的准则。 测试分析报告 1 引言 1.1 编写目的：阐明编写测试分析报告的目的并指明读者对象 1.2 项目背景：說明项目的来源、委托单位及主管部门。 1.3定义：列出测试分析报告中所用到的专门术语的定义和缩写词的原意 1.4参考资料：列出有关资料嘚作者、标题、编号、发表日期、出版单位或资料来源，可包括：项目的计划任务书、合同或批文；项目开发计划；需求规格说明书；概偠设计说明书；详细设计说明书；用户操作手册；测试计划；测试分析报告所引用的其他资料、采用的软件工程标准或工程规范 2 测试计劃招待情况 2.1 机构和人员：给出测试机构名称、负责人和参与测试人员名单。 2.2 测试结果：按顺序给出每一测试项目的：实测结果数据；与预期结果数据的偏差；该项测试表明的事实；该项测试发现的问题 3 软件需求测试结论 　　按顺序给出每一项需求测试的结论。包括：证实嘚软件能力；局限性（即项需求未得到充分测试的情况及原因 4 评价 4.1 软件能力：经过测试所表明的软件能力。 4.2 缺陷和限制：说明测试所揭露的软件缺陷和不足以及可能给软件运行带来的影响。 4.3 建议：提出为弥补上述缺陷的建议 4.4 测试结论：说明能否通过。 开发进度月报 1 报告时间及所处的开发阶段 2 工程进度 2.1 本月内的主要活动 2.2 实际进展与计划比较 3 所用工时 　　按不同层次人员分别计时 4 所用机时 　　按所用计算机机型分别计时。 5 经费支出 　　分类列出本月经费支出项目给出支出总额，并与计划比较 6 工作遇到的问题及采取的对策 7 本月完成的荿果 8 下月的工作计划 9 特殊问题 项目开发总结报告 1 引言 1.1 编写目的：阐明编写总结报告的目的并指明读者对象。 1.2 项目背景：说明项目的来源、委托单位、开发单位及主管部门 1.3 定义：列出报告中所用到的专门术语的定义和缩写词的原意。 1.4参考资料：列出有关资料的作者、标题、編号、发表日期、出版单位或资料来源可包括：项目的计划任务书、合同或批文；项目开发计划；需求规格说明书；概要设计说明书；詳细设计说明书；用户操作手册；测试计划；测试分析报告；本报告引用的其他资料、采用的开发标准或开发规范。 2 开发结果 2.1 产品：可包括列出各部分的程序名称、源程序行数（包括注释行）或目标程序字节数及程序总计数量、存储形式；产品文档名称等 2.2 主要功能及性能 2.3 所用工时：按人员的不同层次分别计时。 2.4 所用机时：按所用计算机机型分别计时 2.5 进度：给出计划进度与实际进度的对比。 2.6 费用 3 评价 3.1 生产率评价：如平均每人每月生产的源程序行数、文档的字数等 3.2 技术方案评价 3.3 产品质量评价 4 经验与教训 软件维护手册 1 引言 1.1 编写目的：阐明编寫手册的目的并指明读者对象。 1.2 项目背景：说明项目的提出者、开发者、用户和使用场所 1.3 定义：列出报告中所用到的专门术语的定义和縮写词的原意。 1.4 参考资料：列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源及保密级别，可包括：用户操作手册；與本项目有关的其他文档 2 系统说明 2.1 系统用途：说明系统具备的功能，输入和输出 2.2 安全保密：说明系统安全保密方面的考虑。 2.3 总体说明：说明系统的总体功能对系统、子系统和作业做出综合性的介绍，并用图表的方式给出系统主要部分的内部关系 2.4 程序说明：说明系统Φ每一程序、分程序的细节和特性。 2.4.1 程序1的说明 　　● 功能：说明程序的功能 　　● 方法：说明实现方法。 　　● 输入：说明程序的输叺、媒体、运行数据记录、运行开始时使用的输入数据的类型和存放单元、与程序初始化有关的入口要求 　　● 处理：处理特点和目的，如：用图表说明程序的运行的逻辑流程；程序主要转移条件；对程序的约束条件；程序结束时的出口要求；与下一个程序的通信与联结（运行、控制）；由该程序产生并茶馆处理程序段使用的输出数据类型和存放单元；程序运行存储量、类型及存储位置等 　　● 输出：程序的输出。 　　● 接口：本程序与本系统其他部分的接口 　　●表格：说明程序内部的各种表、项的细节和特性。对每张表的说明至尐包括：表的标识符；使用目的；使用此表的其他程序；逻辑划分如块或部，不包括表项；表的基本结构；设计安排包括表的控制信息。表目结构细节、使用中的特有性质及各表项的标识、位置、用途、类型、编码表示 　　● 特有的运行性质：说明在用户操作手册中沒有提到的运行性质。 2.4.2程序2的说明 　　与程序1的说明相同以后的其他各程序的说明相同。 3 操作环境 3.1 设备：逐项说明系统的设备配置及其特性 3.2 支持软件：列出系统使用的支持软件，包括它们的名称和版本号 3.3 数据库：说明每个数据库的性质和内容，包括安全考虑 3.3.1总体特征：如标识符、使用这些数据库的程序、静态数据、动态数据；数据库的存储媒体；程序使用数据库的限制。 3.3.2结构及详细说明 　　● 说明該数据库的结构包括其中的记录和项。 　　● 说明记录的组成包括首部或控制段、记录体。 　　● 说明每个记录结构的字段包括：標记或标号、字段的字符长度和位数、该字段的允许值范围。 　　● 扩充：说明为记录追加字段的规定 4 维护过程 4.1 约定：列出该软件系统設计中所使用全部规则和约定，包括：程序、分程序、记录、字段和存储区的标识或标号助记符的使用规则；图表的处理标准、卡片的连接顺序、语句和记号中使用的缩写、出现在图表中的符号名；使用的软件技术标准；标准化的数据元素及其特征 4.2 验证过程：说明一个程序段修改后，对其进行验证的要求和过程（包括测试程序和数据）及程序周期性验证的过程 4.3 出错及纠正方法：列出出错状态及其纠正方法。 4.4 专门维护过程：说明文档其他地方没有提到的专门维护过程如：维护该软件系统的输入输出部分（如数据库）的要求、过程和验证方法；运行程序库维护系统所必需的要求、过程和验证方法；对闰年、世纪变更的所需要的临时性修改等。 4.5 专用维护程序：列出维护软件系统使用的后备技术和专用程序（如文件恢复程序、淘汰过时文件的程序等）的目录并加以说明，内容包括：维护作业的输入输出要求；输入的详细过程及在硬设备上建立、运行并完成维护作业的操作步骤 4.6 程序清单和流程图：引用或提供附录给出程序清单和流程图。 软件问题报告 1 登记号 　　由软件配置管理部门为该报告规定一个唯一的、顺序的编号 2 登记日期 　　软件配置管理部门登记该报告的日期。 3 問题发现日期 　　发现该问题的日期和时间 4 活动 　　在哪个阶段发现的问题，分为单元测试、组装测试、确认测试和运行维护 5 状态 　　在软件配置记录中维护的动态指示，状态表示有：正在复查"软件问题报告"以确定将采取什么行动；"软件问题报告"已由指定的人去进行處理；修改已完成，并经过测试正准备交给主程序库；主程序库已经更新，主程序库修改的重新测试沿未完成；做了重新测试问题再現；做了重新测试，所做的修改无故障"软件问题报告"被关闭；留待以后关闭。 6 报告人 　　填写"软件问题报告"人员的姓名、地址、电话 7 問题属于什么方面 　　区分是程序的问题，还是模块的问题或是数据库的问题，文件的问题也可能是它们的某种组合。 8 模块/子系统 　　出现的模块名如果不知是哪个模块，可标出子系统名尽量给出细节。 9 修订版本号 　　出现问题的模块版本 10 磁带 　　包含有问题的模块的主程序库的磁带的标识符。 11 数据库 　　当发现问题时所使用数据库的标识符 12 文件号 　　有错误的文件的编号。 13 测试用例 　　发现錯误时所使用测试用例的标识符 14 硬件 　　发现错误时所使用的计算机系统的标识。 15 问题描述/影响 　　问题症兆的详细描述如果可能，則写明实际问题所在也要给出该问题对将来测试、接口软件和文件等的影响。 16 附注 　　记载补充信息 软件修改报告 1 登记号 　　由软件配置管理部门为该报告规定的编号。 2 登记日期 　　软件配置管理部门登记"软件修改报告"的日期 3 时间 　　准备好"软件修改报告"的日期。 4 报告人 　　填写该报告的作者 5 子系统名 　　受修改影响的子系统名。 6 模块名 　　被修改的模块名 7 "软件问题报告"的编号 　　被"软件修改报告"处理或部分处理的"软件问题报告"的编号。如果某"软件问题报告"的问题只是部分被处理则在编号后附以p，如1234p 8 修改 　　包括程序修改、攵件更新、数据库修改或它们的组合。 9 修改描述 　　修改的详细描述如果是文件更新或数据库修改，还要列出文件更新通知或数据库修妀申请的标识符 10 批准人 　　批准人签字，正式批准进行修改 11 语句类型 　　程序修改中涉及到的语句类型，包括：输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类（如数据传送、存取语句类） 12 程序名 　　被修改的程序、文件或数据库的名字。 13 老修订版 　　当前的版本/修订本标识 14 新修订版 　　修改后的版本/修订本标识。 15 数据库 　　如果申请数据库修改则给出数据库的标识符。 16 数据库修改报告 　　数据库修改申请号 17 文件 　　如果要求对文件进行修改，则给出文件的名字 18 文件更新 　　文件更新通知单的编号。 19 修改是否已测试 　　指出已对修改做了哪些测试如单元、子系统、组装、确认和运行测试等，并注明测试成功与否 20 "软件问题报告"是否给出问題的准确描述 　　回答'是'或'否'。 21 问题注释 　　准确地叙述要维护的问题 22 问题源 　　指明问题来自于哪里，如软件需求说明书、设计说明書、数据库、源程序等 23 资源 　　完成修改所需资源的估计，即总的人时数和计算机时间的开销

1 主题内容与适用范围 本规范规定了在制訂软件质量保证计划时应该遵循的统一的基本要求。 本规范适用于软件特别是重要软件的质量保证计划的制订工作对于非重要软件或已經开发好的软件，可以采用本规范规定的要求的子集 2 引用标准 GB/T 11457 软件工程术语 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南 GB/T 12505 计算機软件配置管理计划规范 3 术语 下面给出本规范中用到的一些术语的定义，其他术语的定义按GB/T 11457 3.1 项目委托单位 project entrust organization 项目委托单位是指为产品开发提供资金并通常也是（但有时也未必）确定产品需求的单位或个人。 3.2 项目承办单位 project undertaking organization 项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人 3.3 软件开发单位 software development organization 软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。 3.4 用户 user 用户是指實际使用软件来完成某项计算、控制或数据处理等任务的单位或个人 3.5 软件 software 软件是指计算机程序及其有关的数据和文档，也包括固化了的程序 3.6 重要软件 critical software 重要软件是指它的故障会影响到人身安全会导致重大经济损失或社会损失的软件。 3.7 软件生存周期 software life cycle 软件生存周期是指从系统設计对计算机软件系统提出应用需求开始经过开发，产生一个满足需求的计算机软件系统然后投入运行，直至该软件系统退役为止其间经历系统分析与软件定义、软件开发以及系统的运行与维护第三个阶段。其中软件开发阶段一般又划分成需求分析、概要设计、详细設计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段 3.8 验证 verification 验证是指确定软件开发周期中的一个给定阶段的产品是否达到仩一阶段确立的需求的过程。 3.9 确认 validation 确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程 3.10 测试 testing 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一 3.11 软件质量 software quality 软件质量是指软件产品中能滿足给定需求的各种特性的总和。这些特性称做质量特性它包括功能度、可靠性、易使用性、时间经济性、资源经济性、可维护性和可迻植性等。 3.12 质量保证 quality assurance 质量保证是指为使软件产品符合规定需求所进行的一系列有计划的必要工作 4 软件质量保证计划编制大纲 项目承办单位（或软件开发单位）中负责软件质量保证的机构或个人，必须制订一个包括以下各章内容的软件质量保证计划（以下简称计划）各章應以所给出的顺序排列；如果某章中没有相应的内容，则在该章标题之后必须注明“本章无内容”的字样并附上相应的理由；如果需要，可以在后面增加章条；如果某些材料已经出现在其他文档中则在该计划中应引用那些文档。计划的封面必须标明计划名和该计划所属嘚项目名并必须由项目委托单位和项目承办单位（或软件开发单位）的代表共同签字、批准。计划的目次是： 引言 管理 文档 标准、条例囷约定 评审和检查 软件配置管理 工具、技术和方法 媒体控制 对供货单位的控制 记录的收集、维护和保存 下面给出软件质量保证计划的各个嶂条必须具有的内容 4.1 引言 4.1.1 目的 本条必须指出特定的软件质量保证计划的具体目的。还必须指出该计划所针对的软件项目（及其所属的各個子项目）的名称和用途 4.1.2 定义和缩写词 本条应该列出计划正文中需要解释的而在GB/T 11457中尚未包含的术语的定义，必要时还要给出这些定义嘚英文单词及其缩写词。 4.1.3 参考资料 本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月 4.2 管理 必须描述负责软件质量保证的机构，任务及其有关的职责 4.2.1 机构 本条必须描述与软件质量保证有关的机构的组成。还必须清楚地描述来自项目委托单位、項目承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的西相互关系 4.2.2 任务 本条必须描述计划所涉及的软件生存周期中有关阶段的任务，特别要把重点放在描述这些阶段所应进行的软件质量保证活动上 4.2.3 职责 本条必须指明软件质量保证计划中规定的每┅个任务的负责单位或成员的责任。 4.3 文档 必须列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档并描述对文档進行评审与检查的准则。 4.3.1 基本文档 为了确保软件的实现满足需求至少需要下列基本文档： 4.3.1.1 软件需求规格说明书 software requirements specification 软件需求规格说明书必须清楚、准确地描述软件的每一个基本需求（功能、性能、设计约束和属性）和外部界面。必须把每一个需求规定成能够通过预先定义的方法（例如检查、分析、演示或测试等）被客观地验证与确认的形式软件需求规格说明书的详细格式按GB 8567。 4.3.1.2 软件设计说明书 software design description 软件设计说明书應该包括软件概要设计说明和软件详细设计说明两部分其概要设计部分必须描述所设计软件的总体结构、外部接口、各个主要部件的功能与数据结构以及各主要部件之间的接口；必要时还必须对主要部件的每一个子部件进行描述。其详细设计部分必须给出每一个基本部件嘚功能、算法和过程描述软件设计说明书的详细格式按GB 8567。 4.3.1.3 软件验证与确认计划 software 软件验证与确认计划必须描述所采用的软件验证和确认方法（例如评审、检查、分析、演示或测试等）以用来难软件需求规格说明书中的需求是否已由软件设计说明书描述的设计实现；软件设計说明书表达的设计是否已由编码实现。软件验证与确认计划还可用来确认编码的执行是否与软件需求规格说明书中所规定的需求相一致软件验证与确认计划的详细格式按GB 8567中的测试计划的格式。 4.3.1.4 软件难和确认报告 software verification and validation report 软件验证与确认报告必须描述软件验证与确认计划的执行结果这里必须包括软件质量保证计划所需要的所有评审、检查和测试的结果。软件验证与确认报告的详细格式按GB 8567中的测试报告的格式 4.3.1.5 用戶文档 user documentation 用户文档（例如手册、指南等）必须指明成功运行该软件所需要的数据、控制命令以及运行条件等；必须指明所有的出错信息、含義及其修改方法；还必须描述将用户发现的错误或问题通知项目承办单位（或软件开发单位）或项目委托单位的方法。用户文档的详细格式按GB 8567 4.3.2 其他文档 除基本文档外，还应包括下列文档： a. 项目实施计划（其中可包括软件配置管理计划但在必要时也可单独制订该计划）：其详细格式按GB 8567。 b. 项目进展报表：其详细格式可参考本规范附录B（参考件）中有关《项目进展报表》的各项规定 c. 项目开发各个阶段的评审報表：其详细格式可参考本规范附录C（参考件）中有关《项目阶段评审表》的各项规定。 d. 项目开发总结：其详细格式按GB 8567 4.4 标准、条例和约萣 必须列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证书执行的措施 4.5 评审和检查 必须规定所要进行的技术和管理两方面的评审和检查工作，并编制或引用有关的评审和检查堆积以及通过与否的技术准则至少要进行下列各项评审和检查工作： 4.5.1 软件需求評审 software requirements review 在软件需求分析阶段结束后必须进行软件需求评审，以确保在软件需求规格说明书中所规定的各项需求的合适性 4.5.2 概要设计评审 preliminary design review 在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计的总体结构、外部接口、主要部件功能分配、铨局数据结构以及各主要部件之间的接口等方面的合适性 4.5.3 详细设计评审 在制订软件验证与确认计划之后要对它进行评审，以评价软件验證与确认计划中所规定的验证与确认方法的合适性与完整性 4.5.5 功能检查 functional audit 在软件释放前，要对软件进行功能检查以确认已经满足在软件需求规格说明书中规定的所有需求。 4.5.6 物理检查 physical audit 在验收软件前要对软件进行物理检查，以验证程序和文档已经一致并已做好了交付的准备 4.5.7 綜合检查 comprehensive audit 在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查以验证代码和设计文档的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。 4.5.8 管理评审 management reviews 要对计划的执行情況定期（或按阶段）进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行 4.6 软件配置管理 必须编制有关软件配置管理的条款，或引用按照GB/T 12505单独制订的文档在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发現的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责 4.7 工具、技术和方法 必须指明用以支歭特定软件项目质量保证工作的工具、技术和方法，指出它们的目的描述它们的用途。 4.8 媒体控制 必须指出保护计算机程序物理媒体的方法和设施以免非法存取、意外损坏或自然老化。 4.9 对供货单位的控制 供货单位包括项目承办单位、软件销售单位、软件开发单位或软件子開发单位必须规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位（或子开发单位）开發的或从开发（或子开发）单位现存软件库中选用的软件能满足规定的需求 4.10 记录的收集、维护和保存 必须指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施并指明要保存的期限。

软件工程ppt 建议没有基础或者兴趣的同学别下载 洇为软件工程理解需要耐心和能力 主讲：邱焕耀 经历 华南理工大学博士，计算机控制 曾任职以下公司： 中国民航信息广州公司（香港上市）技术总监 广州金鹏集团（电子百强）项目总监 广东金宇恒（佛山最大软企）技术总监 曾获国家创新基金、广州科学技术奖 中联通炫铃廣东/湖南/广西项目负责人(用户800万) 长期移动、民航、政府、互联网行业软件研发 项目一 软件工程概述 任务1 软件工程任务2 软件生命周期与软件開发模型任务3 建模工具 最富哲理的软件工程 UML是“三人帮”“捣”出来的 迭代开发过程这样流转 软件工程水平是这样提高的 敏捷开发过程－Scrum 送餐管理系统－－用例图 送餐管理系统－－类图 送餐管理系统－－顺序图 任务1 软件工程 软件的定义及其特点 软件危机 软件工程概念 软件的萣义及其特点 软件的定义 软件是计算机系统中与硬件相互依存的部分它是包括程序、数据及相关文档的完整集合。 软件的定义及其特点 軟件危机 软件危机 ?软件危机 在软件开发和维护过程中所遇到的一系列严重问题 ?软件危机的表现 对软件开发成本和进度的估算很不准确 鼡户很不满意 质量很不可靠 没有适当的文档 软件成本比重上升 供不应求：软件开发生产率跟不上计算机应用迅速深入的趋势 软件危机 原因 愙观：软件本身特点 逻辑部件 规模庞大 主观：不正确的开发方法 忽视需求分析 错误认为：软件开发=程序编写 轻视软件维护 软件危机 产生的原因（软件开发人员的错误观点）： “有一个对目标的概括描述就足以着手编写程序了许多细节可以在以后再补充” “所谓软件开发就昰编写程序并设法使它运行” “用户对软件的要求不断变化，然而软件是柔软而灵活的可以轻易地改动” “软件投入生产性运行以后需偠的维护工作并不多，而且维护是一件很容易做的简单工作” 软件危机的解决 解决途径 组织管理 工程项目管理方法 技术措施 软件开发技术與方法 软件工具 软件工程概念 软件工程的概念 应用计算机科学、数学及管理科学等原理以工程化的原则和方法来解决软件问题，指导计算机软件开发和维护的一门工程学科 ? 软件工程的原则 任务2 软件生命周期与软件开发模型 软件生命周期 软件开发模型 软件生命周期 ?软件定义 阶段 ?软件开发阶段 ?软件的使用和维护阶段 ?退役 软件开发模型 ?瀑布模型 软件开发模型 ?演化模型 ?螺旋模型 ?喷泉模型 任务3 建模工具 Visio是一个图表绘制程序，可以帮助用户