ISO软件开发全套文档_测试计划编写指南_VIP免费

测试计划编写指南版本<1.0>修订历史记录日期版本说明作者<2002/9/04><1.0>创建Century目录1.介绍51.1文档目的51.2文档摘要51.3文档历史和变更52.背景52.1系统视图和目标52.2联系方式62.3相关信息保存的位置63.质量目标64.测试策略64.1整体策略64.2测试范围65.测试方法65.1里程碑技术75.2测试文档（测试用例）75.3测试实施过程75.3.1测试系统接受条件75.3.2测试时间表75.4稳定阶段测试85.4.1稳定阶段摘要85.4.2测试遍数85.4.3项目结束85.5自动测试策略85.6集成测试策略85.7内容测试85.8性能测试和压力测试95.9兼容性测试96.测试组织96.1测试团队结构96.2功能划分107.资源需求107.1培训需求107.2硬件需求107.3软件需求107.4办公空间需求108.时间进度安排109.缺陷处理109.1数据库管理109.2缺陷处理过程1110.测试过程控制1110.1缺陷数据分析1110.2测试工作周报1111.风险分析1112.系统发布11测试计划编写指南1.介绍测试计划编写指南有两类潜在的受众。首先，测试负责人使用它作为指导方针编写测试计划。测试计划编写完成后，将作为整个团队（包括开发人员和测试人员）沟通的基础。测试项目开始时，应该完成测试计划的大部分内容。项目开始后，由于测试情况有变化，可能导致测试计划文档变化。如果文档有明显的变化，必须在文档中添加变更历史来记载这些变化。1.1文档目的测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。1.2文档摘要这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。提示和技巧：在写这一节时，考虑一下你的计划在那些地方可能会引起反对。这个计划跟以前的计划相比，有什么不同的地方。测试项目与系统开发计划的关系等。使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。1.3文档历史和变更[作者]–[日期]–[文档的当前状态，上版本以来所作的主要变化]2.背景2.1系统视图和目标系统视图对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。系统目标是帮助实现系统视图的重要指标。系统视图和目标对实现整个项目计划来说是至关重要的。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。通常情况下视图和项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。提示和技巧：为什么视图对客户是重要的？你如何向客户表达这种视图？你将做什么来保证你是在向实现视图的方向前进?在你回答这些问题之后，你就可以将视图转换成测试导向的目标？2.2联系方式列出项目参与人员的联系方式包括E-mail和电话。2.3相关信息保存的位置测试服务器的相关信息测试文档保存的位置测试工具保存的位置3.质量目标围绕软件质量，有几种不同的说法。第一个是质量是一种绝对的标准，对所有的系统必须等同处理。事实上，质量是相对的而且是和产品相关的概念。例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。质量目标可能是动态的。在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、开发、系统使用部门、用户教育、系统支撑必须为建立和维护系统的质量标准做出自...