测试计划编写指南

Software Project Plan测试计划编写指南版本 2019整理的各行业企管，经济，房产，策划，方案等工作范文，希望你用得上，不足之处请指正修订历史记录日期版本说明作者创建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 文档摘要这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。提示和技巧：l 在写这一节时，考虑一下你的计划在那些地方可能会引起反对。这个计划跟以前的计划相比，有什么不同的地方。测试项目与系统开发计划的关系等。l 使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。1.3 文档历史和变更作者 日期 文档的当前状态，上版本以来所作的主要变化2. 背景2.1 系统视图和目标系统视图对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。系统目标是帮助实现系统视图的重要指标。系统视图和目标对实现整个项目计划来说是至关重要的。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。通常情况下视图和项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。提示和技巧：l 为什么视图对客户是重要的？l 你如何向客户表达这种视图？l 你将做什么来保证你是在向实现视图的方向前进?l 在你回答这些问题之后，你就可以将视图转换成测试导向的目标？2.2 联系方式列出项目参与人员的联系方式包括 E-mail 和电话。2.3 相关信息保存的位置l 测试服务器的相关信息l 测试文档保存的位置l 测试工具保存的位置3. 质量目标围绕软件质量，有几种不同的说法。第一个是质量是一种绝对的标准，对所有的系统必须等同处理。事实上，质量是相对的而且是和产品相关的概念。例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。质量目标可能是动态的。在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、开发、系统使用部门、用户教育、系统支撑必须为建立和维护系统的质量标准做出自己的贡献。每个部门必须对自己最了解的部分做出相应的质量定义。例如，测试和开发部门对系统质量的衡量标准主要是健壮性和正确性。用户部门可能对易用性方面比较熟悉。最后，质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的。4. 测试策略4.1 整体策略本节的目的是说明计划中使用的基本的测试过程。提示和技巧：l 是否使用里程碑技术和在测试过程中验证每个模块？或者是什么都不做，只是普通的测试而已。l 测试人员是否在项目开发初期就开始工作？或者测试人员只在系统开发完后，才开始测试。4.2 测试范围测试部门可能对应该做什么测试觉得很迷惑。本节试图对这些问题做一些规定。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。提示和技巧：l 需要特别测试那些部分？l 那些部分不需要测试，为什么？l 测试人员是否需要测试内容以及相关部分？l 是否要验证每个模块的稳定性？5. 测试方法下面几节将说明测试计划的核心部分。如果将项目比做游戏，这些内容将是攻关秘籍。它们提供在整个测试过程中，每一个步骤的详细说明。每一节会就测试的不同方面做详细的说明。这一部分的主要读者是测试人员，因为计划主要是为了规定如何进行测试。5.1 里程碑技术里程碑技术将项目的运行分成不同的阶段，在项目过程中提供检查工作进展状态的方法。即使只有一个里程碑，也要在这里说明。在说明中，要列出通过和继续往下走的标准。1. 计划阶段2. 开发阶段3. 稳定阶段5.2 测试文档（测试用例）测试用例需要列出彻底测试一个功能模块所需的详细步骤。使用测试用例的主要目的是避免完成了所需的测试内容而不仅仅是走过场。提示和技巧：l 通常可以定义测试用例模板，这样每个测试用例都有同样的格式。就像测试用例的格式一样，可以用不同的办法来编写测试用例。这些方法的主要区别是用例的详细程度。在极端的情况下，用例的每一步都详细列出，这样的话，能保证运行测试用例的人员在做同样的事情，而且容易实现自动执行。但对于用例编写人员来说，意味着庞大的工作量，他必须考虑每一个步骤。当功能发生变化时，维护这样的测试用例是非常困难的。l 另一种极端的情况是非常概要的测试用例。这些用例是非常宽泛的，只提供简洁的描述说明需要做什么。让测试人员决定如何实现，以及使用那些数据来测试。大多数的专业测试人员赞同于一个折中的方案，并倾向于提供较为详细的步骤。5.3 测试实施过程本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。这一节有助于其他部门（开发部门、用户教育部门）了解在发布测试系统时应做些什么。保持测试系统相对稳定是非常重要的。5.3.1 测试系统接受条件本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。提示和技巧：谁负责建立测试系统，如何保持测试系统和开发系统之间的同步。在开发人员提交新程序时，如何检查代码的质量。开发部门是否需要运行简单的用例，验证系统是否正常，如果验证失败，需要采取什么行动。需要做什么测试验证测试系统是稳定的。同步的间隔时间。当项目进展到不同阶段时，是否需要更新这些规则。5.3.2 测试时间表在系统的不同阶段，需要计划在什么时候应得到什么样的测试系统。提示和技巧：l 测试系统多长时间更新一次（每日，每周一次或多次，在什么时间，准备好代码）？l 当项目进展到不同阶段时，是否需要更新这些规则。5.4 稳定阶段测试5.4.1 稳定阶段摘要在代码完成到系统最后发行之前为系统稳定阶段。在系统稳定阶段需要对系统的各个部分进行最后的检查。可以建立一个检查重点列表，逐项进行检查。5.4.2 测试遍数在稳定化测试阶段至少要运行一遍完整的测试和一个简短的测试。前者用于发现错误，后者用于验证发行版本。5.4.3 项目结束在系统投入使用的时候，最后应作的测试安排。5.5 自动测试策略在测试过程中，可以适当考虑使用自动测试策略。自动测试不是保证产品质量的万能药，不能保证发现软件的缺陷。自动测试有它的长处和短处，要充分考虑系统特性、时间安排、测试人员的编程经验和可以使用的自动化工具。使用自动化技术主要目的是发现系统缺陷，提高测试用例的运行效率和对系统进行快速检测。测试自动化跟系统本身的特性相关，如果系统主要是数值运算，可以对结果进行简单判断，使用自动化技术的效率就高，否则系统主要是跟内容相关，自动化测试的效率就比较低。提示和技巧：l 自动化的目标是什么。l 你如何衡量这些目标。l 在测试中，是否实行代码覆盖，分支覆盖和功能覆盖。l 哪些部分可以自动化？自动化程度有多高。l 使用什么自动化工具？是否开发新的自动化工具？5.6 集成测试策略集成测试有两个范围。一个是系统内部各个功能模块的交互作用，各种可能的组合是非常多的，表现为系统有丰富多彩的表现。另外一种集成是测试系统与相关系统的集成。提示和技巧：l 用户帮助内容在何时如何与系统功能交互作用？怎样测试？l 典型的用户情景是什么？l 有哪些可能的逻辑组合？l 类似功能的逻辑是否一致？l 是否有相同的界面？l 菜单命令是否一致？5.7 内容测试对于系统来说，总有些内容部分需要测试，例如帮助等。对于网站来说，文字说明也是相当重要的。内容测试的第一步就是将内容部分标识出来，再确定谁来实施测试。提示和技巧l 如果内容只是一些帮助文件，用户教育部门会编写和验证这些内容。如果系统是以内容为主的，拥有上百万的文字、千个链接以及不计其数的图片，在这种情况下需要使用由编辑、校对和测试人员组成的小组来负责内容测试。l 与内容提供者确定“什么是内容的缺陷”。避免出现模糊的问题，比如“读起来有点问题”或者“太文绉绉”。l 哪些内容需要测试。l 如何将内容测试与其他工作分开。l 是否使用自动测试（比如超链接测试）。l 如果使用自动测试，区分那些内容无法使用自动测试，哪些部分可以保证能自动测试。5.8 性能测试和压力测试在性能测试中，执行不同的测试，并进行记时，然后将这些数据与以前的数据进行对比。现在的系统多是 C/S 架构或 B/S 架构，需要测试系统对多个用户的并发响应能力，一般情况下可以使用软件在一台机器上模拟几千个客户端进行压力测试来衡量这些指标。提示和要点：l 系统和竞争对手的系统相比有多快。这可能是一个质量指标，比如“比竞争对手 X 快”。l 与以前的系统进行相比。比如“在增添新功能后是否跟以前一样快甚至更快些。”l 如果没有可比性，可以使用合理速度来进行衡量，但这种数据必须经确认。l 需要衡量哪些性能，可以在测试计划中，指定重点领域，在实际测试过程中，在进行具体确定。l 是否有行业标准可在测试中使用。l 在什么时候执行性能测试？如果需要进行代码优化，需要尽早进行性能测试，这样代码修改带来的负面影响比较小。l 性能测试是否跟硬件平台相关。需要确定在何种硬件平台下进行性能测试。l 在性能测试中，有几个指标需要注意，如 CPU 使用率内存使用率以及磁盘吞吐率等，这样能确定系统的瓶颈在哪。是否能进行优化。5.9 兼容性测试对于 C/S 架构的系统来说，需要考虑客户端支持的系统平台。对于 B/S 架构的系统来说需要考虑用户端浏览器的版本。提示和技巧：l 确定主流的客户端浏览器版本。l 决定支持哪些版本的浏览器。l 在什么平台上做开发和测试，在那些平台上进行兼容性测试。6. 测试组织6.1 测试团队结构这一节说明测试团队的结构和项目测试人员的数量。提示和技巧l 查看开发计划确定那些功能需要最多资源。l 确定需要多少测试人员。l 多少人做自动测试，是哪些人。6.2 功能划分这一节说明系统可以分成那些模块，分别由谁负责。提示和技巧：l 系统的那些常用功能需要测试。l 是不是需要测试系统的所有功能。l 是不是需要与开发部门在功能方面对应一致。7. 资源需求7.1 培训需求本节说明项目测试人员需要哪些培训。提示和技巧：l 对于新手需要先介绍测试系统，如果测试人员比较熟悉该系统，则需要说明新系统的功能。l 是否进行自动测试。l 测试人员要不要培训以编写自动化脚本。7.2 硬件需求本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。7.3 软件需求本节说明测试人员需要使用的软件。7.4 办公空间需求本节说明需要多少办公空间。8. 时间进度安排包括主要时间点的安排日期代码完成时间第一遍测试第X遍测试系统发行时间9. 缺陷处理测试过程中可衡量的是发现的缺陷的状况。因此缺陷的报告和管理必须写成书面文档。9.1 数据库管理提示和技巧：l 谁负责创建数据库？l 谁有权限增加数据库的帐号？l 谁有权使用哪类帐号？l 数据库使用过程中出了问题和谁联系？l 谁负责数据库备份？l 多长时间备份一次？l 由谁使用数据库？l 缺陷管理应该与开发部门的负责人一起讨论。9.2 缺陷处理过程提示和技巧：l 解释缺陷报告和分配