北大测试全套课件和教案 全程软件测试课件5-6-7

•W 总工作量 •Wo 一轮测试工作量 •Ri 回归递减系数
工作量计算实例
6 大模块 6x60=360 cases 20mins/case =>15 人日 自动化 手动 70% 30% =》252 cases -- 108 cases
10 测试脚本/天 =》26人日 手动回归测试 108x (1+70%+40%)=227 cases 组合数 227x3=681 cases 5 mins/ cases =>12人日 自动化运行： 5人日
最关键的还是孙悟空，由于孙悟空是这个取经团队里的核心，但是他的性格 恐怕作为普通人来说没有人会让这种人呆 极为放荡， 回想他那大闹天空的历史， 在团队里， 但是取经项目要想成功实在缺不了这个人， 只好采用些手腕来收复他。 这些手段是， 首先， 把他给弄得很惨 （压在五指山下 500 年， 整天喝铜汁铁水） ； 在他绝望的时候， 又让项目经理去解救他于水火之中以使他心存感激； 当然光收 买人心是不够的，还要给他许诺美好的愿景（取完经后高升为正牌仙人）；当然 最主要的是为了让项目经理可以直接控制好他， 给他戴个紧箍， 不听话就念咒惩 罚他。 孙悟空毕竟是牛人，承担了取经项目中的赶妖除魔的绝大多数重要任务，虽 然是个难于管束的主，不能只用手段来约束他，这时猪八戒的作用就出来了，在 孙悟空苦恼的时候，上司不能得罪，沙和尚这种老实人又不好伤害，只好通过戏 弄猪八戒来排除心中的郁闷， 反正猪八戒是个乐天派， 任何的指责都不会放在心 上。 在取经的项目实施的过程中，除了自己的艰辛劳动外，这个团队非常善于利 善于利 资源，只要有问题搞不定，马上向领导汇报（主要是直接领导观音）， 用外部的资源 用外部的资源 或者通过各种关系，找来各路神仙帮忙（从哪咤到如来佛），以搞定各种难题。 西游记里特别强调得到高层支持的重要性， 有没有靠山真的很不同， 君不见象白 骨精这种没有靠山的妖魔都会死得很惨； 只要有靠山的， 这个妖魔就算犯了天大 的事，关键的时候总会有后台跳出来搭救（这种例子太多了）。 项目团队的组织和项目实施真的是一门艺术，希望有志于做项目经理的同仁 能够以另一种角度来好好看一下西游记。
Google Talk的性能测试
• 计算机资源 • 网络资源 • 通讯畅通 • 故障恢复 • 长时间运行
测试计划2
（第6次课）
项目计划编写 （动手） 1、项目工作分解结构表（锯齿缩进编码） 2、项目工作分解结构图 3、项目工作责任距阵（责任人，辅助人）
工作量估计
W=Wo+Wo x R1+Wo x R2+Wo x R3
需求分析 审查 Release
单元测试 回归测试
集成测试 验收测试
功能测试 系统测试
WBS
目的：明确项目所包含的各项工作 目的 内容：项目分解就是先把复杂的项目逐步分解成一层一层的要素（工作）， 内容 直到具体明确为止． 工具： 工具：项目分解的工具是工作分解结构ＷＢＳ原理，它是一个分级的树型结 构，是一个对项目工作由粗到细的分解过程．
测试里程碑
M1——M6 软件测试周期划分：动手记忆
测试风险分析与控制 P73
人员 环境 测试范围 回归测试 需求变更 技术 工具
测试策略的有效制定
事例解释
设计验证 （第三章）
系统架构审查
产品设计规格说明书的复审
系统部署设计的审查
设计验证的分类
• 软件运行和服务 • 软件部署和维护 • 体系结构相关
产品设计规格说明书的复审
规格说明书的编写方法： 1）采用良好的结构化和专业语言编写文本型文档 2）建立图形化模型 3）形式化的逻辑语言来编写
多层次审查
高层次审查 ----功能模块、复杂性 和可测试性等方面 低层次审查 1. 语句和段落的简短 2. 主动语态，表达方式的一致 3. 无错字，语法、标点的正确 4. 避免模糊、主观术语 5. 避免比较性的词
需求评审的作用 P41
1) 尽早发现问题，降低成本、风险 2) 软件的可测试性 3) 认识统一（On the same page） 4) 理解产品，位测试计划和测试方法的使用做准备 5) 确定测试目标和范围
测试人员在需求评审中的角色 P43
几个概念 1）交叉评审（Pear-to-pear Review） 2）轮审（Pass-round） 3）走查（Ｗalkthrough） 4）小组评审（Group Review） 5）审查（Inspection）
58人日 人日
测试计划3
（第7次课）
作业讲解 8 大模块 8x60=480 cases 30mins/case =>30 人日 自动化 手动 70% 30% =》336 cases -- 144 cases
10 测试脚本/天 =》34人日 手动回归测试 144x (1+80%+50%)=332 cases 组合数 332x3=996 cases 5 mins/ cases =>17人日 (一天运行5小时，3小时分析和沟通) 自动化运行： 5人日
全程软件测试
测试计划
（第五次课） 第五次课）
授课：胡运友
一个任务：生日宴会的实施计划
10分钟Biblioteka 产品需求文档的审查和评审需求评审的作用？： 保证系统需求在市场需求文档（MRD）或产品需求文档（PRD）及相关 文档中的无歧义描述。
需求文档的评审是做好软件测试计划和设计等的 基础。
Bug在软件项目过程中的产生比重
需求评审标准
1）真确性 2）完备性 3）易理解性 4）一致性 5）可行性 6）易修改性 7）易测试性 8）易追溯性
需求评审方法
分层次评审
分阶段评审
Sign-off 评审结束的标志
测试需求和任务
• 功能测试需求
• 非功能性的测试需求
功能测试需求 P47
非功能测试需求 P49
软件测试的阶段标准
生日宴会
1.0 准备 1.1 邀请来宾 1.2 采购物品 2.0 晚宴 2.1清洗 2.1.1清洗食品 2.1.2清洗餐具 2.2 做菜 2.2.1做凉菜 2.2.2做熟菜 2.2.2.1制作蔬菜类 2.2.2.2制作海鲜类 2.2.2.2制作海鲜类 2.2.2.3制作其它类 2.2.2.3制作其它类 2.3 吃饭 3.0娱乐 3.1音响调试 3.2灯光布置 3.3室内布置 4.0 结束 4.1 送客 4.2 打扫卫生
界面设计的评审
• 用户界面的惯例和通用法则 • 独特性 • 一致性和规范性 • 自助功能的提供 • 易懂，易用 • 美观性 • 快捷方式 • 错误保护
V&V
系统部署审查
• 逻辑设计 • 物理设计 • 可用性 • 可伸缩性 • 安全性
作业：安装Google talk 和 Yahoo 日历
软件缺陷构成示意图
其他 代码 6% 15%
？
规格说明书 54%
设计 25%
规格说明书
设计
代码
其他
为什么SPEC会产生那么多的Bug?
• 用户理解问题 • 软件产品开发出来前的不清晰 • 需求变化的不一致性 • 开发和管理层的重视不够 • 沟通 • 错误的放大
做个小游戏
缺陷的成本代价与时间关系 100 80 60 40 20 0 需求分析 设计 编程 测试 发布 系列1
责任分配表
图例： ▲负责 责任者（个人或组织） 责任者（个人或组织） ●辅助 工作分解结构 任务编码 任务名称 △承包
项目负责人审核意见： 项目负责人审核意见： 签名： ： 日期
测试范围分析和工作量估计
Google talk 客户端软件
系统测试范围的分析
1.一般系统测试的需求 1）容错处理 2）兼容性要求 3）配置要求 4）性能要求 5）安全性要求 6）可靠性要求 7）日志文件
WBS分解方法
基于可交付成果的划分 上层一般为可交付成果为导向 下层一般为可交付成果的工作内容 基于工作过程的划分 上层按照工作的流程分解 下层按照工作的内容划分 按产品本身的结构划分 按组织的职责划分
WBS注意事项
分解后的任务应该是： 可管理的、可定量检查的、可分配任务的、独立的 复杂工作至少应分解成二项任务 表示出任务间的联系 不表示顺序关系 与任务描述表一起进行 包括管理活动 包括次承包商的活动
86人日 人日
测试资源需求
……… 人力资源 ……….
软件测试
硬件资源
……….
软件资源
……….
项目管理： 项目管理： 西游记
测试团队组建
一个故事
古代有一个最成功的项目团队， 那就是西游记的取经团队背景： 为了完成西天取 经任务，组成取经团队，成员有唐僧、孙悟空、猪八戒、沙和尚。其中唐僧是项 目经理、孙悟空是技术核心 孙悟空是技术核心、猪八戒和沙和尚是普通团员。这个团队的高层领导 孙悟空是技术核心 是观音。 有很坚韧的品性和极高的原则 团队的组成很有意思， 唐僧作为项目经理 PM， 性，不达目的不罢休，又有很得上司支持和赏识（直接得到唐太宗的任命，既给 袈裟，又给金碗；又得到以观音为首的各路神仙的广泛支持和帮助）。 沙和尚言语不多，任劳任怨 任劳任怨，承担了项目中挑担这种粗笨无聊的工作。猪八 任劳任怨 戒这个成员，看起来好吃懒做，贪财好色，又不肯干活，最多牵下马，好像留在 团队里没有什么用处，其实他的存在还是有很大用处的，因为他性格开朗，能够 接受任何批评而毫无负担压力，在项目组中承担了润滑油 润滑油的作用。 润滑油