SVN-4测试规划

实战—功能测试
测Baidu Nhomakorabea目的
测试方法
完成标准 特殊事项
要完成第一轮交付，要把所有的功能均测试一遍
1. 针对每一个测试点，至少编写一条测试用例 2. 每个测试点多考虑用户可能会输入或操作的行为，多从用户或反面编
写用例 3. 用例编写时，针对数据进行等价类、边界值、错误推测法设计用例
针对需求比较明确的业务，采用因果图转判定表设计用例 针对业务流程采用场景法设计用例 4. 本次全部采用黑盒测试 5. 执行测试时注意测试环境 6. 接口测试时采用自动化脚本，自动化脚本请从自动化组得到 7. 测试环境搭建中如有不明白的地方，开发进行协调，开发协调人： Jack
进行管理监督，主要职责：
1（陈XX）
✓ 提供技术指导 ✓ 获取适当的资源
✓ 提供管理报告
确定测试用例、确定测试用例的优先级并
实施测试用例，主要职责：
3（王XX，熬XX，徐XX） ✓ 生成测试计划
✓ 编写测试用例(包括设计测试场景)
✓ 评审测试用例与计划
1（兰XX）
负责SVN，负责版本更新和测试环境搭建
由于不懂测试词汇，因此在这里需要进行阐 述。
术语名
说明
Bugfree 缺陷管理工具
Testlink 用例管理工具
LR
性能测试工具
IETESTER IE浏览器兼容测试工具
Xenu
链接检查工具
用例覆盖率 已执行用例数/用例总数
测试计划的内容－术语&参考资料
参考资料：编写计划时都参考了哪些资料和 文档
压缩测试成本，如不安排出差现场测， 直接拿到本地测，具体活动由测试经 理协调安排。如部分接口无法测试， 由实施人员在现场辅助测试。
测试计划的内容－三大标准
开始标准
1. 测试环境搭建完成且达到可测要求。 2. 测试相关人员准备就绪。
完成标准
1. 测试用例执行覆盖率达到99% 2. 测试需求覆盖率达到100% 3. 系统死锁、系统崩溃、严重错误不能多于1个 （致命） 4. 次要错误不能多于2个(严重等级) 5. 不合理或者别扭，文字错误，微不足道错误不能多于2个 6. 以上错误均不能出现影响用户使用的bug
5
指导进行2次开发
指南.doc
统一安全管理平台V5[1].0(系统集成
6
用户手册
手册)V1.1.doc
7
研发计划v1.0
研发计划
张鹏 张鹏 张鹏 张鹏 张鹏 王伟
测试计划的内容－角色
明确每种角色在测试中的职责和任务
角色 测试组长
测试设计员 配置管理员
QA
所推荐的最少资源
具体职责或注释
（所分配的专职角色数量）
性能管理 网络监视
C ORBA MD
SNMP MD
TCP/IP MD
CDMA网络
仿真终端
数据分析 网络分析 无线分析 报表系统
DB
RS232
MD
MD
外部接口 功能
网络优化 接口
综合服务 支持接口
CRM系统接 口
资源管理 系统接口
部省接口
测试计划的内容－概述
拓扑图
测试计划的内容－术语&参考资料
术语：测试计划这个文档中用到的一些专业 词汇，而这些词汇在其他人（开发、产品）
软件项目在其开发生命周期内出现重大估算，进度偏 差，需暂停或终止时，测试应随之暂停或终止，并备 份暂停或终止点数据。
如有新的项目需求，则在原测试计划下做相应的调整。 若开发暂停，则相应测试也暂停，并备份暂停点数据。 若项目中止，则对已完成的测试工作做测试活动总结。 项目再启动时，测试进度重新安排或顺延。
C. Smith
复审/发布 高级项目管理团队 内部平级复审
内部平级复审 内部平级复审 -
高级项目管理团队
测试经理
高级项目管理团队
截止日期 March 28 March 28 March 28
March 31 March 31 April 2 April 4
TBD
TBD
TBD
测试计划的内容－交付件
测试计划.dor 测试方案.doc 测试用例.doc 各阶段测试报告.doc 测试总报告.doc 各会议纪要.doc 版本报告.doc Bug清单.doc 上线报告.doc 产品使用说明书.doc
2. 更好的方案是，测试计划解决做哪些内容和人员分配形成一 个文档；测试方案解决如何处理计划中提出的内容，用什么 样的对策来更快更优的解决问题，即测试方案是从技术角度 出来形成的一个文档，由此形成两个文档
方案内容
功能测试 界面测试 安全测试 本地/国际化测试 数据库测试 可靠性测试 集成测试 兼容性测试 自动化测试 性能测试 回归测试
测试需求分类
测试需求按适用范围分为公共测试需求和项目测试需求: 公共测试需求：同类型系统共同需要的、通用的需求，列为公共测试
需求。如OA办公系统通用的发文基本信息页面。 项目测试需求：是根据不同的项目，编制出的针对项目特点的测试需
求。
测试需求分类
按需求类别分为:
显性测试需求：即可直接获取的需求，如项目组提供的各类需求文档、会 议纪要、用户手册以及项目组主动告知的一些需求等
编号
资料名称
简介
作者 日期
1
功能列表V1[1].0.xls
需实现的全部功能列表 张鹏
2
统一系统安全管理方案V1[1].1.doc 架构设计说明书
统一系统安全管理平台总体设计说
3
概要设计说明书
明书V1[1].1.doc
统一系统安全管理平台详细设计说
4
详细设计说明书
明书V1[1].1.doc
统一安全管理平台V3[1].0二次开发
测试计划的内容－环境
软件环境
资源名称 测试应用服务器 数据库服务器
浏览器端
资源项 操作系统 应用服务器 操作系统 数据库版本 操作系统 浏览器 Flash版本
Office
描述 RedHat Enterprise 5 Tomcat6.0.30 RedHat Enterprise 5 Oracle11.0.2G Windows xp SP3 IE9，10，firefox、chrome 10.0 2007
里程碑：测试中大事件（节点）
里程碑任务 迭代 C1：Beta 发布版 迭代 C2：R1.0 发布版 迭代 C3：R2.0 发布版
工作量 (pd) 开始日期
TBD
March 15
TBD
April 13
TBD
May 15
结束日期 April 12 May 14 June 17
开始时间
2016-05-01 2016-05-03 2016-05-05 2016-08-11 每周一
测试计划的内容－概述
主要编写系统背景、目的、各种系统概述图 需求规格说明书中一般都有，复制过来即可 系统概述图主要是架构图和拓扑图
测试计划的内容－概述
架构图
系统支撑 管理功能
C/S 终端
B/S 终端
表示层
安全管理 系统管理
适配层
应用层
集中操作维护 局数据管理 仿真终端 智能巡检
网络监控
告警管理 配置管理 拓扑管理
测试规划
目录
测试需求分析
测试计划
测试方案
什么是测试需求
测试需求主要解决“测什么”的问题 ，即指明被测对象中 什么需要测试。 测试需求通常是以软件开发需求为基础进行分析，通过对 开发需求的细化和分解，形成可测试的内容。 测试需求应全部覆盖已定义的业务流程，以及功能和非功 能方面的需求。 测试需求不涉及具体的测试数据，测试数据设计是测试设计 环节应解决的内容；
测试计划的内容－测试工具
测试工具：在测试过程中所使用到的工具
工具名
Bugfree Testlink LR IETESTER Xenu
说明 缺陷管理工具 用例管理工具 性能测试工具 IE浏览器兼容测试工具 链接检查工具
测试计划的内容－甘特图
甘特图：人员任务时间任务表，常用project画
测试计划的内容－里程碑
隐性测试需求：即无法直接获取的需求，需要测试人员在编写时运用自身 的知识、经验、询问或直接运行系统推敲出来的隐含的需求。如程序运行 中一些必要的条件限制，但这些需求无法直接获知，只能通过运行程序逻 辑推敲出来； 再如某系统的行业标准、规范中隐含的需求等。
项目测试需求分为:
功能测试需求：是将系统中显性、不通用的页面、功能，按模块顺序整理 转化为便于测试的一种需求。
结束时间
2016-05-03 2016-05-05 2016-06-05 2016-08-13 每周五
事件 测试计划 测试方案 测试用例 测试报告 会议纪要
负责人
蔡XX 蔡XX 陈XX 蔡XX 朱XX
测试计划的内容－交付件
交付件：测试工作完成后，需要交付的文档
可交付工件 测试计划 测试环境 测试模型
目录
测试需求分析
测试计划
测试方案
测试方案目的
目的是: 怎么测
测试方案需要在测试计划的指导下进行，测试计划提出“做 什么”，而测试方案明确“怎么做”。
测试方案&测试策略
1. 有的软件公司，把测试方案纳入到测试计划中写，文档名称 定为测试计划，但是该计划中的测试方案名称被变更成了测 试策略，即：测试方案＝测试策略，由此形成一个文档
实例
实例
登录画面 输入：职员代码，密码
用户身份检 查
密码过期检 查
密码要通过加密 算法进行检查
密码变更画面
系统初始画面
目录
Chapter 1 测试需求分析 Chapter 2 测试计划 Chapter 3 测试方案
关于测试计划
为什么要编写测试计划？
– 领导能够根据测试计划做宏观调控，进行相应资源配置等； – 测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进
测试数据集 测试过程 测试脚本 测试桩模块、驱动程 序 测试缺陷报告（用于 每次迭代） 测试结果（用于每次 迭代） 测试评估报告（用于 每次迭代）
拥有者 K. Stone S. Jones C. Smith 和 M. Cox M. Cox M. Cox M. Cox M. Cox
C. Smith
C. Smith
测试计划的内容－风险
风险：测试过程中可能出现的风险和规避措 施，如：时间、人力、成本、技术等
风险内容 性能测试人员技能不够 测试周期被压缩 人员不足
项目前期成本过重
规避手段 参加总部组织的性能测试技能培训
周六加班一天，如项目太紧张，周日 也安排加班任务 在5月中旬必须到位3人，其中1人最 好是性能专员
流程测试需求：流程测试需求是将系统业务流程中不同结点不同角色的特 殊功能，整理形成直观的、便于测试的一种需求。
通用测试需求：是指将系统中通用的功能操作、要求转化为便于测试的一 种需求。如通用的功能按钮，页面、规定、名词术语等
非功能测试需求：将软件中除明确的功能需求以外的要求，定义为非功能 测试需求。如兼容性、观感（界面）需求、易用性、性能要求、可维护性 要求等
停止标准
1. 测试中出现一级缺陷较多。 2. 测试环境不稳定。 3. 客户需求变更。
测试计划的内容－三大标准(补充)
软件系统在进行单元、集成、确认、系统、安装、验 收测试时，发现一级错误（大于等于1）、二级错误 （大于等于2）暂停测试返回开发。
软件项目需暂停以进行调整时，测试应随之暂停，并 备份暂停点数据。
1（康XX）
负责整体项目的流程
测试计划的内容－环境
硬件环境
资源名称 测试应用服务器
数据库服务器 测试 PC
资源项 IP地址 操作系统
硬件配置
IP地址 操作系统
硬件配置
数据库类型 操作系统
硬件配置
描述 192.168.1.3 RedHat Enterprise 5 CPU：Celeron（R）G1101 内存：4G 硬盘：256G 网络：局域网100M 192.168.1.4 RedHat Enterprise 5 CPU：Dual-Core E5200 内存：32G 硬盘：500G 网络：局域网100M ORACLE 11.0.2G Windows xp(共1台) CPU：Celeron（R）2.53GHZ 内存：1.25G 硬盘：80G 网络：局域网100M
行的工作等； – 便于其他人员了解测试人员的工作内容，进行有关配合工作
什么时间开始编写测试计划？
需求分析后，在整个测试工作过程中，不断修改
由谁来编写测试计划？
具有丰富经验的项目测试负责人
测试计划的内容
项目概述 术语&参考资料 角色 环境（软件、硬件、网络） 测试工具 甘特图 里程碑 交付件 风险 三大标准 测试策略
测试需求评审
1. 完整性审查：应保证测试需求能充分覆盖软件需求的各种 特征，重点关注功能要求、数据定义、接口定义、性能要 求、安全性要求、可靠性要求、系统约束等方面，同时还 应关注是否覆盖开发人员遗漏的、系统隐含的需求；
2. 准确性审查：应保证所描述的内容能够得到相关各方的一 致理解，各项测试需求之间没有矛盾和冲突，各项测试需 求在详尽程度上保持一致，每一项测试需求都可以作为测 试用例设计的依据。