Module 2 - Test Planning软件测试计划

1、Module Two-Software Test PlanningGeorge Cao Created on March 2, 2011 Last revised on Mar 3, 2014 Software Test Technology学习目标学习目标通过本章的学习，应该： 熟悉软件测试计划的要点； 需求阶段的测试内容及需求测试的方法； 熟悉测试的标准； 熟悉测试工具的选择； 熟悉测试环境的搭建; 熟悉测试进度的建立；1.能够阅读测试计划相关的技术文档（SRS,测试计划和测试进度计划）。Study PurposeModule Two: Test Planning 2.1 Establis

2、h the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Technical Document Reading 2.7 Test in Semester Project软件测试阶段组成软件测试阶段组成测试计划制订过程测试计划制订过程(活动活动)分析和测试软件分析和测试软件需求需求定义测试策略定义测试策略定义测试定义测试环境环境定义测试管理定义测试管理编写和编写和评审评审测试计划测试计划 测试活动进度综述，可供项目经理产生项目

3、进度时参考； 测试方法: 测试分类,如黑盒测试, 测试内容,如安全测试； 测试工具，包括如何和何时获取工具； 实施测试和报告结果的过程； 系统测试进入和结束准则； 设备资源: 设计、开发和执行测试所需的人员和设备； 恰当的测试覆盖率目标； 测试所需的特殊软件和硬件配置； 测试哪些特性，不测试哪些特性； 风险和意外情况计划。 测试计划测试计划（Test Plan）要点）要点目前最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。 基于需求的 测试覆盖测试用例表示的测试数（已计划的、已实施的或成功的）/需要测试的需求总数。 1. 基于代码的测试覆盖 2. 基于代码的测试覆盖，评测测试过程中已

4、经执行的代码的多少，一般通过工具度量得到： 找出程序经过一系列测试而没有执行的部分代码 创建一个附加的测试用例来增加覆盖率 决定代码覆盖的定量度量。测试覆盖率测试覆盖率实验指导实验指导1解读解读2014-3-3软件121 测试计划是描述软件测试努力的目标、范围、方法和焦点的文档。 由于测试的种类多、内容广并且时间分散，并且不同的测试工作由不同的人员来执行，因此一般把(单元测试、集成测试、系统测试)、(验收测试)各阶段的测试计划分开写。 Sample实验报告实验报告1文档解读的问题文档解读的问题 1项目的背景是什么？ 2. 测试的方法内容是什么？ 3. 所需的测试工具是什么？ 4. 测试通过/失

5、败的准则是什么？ 5测试任务有哪些？ 6测试环境需求是什么？ 7功能测试的方案是什么？ 8测试计划识别出哪些风险与应急措施？ 9. 测试的进入和拒绝准则是什么？ 填写其他的文档理解问题-进度计划进度计划 2014-3-4126班班 test schedule (sample).mppModule Two: Test Planning 2.1 Establish the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Techn

6、ical Document Reading 2.7 Test in Semester Project 软件需求文档软件需求文档 需求文档是进行设计、编码、测试的基础文件，软件需求文档中，需要描述下列内容： 说明 一般描述 各种限制条件、假定和以来 功能需求 非功能需求 参考2.2 2.2 测试软件需求测试软件需求 需求测试的方法需求测试的方法评审评审(Review) ： 走查 (Walkthrough) 复查一般是让工作中合作者检查产品并提出意见。同级互查可以面对面进行，也可以通过E-Mail实现，并没有统一标准。发现文档缺陷同级互查的能力是三种方法中最弱的。 相比较审查走查较为宽松，其事先需

7、要收集数据，也没有输出报告的要求。 审查 (Inspection) 审查是为发现缺陷而进行的。关键组件的审查通过会议进行，会前每个与会者需要进行准备，会议必须按规定的程序进行，缺陷被记录并形成会议报告。审查被证明是非常有效的发现缺陷的方法。 Requirement Review Process需求评审是技术评审的一种，后者通常指对需求、设计、代码和测试的评审，四者的评审过程和方法都是相同，所以系统设计、代码和测试的评审过程全部都可以参考此处的内容。技术评审的目的是在软件开发阶段对有关技术性文档进行正确性的检查，侧重于在缺陷导入阶段就尽早尽可能地发现他们以防止他们进入下一个阶段（To focus

8、 on discovering defects at the defect import phase as early as possible and prevent them from entering the next phase），从而节约成本，使后续过程的变更减少，减少重复工作的工作量（to reduce rework effort），降低风险。技术评审尝试发现更多的缺陷而不能发现所有的缺陷。角色与职责角色与职责角色角色主要职责主要职责项目经理规划技术评审，确保所有的交付物都准备好了评审组长Review Leader评审前介绍评审检查单组织(Organize)评审的成员审计评审检查单的

9、覆盖情况提供评审分析报告评审组员评审交付物并发现缺陷作者Author 把交付物分发(Distribute)给评审组员介绍交付物修正缺陷并修改交付物记录员Recorder在评审记录单上记录缺陷本角色由评审组长指派技术评审程序技术评审程序1）组织评审组一般地，由PM担任管理评审的组长，由DM 担任SDS/SRS评审的组长，由技术组长担任代码评审的组长，由测试经理担任测试评审的组长。 评审小组由评审组长组织，作者不能作为评审组长。2）在进度计划上列出正式评审（Formal Review）活动PM 及 DM必须识别并在项目进度计划中作为重要的里程碑列出所有正式的技术评审任务 。3）发送评审检查单及交付

10、物评审组长和作者分别把评审检查单及交付物发送给评审组员。技术评审程序技术评审程序4）执行评审会议如果必要，评审组长应该在会议开始前向所有的评审组员介绍评审检查单的内容；作者概要地介绍交付物的内容 ；评审组员及作者在会上讨论发现的缺陷；需要修正的缺陷被记录到评审记录单上；会议结束前，评审组长应该用评审检查单来监督是否所有的简检查单项都被覆盖了。5）交付物的修改及追踪会后，记录员把评审记录单发布到配置管理工具上，作者根据发现的缺陷修改交付物。当作者把所有的缺陷都修改完成后,他应该通知（inform）所有的评审组员 。 6）关闭（Close）此次评审评审组长负责对发现缺陷的追踪直至问题关闭，并发布（

11、submit）评审分析报告给项目有关干系人。需求评审检查单需求评审检查单(Requirement Review Checklist)从以下几个方面来评价需求文档：从以下几个方面来评价需求文档：需求文档是否符合公司的格式要求？需求是否正确？这是“真正的”需求吗？描述的产品是否就是要开发的产品？需求是否完备？需求是否可实现？是否考虑过将来可能会提出的软件需求；有没有遗漏、重复或不一致(矛盾)的地方；与所有其他系统成份的重要接口是否都已经描述；所有图表是否清楚，在不补充说明时能否理解；是否确定了需求的优先级；理解需求理解需求理解什么？理解什么？理解系统的目标理解系统的业务（业务流程、方法等）理解需求

12、的范围和需求（功能）清单参与需求评审提出Q&A问题清单，与系统分析师SA及客户沟通原则：不限于自己负责的模块，整个系统都要熟悉分小组解读SRS的部分章节内容（2.2小节前的内容为公共部分必看，后面每个小组读一个用例），并对照需求评审检查单和需求理解内容（见前2页），提出至少两个需求理解方面的问题。随机分配其他小组来解答另外一个小组的问题。老师点评并总体回答问题。项目小组按照需求评审记录单的格式，填写问题 到实验报告里。SRSUSE CASE for Stock Maintenance实验指导实验指导1需求评审实训（填写实验报告）需求评审实训（填写实验报告）review定义测试范围需要考

13、虑哪些一些因素？定义测试范围需要考虑哪些一些因素？确立测试标准常用的规则有哪些？确立测试标准常用的规则有哪些？影响测试环境有哪些因素？影响测试环境有哪些因素？Module Two: Test Planning 2.1 Establish the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Technical Document Reading 2.7 Test in Semester Project2.3 测试策略测试策略

14、测试策略考虑的问题：测试策略考虑的问题： 测试范围 测试方法 测试标准 测试工具2.3.1 确定测试范围确定测试范围 测试过度，则在测试覆盖中存在大量冗余；测试范围过小，则存在遗漏错误的风险。 定义测试范围是一个在测试时间、费用和质量风险之间寻找平衡的过程。 通过分析产品的需求文档识别哪些需要被测试。 测试范围不能仅仅由测试人员来确定。 定义测试范围需要考虑下列一些因素：定义测试范围需要考虑下列一些因素： 首先测试最高优先级的需求。 测试新的功能和代码 或者改进的旧功能。 使用等价类划分来减小测试范围（冗余） 重点测试经常出问题的地方 确定测试范围方法确定测试范围方法 可采用提问单的方式来确定

15、测试范围 哪些功能是软件的特色？ 哪些功能是用户最常用的？ 如果系统可以分块卖的话，哪些功能块在销售时最昂贵？ 哪些功能出错将导致用户不满或索赔？ 哪些程序是最复杂、最容易出错的？ 哪些程序是相对独立，应当提前测试的？ 哪些程序最容易扩散错误？ 哪些程序是全系统的性能瓶颈所在？ 哪些程序是开发者最没有信心的？ 2.3.2 选择测试方法选择测试方法 在不同的开发阶段，需要选择不同的测试方法。 在瀑布生命期模型中不同的阶段可以选择的不同的测试方法： 需求分析阶段：静态测试 概要设计与详细设计阶段：静态测试 编码和单元测试阶段：静态测试和动态测试、白盒测试 集成测试阶段：动态测试、白盒测试、黑盒测试

16、 系统测试阶段：动态测试、黑盒测试 验收测试阶段：动态测试、黑盒测试2.3.3 定义测试标准定义测试标准 定义测试标准的目的是设置测试中遵循的规则。 需要制订以下几种标准： 测试开始标准test entry criteria 测试退出标准test exit criteria比如发布给客户前的系统测试结束标准是什么？ 测试暂停与继续标准test rejection/continual criteria制订测试标准常用规则制订测试标准常用规则 基于测试用例的规则基于测试用例的规则 当测试用例的不通过率达到某一百分比时，则拒绝继续测试。 优点是适用于所有的测试阶段 缺点是太依赖于测试用例。 基于基于

17、“测试期缺陷密度测试期缺陷密度”的规则的规则 “测试期缺陷密度”：测试一个CPU小时发现的缺陷数。 如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。 2.3.4 选择自动化测试工具选择自动化测试工具 使用测试工具可以带来下面一些主要的好处： 能够很好地进行性能测试和压力测试 能够缩短测试周期 能够提高测试工作的可重复性 选择自动化测试工具需要注意以下几方面：选择自动化测试工具需要注意以下几方面： 并不是所有的测试工作都可以由测试工具来完成 并不是一个自动化工具就可以完成所有的测试 使用自动化工具本身也是需要时间的，这个时间有可能超过手工测试的时间 如果测试人

18、员不熟悉测试工具的使用，有可能不能更多发现软件错误，从而影响测试工作质量 自动化测试工具并不能对一个软件进行完全的测试 购买自动化测试工具，有可能使本项目的测试费用超出预算Module Two: Test Planning 2.1 Establish the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Technical Document Reading 2.7 Test in Semester Project2.4 测试

19、环境测试环境 从软件的编码、测试到用户实际使用，存在着：开发环境、测试环境和用户环境。 “环境”，指的是被测试软件所运行的软件环境和硬件环境。 测试环境是测试人员为进行软件测试而搭建的环境，一般情况下，将包括多种典型的用户环境。 测试环境的环境项测试环境的环境项 计算机平台 操作系统 浏览器 软件支持平台 外部设备 网络环境 其它专用设备如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境Cohabit kuhbit 同居同居如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环

20、境Cohabit kuhbit 同居同居如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境20110315S1如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境。（同传）（同传）如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境如何配置测试环境20110322S1mediocre,mi:diuk, mi:diuk中等

21、的、平凡的中等的、平凡的 Module Two: Test Planning 2.1 Establish the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Technical Document Reading 2.7 Test in Semester Project2.5 测试管理测试管理 在测试管理方面，需要考虑的主要问题包括： 选择缺陷管理工具和测试管理工具 定义工作进度 建立风险管理计划（一般在整个项目RSKM中统

22、一管理） 在测试计划阶段，需要确定用什么工具进行测试管理和缺陷管理。如JIRA, QC(Quality Control), TD(TestDirector)或 Bugzilla等。 在执行测试的过程中，缺陷管理工具和测试管理工具并不是必须的。但多数公司都会使用缺陷管理工具。2.5.1缺陷工具和管理工具的选择缺陷工具和管理工具的选择 定义工作进度的过程定义工作进度的过程同项目进度计划的制定过程同项目进度计划的制定过程确认工作任务估算工作量编写进度计划2.5.2定义工作进度定义工作进度确认测试工作任务确认测试工作任务 测试人员的测试工作任务可以分为两类，一类是可以直接和需求文档对应起来的，另外一类和需求文档没有直接的关联（纯测试工作）。 在需求文档中，描述了软件的功能性需求和非功能性需求，对需求中的每一个条目，都应该有相应的测试工作与之对应起来。 确认好测试任务后，还应该排列这些任务的优先级。 与需求文档没有直接关联的测试任务：与需求文档没有直接关联的测