_软件测试面试必备SoftwareProjectFlat测试计划编写指南版本<1.0>修订历史记录日期版本阐明作者<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.质量目的围绕软件质量，有几种不一样的说法。第一种是质量是一种绝对的原则，对所有的系统必须等同处理。实际上，质量是相对的并且是和产品有关的概念。例如，多媒体产品的质量目的倾向于精美的表达和合适的内容，而应用系统也许倾向于易用性、强健性和合用于不一样的任务。质量目的也许是动态的。在项目进行过程中，会由于市场压力、新的机会和功能变化而重新设定质量目的。另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一种部门的事。实际上，建立质量原则是所有职能部门共同努力的成果。测试、开发、系统使用部门、顾客教育、系统支撑...
