【精品】测试计划编写指南.doc

【精品】测试计划编写指南 测试计划编写指南文档目的和结构测试计划编写指南说明测试计划编写的各个方面。 文档按照大纲的形式组织。 大纲的每个标题下有详细的说明1.说明该主题的重要性。 2.提示和技巧。 一、介绍A.文档目的B.文档摘要C.文档历史和变更 二、背景A.系统视图和目标B.联系方式C.相关信息保存的位置 三、质量目标 四、测试策略A.整体策略B.测试范围 五、测试方法A.里程碑技术B.测试文档（测试用例）C.测试实施过程1.测试系统接受条件2.测试时间表D.稳定阶段测试1.稳定阶段摘要2.测试遍数3.项目结束E.自动测试策略F.集成测试策略G.内容测试H.性能测试和压力测试I兼容性测试 六、测试组织A.测试团队结构B.功能划分 七、资源需求A.培训需求B.硬件需求C.软件需求D.办公空间需求 八、时间进度安排 九、缺陷处理A.数据库管理B.缺陷处理过程 十、测试过程控制A.缺陷数据分析B.测试工作周报 十一、风险分析 十二、系统发布 一、介绍测试计划编写指南有两类潜在的受众。 首先，测试负责人使用它作为指导方针编写测试计划。 测试计划编写完成后，将作为整个团队（包括开发人员和测试人员）沟通的基础。 测试项目开始时，应该完成测试计划的大部分内容。 项目开始后，由于测试情况有变化，可能导致测试计划文档变化。 如果文档有明显的变化，必须在文档中添加变更历史来记载这些变化。 A.文档目的测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。 测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。 另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。 测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。 B.文档摘要这一节主要说明测试计划中重要的和可能有争议的问题。 本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。 提示和技巧l在写这一节时，考虑一下你的计划在那些地方可能会引起反对。 这个计划跟以前的计划相比，有什么不同的地方。 测试项目与系统开发计划的关系等。 l使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。 C.文档历史和变更作者日期文档的当前状态，上版本以来所作的主要变化 二、背景A.系统视图和目标系统视图对测试人员了解自己需要做什么是非常重要的。 测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。 系统目标是帮助实现系统视图的重要指标。 系统视图和目标对实现整个项目计划来说是至关重要的。 测试人员必须知道系统是做什么并且帮助项目实现这种目标。 在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。 通常情况下视图和项目计划都是模糊的。 模糊的目标必须通过成员的努力转换成可衡量和实现的东西。 没有固定的视图和目标，你将无法完成部分任务。 而且，你会发现很难将对产品的认识向别人转述。 提示和技巧l为什么视图对客户是重要的？l你如何向客户表达这种视图？l你将做什么来保证你是在向实现视图的方向前进?l在你回答这些问题之后，你就可以将视图转换成测试导向的目标？B.联系方式列出项目参与人员的联系方式包括E-mail和电话。 C.相关信息保存的位置l测试服务器的相关信息l测试文档保存的位置l测试工具保存的位置 三、质量目标围绕软件质量，有几种不同的说法。 第一个是质量是一种绝对的标准，对所有的系统必须等同处理。 事实上，质量是相对的而且是和产品相关的概念。 例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。 质量目标可能是动态的。 在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。 另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。 实际上，建立质量标准是所有职能部门共同努力的结果。 测试、开发、系统使用部门、用户教育、系统支撑必须为建立和维护系统的质量标准做出自己的贡献。 每个部门必须对自己最了解的部分做出相应的质量定义。 例如，测试和开发部门对系统质量的衡量标准主要是健壮性和正确性。 用户部门可能对易用性方面比较熟悉。 最后，质量不仅是衡量系统的功能或性能是否正常。 对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。 质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。 一个定义准确的质量目标在以后的产品开发过程中帮助决策。 例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的。 四、测试策略A.整体策略本节的目的是说明计划中使用的基本的测试过程。 提示和技巧l是否使用里程碑技术和在测试过程中验证每个模块？或者是什么都不做，只是普通的测试而已。 l测试人员是否在项目开发初期就开始工作？或者测试人员只在系统开发完后，才开始测试。 B.测试范围测试部门可能对应该做什么测试觉得很迷惑。 本节试图对这些问题做一些规定。 通常说明什么是要测试的，什么是不要测试的是非常重要的。 明确规定这些问题后，测试人员对该做什么有一个清晰的认识。 提示和技巧l需要特别测试那些部分？l那些部分不需要测试，为什么？l测试人员是否需要测试内容以及相关部分？l是否要验证每个模块的稳定性？ 五、测试方法下面几节将说明测试计划的核心部分。 如果将项目比做游戏，这些内容将是攻关秘籍。 它们提供在整个测试过程中，每一个步骤的详细说明。 每一节会就测试的不同方面做详细的说明。 这一部分的主要读者是测试人员，因为计划主要是为了规定如何进行测试。 A.里程碑技术里程碑技术将项目的运行分成不同的阶段，在项目过程中提供检查工作进展状态的方法。 即使只有一个里程碑，也要在这里说明。 在说明中，要列出通过和继续往下走的标准。 1.计划阶段2.开发阶段3.稳定阶段B.测试文档（测试用例）测试用例需要列出彻底测试一个功能模块所需的详细步骤。 使用测试用例的主要目的是避免完成了所需的测试内容而不仅仅是走过场。 提示和技巧l通常可以定义测试用例模板，这样每个测试用例都有同样的格式。 就像测试用例的格式一样，可以用不同的办法来编写测试用例。 这些方法的主要区别是用例的详细程度。 在极端的情况下，用例的每一步都详细列出，这样的话，能保证运行测试用例的人员在做同样的事情，而且容易实现自动执行。 但对于用例编写人员来说，意味着庞大的工作量，他必须考虑每一个步骤。 当功能发生变化时，维护这样的测试用例是非常困难的。 l另一种极端的情况是非常概要的测试用例。 这些用例是非常宽泛的，只提供简洁的描述说明需要做什么。 让测试人员决定如何实现，以及使用那些数据来测试。 大多数的专业测试人员赞同于一个折中的方案，并倾向于提供较为详细的步骤。 C.测试实施过程本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。 这一节有助于其他部门（开发部门、用户教育部门）了解在发布测试系统时应做些什么。 保持测试系统相对稳定是非常重要的。 1.测试系统接受条件本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。 提示和技巧谁负责建立测试系统，如何保持测试系统和开发系统之间的同步。 在开发人员提交新程序时，如何检查代码的质量。 开发部门是否需要运行简单的用例，验证系统是否正常，如果验证失败，需要采取什么行动。 需要做什么测试验证测试系统是稳定的。 同步的间隔时间。 当项目进展到不同阶段时，是否需要更新这些规则。 2.测试时间表在系统的不同阶段，需要计划在什么时候应得到什么样的测试系统。 提示和技巧l测试系统多长时间更新一次（每日，每周一次或多次，在什么时间，准备好代码）？l当项目进展到不同阶段时，是否需要更新这些规则。 D.稳定阶段测试1.稳定阶段摘要在代码完成到系统最后发行之前为系统稳定阶段。 在系统稳定阶段需要对系统的各个部分进行最后的检查。 可以建立一个检查重点列表，挨项进行检查。 2.测试遍数在稳定化测试阶段至少要运行一遍完整的测试和一个简短的测试。 前者用于发现错误，后者用于验证发行版本。 3.项目结束在系统投入使用的时候，最后应作的测试安排。 E.自动测试策略在测试过程中，可以适当考虑使用自动测试策略。 自动测试不是保证产品质量的万能药，不能保证发现软件的缺陷。 自动测试有它的长处和短处，要充分考虑系统特性、时间安排、测试人员的编程经验和可以使用的自动化工具。 使用自动化技术主要目的是发现系统缺陷，提高测试用例的运行效率和对系统进行快速检测。 测试自动化跟系统本身的特性相关，如果系统主要是数值运算，可以对结果进行简单判断，使用自动化技术的效率就高，否则系统主要是跟内容相关，自动化测试的效率就比较低。 提示和技巧l自动化的目标是什么。 l你如何衡量这些目标。 l在测试中，是否实行代码覆盖，分支覆盖和功能覆盖。 l哪些部分可以自动化？自动化程度有多高。 l使用什么自动化工具？是否开发新的自动化工具？F.集成测试策略集成测试有两个范围。 一个是系统内部各个功能模块的交互作用，各种可能的组合是非常多的，表现为系统有丰富多彩的表现。 另外一种集成是测试系统与相关系统的集成。 提示和技巧l用户帮助内容在何时如何与系统功能交互作用？怎样测试？l典型的用户情景是什么？l有哪些可能的逻辑组合？l类似功能的逻辑是否一致？l是否有相同的界面？l菜单命令是否一致？G.内容测试对于系统来说，总有些内容部分需要测试，例如帮助等。 对于网站来说，文字说明也是相当重要的。 内容测试的第一步就是将内容部分标识出来，再确定谁来实施测试。 提示和技巧l如果内容只是一些帮助文件，用户教育部门会编写和验证这些内容。 如果系统是以内容为主的，拥有上百万的文字、千个链接以及不计其数的图片，在这种情况下需要使用由、校对和测试人员组成的小组来负责内容测试。 l与内容提供者确定“什么是内容的缺陷”。 避免出现模糊的问题，比如“读起来有点问题”或者“太文绉绉”。 l哪些内容需要测试。 l如何将内容测试与其他工作分开。 l是否使用自动测试（比如超链接测试）。 l如果使用自动测试，区分那些内容无法使用自动测试，哪些部分可以保证能自动测试。 H.性能测试和压力测试在性能测试中，执行不同的测试，并进行记时，然后将这些数据与以前的数据进行对比。 现在的系统多是C/S架构或B/S架构，需要测试系统对多个用户的并发响应能力，一般情况下可以使用软件在一台机器上模拟几千个客户端进行压力测试来衡量这些指标。 提示和要点l系统和竞争对手的系统相比有多快。 这可能是一个质量指标，比如“比竞争对手X快”。 l与以前的系统进行相比。 比如“在增添新功能后是否跟以前一样快甚至更快些。 l如果没有可比性，可以使用合理速度来进行衡量，但这种数据必须经确认。 l需要衡量哪些性能，可以在测试计划中，指定重点领域，在实际测试过程中，在进行具体确定。 l是否有行业标准可在测试中使用。 l在什么时候执行性能测试？如果需要进行代码优化，需要尽早进行性能测试，这样代码修改带来的负面影响比较小。 l性能测试是否跟硬件平台相关。 需要确定在何种硬件平台下进行性能测试。 l在性能测试中，有几个指标需要注意，如CPU使用率内存使用率以及磁盘吞吐率等，这样能确定系统的瓶颈在哪。 是否能进行优化。 I兼容性测试对于C/S架构的系统来说，需要考虑客户端支持的系统平台。 对于B/S架构的系统来说需要考虑用户端浏览器的版本。 提示和技巧l确定主流的客户端浏览器版本。 l决定支持哪些版本的浏览器。 l在什么平台上做开发和测试，在那些平台上进行兼容性测试。 六、测试组织A.测试团队结构这一节说明测试团队的结构和项目测试人员的数量。 提示和技巧l查看开发计划确定那些功能需要最多资源。 l确定需要多少测试人员。 l多少人做自动测试，是哪些人。 B.功能划分这一节说明系统可以分成那些模块，分别由谁负责。 提示和技巧l系统的那些常用功能需要测试。 l是不是需要测试系统的所有功能。 l是不是需要与开发部门在功能方面对应一致。 七、资源需求A.培训需求本节说明项目测试人员需要哪些培训。 提示和技巧l对于新手需要先介绍测试系统，如果测试人员比较熟悉该系统，则需要说明新系统的功能。 l是否进行自动测试。 l测试人员要不要培训以编写自动化脚本。 B.硬件需求本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。 C.软件需求本节说明测试人员需要使用的软件。 D.办公空间需求本节说明需要多少办公空间。 八、时间进度安排包括主要时间点的安排日期代码完成时间第一遍测试第X遍测试系统发行时间 九、缺陷处理测试过程中可衡量的是发现的缺陷的状况。 因此缺陷的报告和管理必须写成书面文档。 A.数据库管理提示和技巧l谁负责创建数据库？l谁有权限增加数据库的帐号？l谁有权使用哪类帐号？l数据库使用过程中出了问题和谁联系？l谁负责数据库备份？l多长时间备份一次？l由谁使用数据库？l缺陷管理应该与开发部门的负责人一起讨论。 B.缺陷处理过程提示和技巧l解释缺陷报告和分配过程。 l缺陷标题、测试环境应如何填写l解释如何输入，解决，重新打开，关闭和重新即或一个缺陷。 l让测试人员清楚一个缺陷从击活到解决的全过程。 l缺陷必须指定由谁负责解决。 l定义优先级、严重级别等。 l在项目结束时，如何解决这些缺陷。 十、测试过程控制在测试过程中，通过对缺陷数据库进行分析可以确定测试的状态。 另外，通过让测试人员填写测试工作周报，可以对项目进展状况进行反馈。 A.缺陷数据分析提示和技巧l在开发过程和稳定阶段是否有过多的未处理缺陷，这可能说明开发的资源不够，或者有其它问题。 l如何确定项目中是否有过多的缺陷。 l测试人员是否积极发现缺陷，或者过分积极。 l在每个时间点上，系统是否稳定。 l系统哪些部分的缺陷最集中。 l在系统发行时修复了多少缺陷。 l哪些类型的缺陷最普遍。 B.测试工作周报提示和技巧l周报中应包括哪些信息。 l如何填写工作周报。 l谁负责查看工作周报。 十一、风险分析在系统开发和测试过程中，会有各种可能导致系统发布延迟，在计划中需要预先估计这些风险，并且提出相应的对付办法。 十二、系统发布确定系统在什么情况下可以发布，由谁决定。 制定成功的测试计划世界商业评论ICXO.(日期xx-07-2811:04)工欲善其事，必先利其器”。 专业的测试必须以一个好的测试计划作为基础。 尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。 测试的计划应该作为测试的起始步骤和重要环节。 一个测试计划应包括产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。 产品基本情况调研这部分应包括产品的一些基本情况介绍，例如产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。 对于大的测试项目，还要包括测试的目的和侧重点。 具体的要点有目的重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置，粗略的估计测试大致需要的周期和最终测试报告递交的时间。 变更说明有可能会导致测试计划变更的事件。 包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。 技术结构可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。 每一个部分是怎么实现数据更新的。 还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。 产品规格就是制造商和产品版本号的说明。 测试范围简单的描述如何搭建测试平台以及测试的潜在的风险。 项目信息说明要测试的项目的相关资料，如用户文档，产品描述，主要功能的举例说明。 测试需求说明这一部分要列出所有要测试的功能项。 凡是没有出现在这个清单里的功能项都排除在测试的范围之外。 万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。 具体要点有功能的测试理论上是测试是要覆盖所有的功能项，例如在数据库中添加、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。 设计的测试对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。 整体考虑这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。 测试的策略和记录这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。 要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下公正性声明要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。 测试案例描述测试案例是什么样的，采用了什么工具，工具的是什么，如何执行的，用了什么样的数据。 测试