北大测试全套课件和教案 全程软件测试课件5-6-7
北大测试全套课件和教案-14.-第5章-第4讲-1
边界值分析法思想和常用的边界值。
2、本课内容（75 分钟） 因果图理论知识（10 分钟） 因果图举例（50 分钟） 错误推测法（5 分钟） 功能图法（10 分钟）3、课后小结（5 分钟）4、布置作业（2分钟）教学参考书： 1. 软件测试方法和技术朱少民清华大学出版社 2. 软件测试Paul C.Jorgensen 机械工业出版社作业: 1．因果图中有哪些关系和约束？ 2．简述用因果图法设计测试用例的步骤。
复问题目： 序号题目学生成绩 1 2 3 教学内容与方法步骤 5.4 因果图方法引言： 前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系, 相互组合等。
考虑输入条件之间的相互组合，可能会产生一些新的情况。
但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。
因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。
这就需要利用因果图（逻辑模型）。
因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
2) 约束输入状态相互之间还可能存在某些依赖关系，称为约束。
例如, 某些输入条件本身不可能同时出现。
输出状态之间也往往存在约束。
在因果图中,用特定的符号标明这些约束。
如图 5-4 所示。
a a a a a b b b b b 强制cE异I或O唯一RM要求图 5-4 因果图约束 A.输入条件的约束有以下 4 类： E①约束（异）： a 和 b 中至多有一个可能为 1 ，即 a 和 b 不能同时为1。
I②约束（或）： a、 b 和 c 中至少有一个必须是 1 ，即 a、 b 和 c 不能同时为 0。
O③约束（唯一）； a 和 b 必须有一个，且仅有 1 个为 1 。
R④约束（要求）： a 是 1 时， b 必须是 1 ，即不可能 a 是 1 时 b 是 0。
北大测试全套课件和教案 软件测试概述课件3
What is Bug?
Bug一词的原意是“臭虫”或“虫子”。但是现在，在电脑系统或程序中， 如果隐藏着的一些未被发现的缺陷或问题，人们也叫它“Bug” ．
Bug的由来
•机诞生之日起,就有了Bug，第一个有记载的Bug是美国海军的编 程员，编译器的发明者格蕾斯哈珀（Grace Hopper）发现的。哈珀后 来成了美国海军的一个将军，主持了著名计算机语言Cobol的开发。 1945年9月9日，下午3点，哈珀中尉正领着他的小组构造一个称为“马 克二型”的计算机。这还不是一个完全的电子计算机，它使用了大量的 继电器，是一种电子机械装置。第二次世界大战还没有结束，哈珀的小 组夜以继日地工作。机房是一间第一次世界大战时建造的老建筑，那是 一个炎热的夏天，房间没有空调，所有窗户都敞开散热。 突然，“马克二型”死机了。技术人员试了很多办法，最后定位到70号 继电器出错。哈珀观察这个出错的继电器，出现一只飞蛾躺在中间，已 经被继电器打死。他小心地用摄子将蛾子夹出来，用透明胶布粘到“事 件记录本”中，并注明“第一个发现虫子的实例。” 从此以后人们将计算机错误戏称为虫子（Bug），而把找寻错误的工作 称为（Debug）。 哈珀的事件记录本，连同那个飞蛾，现在陈列在美国历史博物馆中。
• 不充分的测试是愚蠢的，而过度的测试 是一种罪孽
软件测试的心理学问题
• 1、程序测试的过程具有破坏性 • 2、程序员应避免测试自己的程序 • 3、程库设计机构不应测试自己的程序
• 好的测试工程师应具备的素质 ？
• • • • • • • • • • •
①、沟通能力。 ②、移情能力 ③、技术能力 ④、自信心 ⑤、外交能力 ⑥、幽默感 ⑦、很强的记忆力 ⑧、耐心 ⑨、怀疑精神 ⑩、自我督促 11、洞察力
北大测试全套课件和教案第7章验收测试
验收测试过程的主要内容（续）
4. 测试环境搭建：建立测试的硬件环境、软件环境 等。（可在委托客户提供的环境中进行测试）
5. 测试实施：测试并记录测试结果。 6. 测试结果分析：根据验收通过准则分析测试结果，
作出验收是否通过及测试评价。 7. 测试报告：根据测试结果编制缺陷报告和验收测
试报告，并提交给客户。
• 通常，正式的审核过程分为5个步骤：
–计划 –预备会议（可选）：对审核内容进行介绍并
讨论 –准备阶段：各责任人事先审核并记录发现的
问题 –审核会议：最终确定工作产品中包含的错误
和缺陷 –问题追踪
7.5 用户验收测试实施(续)
审核要达到的基本目标是： 根据共同制定的审核表，尽可能地发现 被审核内容中存在的问题，并最终得到 解决。
北大测试全套课件和教案第7章验 收测试
第7章 验收测试
7.1 验收测试的主要内容 7.2 验收测试过程 7.3 验收测试的常用策略 7.4 验收测试报告 7.5 用户验收测试实例
7.1 验收测试的主要内容
• 验收测试是部署软件之前的最后一个测 试操作。
• 验收测试的目的是：确保软件准备就绪， 并且可以让最终用户将其用于执行软件 的既定功能和任务。
《程序维护手册》的主要内容包括：系统说明 （包括程序说明）、操作环境、维护过程、源 代码清单等，编写目的是为将来的维护、修改 和再次开发工作提供有用的技术信息。
《程序员开发手册》的主要内容包括：系统目标、 开发环境使用说明、测试环境使用说明、编码 规范及相应的流程等，实际上就是程序员的培 训手册。
7.5 用户验收测试实施(续)
• 施验收测试的常用策略有三种，它们分 别是：
1. 正式验收测试 2. 非正式验收或 α 测试 3. β 测试
北大测试全套课件和教案 7. 第4章 第1讲
《软件测试基础》授课教案授课内容：第四章白盒测试技术授课课次：第7次课授课时数：2学时授课日期: 上课教室:目的与要求：了解静态测试的必要性；理解静态测试的方法，包括代码检查、静态结构分析、代码质量度量。
教学重点：代码检查和编程风格教学难点：代码质量度量教学方式：1.运用《白盒测试技术》课件进行课堂讲授，了解静态测试的必要性；2.通过讲述静态测试，拓宽学生们对测试的理解，测试不光是设计用例，执行用例观察结果，测试的工作也包括不实际运行软件，对软件评估。
3.展开课堂讨论，怎们样做静态测试。
教学内容：1．代码检查2．静态结构分析3．代码质量度量4．课堂讨论。
内容提要及时间分配：1、课前引导（5分钟）◆什么叫做静态测试和动态测试？◆什么叫做白盒测试和黑盒测试。
2、代码检查（50分钟）◆代码走查（10分钟）◆编程风格与规范（25分钟）◆代码审查（15分钟）3、静态结构分析（5分钟）4、代码质量度量（5分钟）5、课堂讨论（20分钟）在做静态测试的时候，我们可能会遇到什么困难？怎样解决呢？6、课后小结和布置作业（5分钟）教学参考书：1.软件测试方法和技术朱少民清华大学出版社2.软件测试Paul C.Jorgensen 机械工业出版社讨论与思考：为什么要做静态测试，在做静态测试的时候，我们可能会遇到什么困难？怎样解决呢？作业:试写c++语言编程中变量和常量的命名规范。
复问题目：教学内容与方法步骤4.1 静态测试引言：静态测试包括包括代码检查、静态结构分析、代码质量度量等。
它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
动态测试在完成静态测试之后进行，这样，就需要设计一系列的测试用例来确保测试的完整性和有效性，而在测试用例的设计中，通常会把白盒测试和黑盒测试结合起来使用。
本章主要介绍静态测试技术和白盒测试技术和方法，白盒测试技术包括逻辑覆盖、程序结构分析、路径测试和程序插桩。
4.1 静态测试技术静态测试是指不运行程序进行的测试------只是检查和审阅。
最新北大测试全套课件和教案 白盒测试.教学讲义PPT
2.判定覆盖
• 基本思想是：设计若干测试用例，运行被 测程序，使得程序中每个判断的取真分支 和取假分支至少经历一次，即判断真假值 均曾被满足。
1
2.判定覆盖……续1
a=2，b=1 ，c=6可 覆盖判断M的Y分支 和判断Q的Y分支； a=-2，b=-1 ，c=-3 可覆盖判断M的N分 支和判断Q的N分支 。 这两组测试用例可覆 盖所有判定的真假分 支。
a>1 or c>1
c=c/a c=c+1
5N c=b+c
1.语句覆盖……续2
• 【优点】 ：可以很直观地从源代码得到 测试用例，无须细分每条判定表达式。
• 【缺点】 ：由于这种测试方法仅仅针对 程序逻辑中显式存在的语句，但对于隐 藏的条件是无法测试的。如在多分支的 逻辑运算中无法全面的考虑。语句覆盖 是最弱的逻辑覆盖。
8. End if 9. c=b+c
c=b+c
c=c/a c=c+1
1.语句覆盖
• 基本思想是：设计若干测试用例，运行 被测程序，使程序中每个可执行语句至 少执行一次。
1
1.语句覆盖……续1
只需设计一个测试 用例:a=2，b=1， c=6；即达到了语 句覆盖。
1 Y2
a>0 and b>0
3N Y4
1 Y2
a>0 and b>0
3N Y4
a>1 or c>1
5N c=b+c
判断 M
c=c/a
c=c+1
判断 Q
2.判定覆盖……续2
a=1，b=1 ，c=-3 可 覆盖判断M的Y分支 和判断Q的N分支 ； a=1，b=-2 ，c=3可 覆盖判断M的N分支 和判断Q的Y分支 ； 同样的这两组测试用 例也可覆盖所有判定 的真假分支。
2022年北大测试全套课件和教案-2.--第2讲
《软件测试基础》讲课教案讲课内容：第一章测试概述讲课课次：第2次课讲课时数：2课时讲课日期: 上课教室:目旳与规定：通过课堂教学，使学生理解软件测试过程，掌握软件软件质量旳概念及质量保证体系，理解软件测试职业与素质规定。
教学重点：1.软件质量旳概念及质量保证体系2.软件测试职业与素质规定教学难点：软件质量保证和软件测试旳关系教学方式：1.运用《软件测试技术》课件进行课堂讲授，加深对软件测试基本概念旳理解；2.在简介软件测试职业及其素质规定后，组织学生讨论对从事软件测试职业旳生涯设计有何影响？教学内容：1.软件测试过程2.软件质量保证与软件测试旳关系3.软件测试职业内容提纲及时间分派：1、课前复习（5分钟）◆什么叫软件缺陷？引起软件缺陷旳最大原因是什么？◆软件测试旳定义2、软件测试过程（35分钟）◆软件测试过程模型简介◆测试过程管理理念◆测试过程管理实践3、软件质量保证与软件测试旳关系（25分钟）◆软件质量保证旳基本概念◆软件质量保证与软件测试旳关系4、软件测试职业（20分钟）◆企业对软件测试职位旳规定◆怎样成为一种优秀旳软件测试人员5、课后小结和布置作业（5分钟）教学参照书：1.软件测试措施和技术朱少民清华大学出版社2.软件测试Ron Patton 机械工业出版社3.软件测试教程贺平电子工业出版社4.软件测试旳有效措施William E.Perry 机械工业出版社讨论与思索：1.为何不也许完全测试程序？2.软件测试员旳目旳是什么？作业:1.启动Windows计算器程序，输入5，000-5=（逗号不能少），观测成果。
这是软件缺陷吗？为何？2.假如测试飞行之类旳模拟游戏，精度和精确度哪一种愈加值得测试？复问题目：教学内容与方法步骤1.4 软件测试过程引言：软件测试过程是一种抽象旳模型，用于定义软件测试旳流程和措施。
众所周知，开发过程旳质量决定了软件旳质量，同样旳，测试过程旳质量将直接影响测试成果旳精确性和有效性。
软件测试教案ppt课件
软件测试的对象：
——软件测试不等于程序测试。
——软件测试贯串于软件定义和开发的整个过程。
——软件开发过程中所产生的需求规格说明、概要 设计规格说明、详细设计规格说明以及源程序都是 软件测试的对象。
A Free sample background from
的定义有两种描述：
定义1：软件测试是为了发现错误而执行程序的 过程。
定义2：软件测试是根据软件开发各阶段的规格 说明和程序的内部结构而精心设计的一批测试用
例，并利用这些测试用例运行程序以及发现错误
的过程，即执行测试步骤。
A Free sample background from
功能冻结
代码冻结
图1-3 软件测试的周期性
第1章
A Free sample background from
软件测试概述
Slide 19
软件测试的基本理论（续）
6、测试停止的依据（标准） 第一类标准：测试超过了预定时间，则停止测试。 第二类标准：执行了所有的测试用例，但并没有发
北大测试全套课件和教案 5. 第2章 第3讲
《软件测试基础》授课教案授课内容：第二章实例介绍授课课次：第5次课授课时数：2学时授课日期: 上课教室:目的与要求：通过佣金问题、简单ATM系统和货币转换器的介绍，让学生理解软件的商业用途，对于这类软件我们采用什么样的思维方式，如何从测试的角度去考察实用性软件。
教学重点：1．佣金问题2．简单ATM系统3．货币转换器教学难点：从测试的角度去思考商业软件和工程软件的测试工作。
教学方式：1.运用《实例介绍》课件进行课堂讲授，加深对软件测试策略的理解；2.讲述几个实例为什么被选为我们通篇使用的例子，这样，也锻炼了学生的测试思维。
教学内容：1．佣金问题2．简单ATM系统3．货币转换器内容提要及时间分配：1、课前提问（5分钟）◆对于循环结构，我们怎样用流程图实现。
◆什么时候用FOR循环，什么时候用While循坏。
2、佣金问题（30分钟）◆佣金问题陈述◆问题实现3、简单ATM系统（25分钟）◆问题陈述◆问题实现4、货币转换器（25）◆问题陈述◆问题实现5、课后小结和布置作业（5分钟）教学参考书：1.软件测试方法和技术朱少民清华大学出版社2.软件测试Paul C.Jorgensen 机械工业出版社3.Visual Basic.编程导论David I.Schneider 电子工业出版社讨论与思考：部分GUI设计的艺术是为了防止用户输入错误。
事件驱动的应用程序尤其容易受到输入错误的影响，因为时间可以以任何顺序发生。
利用前面已经给出的货币转换器，我们可以输入人民币金额，然后点击计算按钮，而没有选择要换算的外币。
类似的，我们还可以选择一个国家并点击计算按钮，而没有输入人民币金额。
我们怎么样控制这种情况呢？作业:用Visual Basic实现如图2-4的货币管理器。
复问题目：教学内容与方法步骤2.4佣金问题引言：这是一个商务计算例子，包含了计算和决策，因此引出有意思的测试问题。
2.4.1问题陈述一酒水销售公司指派销售员销售各种酒水。
软件测试完整ppt课件
目录 首页 上页 下页 末页
第10章 软件测试
7
有关软件测试的错误观点
“软件测试是为了证明程序是正确的，即测 试能发现程序中所有的错误”。事实上这是不可 能的。要通过测试发现程序中的所有错误，就要 穷举所有可能的输入数据。
例：程序P有两个整型输入量 X、Y，输出量为Z，
在32位机上运行。所有的测试数据组（Xi，Yi）的 数目为：232×232= 264，1毫秒执行1次，共需5亿
目录 首页 上页 下页 末页
第10章 软件测试
6
10.1 软件测试基础
一、软件测试的目的
➢ 测试是一个为了发现错误而执行程序的过程 ➢ 一个好的测试用例是指很可能找到迄今为至尚未发
现的错误的测试用例 ➢ 一个成功的测试是指揭示了迄今为至尚未发现的错
误的测试 根据这个测试目的，应该排除对测试的错误观点，设 计合适的测试用例，用尽可能少的测试用例，来发现 尽可能多的软件错误。
12
评审（Review）
评审是由若干开发人员、项目经理、测试人员、用 户或领域专家等组成一个会审小组，通过阅读、讨论和争 议，对工作制品进行静态分析的过程。
类型：需求评审、设计评审和代码评审。
•评审过程
–小组负责人先把需求规格说明、设计说明或程序代 码及有关要求、规范等分发给小组成员，作评审依据；
–在充分阅读有关材料后召开评审会议，主要开发人 员进行讲解，其他成员提出问题并展开讨论，审查是否存 在错误；
d — 定义 r — 引用 u — 未引用
R：duuuuu 只定义不用 S：uruuur 未定义引用 Y：uuddru 连续定义
目录 首页 上页 下页 末页
第10章 软件测试
16
审查（Inspection）
北大测试全套课件和教案-第1-6章习题与解答
北大测试全套课件和教案-第1-6章习题与解答
第1章习题解答
1．为何说软件缺陷的最大来源是产品说明书？
解答：产品说明书没有写，我们要记得说不出来就做不出来；
产品说明书不完整、不停更改，难以和开发人员沟通。
2．简述软件质量保证和软件测试的关系。
解答：软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。
软件测试流程包括项目计划检查、测试计划创建、测试设计、执行测试、更新测试文档和测试评估；SQA的活动可总结为协调度量、风险管理、文档检查、促进／协助流程改进、监察测试工作。
软件质量保证和软件质量控制之间的界限越来越模糊了。
软件测试是SQA中的重要手段，SQA的主要功能在软件测试中得到体现，集中在静态测试中，两者的关系越来越紧密。
3．在了解软件测试职业及其素质要求后，对你从事软件职业的生涯设计有何影响？
略。
第2章习题解答
1.用流程图实现下面这个问题：计算并报告一个班学生的平均分数。
2.用伪代码实现下面这个问题：输入一年中的某月，然后给出该月
的天数，如果是2月，用户将回答这年是否是闰年。
#include<iostream.h>
void main()
{
int month,year;
bool Isleap;
cout<<"please input year:(1812-2012)";
cin>>year;。
《软件测试》PPT课件
划（测试规划）。一般而言，测试计划可以在需求分析 完成后开始，详细的测试用例定义可以在设计模型被确 定后立即开始。因此，所有测试可以在任何代码被编写 前进行计划和设计。 ⑶ Pareto 原则应用于软件测试。Pareto 原则意味着测试发 现的错误80%的很可能集中在20%的程序模块中。 ⑷ 测试应从“小规模”开始，逐步转向“大规模”。即从 模块测试开始再进行系统测试。 ⑸ 穷举测试是不可能的，因此，在测试中不可能覆盖路径 的每一个组合，然而，充分覆盖程序逻辑，确保覆盖程 序设计中使用的所有条件是有可能的。 ⑹ 为达到最佳的测试效果，提倡由第三方来进行测试。
步行检查（Walkthroughs）最常用的静态分析方法。 与代码会审类似，也要进行代码评审，但评审过程 主要采取人工执行程序的方式，故也称为“走查”。
步行检查时，还常使用以下分析方法： ① 调用图 从语义的角度考察程序的控制路线。 ② 数据流分析图 检查分析变量的定义和引用情况。
A READY
N
选择用例： [(2,0,4),(2,0,3)]
2、判定覆盖
a
A>1 AND B=0
N
b
c
Y
X:=X/A
A=2 OR X>1
dN
e
Y
X:=X+1
使得程序中每个判定至少为 TRUE 或FALSE各一次。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
•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， 性，不达目的不罢休，又有很得上司支持和赏识（直接得到唐太宗的任命，既给 袈裟，又给金碗；又得到以观音为首的各路神仙的广泛支持和帮助）。 沙和尚言语不多，任劳任怨 任劳任怨，承担了项目中挑担这种粗笨无聊的工作。猪八 任劳任怨 戒这个成员，看起来好吃懒做，贪财好色，又不肯干活，最多牵下马，好像留在 团队里没有什么用处，其实他的存在还是有很大用处的，因为他性格开朗，能够 接受任何批评而毫无负担压力，在项目组中承担了润滑油 润滑油的作用。 润滑油