第一章 软件测试基本概念 本章要点 了解软件，Bug，用户需求，软件测试，测试环境 掌握软件环境分类，测试用例概念

Presentation on theme: "第一章 软件测试基本概念 本章要点 了解软件，Bug，用户需求，软件测试，测试环境 掌握软件环境分类，测试用例概念"— Presentation transcript:

1 第一章 软件测试基本概念 本章要点 了解软件，Bug，用户需求，软件测试，测试环境 掌握软件环境分类，测试用例概念
学会使用测试用例模板与编写测试用例的注意事项

2 ₌ 软件测试 程序测试

3 什么是软件 软件=程序+文档 测试 程序测试 软件测试 文档测试 硬件测试 软件是计算机中与硬件相结合的一部分，包括程序和文档
软件测试：程序测试与文档测试 硬件测试

4 软件的分类 功能划分 系统软件 应用软件 技术架构划分 C/S结构软件 B/S结构软件 按照用户划分 产品软件 项目软件 规模划分 小型
中型 大型

5 Bug的由来

6 Bug 说法 指程序运行时出现的故障 错误：还包括文档，片面了；软件没错，但不是用户需要的 或者要求5秒实现查询，而实际10秒，性能BUG

7 Bug BUG 是否是BUG的标准 完全没有实现的功能：A,B,C-----A,B 基本实现用户需要的功能，但运行出现错误。
实现用户不需要的功能 是否是BUG的标准 是否满足用户的需求

8 Bug 用户想要的----用户所说的-----需求分析人员理解的-----系统需求规格说明书----开发人员理解的---实际软件 沟通

9 Debug

10 CMM --BUG

11 经典Bug案例

12 经典Bug案例

13 经典Bug案例

14 经典Bug案例

15 什么是软件测试 Software Testing 定义 说法 软件测试就是为了发现错误而执行程序或系统的过程
测试文档属于软件测试 按照需求，没发现错误同样有意义 目的是为了在投入生产性运行之前，尽可能多地发现并排 除软件中潜藏的错误，从而提高软件的质量

16 软件测试 标准定义 使用人工或自动手段，运行或测试某个系统的过程，目的在于检验它是否满足规定的需求或弄清预期结果与实际结果的差别。

17 测试环境 什么是测试环境 测试环境=软件+硬件+网络

18 硬件 品牌机 PC机 兼容机 笔记本 硬件 服务器 PDA 手机

19 软件 XP Vista Win7 软件 Mac Unix Linux

20 网络 10M 局域网 100M 网络 互联网 3G网 Wifi

21 测试环境 怎样搭建测试环境 真实 干净 无毒 独立 项目软件 产品软件 产品：硬件更多，软件系统更多，网络更不确定，主流
真实（尽量模仿用户的真实使用环境） 干净：测试环境中尽量不要安装其他与被测软件相关的软件 无毒：没有中毒 测试和开发环境，如数据库共享问题

22 测试用例 什么是测试用例 TestCase—TC,在测试之前设计的一套详细的测试方案，测试环境，测试步骤，测试数据，测试结果
测试用例=输入+输出+测试环境 评价测试人员的标准：发现的有效Bug数，编写的有效测试用例数

23 测试用例

24

25 测试用例 Why：为什么要写用例 When：什么时候写用例 4W Who：由谁来写用例 What：根据什么写测试用例

26 测试用例注意事项 为什么要 团队交流 重复测试 跟踪统计 用户自测 什么时候写 需求计划，测试计划完成后 谁写 测试人员 依据 需求分析

27 第二章：软件测试分类 本章要点 了解黑盒测试和白盒测试的概念，静态测试、动态测试、单元测试的概念和应用，集成测试，系统测试，验收测试的概念
掌握功能测试，性能测试的概念和应用，界面测试、易用性测试、安装测试、兼容性测试、回归测试、冒烟测试、随机测试的含义

28 软件测试 其它 按阶段 逻辑功能测试 界面测试 是否运行 易用性测试 安装测试 是否查看源代码 兼容性测试 一般性能测试 稳定性测试 回归
单元测试 按阶段 集成测试 系统测试 验收测试 软件测试 静态测试 逻辑功能测试 是否运行 界面测试 易用性测试 动态测试 白盒 安装测试 是否查看源代码 功能 兼容性测试 黑盒 一般性能测试 性能 稳定性测试 回归 负载测试 其它 冒烟 随机 压力测试

29 黑盒测试 & 白盒测试 黑盒测试（black-box testing）：指的是把被测的软件看做是一个黑盒子，我们不关心里面的结构是什么样子的，只关心软件的输入数据和输出结果。 X=2 Y=4

30 黑盒测试 & 白盒测试 白盒测试（white-box testing）：指的是把被盒子盖打开，去研究里面的源代码和程序结构。 Y=2x

31 黑盒测试 & 白盒测试 在软件公司里，往往采用黑盒和白盒技术相结合的方法，对软件的整体功能和性能进行黑盒测试，对软件的源代码采用白盒测试。

32 静态测试 & 动态测试 静态测试（static testing）：指的是不实际运行被测软件，而只是静态的检查程序代码，界面或文档中可能存在的错误的过程。

33 静态测试 & 动态测试 （1）：代码测试：代码是否符合相应的标准和规范。 （2）：界面测试：软件的实际界面与需求是否相符。 静态测试
需要我们按照相应语言的代码规范模板来逐行检查程序代码。 （1）每个公司都有自己相应的编码规范。 （2）很多白盒测试工具中已经自动集成了各种语言的编程规范。 （3）：文档测试：用户手册和需求说明是否真正符合用户的实际需求。

34 静态测试 & 动态测试 例如：华为软件编程规范总则。

35 #include<stdio.h> max(float x, float y) { float z;
z = x > y ? x : y; return (z); } main() float a, b; int c; scanf(“%f, %f”, &a, &b); c = max(a, b); printf(“Max is: %d\n”, c); 注释 Max 返回类型 精度 c=max(a,b)

36 /* 程序名称：求两个实数中的最大值 作者：Bill Gates 版本：V 2.1 创建日期： */ #include<stdio.h> float Max(float fVar1, float fVar2) //返回两个实数中的最大值 { float fMaxVar; fMaxVar = fVar1 > fVar2 ? fVar1 : fVar2; return (fMaxVar ); } void main(void) float a; float b; float c; scanf(“%f, %f”, &a, &b); c = max(a, b); printf(“Max is: %d\n”, c);

37 静态测试 & 动态测试 动态测试：实际运行被测试程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以我们判断一个测试属于动态测试还是静态测试，唯一的标准是看是否运行程序。

38 静态测试 & 动态测试 静态测试，动态测试，黑盒测试，白盒测试之间的关系？ ---测试的不同分类角度而已。

39 其它重要测试 单元测试 集成测试 按测试阶段划分 系统测试 验收测试

40 什么是单元测试？ 单元测试（unit testing）：是指对软件中的最小可测试单元进行检查和验证。 C语言：？？？？
单元：人为规定的最小的被测功能模块。 过程 函数 对象 类 界面 窗口 Java语言：？？？？ 图形界面：？？？？

41 什么时候进行单元测试？ 程序员编码之后，代码已经通过编译后进行单元测试。测试前期，还要撰写单元测试计划，编写单元测试用例。

42 由谁来进行单元测试？ 白盒测试工程师或开发人员。若是开发人员来测试，最好做到交叉测试。避免即当裁判员，又到运动员。

43 单元测试的依据？ （1）源程序本身，代码 + 注释。 （2）《详细设计》文档。

44 单元测试的通过标准？ （1）程序通过所有的单元测试的用例。 （2）语句的覆盖率达到100%。 （3）分支的覆盖率达到85%。
语句的覆盖率：它只管覆盖代码中的执行语句，却不考虑各种分支的组合等等 代码覆盖率 ＝ 代码的覆盖程度，一种度量方式。

45 如何进行单元测试？ 单元测试：主要用白盒测试，先静态的检查代码是否符合规范，然后动态的运行代码，检查其实际运行结果，以及程序的非法数据的容错性，程序的边界处理等。

46 单元测试的一般步骤？ （1）编译运行程序：查看能否正确运行。 （2）静态测试。 《编码规范检查单》 （3）动态测试。 《测试用例》

47 什么是集成测试？ 集成测试（integration testing）：是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。 集成测试就是用来检查各个单元模块结合到一起能否协同配合，正常运行。 重点检测各个模块的接口部分，如函数之间的参数传递是否正确等。

48 什么时候进行集成测试？ 理论上，集成测试在单元测试之后。但： 效率太低。
实际： 单元测试和集成测试同步进行，在单元测试中先测试几个函数的功能，然后再集成测试一下这几个函数的接口（即参数传递）。

49 由谁来进行集成测试？ 白盒测试工程师或开发人员。

50 集成测试的依据？ （1） 单元测试模块。 （2）《概要设计》文档。

51 什么是系统测试？ 系统测试（system testing）：是指将整个软件系统看做1个整体进行测试，包括对功能，性能，以及软件所运行的软硬件环境进行测试。 主要由黑盒测试工程师在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性。

52 系统测试的特点？ （1）系统测试需要花大量的时间和精力去完成，也是软件交付给用户进行验收测试的最后一道关口。
（2）测试工作前松后紧，后期的系统测试的工作量是很大的。

53 系统测试的依据？ （1）《系统需求规格说明书》文档。

54 什么是验收测试？ 验收测试（acceptance testing）：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保证人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。 重要性：涉及到用户能否最终验收签字并付款。

55 软件项目运营？ （1）：客户支付项目总经费的20%作为定金。用于支付软件项目前期的开发成本和效益。
（2）：在项目的中期会有一个中期评审，客户通过中期评审来检查软件项目的进度和质量，通过中期评审，再付50%的经费。 （3）：通过最后的验收测试，再支付最终的30%。

56 Alpha测试：由用户、测试人员、开发人员共同参与的内部测试。 Beta测试：内侧后的公测，即完全交给最终用户测试。
验收测试 Alpha测试：由用户、测试人员、开发人员共同参与的内部测试。 验收测试 Beta测试：内侧后的公测，即完全交给最终用户测试。

57 测试名称 测试对象 测试依据 人员 测试方法 时间比例 白盒测试工程师，或开发人员 详细设计 主要采用白盒 1 最小模块 单元测试 模块间的接口 概要设计 白盒测试工程师，或开发人员 黑盒白盒结合 2 集成测试 整个系统 黑盒测试工程师 需求规格说明书 黑盒测试 4 系统测试 主要为用户，还可能有测试工程师 整个系统 需求规格说明书 黑盒测试 2 验收测试

58 功能测试 黑盒测试 逻辑功能测试。 界面测试。 功能测试 Function Test 易用性测试。 安装测试。 兼容性测试。 性能测试
检查实际软件的功能是否符合用户的需求。 界面测试。 功能测试 Function Test 易用性测试。 安装测试。 黑盒测试 兼容性测试。 性能测试 Performance Test

59 题1：为Xp系统中的计算器程序的加法功能编写逻辑功能测试用例。
Logic Function Test

60 界面测试 界面测试 User Interface Test

61 窗口中的数据能否用鼠标，功能键，方向键访问
界面测试—窗口 窗口能否改变大小，移动，滚动 窗口是否能正确的被关闭 窗口中的数据能否用鼠标，功能键，方向键访问 窗口的声音和颜色是否符合需求

62 界面测试—下拉菜单 下拉菜单能否正确工作 是否列出了所有菜单功能和下拉子菜单功能 是否可以通过鼠标访问所有菜单功能 文本，字体，大小是否合适
菜单功能的名字是否具有自解释性

63 界面测试—检查重点 （1）普通文字居左，状态居中，数字金额居右。 （2）检查输入非法字段时，系统处理是否合理。
（3）按TAB键，界面输入框是否按排列自上而下，自左而右的顺序获得焦点。 （4）处理时间较长（=>10S）,应给出提示或进度条。 （5）退出系统时，应提示。 （6）在保存数据修改，删除等不可恢复性操作时，应明确提示用户是否进行该操作。

64 从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。
易用性测试 易用性测试 Usability Test 从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。

65 易用性测试 易理解性 易用性测试 Usability Test 易学性 易操作性

66 易用性测试 常用的功能有无快捷方式 友好的软件联机帮助 工具栏图标准确表达操作意图 反馈时间较长的操作显示进度条
功能相同或相近的操作划分到一个区域 软件出现问题，要提供技术支持联系方式

67 安装测试 安装测试 Installation Test 检查软件能否正确的安装和卸载。

68 （1）典型安装，完全安装，自定义安装，检查安装步骤和界面 （5）从程序组，控制面板卸载，检查信息是否被成功删除。
安装测试 （1）典型安装，完全安装，自定义安装，检查安装步骤和界面 （2）突然中断安装，下次安装能否正确 （3）安装的时候磁盘空间不足 （4）能否安装一个软件的多个版本 （5）从程序组，控制面板卸载，检查信息是否被成功删除。 （6）卸载正在使用的程序

69 兼容性测试 硬件兼容性测试。 兼容性测试 Compatibility Test 软件兼容性测试。

70 单机版软件--兼容性测试 操作系统 测试优先级 Windows 98 ★ Windows 2000 Windows XP ★★★
Windows Vista ★★ Windows 7 Unix Linux

71 B/S版软件--兼容性测试 客户端 Internet Web服务器 DB服务器 IIS Tomcat Websphere SQL Sever
Oracle Sysbase Internet Web服务器 DB服务器

72 B/S版软件—服务器端配置 配置项 内容 服务器硬件 IBM 小型机 服务器操作系统 Linux 8.0 Web服务器
Websphere 4.0 数据库服务器 Oracle 9i

73 B/S版软件—客户0端配置 IE 6.0 IE 7.0 遨游 火狐 360 Windows Xp ★★ ★★★ ★
Windows Vista Windows 7 Mac Linux

74 性能测试 时间性能 性能测试 Performance Test 空间性能

75 时间性能： 主要指软件的一个具体事务的响应时间。
性能测试 时间性能： 主要指软件的一个具体事务的响应时间。 2S：非常有吸引力 标准 2/5/10 5S：比较不错 10S：用户忍受的上限

76 性能测试 空间性能： 软件运行时所消耗的系统资源。 最低配置 推荐配置 CPU 400M 1.2G 内存 128M 512M 硬盘 200M

77 性能测试 一般性能测试 稳定性测试 性能测试 负载测试 压力测试

78 让被测系统在正常的软硬件环境下运行，不像其施加任何压力的性能测试。
一般性能测试 让被测系统在正常的软硬件环境下运行，不像其施加任何压力的性能测试。 单机版：在推荐配置下运行软件，检查CPU的利用率，内存的占有率等性能指标以及软件主要事务的平均响应时间。 一般性能测试 CS/BS结构：测试单个用户登录后，系统主要事务的响应时间和服务器的资源消耗情况。

79 稳定性测试—Reliability Testing
连续运行被测系统，检查系统运行时的稳定程度。 MTBF：错误发生的平均时间间隔（Mean Time Between Failure）用来衡量系统的稳定性。该值越大越稳定。 稳定性测试 采用24 * 7（24小时 * 7天）的方式让系统不间断运行，具体运行多长时间，视项目实际情况而定。

80 让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
负载测试—Load Testing 让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。 负载测试，稳定性测试都是连续运行被测系统，两者的差别在何处？？？？？？？？？？？？？ 负载测试 施加刚好能承受的压力 1-5- 加用户 Cpu利用率90% 作用：为我们测试系统在临界状态下运行是否稳定提供了一种方法。

81 持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。
压力测试—Stress Testing 持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。

82 几种性能测试的比较 名称： 测试方法： 一般性能测试 背1袋米。 稳定性测试 背1袋米，在操场一直跑，看多久累倒。 负载测试
背2袋米，在操场一直跑，看多久累倒。 压力测试 背1袋米，2袋米，3袋米，4袋米。。。看最多能被多少袋米。

83 回归测试—Regression Testing
对软件的新的版本进行测试时，重复执行上一个版本测试时的用例。 回归测试可以在任何阶段进行，既有黑盒测试的回归，也有白盒测试的回归。

84 是指在对一个新版本进行系统大规模的测试之前，先验证一下这个软件的基本功能是否实现，是否具备可测性。
冒烟测试—Smoke Testing 是指在对一个新版本进行系统大规模的测试之前，先验证一下这个软件的基本功能是否实现，是否具备可测性。 冒烟测试名字的由来同电路板测试有关。 测试小组在正规测试一个新版本之前，先指派一两个测试人员测试一下软件的主要功能，如果没有实现的话，则打回开发组重新开发。节省大量的时间成本和人力成本。

85 随机测试（猴子测试—Monkey Testing）
是指测试中所有的输入数据都是随机产生的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

86 第三章：软件测试常识

87 公司里测试部门的组织结构 中国 1：9~~ 1：15 测试 Vs 开发 微软：1.5：1 国外 Borland：1：1

88 公司里测试部门的组织结构 40% 工作量 经费 30% 欧美软件项目

89 公司里测试部门的组织结构 比尔盖茨：“人们都说我们是世界上最大的软件开发公司，其实我们更是世界上最大的软件测试公司。”

90 （1）小公司 技术总监 项目经理 开发工程师 测试工程师:1到3名

91 （2）大公司

92 （3）测试外包公司 项目经理 测试组长 测试工程师

93 软件测试工程师所需的素质 细心 三心 耐心 信心 服务意识 三心二意一能力 二意 团队意识 一能力 沟通能力

94 软件测试工程师所需的素质 搭建黑盒测试环境 黑盒工程师 掌握黑盒测试技术 技术能力 白盒工程师 阅读代码

95 客户 测试经理 项目经理 测试工程师 开发人员

96 优秀测试工程师 大侠 高人指点 内功心法 江湖阅历 武术招式

97 优秀测试工程师 测试高手 名师指点 基础知识 项目经验 测试技术

98 软件测试工程师所需的素质 （1）不断学习充电。---与时俱进。 （2）阅读原版书籍。 （3）阅读缺陷报告。--前车之鉴，后事之师。
（4）阅读高手写的测试用例。--站在巨人的肩膀上会看的更远。 （5）学习产品相关的业务知识。

99 什么是SQA？ SQA（Software Quality Assurance—软件质量保证）：
为确保开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。

100 餐厅和项目组 餐厅 老板 当班经理 主厨 检验员 厨师 监督员

101 餐厅和项目组 项目组 老板 项目经理 系统架构师 测试员 程序员 SQA

102 SQA的定位？ SQA是独立于项目组之外的第三方监督机构，理论上，他的权力与项目经理平行，监督整个项目的管理，需求分析，设计，编码，测试与维护等软件工程的各个环节。

103 SQA要做的工作 （1）通过监控软件开发过程来保证产品质量。
（2）保证开发出来的软件和软件开发过程符合相应标准与规程。（ISO9000， CMM） （3）保证软件产品，软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者。 （4）确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要。

104 CMM？ CMM（Capability Maturity Model—能力成熟度模型），是由卡耐基-梅隆大学与20时机80年代制定的。CMM就是SQA用来监督项目的一个标准质量模型，SQA按照CMM上面各种规则来检验各种各样的项目。CMM共分为5级。 说明：质量模型不止一种，98年以前ISO9000比较火，2000以后，CMM比较受欢迎。

105 软件达到一定质量要求，就可以停止测试了。
软件测试的一些基本原则 Zero Bug 与 Good Enough Zero Bug 没有任何Bug Good Enough 软件达到一定质量要求，就可以停止测试了。

106 软件测试的一些基本原则 权衡投入/产出比原则。 不充分的测试—不负责任 Good Enough 过分的测试—资源的浪费
Zero Bug 与 Good Enough 权衡投入/产出比原则。 不充分的测试—不负责任 过分的测试—资源的浪费 Good Enough

107 软件测试的一些基本原则 （1）遗留Bug在10个以下，严重的Bug在5个以下。 （2）测试用例的执行率为100%，通过率为95%。
Good Enough通过标准 （1）遗留Bug在10个以下，严重的Bug在5个以下。 （2）测试用例的执行率为100%，通过率为95%。 （3）单元测试中，关键模块的语句覆盖率要达到100%，分支覆盖率要达到85%。

108 软件测试的一些基本原则 测试时考虑所有可能的输入值。--太耗费时间。 在测试用例上下功夫，用最少的测试用例达到最大的覆盖率。
不要试图穷举测试。 测试时考虑所有可能的输入值。--太耗费时间。 在测试用例上下功夫，用最少的测试用例达到最大的覆盖率。

109 软件测试的一些基本原则 开发人员不能既是运动员又是裁判员 测试应该由独立的第三方机构来完成。

110 软件测试的一些基本原则 （1）实践证明：需求分析阶段引入的缺陷是最多的，修复成本确是最低的。
软件测试要尽早执行 （1）实践证明：需求分析阶段引入的缺陷是最多的，修复成本确是最低的。 （2）测试需求说明是否真正符合用户的需要，测试设计是否严格按照需求说明的要求。可以减少后期测试和维护的工作量。

111 软件测试的一些基本原则 软件测试要尽早执行 1 需求 3-6 设计 10 编码 15-40 测试 30-70 系统测试 维护

112 原始要求 软件测试要追溯需求 正确的规格说明书 错误的规格说明书 正确的设计 错误的设计 对错误的说明的设计 正确的编码 错误的编码
对错误设计编码 对错误说明编码 正确功能 可改正错误 不开改正错误 潜伏的错误

113 软件测试的一些基本原则 缺陷的二八定理 一般情况下，软件80%的缺陷集中在20%的模块中，测试的时候抓住主要矛盾。重点测试。--缺陷的集群现象或是虫子窝现象。

114 软件测试的一些基本原则 缺陷具有免疫性 程序员在修改完缺陷，把新版本提交给测试人员进行回归测试，测试用例依然用相同的，效果会大大折扣。--测试人员根据新版本的特点，修改维护测试用例。 每修复3—4个缺陷，一般就会产生一个新的缺陷，所以要充分注意修改错误所产生的影响和波及效果。

115 黑盒测试 115

116 要点 等价技术 边界值技术 因果图技术 业务流程图技术

117 （1）等价类技术（Equivalence Class Testing）
等价类划分是一种黑盒测试技术，它不考虑程序的 内部结构，只是根据软件的需求说明来对输入的范围进 行细分，然后再从分出来的每一个区域内选取一个代表 性的测试数据。如果等价类划分的好，这个代表性的测 试数据的作用就等价于其区域内的其它值。 等价类：是指某个输入域的子集合。在该子集合 中，各个输入数据对于揭露程序中的错误都是 等效的。 117

118 （1）等价类技术 有效等价类 合理的输入数据集合 等价类 无效等价类 无意义的输入数据集合 118

119 （1）等价类技术 题1：有一个C语言程序，其功能为计算两个1~100之间 （包括1和100）的整数的和。请构建其等价类划分。 119

120 （1）等价类技术 <1的整数 （如-9，-19，-2等） 1~100的整数 （如4，7，87等） >100的整数
（如400，107等） 无效等价类1 有效等价类2 无效等价类3 120

121 （1）等价类技术 <1的整数---1 整数 1~100整数---2 数值 >100整数---3 小数---4 加数 字母---5
特殊字符---6 空格---7 非数值 空白---8 121

122 （1）等价类技术 用例编号 所属等价类 加数1 加数2 结果 1 -8 -9 “输入有误！” 2 23 56 79 3 102 199 4
1.36 69.3 5 A b 6 $ % 7 8 122

123 （1）先考虑输入数据的数据类型。---合法类型 & 非法类型。
（1）等价类技术 （1）先考虑输入数据的数据类型。---合法类型 & 非法类型。 （2）合法类型中的合法区间和非法区间。 （3）画出示意图，区分等价类。 （4）为每一个等价类编号。 （5）从一个等价类中选举一个测试数据构造测试用例。 123

124 （2）边界值技术(Boundary Value Testing)
“错误隐含在角落”，大量的测试实践经验表明， 边界值是最容易出现错误的地方，也是我们测试的 重点。 测试边界值时，一般测试边界值和正好超出边界 值一个单位的值。 124

125 （2）边界值技术 用例编号 加数1 加数2 结果 1 2 100 200 3 “输入有误！” 4 101 125

126 （3）因果图法 所谓原因，指的就是输入；所谓结果，指的就是输 出。因果图法比较适合输入条件比较多的情况，测 试所有的输入条件的排列组合。
126

127 （3）因果图法 题2：某奖金计算软件完成如下功能： （1）该软件可以计算某公司的年终奖，该公司员工分为普通员工 和管理人员。
（2）员工表现分为普通，优秀和特殊贡献奖。（普通员工和优秀 员工都可以有特殊贡献，普通员工和管理人员表现相同，但工资是 不同的）。 （3）根据员工的分类和表现，将奖金分为1类奖金，2类奖金，3类 奖金……。输入员工类型和表现，就会输出相应的奖金类别。 编写测试用例？ 127

128 （3）因果图法 普通员工A1 员工类别 管理人员A2 普通B1 表现类别 优秀B2 特殊贡献B3 1类奖金C1 奖金类别 2类奖金C2
……………… 128

129 （3）因果图法 原因 结果 A1 + B1====（普通员工表现普通） C1==1类奖金 A1 + B2====（普通员工表现优秀）
A1 + B1 + B3====（普通员工表现普通，且有特殊贡献） C3==3类奖金 A1 + B2 + B3====（普通员工表现优秀，且有特殊贡献） C4==4类奖金 A2 + B1====（管理人员表现普通） C5==5类奖金 A2 + B2====（管理人员表现优秀） C6==6类奖金 A2 + B1 + B3====（管理人员表现普通，且有特殊贡献） C7==7类奖金 A2 + B2 + B3====（管理人员表现优秀，且有特殊贡献） C8==8类奖金 129

130 （3）因果图法 （1）找出所有输入条件和输出条件，并编号 （2）分析输入条件之间的关系，是互斥 还是可以同时满足。
（3）画出输入条件的排列组合情况。 （4）编写测试用例。 130

131 （3）因果图法 应用场合：当软件的输入条件较多的时候，可以考 率用因果图法来设计测试用例。考虑输入的所有 排列组合情况，防止遗漏。
因果图的局限性：假如有n个条件。每个条件有真 或假两种取值，理论上就有2的n此方种排列组合。 大大增加了测试用例的个数，不便于维护。 131

132 （4）流程图法 在编程的时候我们要画算法流程图，将这一思想应 用到黑盒测试领域。黑盒测试的流程图针对整个系统 业务功能流程的。 132

133 （4）流程图法 （1）详细了解需求。 （2）根据需求说明或界面原型，找出 业务流程的各个页面以及流转关系。 （3）画出业务流图，或路径图。
（4）编写测试用例，覆盖所有的路径分支。 133

134 （4）流程图法 题3：画出淘宝网站购物业务流程，并依据此业务 流程编写测试用例，进行测试？ 134

135 购物模块业务流程图 登录 身份验证 退出 查询商品 选择商品 网上付款 出货

136 （5）综合 在实际测试中，我们往往需要综合各种测试技术？ 我们首先应用流程图法画出被测软件的总体业务流
程，然后针对具体某个页面或是模块，再应用等价 类的思想来划分输入范围（重点测试边界值），如果 涉及多个输入条件的组合情况，在应用因果图法来 考虑所有情况的排列组合。 136

137 题4：计算三角形面积程序功能：输入三个整数A，B C，输出以ABC为边的三角形的面积（ABC在【1， 100】之间）， 结果保留两位小数。
编写测试用例。 137

138 第五章 缺陷管理

139 一般的缺陷管理工具会自动给出一个默认的Bug严重程度划分。
系统崩溃 严重 按严重程度划分：是指Bug对软件质量的破坏程度，即此Bug的存在将对软件的功能和性能产生什么样的影响。 按严重程度划分 一般 次要 建议 一般的缺陷管理工具会自动给出一个默认的Bug严重程度划分。

140 时间允许该修改的，或可以暂时存在的Bug
高 按优先级划分：表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。 按优先级划分 在产品发布之前修复的Bug 中 时间允许该修改的，或可以暂时存在的Bug 低

141 Bug的分类 Bug的严重程度和优先级是含义不同但相互联系密切的两个概念，从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

142 （1）如果某个严重的缺陷只在非常极端的条件下产生，则没有必要马上解决。 （2）若修正一个缺陷，要修改软件的整体架构，可能产生更多缺陷。
Bug的分类 严重程度高，优先级一定高？ （1）如果某个严重的缺陷只在非常极端的条件下产生，则没有必要马上解决。 （2）若修正一个缺陷，要修改软件的整体架构，可能产生更多缺陷。

143 例如软件名称或公司名称的拼写错误，随属于界面错误，不严重，但关系公司形象，必须尽快修正。
Bug的分类 严重程度低，优先级不一定低？ 例如软件名称或公司名称的拼写错误，随属于界面错误，不严重，但关系公司形象，必须尽快修正。

144 按照测试种类分类，可让我们了解不同测试方法所能发现的Bug比例，使测试的时候有所重点。
逻辑功能类 性能类 界面类 按测试种类划分 边界值类 内存溢出类 …………………… 按照测试种类分类，可让我们了解不同测试方法所能发现的Bug比例，使测试的时候有所重点。

145 Bug的分类 按功能模块划分 一般的软件产品都是分为若干功能模块的。二八定理。统计Bug主要集中在哪个功能模块里面，后面投入重点精力去测试。

146 Bug的分类 新建 确认 把Bug当做一个小虫子，它也有生存和死亡的生命周期。 按生命周期划分 解决 关闭 重新打开

147 Bug的分类 新建 确认 已解决 重新打开 关闭

148 缺陷报告 缺陷报告把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。 在软件测试过程中，缺陷报告起到了一个交接单的作用，它帮助开发人员和测试人员之间更有效的交流，提高了缺陷的解决速度和质量。同时也可以通过统计bug数来对被测的软件进行质量评估。

149 缺陷报告

150 缺陷报告

151 提交测试报告的注意事项 （1）确保重现Bug。严重错误重复测试两次以上。 （2）用最少且最必要的步骤描述Bug。
（3）简介，准确，完整。尽量使用中性词语。 （4）一个Bug一个缺陷报告。--便于Bug分配，便于回归测试。

152 Bug的处理流程 提交缺陷报告 分配缺陷报告 重复？ 重新打开 Bug？ 推迟？ 推迟处理 处理缺陷报告 反测缺陷报告 完成？ 关闭缺陷报告

153 常见缺陷管理工具 （1）一个软件项目只有几十个缺陷 ---Excel缺陷报告模板。 （2）一个软件项目有几百个缺陷
---缺陷管理工具集中管理。