IEEE定义的测试计划
• 测试计划：
- 一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。
- 它确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险。
- 三要素：
• 时间
• 资源
• 范围
- 其他方面
• 策略
• 风险控制
计划的作用
• 计划能给管理者和被管理者指明前进的方向
• 计划可以减少不确定性对组织的影响和冲击
• 计划可以减少无序和浪费
• 计划有利于管理和控制
关于测试计划
• 1. 为什么要编写测试计划？
- 领导能够根据测试计划做宏观调控，进行相应资源配置等；
- 测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工
作等；
- 便于其他人员了解测试人员的工作内容，进行有关配合工作
• 2. 什么时间开始编写测试计划？
需求分析后，在整个测试工作过程中，不断修改
• 3. 由谁来编写测试计划？
具有丰富经验的项目测试负责人
测试计划的核心活动
1.确定测试策略
2.确定测试系统（软件和硬件）
3.预估工作量（资源和时间进度计划）
4.评估事件进度风险并准备风险缓解计划
5.准备并复查测试计划文档
测试计划的设计与实现
测试策略（5）
• 确定测试范围
- 问题：
测试过度
测试不足
- 某些阶段的测试或者某些内容的测试可以简化
- 当对原有系统进行修改升级时，某些测试不需要
- 某些测试根本不可能进行
• 确定测试顺序
- 先测优先级最高的需求
- 对新功能和修改功能进行测试
- 运用等价划分技术和边界值分析技术减少测试工作量
- 测试那些最有可能出现问题的地方
- 关注用户最常使用的功能和配置情况等
• 确定测试方法
• 测试标准
- 入口标准：描述在开始之前需要做哪些工作
- 出口标准：描述在怎样的情况下可以结束测试
- 暂停/继续测试：
描述如果缺陷妨碍测试进行下去，会发生什么事情。如果情况很糟，无法执行计划的测试，则应暂停测试，等完成修复工作后，再完成测试工作。
- 通过/失败标准
执行每项测试应该有一个明确的预期结果。如果得到了预期的结果，测试就通过。否则表示测试失败。
• 自动化测试工具的选择
- 是否使用自动化测试工具，哪个阶段用什么工具
- 好处：
能够很好进行性能测试和压力测试
能够改进回归测试
能够缩短测试周期
能够提高测试工作的课重复性
- 测试软件的编写
确定测试系统
• 确定测试系统
- 测试系统不仅指用于测试的硬件，也包括测试架构以及测试配置
- 测试架构：测试用例的组织形式
- 测试配置：软硬件环境
预测工作量（2）
• 预测工作量
- 确定要完成的任务：测试用例的组织形式
- 确定每个任务的所需工作量
- 确定完成每个任务的时间
- 为测试工作建立详细的时间进度计划和里程表
• 评估进度风险
- 开始测试时，所需硬件没有到位
- 开始测试时，测试的系统还没有布置好
- 开始测试时，测试用例还没有准备好
- 测试过程中，需求发生变更
- 测试过程中，用户界面发生变更
复查测试文档
- 详细描述工作的范围
- 估计定义测试用例和实施测试所需工作
- 确定所需资源（人、硬件、软件和工具）
- 为各个人物分配资源
- 制定进度表
- 确定进度安排或质量风险
- 制定解决风险的应急计划
- 追踪项目进展并采取纠正措施
- 在适当的时候重新定制
- 向整个项目提供测试状态的可视性
- 对失败或堵塞测试纠正后重新测试
测试计划的目的
1、尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。
2、所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。
3、测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。
测试计划注意事项
• 增强测试计划的实用性
• 坚持“5W1H”规则，明确内容与过程
• 采用评审和更新机制，保证测试计划满足实际需求
• 测试计划和测试策略
测试计划编写6要素？（5W1H）
测试类型和目的
测试阶段
• 可以用表格明确测试的执行情况
• 不同测试阶段对测试内容和测试方法考虑不同
如：单元测试——考虑代码的覆盖
系统测试——考虑需求的满足情况
测试方法
功能测试（2）
• 测试目标
- 确保所有的被测对象功能正常
• 测试方法
- 至少为每条测试需求设计两个测试用例，一个用来验证是否实现了应有的功能，一个用来检查功能的实现是否存在问题
- 符合业务规则的操作和数据是否可以得到预期的结果？
- 不符合业务规则的操作和数据是否都被拒绝接受，并提供出正确的、容易理解的提示信息。
- 所有的业务规则的实现是否同需求中的描述相互一致
• 系统测试阶段所有的测试用例均采用手工方式通过对用户界面的操作来执行。
• 完成标准：
- 对系统测试阶段：必须保证所有准备执行的测试用例全部被执行，并且保证
所有提交的缺陷全部被正确地解决。
• 特殊事项的考虑
- 如果由于某项原因导致测试时间被缩短，将会考虑按照测试用例的优先级重新选择测试用例
性能测试
• 测试目标
- 确保系统在一般状态和极限状态下，都可以保持正常的响应速度和最大用户
连接数量
• 测试方法
- 关于极限的模拟，将考虑使用以下几个方法实现：
1、在服务器端启动大量事务以模拟服务器端系统资源被大量占用的情况
2、使用某软件模拟网络拥挤的情况
3、启动数据库事务来模拟数据库端对数据进行修改时的竞争情况
4、使用某软件录制性能测试脚本，虚拟50个用户同时操作的情况，并在10台计算机上连续运行7天
5、准备超过100万条数据，验证对大量数据进行查询和汇总的时间
确定测试资源（4）
• 人力资源
- 测试工作完成需要多少人？
- 参与者都需要哪些技能？
- 每个人的工作准备如何分配？
- 是否需要专门的硬件工程师来协助网络和系统维护？
- 是否需要其他部门的同事共同参与？
• 硬件和软件资源
- 测试工作共需要多少计算机？
- 计算机从何处调配？
- 有没有为测试环境的搭建单独准备一台服务器？
- 是否准备了不同配置的测试用例执行机器？
- 如果需要介入internet专线，是否可以提供？
- 如果测试不同硬件的兼容性，是否有足够多的硬件资源可以使用？
- 常用的系统软件和软件工具在哪里可以找到？
- 是否需要把测试用机的操作系统统一？
• 其他资源
- 文档的存放位置？
- 项目参与者的角色如何？
- 项目参与者的联系方式？
时间表（3）
• 某项工作的开始时间？
- 可以写相对时间，如，从开发部门提交可供测试的版本开始，而非具体的年
月日
• 某项工作需要多少时间完成？
- 评估工作量+测试效率评估=确定测试用时间
- 评估工作量
1、被测对象的数量
2、 业务复杂度等
- 测试效率的评估
1、 测试活动参与者的数量
2、 可以投入的工作时间
3、参与者的技术水平和工作效率
4、测试资源和支持工作是否到位
• 某项工作需要多长时间完成？
- 一个简单的方法：参考过去的经验
- 查找过去的测试计划和日志
- 找到工作量相仿的产品
1、参与者多少？
2、 工作用时多少？
3、 单位工作效率如何？
- 根据上述历史数据，可以估算出本次的工作用时
词汇表
生成测试计划文档
如何不让测试计划束之高阁
• 原因：测试计划缺乏参考价值
• 措施：
- 上面讲的完成测试计划的方法并不是完成该项工作的全部方法
- 当那些会对测试计划产生影响的因素发生变化时，要及时跟新测试计划的相关内容
1、软件需求和软件设计发生变化
2、同时调离项目
3、测试设备的配备无法达到要求
4、测试计划发生重大调整，要考虑工作量是否需要重新估算，是否应调整测试所用时间
- 计划不是用来应付领导或客户的，而是用来指导实际工作的，因此，计划的内容要正确、详实、具有可行性
- 若项目过于庞大，可以尝试着把工作阶段分几个更小的阶段来设计完成。把测试工作控制在自己的能力范围内。
风险评估
• 风险评估的考虑要点
- 重要性、严重性
- 原因
- 可能性
1、重要性和严重性
2、原因
3、可能性1
4、可能性2
确定测试策略
• 测试策略的描述内容
- 不同的测试阶段需要考虑的测试类型和具体目标
- 需要哪些测试技术，不同测试阶段结束的标准是什么？
- 一些对测试工作可能产生影响的因素
测试环境
-从软件的编码、测试到用户实际使用，存在着：开发环境、测试环境和用户环境。
- “环境”，指的是被测试软件所运行的软件环境和硬件环境。
-测试环境是测试人员为进行软件测试而搭建的环境，一般情况下，将包括多种典型的用户环境。
• 测试环境的环境项
- 计算机平台
- 操作系统
- 浏览器
- 软件支持平台
- 外部设备
- 网络环境
- 其它专用设备
定义工作进度
• 确认工作任务
• 工作任务可以分为两类：
- 一类是可以直接和需求文档对应起来的，
- 另外一类和需求文档没有直接的关联。
• 在需求文档中，对需求中的每一个条目，都应该有相应的测试工作与之对应起来。
• 确认好测试任务后，还应该排列这些任务的优先级。
• 与需求文档没有直接关联的任务：
- 开发和安装专用测试工具
- 学习使用测试工具
- 将测试用例编写为脚本或数据文件
- 重新运行以前没通过的测试用例
- 编写测试计划
- 人员培训
- 与程序员之间的交流
- 与客户之间的交流
• 估算工作量
• 工作量可以使用“人*日”、“人*月”、“人*年”这样的单位。
• 测试工作量的估算可以采用以下方法：
- 建立详细的工作分解结构
- 分析以往项目，寻找历史数据
