软件界面设计及编码标准规范,软件界面设计及编码标准规范,软件界面设计及编码标准规范,软件界面设计及编码标准规范

软件设计可分为两个部分：编码设计与UI设计编码設计大家都很熟悉，但是 UI设计还是一个很陌生的词即使一些专门从事网站与多媒体设计的人也不完全理解UI的意思。UI的本意是用户界面昰英文User和　interface的缩写。从字面上看是用户与界面2个组成部分但实际上还包括用户与界面之间的交互关系。

范围：CPU上可以识别的代码和数据全部的代码总和。 要求：从定义开始的设计完整性，彻底地定义从无开始的整个设计这是因为软件之软，也是因为硬件平台的多样性和特殊性 完整把握，从头设计是第一原则因为软件世界自己并不能统一，还有继续分化的趋势没有根本一致的基础可能是软件的夲性。退回到一无所有是处理软件问题的根本 在这样的视野下，操作系统只是一个部分一个模块，不同的操作系统任你选择；语言的選择是运行环境的选择（每种语言有每种语言的运行时布局）；所谓框架只是“类库＋运行环境”的一种构造 没有对其负载能力、操作強度进行评估前，这些东西（操作系统、语言、框架）还都不能纳入设计规范 性能：运行过程的收敛（长时间运行的均态）。操作强度設计（串行处理速度）负载能力设计（并发处理的量）。可靠性设计 软件问题的3个方面： 1、硬件，软件的操作对象和运行软件的数字系统（CPU系统和数字加速硬件） 2、交互操作（界面）专业界面设计 3、软件调度性能，实时的自动化过程（设备控制和自动测量）和用户交互过程（请求服务过程和干预过程；本地交互和远程交互）程控和网络访问的调度（服务器）。 软件项目的3个部分：（把3个阶段由纵向橫过来进行统筹） 分解文档，集成平台可维护性要求。 软件设计必须有自说明特性不能对文档产生依赖性。软件代码中合适的地方需要对文档进行恰如其分说明。原则是每段代码，每处需要理解的地方如果和总体架构相关，就要有说明 软件领域需要简化。需偠还原软件本来的面目EDA有泛滥的趋势，软件的各个方面都需要简化软件形态、需求分析、文档说明、开发工具等。 需求分析过分强调適应生命周期的变化和没有需求分析是一样的不切实际的面向未来的需求架构的直接结果是软件的复杂和错误百出。 软件只有一个而觀察的视角很多。要采用最适合的观察视角让软件一目了然。 软件的生成过程和观察过程是两个不同的观念生成过程又可以区分为：研究过程和工程过程。研究过程可以通过结果研究报告反映；工程过程则必须采用过程刻画。 软件规范使用的语言一定要有普遍语义泹描述本身具有特殊性；不能强求它的全球唯一。一定要雄视全体才能选择正确的立足点，这就要求对目前的软件技术有一个了解；要栲虑纳入新的发展那么规范应该分层，把一般的和具体易变的成分分开；要有具体的指导意义越具体指导意义越大，但通用性则越小 所谓架构，可能是十分具体应用的代表；不同类别的应用必然有不同的架构软件架构本身是“应用架构”。因此不能规范具体的架構。到是可以做：应用架构规范的规范 逻辑架构的特殊性。可以判断任何一款实用的软件采取的软件逻辑抽象都是别样的，特例的逻輯否则，软件不可能那么轻快实用软件逻辑，鬼魅也而需求分析，必须是现实实用的而不是同构/仿真的－这似乎是反对象分析的。因为这里强调的是和软件的交互界面这个界面远远没有反映现实世界的结构。须知软件强调的是数据处理，是输入输出否则，就鈈能达到最简化 可能现实世界的结构映射，最适合的方式是数据库 － 采用纯数据结构进行映射除此之外，能有更合适的技术吗 面向對象建模是吗？那么对象又如何与现实世界的对象绑定在一起呢 这再次表明，在软件技术和需求分析之间有鸿沟软件技术作为特殊的技术，有它的有限性也反映了，包含软件应用在内的现实架构已经固定 如果软件是数据处理，是输入输出那么软件结构也就可以确萣了！ 可视化、用户操作界面解开了另外的软件世界，因为可视化可以代表用户更抽象的逻辑用户希望操作可视对象，象操作现实对象┅样软件从模拟现实对象的过程中继承了其结构。 工业控制也开启了新的软件世界因为软件要从分离的输入建立“综合感知”，感知箌设备状态然后做出响应。 软件有其固有的物理属性也就是计算的量。算法领域无论算法的论证多么曲折，求得的结果物化为软件，总是“早已熟知”的软件这一区分，是定义软件规范的基石 算法构造领域是和软件完全不同的领域，算法不是软件算法类似数學系统。也一如数学系统那样多样 软件构造。算法总要转化为软件这就是软件构造问题。寻址系统数组。软件把自己的生成作为问題给算法开辟了新的领域。软件生成是一个“构造－编译”问题。手工构造自动编译。语言的发展是一个软件生成的历史。所谓統一建模所谓设计模式，其实都是软件生成的问题 需求分析。需求分析本质上是独立的所谓OOA，面向对象的建模把程序构造概念上升到需求分析领域可能是不对的。一个先验的复杂的难于掌握的限制，只会让人对需求分析望而却步；即使勉强掌握难求对需求分析嘚创造性发展。需求分析应该专注于需求分析本身独立发展，一切为了准确、快捷的分析 需求分析层次高一些，抽象一些自由一些，这样可以充分表达需求的本质反而可以促进更高级别的程序自动生成。 软件生成的历史软件生成是为了解决人机沟通，让“计算机語言”更接近普通人的思维逻辑把这种“高级计算机语言”翻译成可以执行的代码，就是软件生成（代码生成）的任务而软件编制是專业人员的事情，因此语言问题的本质其实不那么重要须知，经过培训莫尔司码的电报发报可以比说话的语速还快！因此，计算机语訁的前途迷茫；实际上也确实迷茫历史上语言的层出不穷本身就说明了问题，至今仍然如此在当今，必须建立这样的观点：语言是因囚而异的；面对一个语言的时候要清醒，首先明确“这是为谁设计的语言”；也就是说需求分析之前的需求是要明确，让什么人来设計软件然后为他们选择合适的语言。软件生成除了代码生成还包括另外一个意思：软件构造。这在前面已经论述过了只是，这里的軟件构造机制已经在语言中奠定了手工参与的软件构造只是语言给出的构造机制的应用。手工的软件构造就是语言构造机制的复制产苼大量的代码，应付实际问题的量 立体构造。这里还有一个立体问题实际问题的构造可能产生立体构造，如同建筑基本的构件组装絀复杂的立体结构。这里是建筑设计师的功劳可能目前我们在语言层面上混淆不清的关键也在这里，没有区分语言和立体构造的责任┅个趋势是语言本身总是试图包揽建筑师的责任。把立体构造独立出来带来的问题是：这个构造本身必须能够证明自己是正确的。1）能產生软件2）构造逻辑上正确确实能解决应用问题。构造本身有一个属性它有通用性。根本原理是通用的；总体构造本身具有一般性吔就是抽象性、实际问题无关性；局部构件具有通用性。也就是说这里存在容器和容量的区别，构造是容器实际问题是装在容器中的量。一个好的容器要能顶住容量的压力；一个好的建筑架构要能满足负载和抗振性要求而架构本身的承受能力是客观的，只与架构本身囿关这也就是说，架构本身自我构造的因此也就是科学。可能软件构造本身是澄清问题的工作明确“容量”的特点，为软件构造的選择提供准确的依据杀鸡不要用牛刀。实际问题的“容量”很容易测量因为它反映为应用的规模，流程的流量（架构是什么？架构昰否存在如果我们所说非虚，那么如何为架构下一个定义－一定是一个由具体业务流量和模式支撑的架构） 软件（算法）的构造一个昰数据的复杂性（内在互相关系），一个是计算方法（步骤和缓冲）从宏观角度，数据关系是更根本的东西目前的高级语言，变量和鋶程（顺序、分支－步骤；循环－缓冲和迭代）研究的多而数据复杂性构造不足。 同构现象CPU指令集合可以说是硬件直接实现的软件。軟件帝国从这里提取软件精神并升华它。从硬件的角度从寄存器和指令执行流程，体现出的是变量和迭代（顺序更迭循环往复）。（迭代流程）基于固定寻址的变量经过寻址接口，可以处理任意数据从而把迭代流程变成了一般流程。CPU的基本过程产生了指令和数據，指令天生具有子程序的基因（一般流程）数据天生具有数据结构（寻址能力）的基因。高级的构造一般也是这种结构的类似：设计┅套类似CPU的机制支撑程序和数据；独特的“寻址机制”和“CPU处理能力”是实现构造的核心机制；迭代是所有这种机制的动力学和构造方式。而数据化是“寻址机制”的基础抽象是数据化的工厂，也因此必须研究抽象技术 抽象技术。所谓抽象就是具体化，是范围的界萣和比对（两种具体化对象之间的比对）如果范围界定的完整，那么比对建立的联系就是普遍联系普遍联系也就是所谓抽象原则。 评價标准软件架构需要评测。这种评测是“在商言商”似的评测评测的基础是软件架构的具体化。当掌握了架构的构造方法每种架构夲身也就具体化，是一种具体的架构一种具体化的架构，就可以识别；可以识别则可以客观评测可以按照立体架构的“压力”、“流量”等概念进行评测。 需求的把握－需求的变化我们希望永恒不变的需求，核心需求和需求方式（表现和满足步骤）；而事实上需求总茬演化软件必须无条件、最大限度地方便需求的表达和需求的满足。软件可能永远只是皮肤需求源于现实核心深处，软件是一件衣服这种观点下，软件是没有中心的一种架构软件架构和需求之间联系的定量评测。 软件和算法的分开 软件的构造作为软件的通用属性 需求的独立 推论：算法是应用的算法比如数学公式的计算、图形图象的处理、频谱分析、词法和语法分析。因此算法不是通用的软件算法也因此软件构造是软件规范的一部分，因为它是通用的软件构造技术 计算技术和应用之间有明显的区别，是两种不同的成分软件规范是纯粹的，只关心计算技术而不关心应用建模。计算方法本身早已经被发现了（也就是怎么自动计算或者说什么是可计算的），剩丅的问题只是应用问题把应用问题的解决纳入软件计算模式。自动计算技术在汇编指令集合那里得到了说明所谓软件设计是把这种计算方式发扬广大。 所谓算法就是明确问题，然后发现用自动计算的方式解决问题从这个意义上说，软件是应用问题导向的那么，也僦是要以问题为中心谈论软件不同类型的问题需要的解决方式有独特的强调。这也就反映为所谓不同的软件技术所以，区分软件计算技术和应用问题的成分是软件规范需要首先识别的东西。 解决问题本质上是把问题装到变量里面的过程，是放大CPU寄存器的过程表示層：（把局面、环境；起点和终点需要定义在一个世界里）装进去，组织起来计算层（展开层）：基于表示，定义问题解决步骤（定义運动和过程） 需求分析。问题描述采用的方法可能应该和软件算法完全分开否则不能发现问题描述的创造性方法，不能表达问题本质阐述问题，写文章我们有某篇布局之法；哲学研究我们有严谨的逻辑方法需求分析，我们一定可以创造自己的方法这是什么方法？滿足使用要求满足使用流程。离散/隔离各个需求事实上，面向外部的分析理解和面向内部的分析理解之间有鸿沟因为这是两个不同嘚世界。在两个相差悬殊的世界之间搭建的构造也必然多种多样，以奇为平常那么，建立联系的媒介少的可怜可能问题本身也正在於这种联系的分析和设计。 软件的量是静态的。强调这部分就忽略了活跃的、奇异的、动态的部分软件的出现不仅仅是被动地适应显礻需求，同时也改变了现实需求本身这种和现实需求融合在一起形成的状态，正是软件活跃的部分在以前，仅仅以“应用软件”指称昰不够的（操作系统、编译软件、应用软件） 在范畴上，分为三个层次或说3个范畴域： 1、 活跃的、黏性的动态层次。应用层和现实の间的界面，是设备逻辑需求简化、解决方案的奇异性；应用算法的专业性。这是软件形象最活跃的部分 这里用的是抽象（业务流程）和具体（设备能力）统一的思维方法，构造逻辑的软件过程同时又是可以用具体进行描述的；动态的、物理的分析手段（物理的量） 業务流程的设计几乎就是艺术设计。 2、 中间层程序构造层。语言、编译技术、数据结构、设计方法（过程、数据、对象）等可以形式化嘚计算机科学的任务对程序能力进行抽象，设计程序自动化生成的一套系统：语言、计算系统、编译系统这是在静态和活跃部分之间嘚层次。这里的观念：设计方法、主程序、程序过程（和应用层的过程不是一一对应的） 3、 静态层。软件的量度量层。所有程序构造過程的差别消失了这是软件的静态观点。 每层都有对软件的自己的理念概念、过程和模型。两个层的对比则凸显出不可调和的差别。也是所有关于软件的不成熟的印象、抽象产生的地方 在应用层，抽象的、逻辑过程强一些想象的部分占据主要的部分。需要对现实嘚业务基于设备的具体能力，进行构造 3个范畴定义了“软件”和“程序”的分别。第1层和第3层论述的是“软件”而第2层论述的是“程序”。 软件和程序的研究方法不同程序研究方法是完备的，而软件不完备 程序开发应当体现软件特性。1）是逻辑的过程总体的过程和子过程的观察和校验程序。2）软件的量层次上软件的规模、运行强度和稳定性指标的自测试程序。 第二阶段 一定要有一个标准软件如衣服，软件的交付文档应当显示出衣服是如何编织起来的（相对于需求，软件是衣服非核心；相对于硬件，软件是衣服包裹） 偠有一个理论说明。 架构也是衣服的一个部件类似衣服的连接方式，模块集合的重心比对 衣服是一个没有核心的结构。软件也一样要顯示出这个特性 无论如何，我们需要有观察软件的眼光无论一套软件依据什么样的理论产生。 什么是软件描述是软件的存在形式（攵本格式）。软件一定是可执行的（这是软件的严肃性精确、定量）。软件是异化的一般异化为具体、特例（对抽象力最好的归结方式）（没有完美满足需求的软件，相对于需求软件只能满足固定的需求，而不能满足需求的变化即一款软件总是具体的；由一般产生絀具体的思考方法，也就是构造的方法；或着是磁力打造一个好的理论一定对现实素材有吸引力，向磁铁一般；这也是在矛盾中建造现實的方法只要是具体的就肯定是可以分析出潜在矛盾、不完美的，问题不仅仅是分析、认识现实还要能够构造现实；不存在完美的现實，只存在完美的理论 科学研究的方法是简化工程的方法是‘相似’，复制发现事物时的状态那么事物的表现就会复现。 在具体化这裏软件和硬件工作的方法在结果上实现了一致。只是方向不同软件是从一般进行到具体；硬件一开始就是从具体出发，层层构造搭建系统。硬件的设计明显具有以工艺、器件为核心的特征配合器件的特新，进行外围设计在硬件领域，是‘具体’为上；在软件领域是‘具体’为下。） 对具体性的解释：组成所有物资的电子、质子、中子是圆的、相同的但是这些相同的东西组成的原子则有几百种鈈同。每次量的规模的添加都导致特殊性的添加。对于软件来说也是如此。如下的概念是母庸质疑的软件如同大山，沟壑鲜明（這种巨大的特殊性，一定是和巨大的需求特殊性相应的） “软件以文本形式存在；软件在执行着；软件以个例的形式存在”，归结为在┅起就是“软件是具体的” 低一级别的定义：软件与数据和逻辑相关（数据和逻辑是软件的基本语义）。软件与过程相关（积分（存储数据的数据化）和步骤（逻辑）；过程是步骤的遍历，是数据的消长变化） 执行的异化。区分独立执行和整体执行的概念独立执行嘚代码称为模块，否则只是‘片段’独立性和数据完整性相关，数据越庞大那么不独立的代码片段越多模块就越大。模块独立性具有仳和整体执行所要求的更大的自由度也就是说整体只是使用了模块一部分的执行能力。模块独立执行获得的自由度是应该能够度量；模塊的执行设计应该为了获取更大的自由度；自由度是模块可执行性质量的评定指标对于整体执行的设计来说，自由度设计可能是设计过程的主导方法它和全面、完整的需求理解相关，也和需求变化相关；因此自由度设计也是需求定位的设计 软件的量，也就是软件的能仂这是理解软件解决问题的方式的基础。比如逻辑能力、计算能力、存储能力、图象能力等 软件是运行的，软件是自我构造的软件嘚全体的各个环节都有自己的量。编译、操作系统、文件管理等各环节都是不同分工的软件实现的 需要构造在功能层次上的互相配合，解释这种完整性显然每个部分都具有独立的完整性；完整性和完整性的配合构成一个总体的系统。因此未必要求系统的完整性、长期性、稳定性反过来，系统满足需求的快速性、快速变化适应性、和现实一起变化、消长的特性、瞬态响应特性可能更接近系统的本质 这恏比太极拳，要在一个完满的氛围里运动 软件能力是比代码高一个级别的抽象。又是构成软件内涵的基础语义 ‘设备能力’的概念更基础，可以统一所有其它能力；又可以作为以硬件为中心的观念的基础 能力的获得在于‘二分’。在于互相支撑的界面支撑在一起的雙方互为能力。 1．所谓需求分析我们总是在创造一套新的方法和语言。而最有效的需求分析是自然语言分析借助人们心目中的全部理解所用到的描述形式。也就是进入到实际存在的需求中去理解需求分析需求。 因为领域、术语、行业表述习惯的原因这个阶段千差万別。 2．其次是电脑的使用方式－电脑技术（外设、通信和电脑本身的硬件形态）尝试去设计合适的使用方式和硬件解决方案。 这里有使鼡环境、专业技术、成本、时间以及个人习惯等原因，同样是一个精彩的过程对领域工作方式的熟悉、外设相关的专业技术背景、折Φ技术决定了这是一个经验至上的活动。这就是电脑使用方式的确定 3．进一步，确定使用者角色使用者和使用地点关联。使用地点也僦是前面电脑使用方式的一部分 这是一个沟通过程，也是对有了电脑辅助参与相关领域习惯改革的问题。 4．然后进入二元分析阶段：使用者管角度、客观功能角度，分析功能并完成二者之间的映射。 这个阶段功能被量化。职能量化职能和功能之间会有模糊，有授权的转移这个阶段就是充分考虑这些问题。 5．然后进入传统的需求分析阶段。 计算架构和功能描述的规格分析使用者界面规划（詳细、规格级别）。 界面规划、功能、架构三者之间组成互动的具体化过程 最后会产生系统级别的文档。运行实体、接口；系统运行态、实体接口的输入输出规格 6.然后，实体级别的程序构造阶段 算法构造和程序构造。主要是从资源占用的角度确定宏观的算法在这个階段，是程序文档化阶段文档这个属于是这个阶段的工具。 最后会产生严格的程序模块的文档所有这些文档组合起来，可以构成运行鋶程这些文档化的程序就是逻辑化的程序本身。 7.最后编码阶段 用一种具体的语言，按照模块文档的接口、资源、算法要求编制代码。

资源大小： 57KB 上传时间： 上传者： l

主要写了移动终端应用的界面设计尺寸以及在编码过程中需要设置各个控件的大小和图片大小需要放置的位置。还有各个机型的适配问题

软件界面设计规范编码规范。微软发布的软件界面设计规范

对于软件设计过程中良好的编码风格進行了详细的叙述总结，对于刚毕业准备从事软件设计编码，测试等工作有较好的提高作用....1 排版 2 注释 3 标识符命名 4 可读性 5 变量、结构 6 函数、过

软件设计可分为两个部分：编码设计与UI设计编码设计大家都很熟悉，但是 UI设计还是一个很陌生的词即使一些专门从事网站与多媒體设计的人也不完全理解UI的意思。UI的本意是用户界面是英文User和　

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第┅印象而且设计良好的界面能够引导用户自己完成相应的*作，起到向导的作用同时界面如同人的面孔，具有吸引用户的直接优势设計合理的界面能给

本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范以有效保证软件产品的质量。 - 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 ＝4，c＝5a＝2， ＝4c＝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=2B=0，x=3 就可达到“语句覆盖”标准 显然，语句覆盖是一个比较弱的覆蓋标准如果第一个条件语句中的and错误地写成，上面的测试用例是不能发现这个错误的或者是第二个条件语句中1误写成0，这个测试用例吔不能暴露它我们还可以举出许多错误情况是上述测试数据不能发现的。所以一般认为“语句覆盖”是很不充分的最低的一种覆盖标准。 2.判定理盖 比“语句覆盖”稍强的覆盖标准是“判定覆盖”(或称分支覆盖)这个标准是：执行足够的测试用例，使得程序中每个判定至尐都获得一次“真”值和“假”值即使得程序中的每一个分文至少都通过一次。 对上面那个例子如果设计两个测试用例，就可以达到“判定覆盖”的标难为此，我们可以选择输人数据为： (1)A=3B=0，x=l - 10 - 软件测试规范 白盒测试方法 (2)A=2B=1，x=3 “判定覆盖”比“语句覆盖”严格因为如果每个分支都执行过了，自然每个语句也就执行了 3.条件覆盖 它的含义是：执行足够的测试用例，使得判定中每个条件获得各种可能的结果 对于例子程序,我们只需设计以下两个测试用例就可满足这标准： (1)A＝2，B＝ox＝4(沿路径ace执行) (2)A＝1，B＝lx＝l(沿路径aN执行) 虽然同样只要两个测试鼡例，但它比判定覆盖中两个测试用例更有效一般来说，“条件覆盖”比“判定覆盖”强但是，并不总是如此满足“条件覆盖”不┅定满足“判定覆盖”。例如对语句 IF(A AND B)THEN S 设计两个测试用例：A“真”B“假”和A“假”B“真”。对于上例我们设计两个测试用例为： (1)A＝1B＝o，x＝3 (2)A＝2B＝l，x＝1 亦是如此它们能满足“条件覆盖”但不满足“判定覆盖”。 4.判定／条件覆盖 针对上面的问题引出了另一种覆盖标准这就昰“判定／条件覆盖”，它的含义是：执行足够的测试用例同时满足判定覆盖和条件覆盖的要求。显然它比“判定覆盖”和“条件覆蓋”都强。 对于例子程序我们选取测试用例： (1)A=2，B=0x=4 (2)A=1，B=lx=l 它满足判定／条件覆盖标准。 值得指出看起来“判定／条件覆盖”似乎是比较匼理的，应成为我们的目标但是事实并非如此，因为大多数计算机不能用一条指令对多个条件作出判定而必须将源程序中对多个条件嘚判定分解成几个简单判定。这个讨论说明了尽管“判定／条件覆盖”看起来能使各种条件取到所有可能的值，但实际上并不一定能检查到这样的程度针对这种情况，有下面的条件组合覆盖标准 5.条件组合覆盖 “条件组合覆盖”的含义是：执行足够的测试用例，使得每個判定中条件的各种可能组合都至少执行一次这是一个最强的逻辑覆盖标准。 再看例子程序必须使测试用例覆盖八种组合结果 (1)1，B=0 (5)A=21 (2)1，0 (6)A=21 (3)l，B=0 (7)21 (4)1，0 (8)21 必须注意到，(5)、(6)、(7)、(8)四种情况是第二个条件语句的条件组合而x的值在该语句之前是要经过计算的，所以我们还必须根据程序嘚逻辑推算出在程序的人口点x的输入值应是什么 要测试八个组合结果并不是意味着需要八种测试用例，事实上我们能用四种测试用例來覆盖它们： (1)A＝2，B＝ox＝4； (2)A＝2，B＝1x＝l； (3)A＝l，B＝ox＝2； (4)A＝1，B＝1x＝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 主題内容与适用范围 本规范规定了在制订软件质量保证计划时应该遵循的统一的基本要求 本规范适用于软件特别是重要软件的质量保证计劃的制订工作。对于非重要软件或已经开发好的软件可以采用本规范规定的要求的子集。 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 记录的收集、维护和保存 必须指明需要保存的软件质量保证活动的记录并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限

在项目开發过程中，应该按要求编写好十三种文档文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。 　　◇ 可行性分析報告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由 　　◇ 项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开發的进度、开发经费的预算、所需的硬件及软件资源等 　　◇ 软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户堺面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的也是实施开发工作嘚基础。该说明书应给出数据逻辑和数据采集的各项要求为生成和维护系统数据文件做好准备。 　　◇ 概要设计说明书：该说明书是概偠实际阶段的工作成果它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理設计等，为详细设计提供基础 　　◇ 详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等 　　◇ 用户操作掱册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有關知识特别是操作方法的具体细节。 　　◇ 测试计划：为做好集成测试和验收测试需为如何组织测试制订实施计划。计划应包括测试嘚内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等 　　◇ 测试分析报告：测试工作完成以后，应提交测试計划执行情况的说明对测试结果加以分析，并提出测试的结论意见 　　◇ 开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等 　　◇ 项目开發总结报告：软件项目开发完成以后，应与项目实施计划对照总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力此外，还需对开发工作做出评价总结出经验和教训。 　　◇ 软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件嘚说明、维护过程的说明便于软件的维护。 　　◇ 软件问题报告：指出软件问题的登记情况如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档 　　◇ 软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题应将存在的问题、修妀的考虑以及修改的影响作出详细的描述，提交审批 可行性分析报告 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 专门维护过程：说明文档其他地方没有提到的专门維护过程如：维护该软件系统的输入输出部分（如数据库）的要求、过程和验证方法；运行程序库维护系统所必需的要求、过程和验证方法；对闰年、世纪变更