搜索
模版集萃(软件质量保证类)综述：在程序员的日常工作中，除了编写代码之外，还免不了需要编写各种技术文档。一个编写良好的技术文档在项目中能够很好地建立沟通与协作，起到很积极的作用。因此，编写技术文档也就成为了程序员技能提升的很重要的一面。为此，我们特意收集了一些在项目开发过程中经常用到的文档模板，这些模板包括格式和简单的写作说明，相信能够帮助大家编写出更加高效、实用的技术文档。在收集过程中，我们十分注重其实用性，以确保每个模板的价值，而且对于一些重要的文档提供了多个模板。为了方便大家查找，我们将收录的57模板分为以下几类：1）项目及开发管理类：包括立项前的分析，立项后的计划、以及进度跟踪、风险控制方面的文档模板，共计16个；2）需求分析类：明确清晰的需求，是项目成功的基础，在此收集了在需求分析过程中所将使用到的文档模板，共计14个；3）系统分析与设计类：包括体系结构设计、高层设计、详细设计、数据库设计等6个相关文档模板；4）软件质量保证类：软件测试是质量保证的关键活动，在此收集了软件测试相关的11个文档模板；5）其它类：除此之外，还收集了关于用户手册、软件维护等方面的10个文档模板，其中还有一个软件过程规范的示例。另外，值得说明的是，文档模板只是为文档的编写提供一个基础，在实际的编写过程中，你可以根据自己的需要进行必要的剪裁和增补。测试计划编者说明：要想系统性地完成一件事，首先要做好计划，测试工作是十分重要的，因此测试计划也是十分必要的。该文档适用于集成测试、系统测试、验收测试的计划制订，并不适用于单元测试计划。第1章引言1.1综述1.2参考文献序号名称文件标识/版本出版单位出版日期第2章测试项2.1测试项测试项名称测试项标识介质特性变换要求相关引用材料2.2不测试的软件项软件项名称软件项标识未测试原因相关引用材料第3章被测试的特性特性或组合名称测试设计说明编号第4章不被测试的特性特性或组合名称测试设计说明编号第5章方法5.1方法名称5.2方法名称第6章项通过准则第7章暂停标准和再启动要求7.1暂停标准7.2再启动要求第8章应提供的测试文档文档名称标识符第9章测试任务序号任务前期任务特殊技能责任人工作量（天）完成日期第10章环境要求10.1硬件10.2软件10.3安全性10.4工具10.5文档第11章职责11.1测试组11.2开发组11.3……第12章人员和培训要求12.1人员12.1.1测试组12.2培训第13章进度13.1进度序号测试任务名称工作量开始日期完成日期13.2测试资源使用期限第14章风险和应急测试日志编者说明：测试都有一个结果，而这些结果对于软件质量保证活动来说是十分重要的，因此应该将这些结果有序地记录下来，这就是测试日志模板所要解决的问题。第1章描述1.1测试项序号测试项名称标识符版本相关传递报告1.2测试的环境1.2.1硬件1.2.2软件第2章活动和事件条目2.1日期时间活动描述事件2.2日期测试设计说明编者说明：如果说测试计划是对测试的活动、人员进行安排，那么测试设计则是对测试方法、测试技术的说明。第1章被测试的特性1.1单项特性1.2组合特性1.3引用文档第2章方法详述2.1方法描述2.2测试评价标准2.3测试用例选择原则2.4测试用例的共同属性和依赖关系测试用例说明编者说明：测试计划解决的是怎么安排测试活动，测试设计说明是怎么测试，那么测试用例说明就是测试什么，也就是列出具体的测试项目，以使得测试有目的、有计划。第1章测试项1.1测试项名称测试项名称标识符说明1.2引用文档编号文档名称章节名第2章输入说明序号名称值类型允许误差输入方式第3章输出说明序号名称值类型允许误差输出方式第4章环境要求4.1硬件4.2软件4.3其它第5章特殊的规程要求第6章用例间的依赖关系6.1所依赖的用例序号用例名称或标识6.2依赖关系的性质集成测试计划(ISO标准)编者说明：前面的测试计划模板是一个通用性的，也可以是用于制定所有测试活动的计划，而本模块则是用来指导编写集成测试计划的。1.引言1.1编写目的[说明编写这份测试计划目的，指出预期的读者。]1.2背景a.待开发系统的名称；b.列出本项目的任务提出者、开发者、用户。1.3定义[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]1.4参考资料[列出有关的参考资料。]2．计划2.1系统说明[提供一份图表，并逐项说明被测系统的功能、输入、输出等质量指标，作为叙述测试计划的提纲。]2.2测试内容[列出集成测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的。]2.3测试1（标识符）[给出这项测试内容的参与单位及被测试的部位。]2.3.1进度安排[给出对这项测试的进度安排，包括进行测试的日期和工作内容。]2.3.2条件[陈述本项测试工作对资源的要求。包括：]a.硬件b.软件c.人员2.3.3测试资料[列出本项测试所需的资料。]2.3.4测试培训[说明或引用资料说明为被测系统的使用提供培训的计划。规定培训的内容、受训的人员及从事培训的工作人员。]2.4测试2（标识符）[用与本测试计划2。3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。][……]3．测试设计说明3.1测试1（标识符）[说明对第一项测试内容的测试设计考虑。]3.1.1控制[说明本测试的控制方式。]3.1.2输入[说明本项测试中所使用的输入数据及选择这些输入数据的策略。]3.1.3输出[说明预期的输出数据。]3.1.4过程[说明完成此项测试的一个个步骤和控制命令。]3.2测试2（标识符）[用与本测试计划3。1条相类似的方式说明第2项及其后各项测试工作的设计考虑。][……]4．评价准则4.1范围[说明所选择的测试用例能够检查的范围及其局限性。]4.2数据整理[陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同已知结果进行比较而要用到的转换处理技术；如果是用自动方式整理数据，还要说明为进行处理而要用到的硬件、软件资源。]4.3尺度[说明用来判断测试工作是否能通过的评价尺度，如合理和输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大数。]软件集成测试工作流程指南编者说明：严格地说，该文档不属于文档模板，它只是一个工作指南。要想更好地完成集成测试工作，你就需要为团队制定一个工作指南。你可以根据该文档，结合实际进行修改。1.简介1.1目的本文详细阐述了集成测试流程，指导项目开发人员如何开展软件集成测试。1.2范围此指南可运用于使用RUP的任一软件项目的集成测试。1.3参考文件SoftwareTestProcessRationalUnifiedProcess1.4定义与缩写RUP：统一开发过程SIT：软件集成测试SEPG：软件工程过程小组SQA：软件质量保证2.集成测试指南2.1简介集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。2.2单元测试工作内容及其流程活动输入工件输出工件参与角色和职责制定集成测试计划设计模型集成构建计划集成测试计划测试设计员负责制定集成测试计划设计集成测试集成测试计划设计模型集成测试用例测试过程测试设计员负责设计集成测试用例和测试过程。实施集成测试集成测试用例测试过程工作版本测试脚本（可选）测试过程（更新）测试设计员负责编制测试脚本（可选），更新测试过程。驱动程序或稳定桩设计员负责设计驱动程序和桩，实施员负责实施驱动程序和桩。执行集成测试测试脚本（可选）工作版本测试结果测试员负责执行测试并记录测试结果评估集成测试集成测试计划测试结果测试评估摘要测试设计员负责会同集成员、编码员、设计员等有关人员（具体化）评估此次测试，并生成测试评估摘要。2.3集成测试需求获取集成测试需求所确定的是对某一集成工作版本的测试的内容，即测试的具体对象。集成测试需求主要来源于设计模型（DesignModel）和集成构件计划（IntegrationBuildPlan）。集成测试着重于集成版本的外部接口的行为。因此，测试需求须具有可观测、可测评性。1.集成工作版本应分析其类协作与消息序列，从而找出该工作版本的外部接口。2.由集成工作版本的外部接口确定集成测试用例。3.测试用例应覆盖工作版本每一外部接口的所有消息流序列。注意：一个外部接口和测试用例的关系是多对多，部分集成工作版本的测试需求可映射到系统测试需求，因此对这些集成测试用例可采用重用系统测试用例技术。2.4集成测试工作机制软件集成测试工作由产品评测部担任。需要项目组相关角色配合完成。如图示：软件评测部：角色职责测试设计员负责制定集成测试计划、设计集成测试、实施集成测试、评估集成测试。测试员执行集成测试，记录测试结果。软件项目组：角色职责实施员负责实施类（包括驱动程序和桩），并对其进行单元测试。根据集成测试发现的缺陷提出变更申请。配置管理员负责对测试工件进行配置管理。设计员负责设计测试驱动程序和桩。根据集成测试发现的缺陷提出变更申请。集成测试工作内容及其流程工作流程：2.5集成测试产生的工件清单1、软件集成测试计划2、集成测试用例3、测试过程4、测试脚本5、测试日志Desinger：开发设计模型Integrator：制定集成计划Implementer：实施类，进行单元测试TestDesigner：制定集成测试计划，设计集成测试用例、测试过程、测试脚本Tester：执行集成测试，生成测试日志Designer&Implementer：提出变更请求变更流程TestDesigner：评估集成测试，生成评估摘要缺陷6、测试评估摘要软件系统测试工作指南编者说明：这是一个系统测试的工作指南。你可以根据该文档，结合实际进行修改。1.简介1.1目的本文详细阐述了系统测试的类型以及各个类型的基本测试方法，指导项目开发人员进行软件系统测试。1.2范围本文适用于使用RUP的所有软件项目的系统测试工作。1.3文档结构第一部分：简介，介绍软件系统测试指南的目的，本指南的适用范围，以及在本文档中使用的术语的解释。第二部分：描述系统测试指南。包括系统测试流程、系统测试需求的获取、系统测试侧策略选择、系统测试技术和方法等。第三部分：列出本指南使用的参考文献。1.4词汇表系统测试（SystemTesting）：系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统进行的测试。黑盒测试（Black-BoxTesting）：黑盒测试是基于系统需求规格，在不知道系统或组件的内部结构的情况下进行的测试。通常又将黑盒测试叫做：基于规格的测试（Specification-BasedTesting）、输入输出测试（Input/OutputTesting）、功能测试（FunctionalTesting）。2.系统测试指南2.1系统测试过程活动名称输入工件输出工件参与角色制定系统测试计划软件需求工件软件项目计划系统测试计划测试设计员设计系统测试系统测试计划软件需求工件系统测试用例系统测试过程测试设计员实施系统测试系统测试计划工作版本系统测试脚本测试设计员执行系统测试系统测试计划系统测试用例系统测试过程系统测试脚本测试结果测试员评估系统测试测试结果测试分析报告变更请求测试设计员相关组2.2系统测试需求获取系统测试需求所确定的是测试的内容，即测试的具体对象。系统测试需求主要来源于需求工件集，它可能是一个需求规格说明书，或是由前景、用例、用例模型、词汇表、补充规约组成的一个集合。在分析测试需求时，可应用以下几条一般规则：1）测试需求必须是可观测、可测评的行为。如果不能观测或测评的测试需求，就无法对其进行评估，以确定需求是否已经满足。2）在每个用例或系统的补充需求与测试需求之